1

Exercise 5 – Business Process Management – Async/Sync bridge Overview In this exercise we introduce the Business Process Management capabilities of XI 3.0. We will implement a stateless BPM pattern called an “asynchronous to synchronous bridge”. This is a common requirement from customers. It also addresses a former gap of XI 2.0. As a result of this exercise, you will become familiar with the business process engine and its monitoring features. You will have a better idea of how BPM allows you to mix asynchronous and synchronous messages. You will also be aware of the limitations in this area. Finally you will be able to revisit one of the previous scenarios with the inherent challenges of tRFC communication, and improve the message flow and error handling. This exercise will also introduce the usage of the receiver file adapter. Prerequisites

- Good knowledge of basic XI features. - Good knowledge of RFC/tRFC concepts - Basic knowledge of BPM architecture and concepts

Description In the advanced variant of exercise 3, we issued an asynchronous HTTP call to XI, which in turn posted a BAPI call asynchronously, via tRFC. The main advantage is that the calling application does not have to wait for the synchronous response. Instead we rely on the quality of service offered by XI and tRFC technology. Overall this is a more efficient use of system resources, in both application systems and in the Integration Server. However, this does not come without challenges. Asynchronous BAPI calls do not provide a response, and tRFC is arguably difficult, if not impossible to monitor at the application level. Basically the only way to make sure that the BAPI call was successful is to check with transaction ME23 that the purchase order was actually posted. In order to improve the situation, one approach is to combine asynchronous and synchronous messages. From the calling side, the HTTP request arrives as an asynchronous document into XI. As a result, it is persisted immediately in XI and the calling application can move on. On the receiving end we would like to call the BAPI synchronously because the PO number will be immediately returned. This is referred to as an asynchronous-synchronous bridge, which is now possible with XI 3.0 and BPM. Then we would like to send this response, containing the PO number, asynchronously to an external legacy system. Finally, we will implement some error handling, such that if the BAPI call fails, an alert will be generated. The WebAS alert framework will be used for this purpose. Exercise steps We will first implement the basic asynchronous-synchronous bridge, then we will revisit the business process and build the error handling. Step 1 – Repository There are many objects to prepare in the Integration Repository, before we can build the BPM.

2

Navigate to your SWCV TBIT40_WORKSHOP##, and open your existing namespace urn:tbit40:workshop:group##:webapp. 1.1 Copy the message interface PurchaseOrder_out_async to

PurchaseOrder_out_async_BPM. This will be the outbound asynchronous interface used by the HTTP client to send the initial message.

1.2 Copy the message interface PurchaseOrder_out_async_BPM to abstract interface

PurchaseOrder_async_abstract. Change copied interface to “Abstract”. This will be the input to the BPM.

1.3 Copy the message interface PurchaseOrder_out to abstract interface

PurchaseOrder_sync_abstract. Change copied interface to “Abstract” (and it remains “Synchronous”). This will be the output of the BPM, representing the synchronous call.

1.4 Copy the interface mapping PO_out_ZBAPI_PO_CREATE to

PO_abs_ZBAPI_PO_CREATE (the mapping will be applied between the BPM and R/3): o Source interface: PurchaseOrder_sync_abstract o Target interface: ZBAPI_PO_CREATE (unchanged) o Request mapping: POReq__ZBAPI_PO_CREATE_req (unchanged) o Response mapping: ZBAPI_PO_CREATE_resp__POResp (unchanged)

1.5 Create the abstract message interface PurchaseOrderResp_async_abstract. This

represents the output of the BPM containing the asynchronous PO response. o abstract, asynchronous o message type PurchaseOrderResponse

1.6 Create the inbound message interface PurchaseOrderResp_in_async. This will contain

the final asynchronous response message to be accepted by the legacy application. inbound, asynchronous message type PurchaseOrderResponse

You may activate all objects if you want to.

Step 2 – BPM (within Repository) 2.1 Create a Business Process object: PO_async_sync 2.2 Create the following containers:

- PO_req: abstract interface, type PurchaseOrder_async_abstract - PO_resp: abstract interface, type PurchaseOrderResp_async_abstract

2.3 Since the BPM is stateless, there is no correlation. 2.4 Compose the business process flow by adding the following steps using drag-and-drop.

For each step, complete the properties as specified below:

3

- Receive step – receive the asynchronous request and trigger the process o Step Name: “Async PO request” o Message: PO_req o Start Process: yes o Mode: Asynchronous o Activate Correlations: none

- Send step – send the request asynchronously and receive a response. Note that,

although the container objects refer to asynchronous abstract interfaces, they can be used as request and response message for the synchronous step (as long as the message types are identical).

