Skip to Content

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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply