Wednesday, August 24, 2011

Using custom objects in SAP Workflow

When implementing workflow, you have the possibility to trigger workflow from an event in a BOR object (transaction SWO1) and passing the object to the workflow and use it in tasks and activities in the workflow.

Now imagine you want to create a workflow on a custom object, an object not supported with a standard object in SWO1 or even an object in another system. You would not be able to do this unless you create a custom object in SWO1. Let’s see what needs to be done.

Create the object
Create the object, ie ZOBJECT (do choose a proper name).

Add an interface to IFSAP

The interface to IFSAP is either standard or highly recommended. Add other interfaces as well if they suit your requirements.

Add the keyfields
The keyfields are used to uniquely identify the object. If you reference the field to a database field in the local system, the system will automatically add the fields’ searchhelp if available when testing the object in test mode.

Add the attributes
If you add all the attributes from a database table at once, the wizard will automatically add a select statement in the program logic to retrieve the data. You can of course also write your own logic to retrieve the data.
Implementing retrieval logic for your attributes
The logic to retrieve the data when an instance of the object is created at runtime should always be based on the object’s keyfields.
Instead of using the standard select statement to collect the data, you can of course also use a function module to retrieve the data.
If you want to create a workflow on data from a different system (for instance build a workflow in SAP CRM on data from SAP ERP), you can use a remote function call to retrieve data.

Add events
In order to be able to trigger the workflow, the easiest way is to raise an event on the object you wish to pass to the workflow. To be able to do this, you should define an event on the object and raise it somewhere in custom coding.

Think OO
If one of the attributes is a foreign key of another object (for instance a partner number being the key of a partner object), instead of adding just the number to the object, add the object, and get all of the object’s data for free in your workflow.
Change the status of the object and it’s components
Before you can use the newly created object in any contex, you should change the status of you object to ‘released’. You will have to change both the object and it’s components to be able to use it in workflow. Also, you will have to click the generate button to generate the coding.

Defining the workflow
In SWDD, create a workflow for your object, for instance an approval workflow. Make sure you pass the object to the workflow in the binding.

BOR Methods
If for instance the approval workflow would change the status of your object, you would add a method called ‘change_status’ to the BOR object, and add a parameter to set the status. This parameter could either be a fixed value in the container of the workflow task, or a value from the workflow binding. In the method, code the logic to change the status.

All set
Now, you are all set to build your workflow on a custom, or even a foreign object.

As workflow in SAP CRM has a much nicer user interface compared to the SAP GUI (as used in SAP ERP). This could open doors to using SAP workflow in CRM, and getting rid of those risky manual workflow processes that have been implemented in your organisatation over time. Say goodbye to inefficient Word templates, Excel forms and Email flows.

Structure your processes using SAP Workflow in SAP CRM.

1 comment:

  1. Very very very effective post. So far I've only had to handle the local SAP BOR objects such as the BOR CRM Sales Transaction as well as the Opportunity object. But I could see this situation come up in the future. Thanks for posting this!