Technical Articles
MDG process visualization
SAP MDG processes are implemented as SAP Business Workflows, therfore they don’t have so nice runtime visualisation like e.g. those in NetWeaver BPM.
Below you can find the way how current state of MDG process and details of tasks execution can be presented to users. This can be achived with relatively small effort and the final result may look like this:
The Idea
The aproach is simple: process is shown as background image in HTML page and the active elements – as bullet icons with tooltips – are added on top of it; primitive, but flexible and effective 🙂
The process can be drawn in any tool (I’ve used ARIS Express), you can prepare simplified version (understandable by end users, with just dialog steps) or make it with all details (system methods, activation, cancelation, replication). Finally the process needs to be saved as image.
The “active elements” should be correctly positioned over the workflow tasks on the image, for that we need configuration table with XY coordinates. This table must also contain information identifying workflow step in the process. It may look like this:
CR_TYPE | STEP_ID | KIND | XPOS | YPOS |
ZMDGM006 | 00 | DLG | 122 | 467 |
ZMDGM006 | 01 | DLG | 233 | 467 |
ZMDGM006 | ZM06_STAT | SSM | 445 | 656 |
ZMDGM006 | TS75707936 | OTH | 445 | 1299 |
Having that information together with Change Request (CR) number passed from calling application we can collect all the data needed for our visualisation:
Collecting data to be displayed
Get top work item (WI) of workflow assigned to the CR
cl_usmd_wf_service=>get_cr_top_wf( EXPORTING id_crequest = iv_cr_number
IMPORTING et_workflow = DATA(lt_top_wf)
ed_rtcode = DATA(lv_rcode) ).
in the returned table there should be one record only of type Workflow ( F )
Collect tasks (WIs) of the workflow
cl_usmd4_crequest_protocol=>get_dependent_wis( EXPORTING i_workitem_id = <ls_top_wf>-wi_id
IMPORTING e_return_code = lv_rcode
CHANGING t_items = lt_workitems ).
See table SWWWIHEAD and TOP_WI_ID field
Now depending if you are using “standard” Workflow or Rule Based Workflow (RBW) in your MDG CR you need to match STEP_ID from our configuration table with just WI task ID (WI_RH_TASK) or get step number (DLG) or/and service name (SSM) from the workitem context – for that use the following method:
cl_usmd4_crequest_protocol=>read_container( EXPORTING i_workitem_id = iv_wi
IMPORTING e_return_code = DATA(lv_return_code)
CHANGING t_simple_container = lt_container ).
For RBWs based on WS60800086 you can check in transaction SWDD that Synchronous System Methods (SSM) are bulid on TS60807949, activation task on TS60808002 and cancel task on TS75707936 – this can be used for filtering the table returned from method GET_DEPENDENT_WIS.
Other information like completion time or potential processors of dialog task you can get with methods GET_WORKITEM_DETAIL and GET_WORKITEM_RECIPIENTS of class CL_USMD4_CREQUEST_PROTOCOL.
If you have implemented SLA timing configuration in your processes then such information can also be shown for dialog tasks.
OK, assume we have already collected the tasks data into table like this:
with nested table of task attributes like:
Now, we need just to show it in proper way on the screen
Application implementation
The page with process visualization is implemented as WebDynpro component with HTML Island (details how-to here)
To make it callable from FPM application the WD component is created as freestyle UIBB, so it implemnts IF_FPM_UIBB_MODEL interface. Here just the method PROCESS_BEFORE_OUTPUT needs to be implemented to read CR number passed as event parameter from calling MDG applicaion. Another option of getting the CR number is to read it directly from context (assuming calling application has set it already):
cl_usmd_conv_som_gov_api=>get_instance( )->mv_crequest_id
In simple version the output can be just pure HTML/CSS code generated from ABAP, in the HTML_ISLAND UI element you have the property staticHtml
In fact its content can be created dynamically from ABAP (but once only – modification triggers shortdump). This can be achieved in method WDDOMODIFYVIEW like below:
DATA: lv_html TYPE string.
...
IF first_time = abap_true.
lv_html = |<style>| &&
add_fixed_styles( ls_cr_data-usmd_creq_type ) &&
add_dynamic_styles( iv_cr_number = lv_cr_number
it_data = lt_data ) &&
|</style>| &&
|<div id="myIsland">| &&
|<p id="header1">CR: #{ lv_cr_number ALPHA = OUT } ({ ls_cr_data-usmd_creq_type })<br>| &&
|{ ls_cr_data-usmd_creq_text }</p>| &&
add_dynamic_html( iv_cr_number = lv_cr_number
it_data = lt_data ) &&
|</div>|.
DATA(lo_html_island) = CAST cl_wd_html_island( view->get_element( 'HTML_ISLAND' ) ).
lo_html_island->set_static_html( lv_html ).
ENDIF
Here is a link to HTML I’ve used for prototyping, you just need to write to lv_html the content (check the comments).
Of course with just HTML/CSS you will not achieve interaction like mouse image positioning, scaling with window resize and zoom in/out – for that some JavaScript code is needed.
The JavaScript approach allows also to get rid of the nasty HTML text operations in ABAP and use DOM methods instead. In result you have static JavaScript code, static code of CSS (both imported as MIME objects in WD component) and just empty DIV tag in staticHtml attribute of your HTMLISLAND UI element. The data can be passed from WD View context as described in previously referenced how-to document.
Hi,
Congrats... great simple solution. Its valid alternative to the process observer approach.
BR
Steffen
Again, great content! Thanks for sharing!