Work Item Execution

1. Synchronous Dialog Chain
   1. Allows User to execute several work items one after the other without returning to Inbox
   1. Set using "Advance with Dialog" flag in workflow  definition.
2. Multiple Execution
   1. Agent can select a set of work items from inbox, and execute all of them together.
   2. Decision of 1st work item is copied applied to all work items.

Forwarding Work Items

• Forwarding a work item to another agent removes it from all other agent's inbox.
• If the receiving agent "replaces" the work item, it will re-appear in all original agent's inbox, AND will also be in the agent's inbox to whome it was forwarded. In other words, the list of agents is modified when forwarding.
• Forwarding can be configured in individual task. Following options exist
  • Work Item cannot be forwarded
  • Work Item can be forwarded to anyone.
  • Work Item can be forwarded only to possible agents.
• Example scenario where forwarding may be useful
  • Change in position of an agent, and handing over remaining work to whoever is replacing
  • Agent determination is incorrect/failed.

Work Item Priority (In Inbox)

• The priority only affects the sorting order in inbox.
• Priority = 1, is the highest priority. If an agent gets a work item with Priority = "1", then a popup message is displayed if they are logged into SAP GUI, irrespective of which transaction they are in.

Work Item Re-Submission

• If an agent does not want to handle a work item immediately, they can "Re-Submit" for a later time. Work items that are re-submitted are removed from the agent's inbox, and will be held in "Resubmit" queue.
• When the re-submit time comes, it pops back in the agent's inbox.

Workflow Logs  

• Technical log is the most detailed workflow log, and should be heavily used during development.

• For average agent, there are mainly 3 kinds of logs:
  • Chronological View
    • Displays non-technical steps
  • Agent-Oriented View
    • Displays which agent worked on what, in the entire workflow execution.
  • Object Oriented View
    • Displays list of objects involved in the process.
    • Eg: Business Objects, Attachments..etc.

Work Item Delivery Strategies

• Email Notification
  • Provided using report : RSWUWFML
  • Periodically polls work items.
• Groupware Integration
• Portal Integration
  • Can use workflow "iView" which has following features
    • Simple UI
    • Auto refresh in 10 mins
    • Display work items from all SAP components.
• External Users

Part 2 :  Agents

Version management in SAP Workflow is very good feature to track the changes. Yet, we do not have easy way to compare two version unlikely in ABAP workbench, It gives us possibility to create different versions for requested changes in workflow.

Consider the following case. You have defined a workflow. It is working correctly on production system. A new requirement has arised and you had to make changes. After that you transported your changes to production system. Everything is fine till that point but there is a question mark. What will happen the current workflows which are still not completed. In some business cases it takes days or weeks to complete workflow. SAP Workflow version emerges at that point.

In SAP Help It's written that :

Each time a workflow definition is transported into another system, only the active version is transported. If the workflow definition exists in the target system with the same version number, it is overwritten by the transported version if it has no workflows running. Otherwise, the transported workflow definition is saved with a free version number. The transported workflow definition becomes the active workflow definition in the target system.

As a result, the old workflow instances will work as they were defined and the new ones will work with the new definition.

In most cases this works correctly. However in some cases workflow version is not activated. Since there is no active version of workflow exists, workflow doesn't start. I don't know the exact case but there is an OSS note about it (OSS note 1027175). To activate the version we can use report RSWDACTIVATE to manually activate the version

When you click on activate icon the selected version is activated and workflow will be working correctly with new active definition.

Introduction

When you read through the blog post Another 10 Common Mistakes made by Workflow Beginners from Paul Bakker, you can find in section #16 the advice to avoid duplicate workflow instances and the advice

You could set a 'check function' on your event linkage, so that no new workflow is started if an active workflow already exists for the same object. Or, when a change occurs, raise an event to terminate the existing workflow and start a new one.

In this blog I will show you, how to achieve a very safe singleton concept, starting with

1. The event coupling and check function to prevent duplicate workflows
2. Trigger-Wait-Event concept for Singleton
3. Enhanced event trigger for super-safe approach

1. Event check function for "is another workflow already running"

If you would like to check, if there's already the same workflow (i.e. to be exact: "A workflow instance of this object running, that is based on the same workflow pattern as this one"), you'll need two information

- The object instance identification: type and instance key

- The workflow pattern ID

Both is already available in the standard event coupling, if you're not using any specialty here:

• - The object comes within the SENDER as an importing element
• - The workflow pattern ID comes as the RECTYPE as another importing element

to the check function module.

This way, it's possibly to create a generic check function module Z_CHECK_OTHER_WORKFLOW_RUNS, that is working with all workflow implementations instantly:

FUNCTION Z_CHECK_OTHER_WORKFLOW_RUNS.

