The metadata repository stores metadata, authorizes access, and enforces the consistency of stored data, whereby the metadata storage component is a relational database built on top of Microsoft SQL Express 2005. This metadata describes objects that are exposed within Microsoft Office and their related UIs and associated actions, and is being pulled by the client, based on the user and his or her role(s) within the organization. The Microsoft Exchange handle, on the other had provides an application-friendly and user-friendly view of messages in Microsoft Exchange. It addresses the conversion of standardized messages from the backend server into Outlook objects, such as IPM.Note. The handler provides an independent layer to different versions and formats of messages, so that calling components do not have to address the versions and formats of Office objects or command messages for the client add-on. The Exchange handler provides interfaces to the most important objects within Microsoft Office, including e-mail (IPM.Note), e-mail attachments, the calendar, tasks, and contacts.
Last but not least, the service bundling component hides the implementation details and distributes incoming calls to Duet-specific Web services or SAP ESA services, or any combination thereof. The criteria that determine which component will be used during implementation is based on the method that can best support the respective use cases within the application. The service bundling component also implements a method to resolve any Duet-specific IDs toward SAP item IDs where necessary. It is anticipated that the vast majority of these services will be executed synchronously for functionality, such as data validation and displaying information in action panes. In case of asynchronous[2] calls, the service bundling component will always reply with an acknowledgment confirmation and then route the reply through the Exchange handler back to the client. An example of such an asynchronous call can be found in team management when requesting all organization contacts for a given user.
In addition to these components, Duet Extensions also include a number of so-called "pluggable services" that interact with existing technology to enable user roles, authentication, security, and reporting, and provide a set of tools for configuration and customization. The pluggable services enable integration with preexisting technologies and provide functionality, such as user roles, authentication, security, and reporting. Since these capabilities are not Duet-specific, customers should be able to deploy any of these services from different vendors that support these standardized interfaces. It should also be possible to reuse existing solutions already installed on site.
Apparently, Duet Extensions can handle all communication between the client and the underlying SAP ERP system, because Duet Extension can gather the context and define the objects that are exposed to the user. Thus, those extensions invoke the relevant underlying SAP ESA services to talk to the underlying applications within the SAP ERP environment. As described previously in some cases, the responses may be handled asynchronously. To accomplish this, Duet Extensions transmit the data back to the local client through the Exchange handler, which completes a simple round trip of data from the UI within an action pane to the SAP ERP system and back.
The metadata that is available on the client resides within Duet Extensions, whose server also acts as a consolidation engine. Most businesses have an IT landscape using a number of different SAP systems, such as an SAP BW, SAP ERP, SAP CRM, SAP SCM (Supply Chain Management), or any number of non-SAP solutions. The Duet Extensions server unites one or more of these backend systems, by taking the metadata from various underlying systems and combining them based on the user and the user's role within the organization, and pushing it down to the client. As the users might not always be online, Duet must be careful in the way it communicates information back to the client, and additional queuing and caching may be required in the Extensions. The data is communicated from SAP ERP into the Exchange handler, which properly formats the information into an extensible markup language (XML) document (or a format that the client can then understand).
If a report is needed, information needs to be converted into a hypertext markup language (HTML)-based email, maybe with some kind of attachment. It also requires flagging the report with specific metadata that is not visible to the end user, but is rather attached to the e-mail body. This enables certain kinds of processes once it reaches the client environment. The client then interprets the metadata and dynamically combines it into the UI screen before presenting the notification of the report to the user (e.g., the final budget status notification). The rules gathered from the back-end system are converted into metadata that the client can understand, and the gap between the two systems is bridged. Because Duet is role sensitive, information presented and executions available to the end user depend on the user's role within the organization (whether the user is an employee or a manager, for example).
The Role of Microsoft Office Add-On
Further, the Microsoft Office Add-On enables communication between the local Microsoft Office client with the Duet Extensions and the SAP system through a metadata portal and storage interface. In other words, the Office Add-On, also known as the Duet Client, represents the Office screen add-ons based on metadata, since it uses the master data for drop-down menus or business rules and then triggers activities in the principal SAP system through either synchronous or asynchronous Web services calls. Metadata descriptions of the various applications are interpreted through the engine, which supports integration with various kinds of host software. The engine also provides Outlook integration, personalization, Excel integration, InfoPath (recently renamed into Windows Workflow Foundation [WF]) integration, and metadata-defined forms. Duet also supports SAP Business Workflows through Microsoft Outlook.
In order to illustrate how data is routed through the Duet architecture, one needs to understand that a typical Microsoft Office user often creates status reports of one kind or another. Using Duet, this process is accelerated since the Office interface already shows which reports an information worker can subscribe to, and offers templates for creating new ones (e.g., a budget report needs to be delivered every Monday morning at 9 a.m., or the project manager wants an alert only after the project has reached 80 percent of total budget consumption). All of these kinds of activities can be done using the local client, in which case it is Microsoft Office combined with Duet.
The Client or Office Add-On is responsible for representing the UI, based on metadata and other kinds of desktop information. For this purpose, the Client/Add-On is separated into three major parts: 1) runtime engine; 2) cashing mechanism; and 3) output queue.
The runtime engine interprets metadata in order to understand which business object is being exposed (a budget report, leave request or time entry, for example). Through these exposed objects, the Office Add-On is able to create subclasses of the existing objects within Microsoft Office. For instance, a "time entry" would then be treated as a subclass of an "appointment" object, and these classes would be exposed through the UI within the action pane environment. In addition to describing objects, the metadata also describes the UI screen and actions that can be triggered from within the user screen. This additional metadata, available on the client side, includes both generalized personalization data and some master data. The generalized personalization data, for example, determines which fields become available in the action pane, whereas the master data, for example, determines which project's budget is being assessed or the default status report profile. The engine's metadata form definition component is the primary method used to customize Duet forms and dialogs, whereby administrator users, using a metadata definition, can customize the action pane, custom dialogs, or Outlook custom forms. This level of customization also enables easy text replacement and user screen fields localization.
The caching mechanism is responsible for maintaining the proper metadata on the client machine, and is based on the user's role and supplies the functionality to store a user's metadata based on user role and data instances. It also stores metadata in a secure manner, and provides access to metadata when disconnected from the Duet server. Furthermore, the cache includes deployment capabilities that deliver application assemblies proactively to a user's machine. Last but not least, the cache provides offline data retrieval for the Duet by switching between the offline store or to the online Duet server when accessing data by using hints from either metadata parameters or other configuration information. The cache component also provides the first-time provisioning and deployment of reference data, reference data expiration refresh rules, and local data storage. In summary, the caching component ensures that metadata, master data, and additional files and objects are kept available locally and are up-to-date. The component is able to store this data on the local client without the need to continuously synchronize and resynchronize with the backend SAP ESA services. And by inserting a validity period into that, Duet can always keep the data cache up-to-date with regards to changes from the back-office system. It is not so much a push for updated information, but rather a pull from it, which should also speed up the end-to-end communication by preloading some of the data that the underlying system will request.
The third component of the Client, the output queue, provides the functionality to enable users to initiate actions while being offline, which are then invoked whenever a connection becomes available. The output queue component is invoked when a user triggers an activity, such as saving a time entry. It then takes the selected business object and triggers activities in the underlying SAP ERP system through either synchronous, or asynchronous Web services calls, which then come into the SAP environment within the Duet Extensions, through the abovementioned service bundling component. This component allows the Duet to compose multiple underlying Web services into a single one for, say, performance improvement, or for using the result of a first call for a second call.
Queued actions are serviced as soon as possible. If online, these calls are serviced in short time intervals; if off-line, the calls are stored for invocation later. Logically, the output queue is used only for asynchronous calls, and to support this functionality, the output queue provides interfaces to be able to "flush the queue" when the backend server is available. Calls made by the output queue to the service bundling component in the backend system will generally respond synchronously with acknowledge confirmation. Duet supports the deployment of applications to the client machine as complete units containing the metadata, assemblies, additional required client components, and reference data required to execute the application. This will occur automatically through a deployment mechanism and includes upgrade control in the form of versioning.
Last but not least, the service bundling component hides the implementation details and distributes incoming calls to Duet-specific Web services or SAP ESA services, or any combination thereof. The criteria that determine which component will be used during implementation is based on the method that can best support the respective use cases within the application. The service bundling component also implements a method to resolve any Duet-specific IDs toward SAP item IDs where necessary. It is anticipated that the vast majority of these services will be executed synchronously for functionality, such as data validation and displaying information in action panes. In case of asynchronous[2] calls, the service bundling component will always reply with an acknowledgment confirmation and then route the reply through the Exchange handler back to the client. An example of such an asynchronous call can be found in team management when requesting all organization contacts for a given user.
In addition to these components, Duet Extensions also include a number of so-called "pluggable services" that interact with existing technology to enable user roles, authentication, security, and reporting, and provide a set of tools for configuration and customization. The pluggable services enable integration with preexisting technologies and provide functionality, such as user roles, authentication, security, and reporting. Since these capabilities are not Duet-specific, customers should be able to deploy any of these services from different vendors that support these standardized interfaces. It should also be possible to reuse existing solutions already installed on site.
Apparently, Duet Extensions can handle all communication between the client and the underlying SAP ERP system, because Duet Extension can gather the context and define the objects that are exposed to the user. Thus, those extensions invoke the relevant underlying SAP ESA services to talk to the underlying applications within the SAP ERP environment. As described previously in some cases, the responses may be handled asynchronously. To accomplish this, Duet Extensions transmit the data back to the local client through the Exchange handler, which completes a simple round trip of data from the UI within an action pane to the SAP ERP system and back.
The metadata that is available on the client resides within Duet Extensions, whose server also acts as a consolidation engine. Most businesses have an IT landscape using a number of different SAP systems, such as an SAP BW, SAP ERP, SAP CRM, SAP SCM (Supply Chain Management), or any number of non-SAP solutions. The Duet Extensions server unites one or more of these backend systems, by taking the metadata from various underlying systems and combining them based on the user and the user's role within the organization, and pushing it down to the client. As the users might not always be online, Duet must be careful in the way it communicates information back to the client, and additional queuing and caching may be required in the Extensions. The data is communicated from SAP ERP into the Exchange handler, which properly formats the information into an extensible markup language (XML) document (or a format that the client can then understand).
If a report is needed, information needs to be converted into a hypertext markup language (HTML)-based email, maybe with some kind of attachment. It also requires flagging the report with specific metadata that is not visible to the end user, but is rather attached to the e-mail body. This enables certain kinds of processes once it reaches the client environment. The client then interprets the metadata and dynamically combines it into the UI screen before presenting the notification of the report to the user (e.g., the final budget status notification). The rules gathered from the back-end system are converted into metadata that the client can understand, and the gap between the two systems is bridged. Because Duet is role sensitive, information presented and executions available to the end user depend on the user's role within the organization (whether the user is an employee or a manager, for example).
The Role of Microsoft Office Add-On
Further, the Microsoft Office Add-On enables communication between the local Microsoft Office client with the Duet Extensions and the SAP system through a metadata portal and storage interface. In other words, the Office Add-On, also known as the Duet Client, represents the Office screen add-ons based on metadata, since it uses the master data for drop-down menus or business rules and then triggers activities in the principal SAP system through either synchronous or asynchronous Web services calls. Metadata descriptions of the various applications are interpreted through the engine, which supports integration with various kinds of host software. The engine also provides Outlook integration, personalization, Excel integration, InfoPath (recently renamed into Windows Workflow Foundation [WF]) integration, and metadata-defined forms. Duet also supports SAP Business Workflows through Microsoft Outlook.
In order to illustrate how data is routed through the Duet architecture, one needs to understand that a typical Microsoft Office user often creates status reports of one kind or another. Using Duet, this process is accelerated since the Office interface already shows which reports an information worker can subscribe to, and offers templates for creating new ones (e.g., a budget report needs to be delivered every Monday morning at 9 a.m., or the project manager wants an alert only after the project has reached 80 percent of total budget consumption). All of these kinds of activities can be done using the local client, in which case it is Microsoft Office combined with Duet.
The Client or Office Add-On is responsible for representing the UI, based on metadata and other kinds of desktop information. For this purpose, the Client/Add-On is separated into three major parts: 1) runtime engine; 2) cashing mechanism; and 3) output queue.
The runtime engine interprets metadata in order to understand which business object is being exposed (a budget report, leave request or time entry, for example). Through these exposed objects, the Office Add-On is able to create subclasses of the existing objects within Microsoft Office. For instance, a "time entry" would then be treated as a subclass of an "appointment" object, and these classes would be exposed through the UI within the action pane environment. In addition to describing objects, the metadata also describes the UI screen and actions that can be triggered from within the user screen. This additional metadata, available on the client side, includes both generalized personalization data and some master data. The generalized personalization data, for example, determines which fields become available in the action pane, whereas the master data, for example, determines which project's budget is being assessed or the default status report profile. The engine's metadata form definition component is the primary method used to customize Duet forms and dialogs, whereby administrator users, using a metadata definition, can customize the action pane, custom dialogs, or Outlook custom forms. This level of customization also enables easy text replacement and user screen fields localization.
The caching mechanism is responsible for maintaining the proper metadata on the client machine, and is based on the user's role and supplies the functionality to store a user's metadata based on user role and data instances. It also stores metadata in a secure manner, and provides access to metadata when disconnected from the Duet server. Furthermore, the cache includes deployment capabilities that deliver application assemblies proactively to a user's machine. Last but not least, the cache provides offline data retrieval for the Duet by switching between the offline store or to the online Duet server when accessing data by using hints from either metadata parameters or other configuration information. The cache component also provides the first-time provisioning and deployment of reference data, reference data expiration refresh rules, and local data storage. In summary, the caching component ensures that metadata, master data, and additional files and objects are kept available locally and are up-to-date. The component is able to store this data on the local client without the need to continuously synchronize and resynchronize with the backend SAP ESA services. And by inserting a validity period into that, Duet can always keep the data cache up-to-date with regards to changes from the back-office system. It is not so much a push for updated information, but rather a pull from it, which should also speed up the end-to-end communication by preloading some of the data that the underlying system will request.
The third component of the Client, the output queue, provides the functionality to enable users to initiate actions while being offline, which are then invoked whenever a connection becomes available. The output queue component is invoked when a user triggers an activity, such as saving a time entry. It then takes the selected business object and triggers activities in the underlying SAP ERP system through either synchronous, or asynchronous Web services calls, which then come into the SAP environment within the Duet Extensions, through the abovementioned service bundling component. This component allows the Duet to compose multiple underlying Web services into a single one for, say, performance improvement, or for using the result of a first call for a second call.
Queued actions are serviced as soon as possible. If online, these calls are serviced in short time intervals; if off-line, the calls are stored for invocation later. Logically, the output queue is used only for asynchronous calls, and to support this functionality, the output queue provides interfaces to be able to "flush the queue" when the backend server is available. Calls made by the output queue to the service bundling component in the backend system will generally respond synchronously with acknowledge confirmation. Duet supports the deployment of applications to the client machine as complete units containing the metadata, assemblies, additional required client components, and reference data required to execute the application. This will occur automatically through a deployment mechanism and includes upgrade control in the form of versioning.
0 comments
Post a Comment