Skip to Content

Motivation

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: http://scn.sap.com/community/bpm/business-workflow/blog/2013/04/25/use-exceptions-in-abap-oo-workflow-with-custom-text

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

                    IMPORTING

                       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

DATA: lo_workitem_handle TYPE REF TO IF_SWF_RUN_WIM_INTERNAL.

TRY.

CALL METHOD cl_swf_run_wim_factory=>find_by_wiid

                        EXPORTING

                           im_wiid             = lv_workitem_id

im_read_for_update  = ‘ ‘

                        RECEIVING

                           re_instance         = lo_workitem_handle.

CATCH CX_SWF_RUN_WIM_ENQ_FAILED. “Enqueue error

             EXIT.

CATCH CX_SWF_RUN_WIM_READ_FAILED. “Read failed

             EXIT.

CATCH CX_SWF_RUN_WIM. “System exception

             EXIT.

ENDTRY.

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

* *  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

    Systems-Integration

    SAP Business Workflow Senior-Expert


To report this post you need to login first.

12 Comments

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

  1. 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!
    Sue

    (0) 
    1. Florin Wach 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,

         Florin

      (0) 
  2. 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.

    Regards

    Ajit

    (0) 
    1. Florin Wach 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

         Florin

      (0) 
  3. 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

    (0) 
    1. Florin Wach 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

      Florin

      (0) 

Leave a Reply