*"----------------------------------------------------------------------

*"*"Local Interface:

*"  IMPORTING

*"     VALUE(SENDER)          TYPE  SIBFLPORB

*"     VALUE(EVENT)           TYPE  SIBFEVENT

*"     VALUE(RECTYPE)         TYPE  SWFERECTYP

*"     VALUE(EVENT_CONTAINER) TYPE REF TO IF_SWF_IFS_PARAMETER_CONTAINER

*"  EXCEPTIONS

*"      OTHER_WORKFLOW_RUNS

*"----------------------------------------------------------------------

   "The method generically finds any workflow based on

   "the sender object.

   DATA: lt_task_filter       TYPE STANDARD TABLE

                                  OF SWR_TASK

                                  INITIAL SIZE 2,

         lt_worklist          TYPE STANDARD TABLE

                                  OF SWR_WIHDR.

   DATA: ls_task              TYPE swr_task.

   ls_task = recType.

   APPEND ls_task TO lt_task_filter.

   CALL FUNCTION 'SAP_WAPI_WORKITEMS_TO_OBJECT'

     EXPORTING

       OBJECT_POR                     = sender

       TOP_LEVEL_ITEMS                = 'X'

       TEXT                           = ' '

       OUTPUT_ONLY_TOP_LEVEL          = 'X'

     TABLES

       TASK_FILTER                    = lt_task_filter

       WORKLIST                       = lt_worklist.

   "Check running. If error-workflows, then start another instance

   READ TABLE lt_worklist TRANSPORTING NO FIELDS

                          WITH KEY wi_stat = 'STARTED'.

   IF sy-subrc = 0.

      RAISE OTHER_WORKFLOW_RUNS.   "Use better MESSAGE E... RAISING ...

   ENDIF.

   "You may also check for wi_stat = 'ERROR' if you like that

ENDFUNCTION.

This looks already like we're done, and for normal cases it's working fine. However, the story continues, as soon as you have multiple starting events at the same time (right after posting a document or later on through a change document). In such cases, if the workflow instances are created simultaneously, each call to SAP_WAPI_WORKITEMS_TO_OBJECT will return that no instance is currently running, and at the end you still have two (or more) workflows running. Just think of the BUS2012.ReleaseStepCreated event, which can occur more than once at the same time.

This leads us to the next section, closing the door via the second workflow design pattern as mentioned by Paul before.

2. Trigger-Wait-Event concept for singleton

As outlined in chapter 1, it's still possible to have a another workflow instance running, although you're checking that in the check-FM during the creation event, or you just can't check at the time of the event creation and you have to rely on the workflow instance.

This trigger/wait event concept foresees, that each new workflow instance will close all already running workflows in place. So, yes, a new workflow will start, but in ends any other existing way, leaving only one left for the object instance.

As you need the instance identification anyways, I suggest to create an event .CloseProcess on the instance level of the object type, regardless if you're using the BOR design or the new ABAP OO Workflow design.

Within the workflow pattern, you design a sender fork/wait combination like this:

The sending step will raise the event for <instance>.CloseProcess and any other workflow who's already listening to that event (because it's running), will end up immediatly. After that is done, the workflow will itself wait for such an event, just for the case, there's a newer workflow coming up.

The fork will cover the complete workflow implementation. So after receiving the event .CloseProcess for the <instance> you'd immediately need to complete your workflow gracefully.

So, that's all not real magic and you have another advantage, that if you'd like to start all-over with a couple of workflow instance, you can now easily raise the event .CloseProcess for the instance you don't like anymore and create a new start event (if you're including the solution of chapter 1 a new workflow wouldn't start with a second start event, because that is prevented).

However, there's a small piece missing, as I have experienced, that the event processing through the workflow runtime system can take some time, and under certain circumstances it may happen, that the workflow is receiving its own .CloseProcess event. This happens, when the rRFC queue is full and the event creation is delayed. In such cases, the wait step is already created, before the event is receiving, ending up with no workflow running at all.

To solve this, please read the next chapter.

3. Enhanced event trigger for super-safe approach

The event trigger for .CloseProcess must provide the own source top-Workflow ID, so that the receiving wait step can identify itself.

Add an event parameter EV_WORKFLOW_ID to the definition for .CloseProcess like this:

Create a dataflow upon creating the event like this now:

Now the trick: Edit the instance linkage for the .CloseProcess event and add a check-function module there (transaction SWEINST):

And when done with it, you'd still need the coding excerpt from the check-FM, so here it comes:

FUNCTION Z_CHECK_NOT_OWN_TOPFLOW.

*"----------------------------------------------------------------------

*"*"Local Interface:

*"  IMPORTING

