SELFITEM delegation

[Former Member]

Introduction

It is a typical requirement of having to change the standard implementation of BOR object SELFITEM method SENDTASKDESCRIPTION. Reasons typically have something to do with sending notifications as e-mails rather than SAP Office documents. I was surprised that no one had written a document/blog on the subject so I thought of doing it.

Technical Information

Basically when defining a step type of mail, BOR object SELFITEM method SENDTASKDESCRIPTION is used. You can do a where-used on the BOR object in transaction SWO1 to get an idea of how widely it is used in the system. What makes BOR object SELFITEM special is that it's internal key field gets automatically populated with the workflow ID, there is no need to bind anything from the workflow container to the task container nor BOR method.

Solution

It is time for the first take away of this blog. When creating a sub type of SELFITEM, e.g. ZSELFITEM and delegating SELFITEM to the sub type, DO NOT refer the sub type, e.g. ZSELFITEM, in your workflow definition. If you do, the internal key field will not get automatically populated. Instead, always refer the standard BOR object SELFITEM. See the screenshots below.

Now you may ask yourself, will this not change all workflow steps that are using SELFITEM? The answer is yes, it will. It is up to you to implement the logic to include or exclude specific workflows/tasks/recipients from the delegated logic.

Now it's time for the second take away of this blog. One of the most common workflow tasks is to forward notifications from SAP Office Workplace as e-mail notifications to your e-mail inbox. The easy way is to use transaction SO16 and forward all notifications from SAP Office Workplace to e-mail inbox but sometimes that simply can't be done, for example a certain group of users still want to use transaction SBWP to process their tasks. Unless you are designing a workflow from scratch and you can retrieve the required e-mail addresses before the SELFITEM step, you are looking at changing a lot of workflows. That is, unless you use the trick defined here. Now redefine the SENDTASKDESCRIPTION method of the BOR ZSELFITEM and make it convert all SAP Office Workplace notifications to e-mail notifications, see below for an example implementation. Place the code before the call to function module SWW_SRV_MAIL_SEND.

data lv_user                    type          bapibname-bapibname.

data lt_smtp                    type table of bapiadsmtp.

data lt_return                  type          bapirettab.

field-symbols: <smtp>           type bapiadsmtp,

               <address_string> type string.

if workitem_task eq 'TS90000001'.

  if send_type eq 'G'.

    loop at t_address_strings assigning <address_string>.

      if <address_string>(2) eq 'US'.

        lv_user = <address_string>+2.

        call function 'BAPI_USER_GET_DETAIL'

          exporting

            username = lv_user

          tables

            addsmtp = lt_smtp

            return  = lt_return.

        check lt_return[] is initial.

        read table lt_smtp assigning <smtp> with key std_no = 'X'.

        if sy-subrc eq 0.

          <address_string> = <smtp>-e_mail.

        endif.

      endif.

    endloop.

    send_type = 'U'.

  endif.

endif.

In the code I'm converting notifications of one specific workflow task, your business requirement might be different or you might even choose to forward everything (which kind of isn't the point since you can achieve that with SO16).

Conclusion

SAP has given us the powerful technique of delegation for BOR objects, you should use it to avoid enhancements/modifications/etc. While I know that everyone should be using ABAP objects in workflow and I do whenever possible, it will still take a while before we see workflows based on BOR objects disappear completely.