Part 2of3: Asynchronous sub process call

[Former Member]

Hello SAP community, before you carry on please have a look at my first blog I discussed the topic how to call synchronous sub processes by reused Visual Composer data types for the service interface of the start event message trigger.

• see  Part 1of3: Synchronous sub process using existing Visual Composer data  type

Part 2of3: Asynchronous sub process call

My system: SAP NetWeaver CE 7.20 SP3

Today I wanna show how to implement a service interface for asynchronous sub process calls. The main difference to synchronous process calls is the missing response. Asynchronous processes can only be triggered without any feedback if further process execution succeeds or fails - like fire and forget.

Current problem is, that asynchronous sub processes will not work out of the box. There are some steps necessary which should be considered.

Follow example tie on part 1 of this series.  There we created one tasks for "Order Request" and one synchronous referenced sub process "Order Approval". Now, for the case that the order was approved, we start a sub process asynchronously by an automated activity "Send Order to R/3 Backend" which itself executes a RFC call to order the stock (Referenced sub process activity can only be used for synchronous use cases).

Main process:

For illustration purposes we do not care if RFC calls succeeds or not. Please spend the attention on HOW the service interface for the automated activity and the sub process has to be implemented for asynchronous calls. For completeness the asynchronous process looks like below picture. To test the asynchronous behaviour I simulate the duration of the backend by an intermediate timer which waits for 60 seconds before sending a completion info mail.

Sub process which will be started asynchronously:

As result we expect that mail notification "Async Process Started" of main process will arrive before mail notification "Send Completion Info-Mail" of sub process.

To get the asynchronous sub process call running, below steps has to be done:

1. Create new service interface for asynchronous process
2. Delete "Output" of the default created operation
3. Move to tab "Source" and delete below described tag otherwise there will be an error shown like "No corresponding Message for direction OUT"
   
4. At tab "Design" I would recommend to create a type "InputType" which should be assigned to the input element of the operation. At type "InputType" it depends on you which parameters the asynchronous process needs or not. In my case I handover the value for "amount" and "stock"
5. Create corresponding message trigger which can be assigned to the Start  Event of the asynchronous sub process.
6. Assign just created service interface to corresponding automated activity ("Send Order to R/3 Backend") in main process

To get the process call running this settings has to be considered:

In the given case the exclusive choice gateway calls the automated activity ("Send Order to R/3 Backend") asynchronously. To do so special permissions, to call this endpoint, are required:

This can be ensured by one of the below options:

1. Calling WS using principle user (user who is logged in): Enable Principal Propagation in the process flow. To do so, in ProcessComposer in the given process model you can set this property. Assign Role 'SAP_BPM_SuperAdmin' to the user, who will start the process.
2. Calling WS using default user: Assign Role 'SAP_BPM_SuperAdmin' to the user 'SAP_BPM_Service'

For further information see SAP Help: Principal Propagation. Mainly it describes which activities forward the principal information and which not.

If these settings are not set, an error will be shown at the default trace of the log file like: "...RuntimeProcessException:  User SAP_BPM_Service (SAP_BPM_Service) is not allowed to start a  process..." (Only if latest BPEM-CORE patch is running)

This blog described how processes can be called asynchronously and demonstrated how the service interfaces has to be implemented. In the next part I will show how sub processes can be implemented loosely coupled and how they can reactivate / awake the main process by using intermediate message events. The whole scenario will also be improved by an offline form using Adobe Forms.

• See Part 3of3: Loosely coupled sub process using intermediate message events and Adobe Form response