In a Think outside the box - enhance processes with Universal Worklist Action Handlers! we introduced UWL action handlers. In this blog focus on the ABAP Web Dynpro action handler.
In our example we have a basic workflow in our backend system. In this workflow, we have steps that are serving as place holders. Our ABAP Web Dynpro will launch the actual application the workflow step should execute.
In this example our business workflow manages the process steps, but the ABAP Web Dynpro is actually what we want to launch.
How the workflow looks
Our workflow has two steps: data entry and approval.
The first step has you enter travel data, the approval happens in the second step. For the purposes of this discussion, we will only refer to the first step in the workflow.
Our first step, data entry (TS65507956), is really just a place holder. The actual form to enter data comes from the ABAP Web Dynpro. The actual task is defined as:
Our object type is WEBSERVICE, however, it does not have to be WEBSERVICE. Since the ABAP Web Dynpro will receive the work item ID at runtime and will access the container, the object and method can be anything.
Highlights of the ABAP Web Dynpro
The ABAP Web Dynpro was written by my colleague Alan Rickayzen. I think he used the ABAP Web Dynpro tutorial in online help to assist him with creating the ABAP Web Dynpro.
If you are a workflow person, then you can get with your Web Dynpro gurus to work on this together. What is cool here is how with just a few lines of code, you can access the workflow container.
The Web Dynpro itself has the WI_ID (work item ID) defined as a parameter. This work item ID for the task is passed via the UWL. The following is a code snippet from the data entry view of the Web Dynpro. This brings in the work item ID that was passed via UWL.
workflowrawdata =
wd_context->get_child_node(
'WORKFLOWRAWDATA' ).
CALL METHOD
WORKFLOWRAWDATA->GET_ATTRIBUTE
EXPORTING
NAME = 'WI_ID'
IMPORTING
VALUE = wi_id.
At the point where you want to read the container data from the workflow, use:
</body>
read the container
CALL FUNCTION 'SAP_WAPI_READ_CONTAINER'
EXPORTING
WORKITEM_ID = WI_ID
IMPORTING
RETURN_CODE = rc
TABLES
SIMPLE_CONTAINER = l_cont.
When your ABAP Web Dynpro completes processing, use the following code to write back to the container and complete the work item.
</body>
write back to the workflow container
CALL FUNCTION 'SAP_WAPI_WRITE_CONTAINER'
EXPORTING
WORKITEM_ID = WI_ID
IMPORTING
RETURN_CODE = rc
TABLES
SIMPLE_CONTAINER = l_cont.
set the work item to complete
CALL FUNCTION 'SAP_WAPI_WORKITEM_COMPLETE'
EXPORTING
WORKITEM_ID = wi_id.
Using transaction code SWFVISU
The other step we must do is ensure UWL knows to launch our custom Web Dynpro. We could create the XML ourselves and upload it into UWL, or we could use transaction code SWFVISU. Transaction code SWFVISU allows you to enter a task, it will generate the XML for you.
In transaction code you create a new entry for your task. In our workflow, TS66507956 is the task for our data entry step in our workflow.
Then you enter parameters such as APPLICATION, which the name of your Web Dynpro. You also enter the DYNAMIC PARAMETER for the work item ID. The other parameter you need is NAMESPACE. An optional parameter is SYSTEM_ALIAS. If used, the SYSTEM_ALIAS field provides the name of the system where the Web Dynpro application lives.
Once you have completed SWFVISU, re-register the work items for the system in UWL. This is done via the portal. Go to System Administration - System Configuration - Universal Worklist - Administration.
Select to "Re-Register" the work items. This will read your new TS tasks and read the settings in SWFVISU and create XML.
Notice the task, it is TS000008267, which you probably recognize as the generic decision task. So, here I've said that for that task, launch my Web Dynpro. We've said that the system B7QCLNT000 is the system that hosts the Web Dynpro.
When I loaded this XML into my UWL, I made it a high priority and had it apply to all systems. I currently have several systems tied to my portal. ERP2004 systems, BI systems, and several other systems. In my ERP2004 system I went to SWU3 and started the basic verification workflow. This creates a user decision in my inbox. Notice what I get in my UWL:
It is the normal task from the verification workflow. Since I've got customized XML tied to TS00008267, the details of my task look like:
I don't have the normal decision steps. The customized XML has been applied and the "launchWebDynProABAP" button is tied to the action to launch my specific Web Dynpro.
Note: In NetWeaver 2004, when you setup a system for UWL, you see a new field called "Web Dynpro Launch System". Let us say you are registering an R/3 4.7 system. However, your Web Dynpro is running on a different system. Let us assume your R/3 system is PRDCLNT800, your Web Dynpro was developed on a system called B7QCLNT000. In the UWL system registration you are adding PRDCLNT800, but in the "Web Dynpro Launch System" you could add B7QCLNT000. This defaults a system to use for Web Dynpro launches for every task in the system.
Additionally, you could override this default by using SYSTEM_ALIAS in either SWFVISU or in manually created XML. The SYSTEM_ALIAS field indicates the Web Dynpro system to use for a particular task.
How it looks at runtime in the UWL
When using an action handler, at runtime work items appear in my UWL as normal. Now they have a link to start the Web Dynpro.
ABAP Web Dynpro only exists on NetWeaver 2004S. But the action handler works in the same way for the Java Web Dynpro as well. I will discuss this in my next blog.
So, use Universal Worklist to renovate and innovate!
32 Comments
| User | Count |
|---|---|
| 545 | |
| 337 | |
| 235 | |
| 233 | |
| 216 | |
| 212 | |
| 179 | |
| 163 | |
| 152 |