o Step Name: “Sync PO request” o Mode: Synchronous o Synchronous Interface: PurchaseOrder_sync_abstract o Request message: PO_req o Response message: PO_resp o Receiver from: Send Context

- Send step – send the response out asynchronously

o Step Name: “send response” o Mode: Asynchronous o Message: PO_resp o Acknowledgement: none o Receiver from: Send context

The completed business process flow should look like this:

2.5 Check the business process (F7). 2.6 Save and activate all objects. Step 3 – Directory 3.1 Install the BPM object as a service

3.1.1 Create new service of type “business process”: The wizard is started. Select your BPM object “PO_async_sync” from the Repository and name your servic XIWS_PO_async_sync_##.

3.1.2 Notice the signature of the process under the tabs ‘sender’ and ‘receiver’.

3.2 Assign your new PurchaseOrder_out_async_BPM as an outbound interface to your Buiness Service XIWS_web_purchasing_##:

3.2.1 Open the the Business Service XIWS_web_purchasing_## and change to edit mode.

3.2.2 Navigate to area “Sender” and use the button to insert your message interface PurchaseOrder_out_async_BPM as a new message interface (namespace urn:tbit40:workshop:group##:webapp) (software component TBIT40_WORKSHOP##).

3.3 Create a new receiver Communication Channel for the business system TBIT40_LEGACY_BS_##, named ‘POResp_file_receiver_##’:

Adapter type: File

4

Direction: Receiver Adapter Engine: Integration Server Target directory: d:/usr/sap/trans/tmp/group## File Name scheme: POResponseGroup##.xml File Construction mode: ‘Add message ID’ (this will append the

message ID to the name of the file being created). We will have to create 3 different receiver determinations:

HTTP client BPM (async) BPM R/3 (sync) BPM Legacy (async)

HTTP client BPM (async) BPM R/3 (sync) BPM Legacy (async)

3.4 Create a receiver determination for HTTP client BPM (async):

On the initial screen, specify: Sender Service: XIWS_web_purchasing_## Sender Interface: PurchaseOrder_out_async_BPM Sender Namespace: urn:tbit40:workshop:group##:webapp and add it to your scenario TBIT40_WORKSHOP##. In the detail view, in the area under Configured Receivers, select the receiver service ‘XIWS_PO_async_sync_##’ and save your receiver determination.

3.5 Create an interface determination: The easiest way to do is in the receiver determination in the area Configuration Overview, by using the right-click to with entry “New specific …” under the column Receiver (Partner|Service) since this already fills most of the necessary parameters. Inbound interface: PurchaseOrder_async_abstract Interface Mapping: none Notice that for BPM no receiver agreement or communication channel is necessary HTTP client BPM (async) BPM R/3 (sync) BPM Legacy (async) 3.6 Create a receiver determination for BPM Legacy (async):

On the initial screen, specify: Sender Service: XIWS_PO_async_sync_## Sender Interface: PurchaseOrder_sync_abstract Sender Namespace: urn:tbit40:workshop:group##:webapp and add it to your scenario TBIT40_WORKSHOP##. Select R3_BACKEND as receiver service and save your receiver determination.

3.7 Create an interface determination: Inbound interface: ZBAPI_PO_CREATE Interface Mapping: PO_abs_ZBAPI_PO_CREATE

3.8 Create a Receiver agreement: The easiest way to do is in the receiver determination in the area Configuration

5

Overview, by using the right-click to with entry “New specific …” under the column Receiver Agreement (Communication Channel) since this already fills most of the necessary parameters. In the detail view, use the input help (F4) to select your Channel: Receiver (Communication Channel): RFC_receiver

HTTP client BPM (async) BPM R/3 (sync) BPM Legacy (async) 3.9 Create a receiver determination for BPM Legacy (async):

On the initial screen, specify: Sender Service: XIWS_PO_async_sync_## Sender Interface: PurchaseOrderResp_async_abstract Sender Namespace: urn:tbit40:workshop:group##:webapp and add it to your scenario TBIT40_WORKSHOP##. Select the receiver service TBIT40_LEGACY_BS_## and save your receiver determination.

3.10 Create an interface determination: Inbound interface: PurchaseOrderResp_in_async Interface Mapping: none

3.11 Create a Receiver agreement: Receiver (Communication Channel): POResp_file_receiver_##

3.12 Activate all objects Step 4 – Test The testing procedure will be similar to the one used in exercise 3. 4.1 Use the plain HTTP client to send a request asynchronously:

- Sender service: XIWS_web_purchasing_## - Sender interface: PurchaseOrder_out_async_BPM - Sender namespace: urn:tbit40:workshop:group##:webapp - QoS: EO - Payload: use the contents of file ‘PORequest_template.xml’ and replace the vendor