*"     VALUE(SENDER)          TYPE SIBFLPORB

*"     VALUE(EVENT)           TYPE SIBFEVENT

*"     VALUE(RECTYPE)         TYPE SWFERECTYP

*"     VALUE(EVENT_CONTAINER) TYPE REF TO IF_SWF_IFS_PARAMETER_CONTAINER

*"  EXCEPTIONS

*"      THIS_IS_THE_SAME_WORKFLOW

*"----------------------------------------------------------------------

   DATA: lv_sending_topflow_ID                  TYPE swwwihead-wi_id.

   TRY.

      CALL METHOD event_container->get

                    EXPORTING

                       name    = 'EV_WORKFLOW_ID'

                    IMPORTING

                       value   = lv_sending_topflow_id.

      IF NOT lv_sending_topflow_id IS INITIAL.

      "The top workflow IS present in the event container, so we will check it!

*    ** Read workitem instance and container from event

          DATA: lv_target_ei_id                 TYPE swwwihead-wi_id.   "Event wait step of target workflow

          CALL METHOD event_container->get

                           EXPORTING

                               name    = evt_receiver_id

                           IMPORTING

                               value   = lv_target_ei_id.

          IF NOT lv_target_ei_id IS INITIAL.

             "Yes, so we have not source TopFlow and target EventID.

             DATA: lo_wi_handle    TYPE REF TO if_swf_run_wim_internal.

             DATA: ls_context      TYPE sww_wimctx.

             DATA: lo_wi_container TYPE REF TO if_swf_cnt_container.

*         - set context

             ls_context-do_commit  = ' '.

             ls_context-called_btc = 'X'.

             ls_context-exec_user  = sy-uname.

             ls_context-fbname     = 'Z_CHECK_NOT_OWN_TOPFLOW'.

             CLEAR lo_wi_handle.

             CALL METHOD cl_swf_run_wim_factory=>initialize( ).

             CALL METHOD cl_swf_run_wim_factory=>find_by_wiid

                              EXPORTING

                                 im_wiid             = lv_target_ei_id

                                 im_read_for_update  = ' '

                                 im_context          = ls_context

                              RECEIVING

                                 re_instance         = lo_wi_handle.

             IF NOT lo_wi_handle IS INITIAL.

                DATA: ls_swwwihead_of_target_EI             TYPE swwwihead.

                ls_swwwihead_of_target_EI = lo_wi_handle->get_wi_header( ).

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

*

*    COMPARE  the sending top-workflow  against the receiving  top-workflow

*

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

                IF ls_swwwihead_of_target_EI-top_wi_id = lv_sending_topflow_ID.

                   MESSAGE E005 RAISING THIS_IS_THE_SAME_WORKFLOW.

                    "Received event from the own workflow instance

                ENDIF.

             ENDIF.

          ENDIF.

       ENDIF.

      CATCH CX_ROOT.

         "Exception handling is cut here for a better overview only

         "Attached coding file has full exception handling provided

   ENDTRY.

ENDFUNCTION.

Enjoy Workflow.

Take care.

Any helpful comments are highly appreciated.

    Florin Wach

    Systems-Integration

    SAP Business Workflow Senior-Expert

Introduction

The new ABAP-Objects Workflow has taken over the existing concept of temporary and application exception, as it was used with BOR-based Workflows. It has been replaced by using a set of predefined exceptions within the method's implementation.

The most commonly used exceptions are the following

You may also lookup for more exception, using the class builder and lookup the class hierarchy of CX_BO_TEMPORARY and CX_BO_APPLICATION, that are the two top-classes for the ABAP-OO Workflow Exceptions.

To use one of the given classes, you can just defined them in the "Exception" definition of the method.

The simplest way to make use of the feature that you've just created, is like this

RAISE EXCEPTION TYPE cx_bo_error.

With the BOR-based implementation, you had to define each exception with reference to a message-ID. This message-ID, including the four variables sy-msgv1,... were then displayed in the workflow log, and under the "Message" button of the workitem, which is a very nice feature, as you can provide more detailed information othen than just saying "There was some kind of error, and you could recover it, because it's possibly temporary".

And by raising the exception, you could pass more information to the workflow log.

exit_return 9001 'WACHF'.   "User &1 is currently locking table XYZ

With the ABAP-OO implementation, this has become a bit more complicated, but once you're through with it, it becomes fairly easy.

I do not repeat the common basis to define the outcomes in the step definition, how to create an ABAP-OO-Workflow class and so forth. Please read through the SCN, documentation or visit BIT611 for more information on that general topic.

Using custom text for OO-Workflow Exceptions

You can use the predefined classes and populate them with your own "text element" to have some more information displayed to the end user or the administration. The first - simplest - approach is, to create a new textID in the repository and use that, when raising the exception.

