Skip to Content

With NetWeaver CE 7.20, SAP released a powerful tool where most of the teething troubles of 7.11 are eliminated. The integrated Business Process Management in combination with NWDS is a great toolset to model and implement business workflows.

This blog series illustrates the use of synchronous, asynchronous and intermediate sub process calls on a detailed technical level. It shows primarily how the different start event triggers, or rather service interfaces, could be implemented and how Adobe Forms could be used in combination with intermediate message events. 

The series contains of:

  • Part 1of3: Synchronous sub process using existing Visual Composer data type
  • Part 2of3: Asynchronous sub process call
  • Part 3of3: Loosely coupled sub process using intermediate message events  and Adobe Form response

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

My system: SAP NetWeaver 7.20 SP3

Synchronous calls are the default case. Each task will be processed  step by step. Steps can only be processed parallel if tasks are called  after an AND gateway.

It depends on the size of the process model  when the process designer should think of splitting the whole process in  little sub processes. A very good guideline can be found right here Composite Development Architecture Guidelines.

Sub  processes have clear advantages:

  • The complete process is  easier to understand and maintained
  • Sub processes can be tested  and debugged much faster. Especially in big processes (20-30 tasks) and  complicated R/3 calls
  • The in- and output parameter can be  changed / customized independent of other processes or tasks

The basis for the complete series is a simple Order – Approval business scenario (The GUIs have been modeled in Visual Composer).

 

Process description:

The whole process consists of two tasks. In the first step the user has to enter his first- and last name, the stock he wants to order and the amount of stocks. This order will be sent to the approver who can Approve or Reject the order. 

In this example we export the “Order Approval” task in a separate referenced process. This is only to demonstrate how to create correct message triggers and belonging service interface (WSDL file).

The data of task “Order Request” will be mapped into the data object “DO_OrderRequestOut”. All data of this data object will be used in the referenced process “Order Approval”. To pass the data to the sub process a message trigger with appropriate input parameters for the sub process start event has to be created. The message trigger itself is bound to a service interface.

For the referenced sub process “Order Approval” an appropriate service interface can be created in two ways:

1. Input and output parameter will be created manually in WSDL file

  1. Process Modeling > Service Interfaces > Context – New WSDL…
  2. New WSDL will be saved default at path src > wsdl with default options
  3. I create my service interfaces always with this basic layout. Two types “InputType” and “OutputType” which will be assigned to the elements for process start- and end event.
  4. The type “InputType” of the referenced sub process service interface are manually defined like the output of the Visual Composer end event “Order Request”

  5. The type OutputType is a hard-coded Boolean element if it is approved or not (= output of task Order Approval).
  6. Create corresponding message trigger which can be assigned to the Start Event of the referenced sub process.

2. Input and output parameter will be inherited from already existing Visual Composer models data types

  1. Process Modeling > Service Interfaces > Context – New WSDL…
  2. To be able to inherit the types from VC models do not save the WSDL at default location src > wsdl. It has to be saved at rep folder with default options. (This is due to a bug in BPM framework and will be fixed in further service packages. See note below)
  3. Create the base layout for service interface like explained before
  4. Assign the output data type “end1TypeOUTPUT” of task “Order Request” to the child “output_order_request” of element “InputType”

  5. The result should look like this. It is very important to assign the inherited types not directly under  the complex type like “InputType” or “OutputType” because this could  lead to errors. Always assign the values to child elements like here  “output_order_request”.

  6. The OutputType of the process has to be modeled quite similar. The output type of the Visual Composer task “Order Approval” should be assigned to the complex type “OutputType” of the service interface.
  7. Create corresponding message trigger which can be assigned to the Start  Event of the referenced sub process.

Note: If you saved the WSDL under src > wsdl you would get an error at the Directives: “…because it contains too many ‘../’ … wsdl Unknown Document Import Flag“. As explained before to solve problem save WSDL under rep folder.

As final step. The output data only has to be mapped to the “Order Approval” task as you can see here:

 
Advantages for inherit data types of already added Visual Composer models:

  • Changes in Visual Composer data types will be automatically adopted to message triggers
  • Save time if very many elements has to be created manually for the start event (e.g. > 20 elements)
  • Data types (e.g. string, int) do not have to be set separately
  • Easier data mapping due to same name and data types

This blog describes the use of synchronous sub processes and the implementation of service interfaces. In the next part I will demonstrate how calls e.g. RFC could be decoupled from process workflow by asynchronous referenced sub processes.

  • See  Part 2of3: Asynchronous sub process call
To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply