Skip to Content
Author's profile photo Florin Wach

How to create individual entries in the (technical) workflow protocol


I was in the need to offer some more detailed information to the workflow-administrator when processing a workitem exit. A single “message” wasn’t sufficient, and storing the result in the workitem container could be an option, but it wasn’t that obvious to the user, although some additional information was stored in that container, too.

So I chose to add some entries to the technical workflow protocol on the step, I was working with, and this is, how it can be done with ECC 6.00 and up.

If you need to add an exception text, when a workitem runs into (a temporary) error, I suggest that you read one of my previous blog posts:

1. Get the workitem context (workflow API)

First of all you need to get the work item context. Within a work item exit class, this is already provided by the event interface: IF_SWF_IFS_WORKITEM_EXIT~EVENT_RAISED has the importing parameter im_workitem_context. So you’re going to use that one.

If you’re within the processing step of a work item you first need to retrieve the currently active workitem-ID and from that you need to get the context.

DATA: lv_current_workitem_ID                TYPE SWOTOBJID-OBJKEY,

lv_workitem_ID TYPE SWW_WIID.

* *********************************************************************

* *  Retrieve the currently active workitem, which is being executed  *

* *********************************************************************

CALL METHOD cl_swf_evt_requester=>get_workitem


                       EX_WORKITEM_ID = lv_current_workitem_ID.

IF NOT lv_current_workitem_ID IS INITIAL.   “workitem found

lv_workitem_id = lv_current_workitem_ID. “I love it, that you always

                                          “have different data elements in use

* *********************************************************************

* *  Get the ABAP OO instance of that working object                  *

* *********************************************************************

“Retrieve the workitem handle



CALL METHOD cl_swf_run_wim_factory=>find_by_wiid


                           im_wiid             = lv_workitem_id

im_read_for_update  = ‘ ‘


                           re_instance         = lo_workitem_handle.





CATCH CX_SWF_RUN_WIM. “System exception



* *********************************************************************

* *  Retrieve the context, as we need to use this for logging         *

* *********************************************************************

DATA: lo_current_workitem_context TYPE REF TO IF_WAPI_WORKITEM_CONTEXT.

lo_current_workitem_context = lo_workitem_handle->get_workitem_context( ).

IF NOT lo_current_workitem_context IS INITIAL.

“There it is…

2. Create short text, assign message ID and log through the context

And then you simply give a short message (up to 30 characters are possible) to the technical protocol, and the message-reference, so that the user can click on the traffic light and can retrieve further detailed information and the long text of that message, too.

* *********************************************************************

* *  Add a technical detail log message through the context.

* *  Within a workitem-exit you can directly use the given context.

* *********************************************************************

DATA: lv_message_text TYPE CHAR30,

               ls_message                  TYPE SWR_MSTRUC.

MESSAGE I101(WF) WITH ‘Testing world’ INTO lv_message_text.

“Transfer the system elments now into the log structure

ls_message-MSGID = sy-msgid.

ls_message-MSGTY = sy-msgty.

ls_message-MSGNO = sy-msgno.

ls_message-MSGV1 = sy-msgv1.

ls_message-MSGV2 = sy-msgv2.

ls_message-MSGV3 = sy-msgv3.

ls_message-MSGV4 = sy-msgv4.

lo_current_workitem_context->set_message_to_log( im_function = lv_message_text

                                                  im_message  = ls_message ).

“The commit don’t needs to be requested here (within the workitem execution),

“as we expect the commit after ending the current execution.

“However, you may have to adapt that.

3. Enjoy the result

… as one example.