Create a new "concept" with transaction SOTR_EDIT.

Maintenance screen of SOTR_EDIT	Call menu option Concept - Create

Then fill in the screen for a new concept, which becomes the TEXTID later on. The field "Object Type" needs to be filled, but it's pretty much useless here.

Please read through the documentation of the transaction to find out, how to translate the object into other languages, create a transport request, and so on.

After you've created the new concept, you'll get a new GUID, which I would suggest to save it into a class constant.

To make use of this custom text within the exception handling of the workflow, you can simply use the following ABAP:

RAISE EXCEPTION TYPE cx_bo_temporary EXPORTING textID = '0050568015291ED2ABB3C86EAD8513B4'.

That's it, already!

This will now look like this in the workflow log:

However, sometimes, that not just enough. ... and the story continues ...

Using custom texts with variables

To make text replacements for the text of the exception class, there're two general approaches possible: Using a TEXTID based exception or a MESSAGE based exception. In the following section I will outline how to implement this with a TEXTID, as we should already know by now, how to use the SOTR elements.

Create a new concept with SOTR and create placeholders as you would like to provide them later in the class definition as public instance member attributes.

Now create a new subclass of the exception type, you need, e.g. a temporary exception. So create a new class ZCX_TEMPORARY_WITH_TEXT, inheriting from CX_BO_TEMPORARY. Please be aware, that the exception class name must begin with ZCX..., YCX... or /<namespace>/CX...

Create new member attributes for that class, as you like. In this example: USERNAME. It must be the same naming as you're using between the & and & of the text element.

The usage is now a bit different. So first of all, you need to list the exception in the method signature, of course:

And you cannot use the shortcut ABAP statement anymore, because you will need the following three steps:

- Instance a new exception class

- Assign the text elements before raising the exception

- Raise the exception object instance

"Special lock exception with text replacement on-the-fly

DATA: lx_temporary_locked                TYPE REF TO ZCX_TEMPORARY_WITH_TEXT.

CREATE OBJECT lx_temporary_locked        EXPORTING textID = cv_textID_locked.

"All text elements embraced by & will be replaced by instance attributes

lx_temporary_locked->username = 'WACHF'.    "As an example

RAISE EXCEPTION lx_temporary_locked.   "Object is temporary locked by user WACHF

And in the workflow log, it appears now like this:

And this is really an improvement, when comparing it with the default text:

It's some work, but it's very nice to use, when you got there.

Variant 2 - Using exception with message classes

Thanks to the comment of Jocelyn, I've added the part to populate a message-ID to an exception and raise that. However, I didn't find any substance need to modify/enhance the exception's constructor. It's working without any coding (changes).

The existing class CX_BO_TEMPORARY is not an exception-class "with message class", so you can't use it directly, but you have to subtype it. So please subtype a new class, e.g. ZCX_TEMP_EXCEPTION_WITH_MESSAGE from the super exception class CX_BO_TEMPORARY.

Check the box "With Message Class" now.

After that, activate the new class. You don't need to make any changes in the subtyped class.

Then add the new temporary exception to your exception list of the method. And here's the coding excpert, how to correctly raise that message. In my example, I chose to set the message WF 015 "Cancelled by user":

DATA: ls_message              TYPE SCX_T100KEY,

      lv_message_text(50)     TYPE C.   "Dummy message holder

MESSAGE I015(WF) INTO lv_message_text.     "For where-used list and SY variables

ls_message-msgid = sy-msgid.

ls_message-msgno = sy-msgno.

ls_message-attr1 = sy-msgv1.

ls_message-attr2 = sy-msgv2.

ls_message-attr3 = sy-msgv3.

ls_message-attr4 = sy-msgv4.

RAISE EXCEPTION TYPE zcx_temporary_with_message EXPORTING textid = ls_message.

After that, you can find a temporary exception in your workflow log with  the detailed message!

Any helpful comments are very welcome.

Please "rate" or "like" if you find this information useful.

Take care.

    Florin Wach

    Systems-Integration

    SAP Business Workflow Senior-Expert

I'm addressing two difficulties that arise, when working with object instances of any kind during workflow processing:

1. The same object instance is used several times during a single sequence of an ABAP transaction
2. The same or different attributes from that instance are used

The approach to work with problem A is: Use a “caching algorithm”, which is put into place on the central spot, where the SAP Workflow Runtime system is picking up any instance: FIND_BY_LPOR of the workflow interface. There is a template implementation provided within the ABAP OO White-Paper from SAP AG, Jocelyn Dart (thanks again to Jocelyn), and I have extended it to be used for a central generic instantiation (please see below).

