workflow activity step overview

The activity step is the preferred way to place a piece of ABAP code in the workflow template.  This can be used for existing SAP delivered pieces of code, Business API’s (aka bapi’s in sapanese), or your own custom code.  This requires sending information up and down the workflow infrastructure by binding workflow container elements.

If we take a look at the infrastructure briefly, we can see that we will need to have a step in the workflow, a task, a business object, and be able to link them all together.  We’ll start by looking at the business object in SWO1.

Here, we see the various key identifiers, descriptors (attributes), and verbs (methods) that are possible to use with this business object.  In our sample, we are going to use the display method.  Beside this method, you can see a green square, which indicates this is a BAPI – Business API – meant to be used for generic access to this action, and available remotely.  By clicking the green square, you can view the signature and the code for the BAPI to ensure it is what you wish to use.  

By selecting the line and clicking the Program button, you can view the code used to call the BAPI.  By selecting the line and clicking the Parameters button, you can view which parameters can or must be used to call this method.  These parameters can be marked mandatory, and if so, they must be sent from the layers above (workflow or task) or defaulted in the container element mapping in the task.

One level up in the infrastructure is the task.  This is pretty much a pointer to the business object type and the method being called.  When using an activity step, a task is used in a workflow step to communicate with a business object, however a task can be used directly in certain scenarios without requiring a workflow template.  To access the business object from the task, simply double click the name in the Object Type field.  Unfortunately, the Method field does not have this functionality, and will just result in the same action as double clicking the Object Name.   Indicators can be found here to indicate that the method is synchronous or not, and requires dialog (i.e. interaction with the end user) or not.

The icon with the two green or grey squares gives you access to the binding screen.  This is how the task communicates with the business object, and provides the parameters for the method.  There are two panes, the top one defines which container elements from the task are used to fill parameters from the method before code execution, and the bottom of the screen defines which output parameters from the method are communicated back to container elements in the task at the end of the call.  The blue arrows will show direction of information flow.  There are options to handle the data transfer under the black arrow.

The final step to connect our BAPI into our workflow application is to create a step.  By creating an activity step, the system permits us to enter a task number.  If we enter the task number that we have already created and already communicates to the display material method, this step in the workflow will attempt to display a material.  The description will default when we hit enter in the Task field, and the system will attempt to generate a binding.  The only difference with this binding is that the element in the task _WI_OBJECT_ID must be completed.  In our example, the system will need to know which material to display, and this is the key identifier required to identify that material.  This will need to come from the workflow container (normally retrieved from another step or event) or be defaulted.

This is a brief overview of how an activity step works.  Please feel free to review our video on the same topic on our YouTube channel if you want more information.