Despite seemingly simple processes that Duet enables, the product exemplifies how serious an undertaking a commercially available composite application can be. When the goals of Project Mendocino (now Duet) were first formulated, it reportedly[1] became clear that two very different architectures needed to be brought together. On the one side was the ubiquitous client application, which required local data storage, while on the other side was the proverbially complex SAP ERP environment. The different technologies in this case reportedly made it quite easy to select Web services as the interface technology, since both camps added standards-based Web services support in their last releases. However, in this case, simply connecting these two worlds using Web services did not offer a comprehensive enough solution. Namely, the goals required more extensibility, because SAP wanted to enable a model-driven environment on the client side, which would allow Duet to push additional screens and updates to the user without the need to continuously run through an installation and reinstallation whenever business needs changed.
On top of that, Microsoft Office currently works in online as well as offline modes. This capability had to be maintained in Duet as well, since users had to be able to trigger activities while being offline which would later have to be automatically resynchronized once their machines went back online. At the time, Microsoft and SAP also realized that the involved disparate system components (i.e., Microsoft Exchange Servers, Microsoft Office, and SAP ERP systems) are of such a high value to customers that massively updating those environments (and exposing the existing system landscape to any unnecessary disruption) would be unacceptable. SAP and Microsoft weighed these requirements carefully and realized that there was a the need for a communications hub that would sit in the middle of the two existing environments and "mediate" communication and processes. The hub collects various configurations from the back-end system, determines the objects that should be exposed, and decides which activities the user can trigger and how all of that ties together within the user screen. The communications hub is also referred to as the Duet Extensions, which are connected with the Microsoft Office client and the SAP ERP system. The result is that there are three primary parts to Duet's architecture: 1) the Duet Extensions; 2) the Microsoft Office Add-On; and 3) SAP ERP foundation.
On top of that, Microsoft Office currently works in online as well as offline modes. This capability had to be maintained in Duet as well, since users had to be able to trigger activities while being offline which would later have to be automatically resynchronized once their machines went back online. At the time, Microsoft and SAP also realized that the involved disparate system components (i.e., Microsoft Exchange Servers, Microsoft Office, and SAP ERP systems) are of such a high value to customers that massively updating those environments (and exposing the existing system landscape to any unnecessary disruption) would be unacceptable. SAP and Microsoft weighed these requirements carefully and realized that there was a the need for a communications hub that would sit in the middle of the two existing environments and "mediate" communication and processes. The hub collects various configurations from the back-end system, determines the objects that should be exposed, and decides which activities the user can trigger and how all of that ties together within the user screen. The communications hub is also referred to as the Duet Extensions, which are connected with the Microsoft Office client and the SAP ERP system. The result is that there are three primary parts to Duet's architecture: 1) the Duet Extensions; 2) the Microsoft Office Add-On; and 3) SAP ERP foundation.
No comments:
Post a Comment