For the duration of an ABAP transaction, all created object instances, will be put into a system cache, where they are picked up again, whenever they are asked for again.

For problem B one can improve database performance to pre-select the main database tables that are commonly used, to avoid a second re-read at a later time.

This is good to provide a more simple delivery of the object’s attributes, that can more easily be used within a workflow implementation.

The approach to work with problem B is to follow the principle of a “big” object. Big objects pre-select all their possible values from the database before they are used. This is a very convenient way, how the workflow implementation can easily access and switch on the object’s attributes. The workflow is usually working with a very limited number of object instances (usually, there’s only one leading object). There is a certain drawback, when the object instances are used within mass processing, that takes place in front or aside of a workflow implementation: Too much data is selected, when there’re only a subset of attributes is needed, and secondly, the memory consumption of the ABAP runtime increases, as per solution to problem A, the object instances – once created – stay in place for the duration of the ABAP transaction.

In a "real" implementation, this could mean that a job, that previously took around 5 minutes to work, runs for hours and hours, because the system is busy to instantiate all the various objects for more-or-less nothing or barely no effect.

Counteractions, when using mass processing

• Mass processing should avoid to instantiate the business objects, before there’s an action required, where the implementation or logic is really needed. So it can be advices to make some part of the database selection first, and have the object instantiated later on for processing.
• The cache algorithm needs to be taken care of. A method .release() can be implemented to finish up the object instance cache, to reduce memory usage.

BOR Objects

Unlike with the ABAP Object implementation of a Business Workflow you have so-called "Virtual attribute" available, that processes an underlying getter-method, once the attribute's value is processed. (A "Table attribute" is basically the same, but they all refer to the same getter method). That is, the expression &BUS2081.CreatedOn& will execute implicitly a method get_createdOn within the BOR object's implementation. Here you can have a similar caching algorithm, which is usually generated by the BOR wizard when creating a "Table attribute".

Thanks to Sue, who outlined this feature below in the comment section, so I have included this section here for referring to it, too.

Once I had to manually downgrade an existing ABAP-OO implementation to a BOR-based workflow I have refactored the functional methods to become virtual attributes, and then using the existing caching algorithm from below. This worked really well, too.

So here follows the approach to have something similar with ABAP Objects.

The generic caching algorithm

Create a new class ZCL_WORKFLOW_CACHEABLE, non-final public instantiation implementing interface IF_WORKFLOW

Provide a private static attribute gt_instances_base, holding a table of object references to ZCL_WORKFLOW_CACHEABLE, including two more - the key -

fields: typeID and instID, as they are also used within the SIBFLPOR structure.

All classes that are being used within the SAP Business Workflow implementation inherit from here and implement the same CONSTRUCTUR signature.

Implementation the method BI_PERSISTENT~FIND_BY_LPOR method roughly as following:

Within such a centrally implementation object instantiation, one could also easily implement the functionality for system-wide delegation, as it was known with the BOR object implementation.

You'll need to fill in some gaps, like a DDIC structure for the cache table, but as this blog-post is mainly addressing experienced Workflow programmers, you'll know, how to fill the missing parts.

method BI_PERSISTENT~FIND_BY_LPOR.

**********************************************************************
*   Cache lookup for existing instance
**********************************************************************

    FIELD-SYMBOLS: <ls_instance> LIKE LINE OF gt_instances_base.

    READ TABLE gt_instances_base ASSIGNING <ls_instance>
                                 WITH KEY typeID   = lpor-typeID
                                          objectID = lpor-instID
                                 BINARY SEARCH.
    IF sy-subrc <> 0.

**********************************************************************
*   Instantiation of a new object
**********************************************************************

       DATA: lo_instance_object  TYPE REF TO ZCL_WORKFLOW_CACHEABLE,
             lv_objectID         TYPE SIBFINSTID.

       lv_objectID = lpor-instID.

       CREATE OBJECT lo_instance_object TYPE (ls_lpor-typeID)
                     EXPORTING
                        iv_objectID   = lv_objectID
                        iv_do_refresh = gc_true.          "Indicator to perform full database selection upon creation

       result ?= lo_instance_object.

       add_instance_to_cache( lo_instance_object ).

    ELSE.

**********************************************************************
*   Retrieving and assigning result from instance cache
**********************************************************************
       result ?= <ls_instance>-instance.

    ENDIF.

endmethod.

This was the most important algorithm. However you'd need some more small methods around it. One is to add an object to the cache, and another helpful one is, to check, if an object is already cached. The third one was to implement the BI_OBJECT~RELEASE method, as well.

The adding to the cache is done centrally to ensure the correct sorting. Be aware that the internal table may grow, when many instances are being processed. So a few thousand entries could be possible.

