Section 9.4. The Project Mendocino architecture
9.4. The Project Mendocino architectureWhen the goals of Project Mendocino were first formulated, it became clear that two very different architectures needed to be brought together. On the one side was the client application, which requires local data storage. On the other side was the mySAP ERP environment. The different technologies in this case made it very easy to select web services as the interface technology, since both technologies added web services support in their last releases. However, simply connecting these two worlds using web services did not offer a comprehensive enough solution, in this case. The goals required more extensibilitySAP wanted to enable a model-driven environment on the client side. The model-driven environment is what allows Project Mendocino to push additional screens and updates to the user without the need to continuously run through an installation and reinstallation for every change in business needs. On top of that, Microsoft Office currently works in online as well as offline modesand that capability had to be maintained in Project Mendocino. The users had to be able to trigger activities while being offline and have them automatically resynchronize once their machines went back online. Microsoft and SAP also realized that the system components involvedExchange Servers, Microsoft Office, and mySAP ERP systemsare of such a high value to customers that massively updating those environments would not be acceptable. There is no reason to expose the existing system landscape to any unnecessary disruption. SAP and Microsoft weighed these requirements carefully and realized the need for a communications hub that would sit in the middle of the two existing environments. The hub is used to collect various configurations from the backend system, determine the objects that should be exposed, and decide which activities the user can trigger and how all of that ties together in the UI. That communications hub is the Mendocino extensions. The Mendocino extensions then had to be connected with the Microsoft Office client and the mySAP ERP system. The result is that there are three primary parts to Project Mendocino's architecture (see Figure 9-9): the Mendocino extensions, the Microsoft Office Add-On, and mySAP ERP. Figure 9-9. Project Mendocino architecture 9.4.1. What makes up the Mendocino extensions?The Mendocino extensions are implemented in .NET as well as by using Java 2 Enterprise Edition (J2EE) technology. The Mendocino extensions sit between the client and the mySAP systems and enable these two to talk with each other. On top of that, the Mendocino extensions include the application description in the form of metadata and cater the metadata to the client. The major components of the Mendocino extensions include:
9.4.2. What is the Office Add-On?The Microsoft Office Add-On enables communication between the local Microsoft Office client with the Mendocino extensions and the mySAP system through a metadata portal and storage interface. The major components of the Office Add-On include:
We will discuss these mechanisms in more detail next. 9.4.3. How is data routed through the Project Mendocino architecture?A typical Microsoft Office user often creates status reports of one kind or another. Using Mendocino, 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. Perhaps a budget report needs to be delivered every Monday morning at 8:00, to be used in a staff meeting at 10:00 a.m. Later, as the inbox overflows with reports, that might need fine-tuning. Now the user wants an alert only after reaching 80 percent of total budget consumption. All of these sorts of activities can be done using the local clientin this case, Microsoft Office combined with Project Mendocino. The client's 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: engine, output queue, and cache. The runtime engine interprets metadata in order to understand which business object is being exposed (a budget report or time entry, for example). Through these exposed objects, the Office Add-On is able to create subclasses of the existing objects within Microsoft Officea time entry would then be treated as a subclass of an appointment object. These cases are exposed through the UI within the action pane environment. In addition to describing objects, the metadata also describes the UI as well as actions that can be triggered from within the UI. This additional metadata, available on the client side, includes both generalized personalization data as well as some master data. The generalized personalization data, for example, determines which fields become available in the action pane. The master data, for example, determines which project's budget is being assessed or the default status report profile. The caching component ensures that metadata, master data, and additional files and objects are being kept available locally and are up-to-date. The cache is able to store this data on the local client without the need to continuously synchronize and resynchronize with the backend ESA services. And by inserting a validity period into that, Project Mendocino can always keep the data cache up-to-date with regard to changes from the backend system. It's not so much a push of the updated information but more of a pull from it. This also dramatically speeds up the end-to-end communication by preloading some of the data that the underlying system will request. The Office Add-On includes features that allow for offline processing. This is being enabled through the output queue component. 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 mySAP system through either synchronous or asynchronous web services calls. Those web services calls then come into the SAP environment within the Mendocino extensions, through the service bundling component. This component allows Project Mendocino 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. The Mendocino extensions handle all of the communication between the client and the underlying mySAP ERP system. They gather the context and define the objects that are being exposed to the end user. So the Mendocino extensions invoke the relevant underlying ESA services to talk to the underlying applications within the mySAP ERP environment. In some cases, the responses might actually not be handled synchronously, but asynchronously. For this, the Mendocino extensions communicate the data back to the local client by means of the Exchange handler. This completes a simple round trip of data from the UI within an action pane to the mySAP ERP system and back. The metadata that is available on the client resides within the Mendocino extensions. This server also acts as a consolidation engine. Most businesses have an IT landscape using a number of different SAP systemsan SAP Business Information Warehouse (SAP BW) system, mySAP/ERP, CRM, Supply Chain Management (SCM), or any number of other solutions that might not even be coming from SAP. The Mendocino Server coalesces one or multiple backend systems. It takes the metadata from various underlying systems and combines it based on the user and the user's role within the organization, and pushes it down to the client. Remember that the client might not always be online, and Project Mendocino must be careful in the way it communicates information back to the client. Additional queuing and caching may be required in the Mendocino extensions. The data is communicated from mySAP ERP into the Exchange handler, which properly formats the information into an XML documenta format that the client can then understand. In the case of a report, that means converting it into an 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 attached to the email body to enable certain kinds of processing once it reaches the client environment. The client interprets the metadata and dynamically combines it into the UI before presenting the final budget status notification to the end user. The rules gathered from the backend system are converted into metadata that the client can understand, and the gap between the two systems is bridged. Project Mendocino is role sensitive. This means that the information which is being presented and the actions 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). 9.4.4. What are the system requirements for using the Project Mendocino architecture?The client runs on Microsoft Windows XP with Microsoft Office 2003 installed. The Mendocino extensions require Microsoft Windows Server 2003 or higher and Microsoft Exchange Server 2003 or higher, including Active Directory 2000. There are no additional installation, software, or hardware requirements for existing Exchange Server landscapes. 9.4.5. What is the primary function of the Office Add-On?The Office Add-On, also known as the client, represents the UI based on metadata. It uses the master data for drop-down menus or business rules and then triggers activities in the underlying SAP system through either synchronous or asynchronous web services calls. The metadata descriptions of the various applications are interpreted through the engine, which supports integration with various kinds of host software. The engine also provides:
The web services calls from the Office Add-On are relayed into the SAP environment (this occurs within the Mendocino extensions, through the service bundling component). The engine on the client loads assemblies and metadata from the cache and interprets the metadata descriptions of applications to:
The runtime engine uses an Outlook services library (using the standard programming features of Outlook) to allow the integration of the following features and services:
The engine's metadata form definition component is the primary way to customize Project Mendocino forms and dialogs. 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 UI localization. The cache is responsible for maintaining the proper metadata on the client machine. It is based on the user's role and supplies the functionality to store a user's metadata based on user role and data instances, stores metadata in a secure manner, and provides access to metadata while disconnected from the Mendocino server. Furthermore, the cache includes deployment capabilities (described later) to have application assemblies proactively delivered to a user's machine. Last but not least, the cache provides offline data retrieval for Mendocino. It allows for the switching of access to data to the offline store or to the online Mendocino server, depending on 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 storage of data locally. The third component of the client, the output queue, provides the functionality to allow users to initiate actions while offline, which are then invoked whenever a connection becomes available. Queued actions will be serviced as soon as possible. If online, these calls are serviced in short intervals of time; if offline, the calls are stored for invocation later. The output queue is used only for asynchronous calls. 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. Mendocino will support 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. 9.4.6. What are the functions of the Mendocino extensions components?The Mendocino extensions include components for the metadata repository, Exchange handler, and service bundling. The metadata repository stores the metadata, authorizes access, and enforces consistency of the stored data. The metadata storage component is a relational database built on top of SQL Express 2005. This metadata describes the objects that are exposed within Microsoft Office and their related UIs and associated actions. This metadata is being pulled by the client based on the user and the role(s) of the user within the organization. The Exchange handler 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 Exchange handler provides an independent layer to different versions and formats of messages so that the calling components do not have to care about versions and formats of Office objects and command messages for the client Add-On. The Exchange handler provides interfaces to the most important objects within Microsoft Office, including email (IPM.Note), email attachments, the calendar, tasks, and contacts. The service bundling component hides the implementation details and distributes the incoming calls to the Mendocino-specific web services or ESA services, or any combination thereof. Which of these is chosen during the implementation depends upon the methods that can best support the respective use cases within the applications. The service bundling component also implements a method to resolve any Mendocino 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 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 the described components, the Mendocino extensions also include pluggable services. The pluggable services enable integration with preexisting technologies for functionality such as user roles, authentication, security, and reporting. Since these capabilities are not Mendocino specific, customers will be able to deploy any of these services from various vendors supporting these standardized interfaces. It is also possible to reuse existing solutions already installed on site. 9.4.7. How is security handled in the Project Mendocino environment?The challenge with authentication in Project Mendocino is the need to separate the authentication from the authentication within the system. For authentication to the system, Project Mendocino is able to reuse the authentication of the local user in the Windows environment. This is generally implemented using Windows NT LAN Manager or Microsoft Active Directory, which most people are familiar with. Within Project Mendocino, SAP security experts are also developing a module that is able to take the user token from the Windows environment and map it to the proper SAP user. In doing so, Project Mendocino is able to issue a single-sign-on ticket for the client to communicate in a secure way with the web services on the SAP side. Once authentication is secured, standard SAP guidelines and principles take effect. To this extent, access is granted based on authorization profiles associated with the user in the underlying SAP system. Each profile is associated with, for example, a handful of cost centers out of all the cost centers that exist in the underlying system. An information worker may have access only to his own personal information based on service scenarios, while a manager will be granted access only to her organizational unit within the entire system, and so on. 9.4.8. How will Project Mendocino change in the future?Today, Project Mendocino is bringing two very different worlds together: the client user experience and the SAP environment. That required a number of enhancements in many of the underlying modules exposing all of the enterprise services, such as enhancements to the reporting functionality and the alerts and notification functionality. SAP continues pushing forward to get all of those pieces in place until eventually it seamlessly becomes part of NetWeaver. By making almost all of Project Mendocino's baseline functionality an integral part of NetWeaver, SAP can ensure that the total cost of ownership for our customers will continue to get lower while at the same time providing more services. It will allow SAP to open up the Project Mendocino suite of applications to application developers outside of SAP to create their own metadata and push that out to the client to provide the same user experience for their relevant applications as well. The next release of Project Mendocino, which is targeted for the third quarter of 2007, will feature these capabilities as well as improved tools that can be used by third-party application developers along with those at SAP. Project Mendocino will be split into two different tracks over time: the underlying infrastructure (the framework and the tools) and the application layer. Some of the additional applications under consideration for enhancement include employee self-service and manager self-service applications and CRM scenarios. Just as Project Mendocino can make an internal meeting request, it will soon be capable of scheduling a customer meeting as well. And once that meeting is scheduled, a travel request and the budget for that request will be triggered, too. A contact within Outlook could be a customer contact, even a business partner at the customer site. An Excel spreadsheet can be used for reporting in the current release, but future releases will offer scenario analysis as part of a customer's supply-chain modeling. The Project Mendocino architecture offers additional possibilities with regard to exposing additional business scenarios, such as use on mobile devices, as well. Without question, Project Mendocino is poised to increase user productivity by giving users a familiar environment that is seamlessly linked to SAP backend functionality. |
EAN: 2147483647
Pages: 265