number with your own. 4.2 Examine your message in transaction SXMB_MONI. Notice that the message was sent

to the process engine, and that the status of the workflow is ‘completed’. 4.2.1 Drill down to the workflow details 4.2.2 Display the workflow log 4.2.3 Display the technical details of the workflow log 4.2.4 Display the graphical details of the workflow log

4.3 Examine the other messages in the monitor. In total there are 4 messages:

- Asynchronous request HTTP BPM - Synchronous request BPM R/3 - Synchronous response R/3 BPM - Asynchronous response BPM file

6

4.4 Open your folder group##. There you should find a file containing the purchase order

response. 4.5 Verify in the R/3 system (transaction ME23) that the PO was created. Step 5 (advanced) – Alert management We will now enhance the process, such that if the PO is not created successfully, then an alert will be triggered. 5.1 Add a Switch step to your process, in order to determine if the PO response contains a

PO number - Step Name: PO Success - Branch 1 outcome name: success - Branch 1 condition: use the condition editor to check for the existence of the field

‘PurchaseOrder’: “PO_resp./p2:PurchaseOrderResponse/PurchaseOrder EX“

7

5.2 Leave the Branch 1 empty (outcome name: success) within the switch step. In our case no action will be taken in case of successful PO creation. Of course, some additional process steps could be inserted here.

5.3 Insert a control step in the bottom branch (BranchOtherwise):

- Step name: ‘No PO created’ - Action: ‘Throw Alert’ - Alert Category: ‘PROCESS ALERT’ (case sensitive, with the space inbetween) - Alert Message: “GROUP ##: PO was not created” (or some other text of your

choice, this will be the long text of the alert message.) 5.4 The completed process should look like this:

5.5 Check, save and activate your process. Testing of Alert management: 5.6 Open the alert inbox before testing:

Go to the alert inbox in the Runtime Workbench, e.g. from the Integration Builder start page (e.g. via abap transaction SXMB_IFR) and check if there are currently any alerts displayed.

5.7 Now send a PO request with erroneous data, for example, a bad material number: ... <item> <key>item</key> <ItemNo>00010</ItemNo> <Material>12345</Material> ...

5.8 Monitor your message in SXMB_MONI. Click on PE in column outbound (or inbound) to

get the workflow log displayed. In the workflow log, verify that the step ‘Trigger a process alert in the background’ occurred. Under goto ‘list with technical details’, notice the instance number for the workflow object.

8

5.9 Refresh your alert inbox. Now you should see the alert corresponding to the process

instance. Look at the long text to ensure that the alert is yours. Again, for exercise purposes we are all subscribing to the same alert category, so you will receive everybody’s alerts.

Note: in this exercise we have demonstrated a simple use of alert management. In general, alerts should be used to monitor technical errors only. In the case of an application error like this one, the correct approach would be to generate a new message, which would be considered a negative application acknowledgement.

9

Appendix: naming conventions and terminology Exercise 6

Area Obj. type Object name Description SLD n/a n/a No SLD objects Int. Rep.

NS urn:xiworkshop:group##:webapp Namespace for web objects

XSD PurchaseOrderCombined Contains 2 message types Msg.type PurchaseOrderRequest Derived from XSD Msg.type PurchaseOrderResponse Derived from XSD Msg.int. PurchaseOrder_out_async_BPM Outbound, asynchronous Msg.int. PurchaseOrderResp_in_async Inbound, asynchronous Abs. int. PurchaseOrder_async_abstract Abstract, asynchronous Abs. int. PurchaseOrder_sync_abstract Synchronous call Abs. int. PurchaseOrderResp_async_abstract Asynchronous response XSLT POReq__Z_BAPI_PO_CREATE_req.xsl Request mapping XSLT ZBAPI_PO_CREATE_resp__POResp.xsl Response mapping Archive PurchaseOrder__Z_BAPI_PO_CREATE Archive for XSLT mappings Int.map. PO_abs__ZBAPI_PO_CREATE Interface mapping Context Vendor Context object BPM PO_async_sync BPM object BPM Cont. PO_req PO request Cont. PO_resp PO response Alert PROCESS ALERT Common alert category Int. Dir scenario TBIT40_WORKSHOP_# Reuse scenario container service XIWS_PO_async_sync_## Business process service XIWS_legacy_BS_## Receiver BS for PO number Comm.ch POResp_file_receiver_## Receiver comm. channel R/3 RFC Z_BAPI_PO_CREATE RFC wrapper File sys folder d:/usr/sap/trans/tmp/group## Target Directory File POresponseGroup##.xml (plus msg ID) Output file