method ADD_INSTANCE_TO_CACHE.

    "Check on cache existence first, as the constructor of the class
    "may have added itself to the cache already to avoid endless loops
    READ TABLE gt_instances_base TRANSPORTING NO FIELDS
                                 WITH KEY typeID   = io_instance->ms_lpor-typeID
                                          objectID = io_instance->ms_lpor-instID
                                 BINARY SEARCH.
    IF sy-subrc <> 0.

       DATA: ls_instance       LIKE LINE OF gt_instances_base.

       ls_instance-typeID   = io_instance->ms_lpor-typeID.
       ls_instance-objectID = io_instance->ms_lpor-instID.
       ls_instance-instance = io_instance.

       APPEND ls_instance TO gt_instances_base.
       SORT gt_instances_base
            BY typeID objectID.

   ENDIF.

endmethod.

A helper method to work with an explicit release.

method BI_OBJECT~RELEASE.
    "Delete from instance cache

    "There should only be exactly one typeID/objectID existing
    "in the instance cache table. But however, we need to be
    "absolutely sure to erase all traces here, so we loop to
    "find everything.

    "We can be sure now, as I have checked all references to ensure sorted table
    READ TABLE gt_instances_base TRANSPORTING NO FIELDS
                                 WITH KEY typeID   = ms_lpor-typeID
                                          objectID = ms_lpor-instID
                                 BINARY SEARCH.

    "Lookup oneself in the instance cache and remove here
    IF sy-subrc = 0. "Found
       DELETE gt_instances_base INDEX sy-tabix.
    ENDIF.

    me->release_instance( ).   "Method, which is to be redefined by subclasses to do their cleanup

endmethod.

And a last (public) method to give a calling report/functionality the opportunity to switch program flow if an object is already cached or not, without instantiating the object.

method IS_IN_CACHE.

    READ TABLE gt_instances_base TRANSPORTING NO FIELDS
                                 WITH KEY typeID   = is_sibflpor-typeID
                                          objectID = is_sibflpor-instID
                                 BINARY SEARCH.
    IF sy-subrc = 0.
       rv_in_cache = gc_true.
    ELSE.
       rv_in_cache = gc_false.
    ENDIF.

endmethod.

Any helpful comments are very welcome.

Take care

    Florin Wach

    Systems-Integration

    SAP Business Workflow Senior-Expert

I am writing a blog series to help introduce you to some of the speakers you will meet at the ASUG Annual Conference this year.

He ain’t heavy, he’s my Mentor (OK, one of them)

You can attribute the above misquote to Boys Town, or the song by the Hollies.  The song was recorded in 1969, and in spite of the fact that I had two older brothers, I still have some fondness for the (somewhat cheesy, I will admit) lyrics. 

It's a long, long road
From which there is no return
While we're on the way to there
Why not share

This year at the ASUG Annual Conference (conveniently co-located with another SAP-related event, SAPPHIRE) I will have the pleasure to welcome back into the fold someone I’ve known for about 15 years.  

We first met in, oh, 1998 I believe, at one of the very first ASUG meetings of the Workflow group (now the Workflow/BPM group).  Alan was the SAP Product Manager for Business Process Technology at the time, and he knew all about all things Workflow.  Even more than that, Alan really enjoyed connecting with users and hearing about our problems, and listening to our wish-lists.  Back then, our meetings were not huge events; we could choose a hotel in some agreed-upon location (with concurrence from a number of ‘board’ members), work with ASUG HQ to arrange the meeting, and search for speakers.  But the events were small, intimate,  focused.  If you traveled to the Tapitio Pointe in Phoenix in September, you were there to learn Workflow. Period.  You can tell from this photo.

Alan always followed up our face-to-face meetings with nice newsletters (remember, there was no SDN or SCN in those days!).  I stumbled across one today, and wanted to share this cute image of SAPGUI  from back then...

No more complaints about SAPGUI these

days, OK?  At least now we have colors!

Alan stayed with Workflow until 2005 – after he and Jocelyn Dart completed what is now known (in the Workflow World) as ‘the bible’ – the ultimate guide to Workflow development from SAP-Press called ‘Practical Workflow for SAP’.  

There is a newer edition, but it was  their blood, sweat, and tears that produced the original!

He still maintains the site www.workflowbook.com so that must demonstrate his ever-lasting affection for the product

Still, I was devastated to learn that Alan was moving on to other technologies in 2005 (little did I know that I  would get another awesome point-of-contact in Ginger Gatling!) The group decided Alan should have a little memento of our time together.

This year, Alan returns to ASUG Annual Conference!

