Recently, I was working on the topic “Monitoring of cross system workflows” in the context of Master Data creation and enrichment processes. In this blog, I would like to share some results with you and ask you for feedback.
The idea to work on this subject came up because from my experience many customers and their users would like to observe the lifecycle of the creation or change of master data on a much larger scale than just in the specific master data system.
One important requirement is to be able to check whether the newly created or changed master data is distributed successfully to the backend or remote systems. In addition, it is useful to be able quickly to find out whether users in client systems have implemented additional views to enrich a specific material, and if so, to identify who those users are.
I completed the study of this topic by building a prototype for a SAP MDG-related use case in which material header data (such as description and basic data) is created and approved in a central MDG Hub and is then replicated to one ERP client. In the ERP client, a local user receives an automatically started workflow item to add additional views (such as sales and planning data) to the material. From an end user perspective, all steps together constitute one end-to-end process and should be observed in that way. Technically however, the prototype was built with SAP MDG standard features including ALE based replication and a new component within the ABAP Stack which is called SAP Process Observer ( read Bernd Schmitt`s blog series on Process Observer ). The following graphic explains the scenario.
2. Architecture and technical setup
The architecture of the prototype is relatively simple: I am using a standard SAP MDG configuration with a predefined workflow template for the governance process to create a new material record within SAP MDG. After the successful validation and activation in SAP MDG, the material record is replicated to a different client on the same system (Note that replication to a different system is an identical process). Within that system, the creation event triggers a SAP Business Workflow for the corresponding Business Object Repository (BOR) Object. Within that workflow, a user can call a standard transaction such as MM01 or MM02 to add more views to the material.
During the end-to-end process, the SAP Process Observer receives events from the following sources:
- The SAP MDG BOR Object for a Change Request
- The locally started workflow in the client system. (These events are sent using a remote function call.)
It is important to understand that the Process Observer is not driving the process itself.
As you can see the SAP Process Observer is a passive component that just collects information arising from events that objects sends (in this case BOR Objects and the API). The Process Observer itself correlates the received information to the corresponding process instances and saves the data down to some data base tables.
To be able to visualize this information, I wrote a smaller Web Dynpro ABAP component with SAP JNET. To make the prototype more user friendly, I have also integrated a visualization component using Collaborative Human Interface Part (CHIP) technology into the Side Panel of the “SAP MDG My Change Request” page. The following graphic shows a screenshot of the prototype.
The screenshot shows what happens after a user selects a change request in the My Change Requests application and then opens a side panel on the right-hand side of the screen. This side panel consists of the CHIP application that I wrote on custom code level with Web Dynpro for ABAP. This application uses an API call to read the corresponding information from the Process Observer.
The side-panel shows the hierarchy of systems and activities involved in the end-to-end processing of the change request. At the top-level, a system box represents the most important activities in the MDG hub. Below the system box for the MDG hub, there are separate system boxes for each client system. Within each system box, there are activity boxes.
All activity boxes have a header showing the activity name. Completed activities have a green header, and provide additional information such as the step name, date, and time for the activity. Not-yet-completed activities have a gray header.
In this prototype, the object ID that displays in activity boxes depends on the object under observation. For activities in the MDG hub, the prototype observes a change request object. For activities in client systems, the prototype observes material objects that are identifiable using material numbers.
Rather than duplicating additional log information within the process observer, I can provide links to logs in root applications (SAP MDG and SAP ERP/mm01/mm02.)
It’s important to mention that the scenario can easily be enhanced to support multiple target systems and clients. The client systems will simply send the events via a remote API to the central Process Observer. Dependent on the detailed requirements no or almost no coding is required to do so. Also the client systems do not have to run a Process Observer (or corresponding SAP ERP Release/EHP) themselves.
3. Pro`s & Business Benefit
After demoing this prototype to some people, I thought about the advantages and business benefits of this prototype and collected this list:
- Increased productivity.
You can now monitor real business activities in end-to-end processes involving multiple systems. During the setup you will configure the steps to be monitored. By doing this you and your business users can decide the granularity of the model. You can decide what important milestones in your end to end process are and your end users will not be spammed with technical steps displayed in the visualization. On one hand side this is an additional work what you must do during the configuration of the scenario but on the other side this is a real benefit as well.
- Faster Go To Market.
You can now use one tool to identify process bottlenecks.
- Lower TCO.
The solution is built in ABAP only; it applies standard technology, and requires minimal coding.
Instead of consulting multiple system-specific logs, you can now access one intuitive diagram, and, if necessary, drill down to the logs that require your attention.
4. Feedback and next Steps
I`m really interested about your feedback and comments on this topic and the blog itself. Maybe you can just write some words in the feedback section below.
If you are interested in the topic I recommend the following as next steps:
- Read Bernd Schmitt’s Blog on SAP Process Observer as mentioned above. (SAP Process Observer)
- Read this blog on Process Observer: http://scn.sap.com/community/bpm/blog/2012/04/03/sap-process-observer-a-new-approach-to-analyze-sap-business-suite-processes
- Inspect your current master data creation and change processes and think about the important milestones within these end-to-end processes which should be observed.
- Enable the SAP ERP Business Function for the SAP Process Observer on our ABAP system. Typically you will run the Process Observer on the same system and client as your SAP MDG is running
- Start with the setup and configuration of your Process Observer objects (such as Facade Layer Objects and Process Modeling). I have implemented 2 Process Observer BADIs for the prototype. One is to read the parameters out of the BOR Event sent by the MDG Change Request Object and the other one is to correlate the remote event sent by the client system via API.
- Develop a Web Dynpro ABAP User Interface which is displayed within the Side Panel. My visualization application is using SAP JNET technology to display the diagram within a Web Dynpro Network UI element. (more info: sap help)
- Reach out to me in case you need additional support (email@example.com)
PS: I would like to thank my colleagues Bernd Schmitt, Jens-Christoph Nolte, Frank Damaschke and Lars Rueter who helped me a lot building the prototype. Lars was so kind to hand over his prototype which he already built months ago and which he already showed at a SAP TechEd. This was really a great starting point. Frank, who is an senior software architect at SAP, helped me a lot with his enormous knowledge in SAP MDG and ABAP. Thanks a lot!