Take care.

    Florin Wach


    SAP Business Workflow Senior-Expert

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Anjan Paul
      Anjan Paul

      Like other documents of you, this is also a really helpful.

      Thanks Florin.

      Author's profile photo Former Member
      Former Member

      nice solution and nice example of the use of the Wf Class cl_swf_run_wim_factory

      thank you

      Author's profile photo Pavan Bhamidipati
      Pavan Bhamidipati

      Nice work Florin thanks for sharing

      Author's profile photo Susan Keohan
      Susan Keohan

      Very Cool, Florin.  There have been many times when I wished I could get a little more info - without opening up the container elements themselves.  So for that matter, could that message be longer? (I am away from a system right now). 

      Keep on sharing!

      Author's profile photo Florin Wach
      Florin Wach
      Blog Post Author

      Hello Sue,

      the text, which is visible immediately visible in the technical list of messages, was designed to provide information about the SOURCE of the message. However, it turned out to be more conventient to have some explanation written there, instead of "Runtime system" or "Rule resolution" or whatsoever.

      I would assume, because of that, the possible length has been restricted to 30 characters only.

      More details can be given with the message-ID and the message variables, which are stored along with the log entry. So when a user clicks on the traffic light:

      A popup appears and will display the full message text. However, this message long text is also limited to about 70 characters. With the help-button one can navigate from there to the long description of the message (if available). Within the long text you can mix the given sy-msgv1...v4 variables, too.

      Take care and thank you for the feedback,


      Author's profile photo Dirk Wittenberg
      Dirk Wittenberg

      Thanks for sharing.

      As I'm doing a lot of workflow development this some day surely will be useful.



      Author's profile photo Former Member
      Former Member

      Nice Content.... ℹ

      Author's profile photo ajeet choudhary
      ajeet choudhary

      hi Florin,

      thanks for sharing, i tried the same in system but it is not workfing out for me, could you please elaborate if we have to do anything more than the mentioned above in your blog to achieve writing in workflow log.



      Author's profile photo Florin Wach
      Florin Wach
      Blog Post Author

      Hi Ajit,

      that's quite interesting, as I've just recently copied the implementation into a new system and it had worked instantly.

      It might have to do with checking of the current workitem-ID, or a commit-work statement was missing or similar. I'm afraid that I cannot help you any further without actually checkin the system as it might also have something to do with the R/3 Release you're working with.

      With the very best wishes


      Author's profile photo Ger Munsters
      Ger Munsters

      Hi Florin,

      Thanks for this post. I put it into practice and the message is put into the work item. But if I raise en 'E' type exception, my workflow does not go into error. Any clues on how to achieve this?

      Thanks and regard,

      Ger Munsters

      Author's profile photo Florin Wach
      Florin Wach
      Blog Post Author

      Hello Ger,

      the log entry will not have any effect on the workitem status.

      If you'd like to change the workitem's status, too, you have to raise an exception during the method's processing that is of type CX_BO_ERROR or CX_BO_APPLICATION, or with BOR object types the exit_return needs to be defined of type E or A.

      You can also use the Class-Based workflow-API to change the workitem's status from there. Maybe the workitem_context has already a method to change the status, otherwise you need to pick-up the cl_swn_workitem instance to turn the status into error.

      With the very best wishes


      Author's profile photo Ger Munsters
      Ger Munsters

      Hi Florin,

      Thanks for the quick response. I will certainly give your suggestions a try.



      Author's profile photo Former Member
      Former Member


      I am using AFTER_CREATION in the program exit then I have followed as suggested in the blog.... log is not getting add. Please suggest.

      I have created method which executes after_creation after that method results succ/fail need to add to the workflow log.

      wapi_create_container is also not working.

      Author's profile photo Florin Wach
      Florin Wach
      Blog Post Author

      Hmm... Maybe it's some release dependency. Using IF_SWF_IFS_WORKITEM_EXIT~EVENT_RAISED with a case on event




      During "After creation" the workitem container should be writeable with this:


      *** Get direct container reference
      DATAlo_wi_container               TYPE REF TO IF_SWF_IFS_PARAMETER_CONTAINER.
      lo_wi_container get_wi_container).

      IF lo_wi_container IS BOUND.

      lo_wi_container->setname  cv_container_name_rule
      value io_rule_to_save  ).

      DATAlo_direct_container     TYPE REF TO IF_SWF_UTL_PERSISTENT_OBJECT.
      lo_direct_container ?= lo_wi_container.


      Where the get_wi_container()-method is defined like this:

      method GET_WI_CONTAINER.
      IF mo_workitem_container IS INITIAL.
      mo_workitem_container mo_workitem_context->get_wi_container).
      ro_workitem_container mo_workitem_container.