SAP® Business Workflow

Exception Handling in SAP® Business Workflow

By Suresh Kumar Parvathaneni

From the release of SAP® NW04 version, SAP® has introduced many new features among which exception
handling is one.

Exception handling is done in workflow using Blocks (TRY-CATCH mechanism). “Blocks” is one of the new
features introduced from NW04 version.

This document details about the usage of Blocks and the approach to trigger and handle the exceptions.

Pre-requisites

It is assumed that the reader of this article has some knowledge in SAP® workflow and has worked with the
steps Mail, Process control earlier.

Overview of Blocks

 Blocks could be treated as folders combining a group of dependent work items. They are shown as
folders in the workflow log.
 Each block would have start and end nodes.
 Blocks can be deadline monitored (only Latest End)
 Blocks can catch exceptions

Following are the screenshots representing how a “Block” appears in the workflow definition and in the
workflow log:
Fig: Appearance of “Block” in the Workflow definition.

Fig: Appearance of “Block” in the Workflow log

A “Block” is completed only if the dependent work items are complete or in the final state. If a “Block” is
cancelled, all its dependent work items are cancelled.

Each “Block” can have its own container elements. All the parent container elements are visible within the
“Block”.

Defining a Block

 Start a new workflow definition using the transaction SWDD

 Double-click on the “Undefined step” and select “Block”.
  Enter the step name and leave the block type as “Standard”. Press Enter. The workflow definition
would be appearing as follows:

All the dependent steps could be defined with in the Block start and Block end.

As mentioned earlier, Blocks can handle exceptions. If an exception is caught, everything inside the block is
cancelled. If exception is not caught, process is set to an ERROR state (This could be compared to TRY-
CATCH in ABAPTM programs. If the exception is not caught, program results in dump)

 Create a new workflow and define a new step “Block” as mentioned earlier page.
 In the “Block” step, click on the tab “Exceptions” and make an entry of a new exception, for e.g.,
“Dummy_Excep”, which would be raised in the workflow definition.

 Activate the exception defined above, by clicking on the button left to the exception name
 Go back to the main screen. Two branches would be appearing between the block begin and block
end, as shown below. Exception branch is taken whenever the exception, Dummy_Excep, is triggered.
 Exceptions are triggered using the step “Process Control”. Define a new step “Process Control” in the
normal branch. Enter the step name and the outcome name. Select “Throw Exception” in the function.
In the event name, select the exception name defined earlier (see the screenshot below).

 Uncheck “Step not in workflow log” if you would like to see this step in the workflow log.
 Define a mail step in the exception branch of the block (for testing purpose – to ensure that this
exception branch is taken, when the exception is triggered). The execution flow of the exception
handling is shown below:
Raising exceptions in a method and handling the same in the
workflow
By Suresh Kumar Parvathaneni

This document details the procedure in defining exceptions in a method and using the same in a
workflow.

Let us first look at raising exceptions in a method:

Go to Business Object Builder (Transaction SWO1).

Create a business object.

Now create a method.

Now select the method you have created and click on button “Exceptions” available on the toolbar.

Following screen appears:

Now click on Create. Following popup screen appears:

Enter the information as shown above. The error type “Temporary error” is chosen in the case wherein
the record is locked by somebody else or some required resource is not available. The error type
“Application Error” is to be chosen when there is no authorization for the document you are processing.
The error type “System error” is to be chosen if there are no values passed for the mandatory
parameters.

Click on continue.

Go back to the main screen.

Now in the method, provide the following code:

Save the business object and release the same.

Try executing the method by clicking on Test/Execute (F8). The exception would be raised as shown
below:

Capturing the exception raised by the method in the workflow:

Go to Workflow Builder (TCode: SWO1).

Create the step “Activity”

Create a task and provide the following details in the new task:

Save your entries and return to the previous screen.

Click on “Outcomes” tab. Here you can observe the exception you defined in your method:

As observed in the observe screen, the outcome is not active by default. If we do not handle the
exception, the work item might go into the error status. Activate the outcome:

Save your entries and go back to the main screen of Workflow builder. Please ensure that you have done
the agent assignment for this task.
You can now observe a new branch when the exception is raised. You can define your steps whenever
the exception is raised.

ALE - Error handling through workflow

By Abhijit Daptary & Siddharth Samal, Capgemini India

Pre-requisites.

It is assumed that the reader of this article has some knowledge in SAP workflow BOR objects and ALE
Idoc process like process code, Partner Profile etc.

Description

Here, we will be discussing in details the Error handling of an Inbound Idoc through triggering an event,
which in turn will be triggering a workflow attached to the workflow.

Steps:-

1. Create custom BOR object with the events, Start and Stop event
2. Create a workflow for the error handling, like generating a notification whenever an error occurred
in the Inbound Idoc.
3. Creation of Function Module and attachment with the Process Code
4. Create the settings for the Inbound Process of the Idoc through the Process Code.

Creation of BOR objects. Go to the transaction SWO1.

Enter a name for the Object type and click ‘CREATE’ button for creating the custom BOR object.

Enter the details required for creating the BOR objects...

Create the Key fields and events of the BOR object.

For creating the Key fields place the cursor on the Key fields and Click on the Create Button
Create events for triggering the workflow and stopping the workflow.

For creating the event place the cursor on the EVENTS and Click the create button like Key fields.

Create two events.

Enter the event name description etc and proceed further to create it.

Similarly create another event for ending the Workflow in the similar manner like that created earlier.
Now, Generate the BOR object through the generate button

Release the EVENTS and subsequently release the BOR object.

After the creation of BOR object

Create a workflow for the generation of notification whenever an error is reached in the Inbound Idoc.

Execute the transaction SWDD.

Click on the CREATE button for creating the workflow for error

handling.

Choose the Step type to be inserted for the notification like here we are using Send Mail option for
sending a mail to the user whenever any error occurred.

Activate the Workflow and test it whether it is working as per the requirement.

After the successful completion it is required to attach the workflow with the event.

Go to the Header section (Denoted by CAP).

Go to the Start Events
TAB.

Enter the details of the event with which the workflow should be linked like the category, BOR object type
and the event with which that should be linked.

Enter here the BOR object that has been created and give the name of event created for starting the
workflow.

Click on the Binding Button for generating the binding between the event and the workflow.
Generate the binding and click OK button to save the binding.
Click on Activate / deactivate button for activating the linkage.

After the successful linkage the following sign will appear on the workflow.....
This shows that the workflow has been linked to the event and it will be triggered whenever that particular
event will be triggered.

After the creation and successful linkage of workflow with the event it is required it is required to generate
a function module and attached it to the process code.

Go to SE37 transaction and copy a standard process code function module to a custom one. Do no
delete any parameters from the function module as the SAP standard program itself is calling this.

In that function module do the required validation and whenever the validation fails set a standard
parameter ‘WORKFLOW_RESULT’ to 9999 from within the function module, otherwise normally proceed
to set the status to 53.

After the creation of function module it is required to attach it to the process code and corresponding
attached to the message type at the Partner Profile stage.

The process code is being created through the transaction WE42

Go to the change mode and click the New Entries button for creating new process code.
Enter the Process Code Name, description and choose the processing type as Processing by function
module. Click on the extension button of Identification.

The details for the of the Process Code after clicking the identification button will be
Whenever idoc arrives into the Destination system then the standard SAP triggers the Process code
attached to the Message type in the partner profile. The partner profile is being maintained in the
transaction WE20.
Since, it is and inbound scenario so the message type and the corresponding process code will be
maintained for the Inbound Parameters.

Click on Create Inbound Parameters button for creating new Inbound Message type and the
corresponding message type.
Enter the process code for the corresponding message type.

Click SAVE button for saving the changes.

Whenever the IDOC arrives into the target system, it checks the partner profile and finds the
corresponding process code. The process code is being linked with the function module through which
the IDOC is required to be processed.