Alan will be discussing another technology – Operational Process Intelligence.  If there is one thing I have learned about (and from) Alan over the years, it’s that he really gets the challenges that businesses face, and he is passionate about solving them.  Operational Process Intelligence is built on Process Observer, and then accelerated and visualized in a manner which allows strategic and tactical decision making. Or, instead of using a map to see where your business should go, you now use a GPS, right?  When driving, you need to know what road hazards lie ahead, where there are traffic jams, but a map won’t show you that.  SAPOPInt is GPS for your business.

There are dozens of blogs on SAP Operational Intelligence on the SAP Community Network – so you can delve in to them in order to whet your appetite.  And then, come to Alan’s session Tuesday, May 14, at 12:30 PM.  The session number is 3902. 

More fun stuff...

Alan was a physics teacher in a previous life.  He made such an impression on at least one of his students, that 32 years later, the boy (now a man) sent him a note in 2012.  This year, they met up for the first time in years. 

An extract of the letter says:

I remember you gave me a feeling of appreciation. You treated me well. I started to enjoy your classes tremendously. Usually I finished the homework on the train; I lived on the other side of Hamburg in Bergedorf. Once I came home I started to write everything down neatly, so I could present a decent piece of homework. You made me feel really good, I started receiving sevens (excellent). What you probably didn’t realise is that due to your teaching and fantastic sense of humour I started getting better in the other subjects as well. I enjoyed learning and going to school.

Wow, that's quite a letter.  Alan was always ready to regale us with tales of his teaching days - so ask him if you get a chance!

He is also an avid supporter of the First Lego League, and I can only imagine how many kids have gotten the same benefit from Alan’s experience, charm, and natural teaching abilities.

http://scn.sap.com/people/alan.rickayzen/blog/2011/12/01/youd-better-watch-out-generation-fll-is-on-its-way-lego-rules

I guess he just never stops teaching in some way - check this using Facebook for Project Managment? 

I hope you will come to Alan's session on SAP Operational Intelligence - you will also find him in some of the other WF/BPM sessions at the ASUG conference.

You can follow Alan on Twitter at @alanrick or challenge him to a game of bridge online alanrick (bbo ID).  That's his newest hobby!

Here are ten more common mistakes made by SAP workflow beginners. An earlier blog discussing the numbers #1 - #10 can be found here.

Have a laugh at my missteps, and make sure you don't repeat them!

11. BOR: Referencing Z subtypes instead of the supertype

This has to be the most common beginners' mistake, and yet is perfectly understandable.

If you delegate a BOR object (say BUS1006 - business partner) to a sub-object ZBUS1006, you should still always refer to 'BUS1006' in your workflows, tasks and event linkages.

That's right: 'ZBUS1006' should ONLY be used while creating the BOR object and setting up a subtype.

Otherwise: nunca / never / nimmer / niemals / aldrig / jamais!

Don't do this

Here are some of the reasons:

• when you search for workflow instances that use object BUS1006, you now have to also search for ZBUS1006
• when you see an explicit reference to a Z* object, you don't know if it has been copied or subtyped
• it also presents difficulties when searching through an alphabetical list of events (Z* is a long way from B*)
• if you only ever refer to 'BUS1006', you can easily switch to a new subtyped object (e.g. ZBUS1006V2) and your workflows won't miss a beat..

12. Not catering for all outside events

This is a blunder I have made many, many times. Just because you have built a great workflow for approving (say) leave requests, this doesn't mean that users will instantly change their habits. No, they will still get desk visits, and they will still approve the leave request through the old SAP transaction.

If your workflow doesn't recognize that this has happened, then you have a big problem. Users will ring, asking you why they have to approve something twice; or the workflow will go into error when it tries to change a request that is already approved.

So you need to consider all possible terminating events - 'Approved', 'Withdrawn', 'Changed', 'Deleted' etc.

Functional specifications rarely mention these scenarios, so it's up to you to include them.

13. Not setting deadlines based on the factory calendar

When a business analyst specifies that they want a reminder sent after 5 days, they usually mean 5 working days - weekends and holidays don't count. It seems obvious, but is often missed.

To implement this you need to specify the use of a factory calendar in your workitem deadlines.  The workflow book shows you how.

Copyright (c) 123RF Stock Photos

Even if your business runs 24/7, it still pays to use a factory calendar to cover all eventualities - e.g. future changes or Christmas shutdowns.

Be careful though - if you choose a custom factory calendar make sure it is correct and maintained well into the future. Otherwise - as reported in SCN - your workflows will stop dead when the calendar stops.

14. Over-complicated workflows

When I arrive at a new site, the first sign of trouble is a workflow definition that looks like a tangled ball of spaghetti.

Pasta Chikatetsu (source: www.tokyometro.jp)

It's pretty rare that all this noise and fury is really needed to implement a mundane business process (such as PO approval).

Typically, such workflows contain:

