How to enable the existing Webdynpro based workflow inboxes to execute ALL tasks without config!
I guess everyone working with SAP Business Workflow has had the question to make the Workflow inbox available as a Web-Based inbox?
Up until today, we had some choices (UWL, WebDynpro POWL, custom, …) but all of them has some drawbacks:
– UWL can only be used when you have an SAP Portal
– Custom development is time consuming and costly
– WebDynpro POWL’s such as “IBO_WDA_INBOX” (used on SRM but also available on ECC) and “SWF_WORKPLACE” (mostly used on ECC) require some configurations to make sure that all Tasks you want can be executed
My personal frustration – and I guess also a lot of yours too – while using the WD4A’s is that every task (TS) needs to be configured whereas by standard SAP all tasks run within the SBWP and the UWL regardless whether they are SAPGui based or WebBased.
Don’t get me wrong, the provided configurations in those WD4A workflow inboxes are really an added value, but if you want to use this inbox as an alternative to SBWP or the UWL, it doesn’t work just like that!
So my question to SAP, why are the existing WebDynpro based workflow inboxes not working right away out of the box?
Anyway, I did not wait for this answer and “enhanced” those 2 Web-based (WD4A) workflow inboxes myself so they could cope with ALL tasks (whether they are SAPGui based tasks, Webflow Tasks or even alternatives specified in SWFVISU or their respective configuration capabilities).
First of all, I created myself a Function module that is able to launch the Workitem, this FM will be used in both of the WebDynpro for ABAP Workflow inboxes…
Creating a function to Launch the Workitem
This function module will be able to launch the following types of workitem from within the mentioned WebDynpro for ABAP applications above:
– WebFlow Tasks
– SWFVISU configured alternative visualizations
– SAPGui Tasks by means of WebGui
Also, the function will call the Task execution differently depending on whether the call originates from NWBC, Portal or stand-alone WD4A
So, here is the code I used for this function module:
FUNCTION ZWDWF_LAUNCH_WORKITEM .
*"----------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(IV_WIID) TYPE SWW_WIID
*" REFERENCE(IV_LANGUAGE) TYPE SYLANGU DEFAULT SY-LANGU
*" CHANGING
*" REFERENCE(WD_COMPONENT) TYPE REF TO IF_WD_COMPONENT OPTIONAL
*"----------------------------------------------------------------------
data: lr_window_mgr type ref to if_wd_window_manager,
lo_window type ref to if_wd_window,
lv_url type swr_url,
lv_wi_execute_url type string,
lv_unescaped_url type string,
lv_escaped_url type string,
lv_navigation_target type string,
lv_window_features type string,
lv_window_name type string,
lv_target_title type string,
lv_portal_event type ref to cl_wdr_portal_event,
lv_context_url type string,
lv_length_url type i,
lv_post_body type string,
lv_nav_mode type string,
lv_his_mode type string,
lv_config_mode type string,
lv_appkey type swn_appkey,
lv_apptype type swn_apptype,
lv_wi_detail type SWR_WIDTL,
lv_return_code type SY-SUBRC.
*
*----- STEP 1 - Get the URL to be started for the Workitem execution
*--- 1A - Retrieve the URL for the WI execution from WEBFLOW
CALL FUNCTION 'SAP_WAPI_LAUNCH_URL_GET'
EXPORTING
WORKITEM_ID = iv_wiid
language = iv_language
IMPORTING
URL = lv_url.
if not lv_url is initial.
lv_wi_execute_url = lv_url.
else.
*--- 1B - Retrieve the URL for WEBDynpro for ABAP execution
lv_appkey = iv_wiid.
CALL FUNCTION 'SAP_WAPI_GET_WORKITEM_DETAIL'
EXPORTING
WORKITEM_ID = iv_wiid
IMPORTING
WORKITEM_DETAIL = lv_wi_detail
RETURN_CODE = lv_return_code.
lv_apptype = lv_wi_detail-wi_rh_task.
CALL METHOD CL_SWN_URL_GENERATOR=>GET_WI_EXECUTE_URL_WDABAP
EXPORTING
I_APP_KEY = lv_appkey
I_APP_TYPE = lv_apptype
RECEIVING
R_URL = lv_wi_execute_url
EXCEPTIONS
CONFIGURATION_INCOMPLETE = 1
FAILED = 2
others = 3.
IF SY-SUBRC <> 0.
clear : lv_wi_execute_url.
ENDIF.
*--- 1C - Retrieve the URL for WEBGui execution
if lv_wi_execute_url is initial.
lv_appkey = iv_wiid.
CALL METHOD CL_SWN_URL_GENERATOR=>GET_WI_EXECUTE_URL_WEBGUI
EXPORTING
I_APP_KEY = lv_appkey
I_APP_TYPE = lv_apptype
RECEIVING
R_URL = lv_wi_execute_url
EXCEPTIONS
CONFIGURATION_INCOMPLETE = 1
FAILED = 2
others = 3.
IF SY-SUBRC <> 0.
clear : lv_wi_execute_url.
ENDIF.
endif.
endif.
*
*----- STEP 2 - Start the URL in a new screen as task execution
if lv_wi_execute_url is not initial.
*--- 2A - Now, call the retrieved URL as a WebDynpro window
if wd_component is bound.
lr_window_mgr = wd_component->get_window_manager( ).
CALL METHOD lr_window_mgr->CREATE_EXTERNAL_WINDOW
EXPORTING
title = 'Execute workitem'
URL = lv_wi_execute_url
MODAL = ABAP_false
RECEIVING
WINDOW = lo_window.
lo_window->open( ).
*
*--- 2B - Now, call the retrieved URL as Portal navigation (eg: NWBC, Portal, ...)
else.
lv_nav_mode = 1. "navigation_mode.
lv_his_mode = 1. "history_mode.
lv_unescaped_url = lv_wi_execute_url.
CALL METHOD cl_HTTP_UTILITY=>ESCAPE_URL
EXPORTING
UNESCAPED = lv_unescaped_url
* OPTIONS =
RECEIVING
ESCAPED = lv_escaped_url.
concatenate 'ROLES://portal_content/com.sap.pct/every_user/com.sap.pct.erp.common.bp_folder/com.sap.pct.erp.common.roles/com.sap.pct.erp.common.erp_common/com.sap.pct.erp.common.lpd_start_url?RequestMethod=GET&URLTemplate=' lv_escaped_url into
lv_navigation_target.
lv_window_features = 'toolbar=no,resizable=yes'.
lv_target_title = 'Execute workflow task'.
lv_portal_event =
cl_wdr_portal_event=>new_absolute_navigation_event( navigation_target = lv_navigation_target
navigation_mode = lv_nav_mode
window_features = lv_window_features
window_name = lv_window_name
history_mode = lv_his_mode
target_title = lv_target_title
context_url = lv_context_url
post_body = lv_post_body ).
wdr_task=>client_window->client->update_client_peer->send_event( lv_portal_event ).
endif.
endif.
*
ENDFUNCTION.Enhancing WebDynpro “SWF_WORKPLACE”
Within the class ‘CL_SWF_POWL_LAUNCH_SERVICES’ and method ‘GET_DEFAULT_TASK_VISU’, you have to make an enhancement at the bottom of this method:
This will fire the WD Event we will capture in the next enhancement…
So, this second enhancement point needs to be created for class ‘CL_SWF_POWL_WORKPL_WD_ASSIST’ and at the end of the method ‘HANDLE_POWL_FOLLOW_UP’:
The full coding which needs to be inserted here can be found here:
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(1) Class CL_SWF_POWL_WORKPL_WD_ASSIST, Method HANDLE_POWL_FOLLOW_UP, End A
*$*$-Start: (1)---------------------------------------------------------------------------------$*$*
ENHANCEMENT 1 ZCL_SWF_POWL_WRKPL_WD_A. "active version
*
data: lr_window_mgr type ref to if_wd_window_manager,
lo_window type ref to if_wd_window.
data: ls_event_parameter type powl_namevalue_sty,
lv_url type swr_url,
lv_wi_execute_url type string,
lv_wi_id type sww_wiid,
lv_action type string.
*
*----- Retrieve the Parameters to get the WI info
loop at it_event_parameters into ls_event_parameter.
case ls_event_parameter-key.
when 'P_WI_ID'.
lv_wi_id = ls_event_parameter-value.
when 'P_ACTION'.
lv_action = ls_event_parameter-value.
endcase.
endloop.
if lv_wi_id is not initial and lv_action = 'EXECUTE'.
*----- Call the Function which will finally execute the workitem
* Passing the WebDynpro component controller is necessary to start the task
CALL FUNCTION 'ZWDWF_LAUNCH_WORKITEM'
EXPORTING
iv_wiID = lv_wi_id
* iv_LANGUAGE = SY-LANGU
CHANGING
wd_component = m_comp_cntlr.
endif.
*
ENDENHANCEMENT.
*$*$-End: (1)---------------------------------------------------------------------------------$*$*
ENDMETHOD.Finally calling our ‘Launch workitem’ function module.
When you execute this WebDynpro application now, ALL workflow tasks should be able to be executed without issues!
Enhancing WebDynpro “IBO_WDA_INBOX”
I also made a similar enhancement to the webdynpro which is mostly used in SRM… unfortunately, I could not realize this one (at this moment 😉 ) without doing some configuration…
The advantage here is that I don’t need to create an enhancement point as I used the configuration capabilities to call the ‘Launch Workitem’ function module
Goto transaction SM30 to maintain the view ‘IBO_V_WF_ACC’ in order to specify a new Action:
Now, we can register the properties for the Action ‘TASKEXECUTE’.
Goto transaction SM30 to maintain the view ‘IBO_V_WF_TAC’:
Finally, we can link all the Tasks that we want to be treated by our custom ‘Launch workitem’ mechanism.
Goto transaction SM30 to maintain view ‘IBO_V_WF_TAC’:
Register the relevant Tasks and link them to our Action ‘TASKEXECUTE’
Logon to the Web-based Workflow inbox now and you will be able to execute the tasks!
I guess I have covered the most common situations with this blog, still in case you find a situation for some specific case not working, please let me know!
Enjoy!!!!!!!!
Hmmm it's creative I'll give you that.
It occurs to me that the problem might be more one of allowing a proliferation of inboxes in the first place. This is after all why we have consolidated inboxes such as UWL and now Fiori Approve All and Gateway Unified Inbox. Personally I never like application-specific inboxes and heavily discourage them on sites anyway. I can justify a workflow inbox vs. email inbox, and different inboxes (just) for different devices (although I expect that need to disappear over time) but application-specific inboxes are madness. I've yet to meet anyone who actually wants to check more than the absolute minimum of inboxes ever.
Another small point... I think you might need to be clearer that SWFVISU tasks still need to be performed and this won't pick up adjustments made in UWL custom config files such as adding on WebDynpro Configuration Ids. Also the UWL will completely ignore whatever you have coded in your method or function so that's a watchpoint that may cause some differences still.
BTW you talk about Web Dynpro inboxes - but SBWP for starters is really just a ABAP inbox - no WD about it at all.
But thanks for an approach that might help those struggling with the same problem
Hi Jocelyn,
I fully agree with you that 'application-specific inboxes are madness' so I'll definitely back you up there : '1 user should have only 1 inbox to look at'.
Only this way, we can get the best efficiency.
But, depending on the type of user it is possible that a high-end user which is only using SAPgui to perform daily tasks receives tasks in his/her SBWP.
On the other hand, occasional users/managers might profit more from 'nicer' Web-based workflow inboxes (UWL, Fiori, the WD4A's).
If we want to motivate the use of workflow or managed processes in general, then the aforementioned WD4A really makes sense as smaller companies don't/can't invest in the portal (UWL), gateway, fiori...
Fair enough & I agree that it can be frustrating that these lookups aren't built into older/less used inboxes. I usually take it as a hint as to future direction or lack thereof. As for SMEs always best to stick with the tried & true favourites that everyone else has beaten into submission which at the moment would be 1) UWL & 2) SBWP but I'm expecting Fiori Approve All & Gateway Unified Inbox to start challenging them soon
Thanks for sharing. One comment about configuring IBO_WDA_INBOX: the name of the customization view in the second step is wrong, the correct one is IBO_V_WF_APC (not IBO_V_WF_TAC).
I thought I would contribute more. The list of standard SAP customization views:
And the same for the customer ones:
See the below screenshot for the IMG location.
In order to have a general launcher for IBO_WDA_INBOX you would have to enhance the respective POWL feeder class(es). In case of POWL type IBO_INBOX_WI the feeder class is CL_IBO_INBOX_FEEDER_WI. The feeder class defines the actions, the Inbox configuration has to match. If the feeder class defines an action called EXECUTE there needs to be Inbox configuration for the same. To have a general launcher, one would have to define a default action and then enhance the feeder class to call your custom function module. Instead of enhancing the feeder class, one could also create a custom version of the feeder class and change the respective POWL configuration to use the custom version.
HI ,
Thanks for the configurations ... I have followed all configurations which you wrote in the blog.
But User is not getting the work item when he clicks on Work item from his POWL Inbox.
From the feeder class : CL_IBO_INBOX_FEEDER_WI
Method : EXECUTE_ACTION_WITH_PARAMS of Class CL_IBO_CH_WD_INB_ACTHDL is getting called .
Inside this method , FM(which we configure ) is getting called .
Inside that FM , I used another FM( MENU_START_OBJECT_VIA_INDX) to call URL .
But URL(work item ) is not getting opened....
Can you please let me know whether did i go wrong somewhere .???
or how to open the work item when user clicks on it ???
To avoid Inbox configuration all together one would have to change the GET_ACTIONS and HANDLE_ACTION methods of the feeder class. Otherwise you will require Inbox configuration for all tasks.
Hi Decock,
Excellent Work, Thanks a lot first of all.
I implemented as you described for SWF_WORKPLACE. A new window is getting opened now to execute the work item but the work item id and the action = Execute is not there. Somewhere the binding is missing.
Enclosed the current output and the link.
Please help a little bit more 🙂
/sap/bc/gui/sap/its/webgui/?%7etransaction=SWNWIEX&P_WI_ID=000002426507&P_ACTION=EXECUTE&P_APPL=NOTIF&%7eOKCODE=ONLI&sap-client=010&sap-language=EN
can anyone help here please !
the link generated is having the correct contents but the contents are not being passed to the dynpro.
Hi,
It works now well for me now except one Problem. When clicking execute on a workitem two Windows gets opened. The first one contains the work item and the second one is the execution Screen of the Transaction swnwiex.
Any way to get rid of the Transaction execution window.
Thanks
LS