We have written about visualization before, but there are some improvements to the visualization of process flow that deserve a separate blog post.
I will discuss the visualization of the process instances. Everything I explain here is also possible for process definitions; however, I believe extensive configuration has more value for process instances, so I will explain that in this post. Some of the functionality for process definitions was delivered with the subsequent support package. So if you want to use the functionality shown here, you will need to read the relevant technical data, IMG and possibly BAdI documentation. I won’t go into all of the relevant technical details in this post, but I need to go into some of them.
So what’s new? If you use the <Instance Diagram> button in the process monitor (POB_MONITOR) nothing much has changed. You really should not see much of a difference. However, the technical implementation behind the visualization and the customer options to influence the visualization has significantly changed.
The new process visualization implementation is as follows: Process definition and instance data is read and processed, then transformed into XML, which controls the JNET control that shows the data to the user. Green indicates possible extensions points for customers.
The XML is generated from the process instance data using a simple transformation (box Transform). This transformation controls the complete visualization: What is shown and how it is shown. To provide flexibility, you have to provide configuration effort. You can find a new IMG activity Define Graphical Presentation of Process Instances and Process Definitions that explains the technical details and lets you configure the transformation used for the visualization. You can set a default transformation for all process definitions. You can also set a separate transformation (POC_V_JNET_TRANS view) for individual process definitions.
To quickly exchange the visualization of your process, you can exchange the current default implementation with another transformation XML that SAP is delivering.
The BAdI has three methods: one to process the JNet control events (Event Exit) and one each for the process definition and instances to enrich the data going into the transformation (Data Exit). This Data Exit BAdI lets you change the data going into the transformation. The relevant data consists of nodes: one node for each activity, and the edges connecting the activities. You can manipulate that data since the tables contain changeable data. The tables also have CI includes (Customer Data) which let you add data to each line.
If you have a process chain going over multiple process instances, there is also information for each process instance and their relations.
To better understand that, let’s look at a typical use case. Let’s say you are looking at a process that involves sales orders. The default visualization will show the business object type and its ID, when the activity was executed, etc., but no additional application-specific data. For the sales orders, you need to see the customer name. To do this, add the customer name data to the CT_NODES table by adding the ZZNAME field to CI_POC_JNET_NODE (Customer Data) and then implementing the BAdI (Data Exit) to read the customer name (the code below is just to illustrate; you need to understand the application and where the data is that you need, which highly depends on your use case):
The transformation consists of the TypeRepository, the UserInterface and the Graph. The Graph defines what is shown on the screen. In this example, the Graph must be changed (TypeRepository defines reusable types. UserInterface is relevant for the events that are generated when you click on buttons or links).
The Graph consists of five loops. In this example, the loop at NODES is relevant. In simple transformations, this looks like: <tt:loop ref=”.NODES”> . You need to output the name (ZZNAME field of the NODES table) underneath the ID, but – in this case – you want to do this only if it is not initial. Otherwise, it would output the label Customer: for all activities of the process.
Now call the process monitor and <Process Diagram> a process instance. The output looks then as shown below.
Obviously, any other field can be added. You can also change the size of the boxes, colors, fonts, etc. This flexibility has its prices: The transformations are not easy to use; SAP delivers simple transformations, but it is also possible to use the more complex, more widely used XSLT. It is generally a good idea to use the transformations that are delivered by SAP as a template and work from there. In theory, you can completely rewrite the visualization depending on your JNET and simple transformation/XSLT skills, but this can become quite challenging – you can go as far as implementing call-backs into ABAP during the transformation and putting events into it (see Processing above). Simple changes along the existing templates are easier. Detailed information on JNET can be found in the JNet Introduction for Developers.
Some advice for working with transformations and JNET: Some settings of the JNET can occasionally get “stuck” – restarting a changed visualization will not let certain settings take effect (like box size), but others will. That’s strange behavior and can be quite confusing the first time it is encountered. It is necessary to “kill Java” to reset JNET; for me using IE, it is generally sufficient to close all browser windows to achieve that. You will notice that you get the Java start screen again when relaunching the visualization.
Process Observer is delivered as part of the Business Suite in the Foundation Layer SAP_BS_FND. This functionality has been provided for releases and support packages 731SP14 and 747SP09 for EHP6/7 of Business Suite ERP. The equivalent features for process definitions and the BAdI are released with the subsequent SPs. There is a note to implement this with earlier SPs but the note requires a lot of manual work. Carefully review the note before you implement it: 2058393. The BAdIs can be put on top using a note that is easy to implement: 2086592.
The extensions for federated processes which have also been released as part of the development described here and that are also referenced in the note will be discussed in a separate blog post, which will also cover the events.
As always, let me know if you have any remarks, questions or ideas – either in the comments below, in our Process Observer Discussion or through personal communication – and good luck with your Process Observer project!