1. A string of container operation steps, which serve as ersatz initializations
2. Numerous activity steps that do nothing more than call a method to 'get' a value (e.g. a user's email address)
3. Unnecessary Sendmail steps
4. A long list of workflow container elements that, really, are just object attributes
5. A sprinkling of undefined steps (why oh why?)

Justify your existence

Does this sound like one of the workflows at your site? Here’s how to clean it up:

1. Initializations: use the 'initial' tab on the workflow container element instead
2. Use object attributes (as explained further in #12)
3. Delete SendMail steps that simply warn the user of a workitem. Use Extended Notifications instead
4. Again, use object attributes
5. Delete delete delete!

And once you've done all that, consider trashing the whole thing.

In my experience, workflows are often built 'on the fly', as requirements are drip-fed or regularly changed. Once you finish the build, it's worth considering whether to redesign from scratch.

Why? I like to think of a workflow definition as a LEGO(tm) house, where the tasks/steps are LEGO(tm) blocks. It's no problem breaking it all down again, just to see if you can design something sleek and elegant using the same steps.

Simplicity is so underrated.

My first workflow

Small, sleek & reliable

15. Using 'get' methods instead of attributes

This item ties in with #14. It is a common mistake made by folks who are used to procedural programming and not so comfortable with OO concepts.

Does your workflow have a step called 'Get User Name', based on a method 'GetUsername', which fetches user data and stores it in a workflow container called 'Username'? Which is then bound to a task container element 'UserName', just so that it can be used in the workitem text?

Sounds just like a traditional ABAP program :-)

All this complexity can be avoided if you instead define a (virtual) attribute called 'Username' that is automatically populated when the ('UserID') object is instantiated. The workitem text can then just use ‘Userid.Username’.

Note: Of course, you have to use your judgement in this. If the determination of an attribute is very expensive, you may not want it executed every time an object is instantiated. In this case, a GET method might be the best approach.

16. Allowing multiple copies of the same workflow to be started for the same object/event

Very typical beginner's error. I can't believe we didn't put this in the top 10.

You create a workflow for approving changes to a PO. It gets triggered when they change a field from 'Ted' to 'Fred'. But should another 3 workflows be triggered if (before approval is granted) 'Fred' then becomes 'Ned', then 'Ed' and finally 'Mildred'? Uh, no. Users hate this; which one should they approve?

You could set a 'check function' on your event linkage, so that no new workflow is started if an active workflow already exists for the same object. Or, when a change occurs, raise an event to terminate the existing workflow and start a new one.

17. Panicking when you see 'No Agent Available' in the workflow log

Don't worry - it doesn't mean that the workitem can't find an agent. It just means that no one has started processing this dialog workitem yet.

Perhaps a better translation from the German would be 'Not yet started' or 'Waiting to be processed'.

18. Using dummy wait steps of arbitrary length

Some workflows are punctuated with wait steps - dummy steps that call a dummy method that has an ABAP statement like WAIT UP TO 100 SECONDS in it.

Apart from being inelegant, you should question why a 'wait' is required and whether 100 SECONDS is long enough. Or perhaps too long. Wouldn't that depend on how busy the system is? And might it not change over time?

Typically a 'wait' step is inserted because you need a process to finish before you can continue - for example, the business partner has to be fully created before we can change it. In cases like this, a 'wait for event' step might be more appropriate.

Another option - e.g. in locking scenarios - is to use temporary exceptions.

19. Paying lip service to OO design

I sigh loudly when I see custom events with names like 'StartApprovalWorkflow'.  That name does not describe a real 'event' in the life of a assessment document.  (And it leaves open the mystery of where this event might be raised...)

In contrast, here are some real-life object events: CREATED, CHANGED, REJECTED. If you want to start an approval workflow, you should figure out which event(s) should trigger it, not invent a bogus one purely for workflow purposes.

For example, if an assessment needs approval when it's CREATED or CHANGED, then you can simply link the approval workflow to these two events (via SWE2).

Similarly, the methods of an object should represent ACTIONS on that object. Don't shoehorn a 'Sendmail' method onto a SalesOrder object, just because you can!

20. Developing custom programs to change workflows / workflow containers

This chimera comes up fairly regularly in SCN - a misbegotten idea to write a report that will automatically approve / forward / obsolete some outstanding workitems. That's bad enough, but much much worse are programs that seek to 'pop the bonnet*' and directly update container values from outside the workflow.

Good luck trying to understand your workflow log, once programs like that start messing with it!

If you feel you have to resort to such measures, then you probably need to study up on workflow features and design principles. Pretty much all of the above can be handled through modelled deadlines or terminating events.

geniet!

Paul Bakker

*North American readers might say ‘pop the hood’