Exercise 5 Business Process Management Async/Sync bridge Overview In this exercise we introduce the Business Process Management capabilities

es 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. <architecture diagram> <sequence diagram> 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. 1.1 Copy the 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. Copy the interface PurchaseOrder_out_async_BPM to abstract interface PurchaseOrder_async_abstract. This will be the input to the BPM. Copy the interface PurchaseOrder_out to abstract interface PurchaseOrder_sync_abstract. This will be the output of the BPM, representing the synchronous call. In this exercise, the mapping will be applied between the BPM and R/3. Copy the interface mapping PO_out__ZBAPI_PO_CREATE to PO_abs__ZBAPI_PO_CREATE: Source interface: PurchaseOrder_sync_abstract Target interface: ZBAPI_PO_CREATE (unchanged) Request mapping: POReq__ZBAPI_PO_CREATE_req (unchanged) Response mapping: ZBAPI_PO_CREATE_resp__POResp (unchanged) Create the abstract interface PurchaseOrderResp_async_abstract. This represents the output of the BPM containing the asynchronous PO response. abstract, asynchronous message type PurchaseOrderResponse Create the inbound interface PurchaseOrderResp_in_async. This will contain the final asynchronous response message to be accepted by the legacy application. inbound, asynchronous message type PurchaseOrderResponse

1.2 1.3

1.4

1.5

1.6

Step 2 BPM 2.1 2.2 Create a Business Process object: PO_async_sync Create the following containers: - PO_req: abstract interface, type PurchaseOrder_async_abstract - PO_resp: abstract interface, type PurchaseOrderResp_async_abstract Since the BPM is stateless, there is no correlation. Compose the business process flow by adding the following steps using drag-and-drop. For each step, complete the properties as specified below: 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 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).

2.3 2.4

o o o o o o -

Step Name: Sync PO request Mode: Synchronous Synchronous Interface: PurchaseOrder_sync_abstract Request message: PO_req Response message: PO_resp 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). Save and activate all objects.

Step 3 Directory We will have to create 3 different receiver determinations: HTTP client BPM (async) BPM R/3 (sync) BPM Legacy (async) 3.1 Install the BPM object as a service 3.1.1 Create new service of type business process: XIWS_PO_async_sync_[XX] 3.1.2 Assign your BPM object from the Repository: PO_async_sync. 3.1.3 Notice the signature of the process under the tabs sender and receiver. 3.2 Copy the existing receiver determination from exercise 3 (asynchronous): XIWS_web_purchasing_XX | PurchaseOrder_out_async. 3.2.1 For the new object select the following: Sender service: XIWS_web_purchasing_XX (unchanged) Sender interface: PurchaseOrder_out_async_BPM Sender Namespace: urn:xiworkshop:groupXX:webapp Add to scenario: xiworkshop_group[XX] Change the receiver service to your BPM: XIWS_PO_async_sync_[XX] Select the inbound interface PurchaseOrder_async_abstract, no mapping. Notice that for BPM no receiver agreement or communication channel is necessary

3.2.2 3.2.3 3.2.4

3.3 Create a new receiver determination from BPM to R/3: Sender service: XIWS_PO_async_sync_XX Sender interface: PurchaseOrder_sync_abstract Sender namespace: urn:xiworkshop:groupXX:webapp

 Receiver service: <select the business system for the R/3 client> Inbound interface: ZBAPI_PO_CREATE Interface mapping: PO_abs__ZBAPI_PO_CREATE Receiver agreement (communication channel): XIWS_RFC_receiver 3.4 Create a new receiver communication channel for the business system XIWS_legacy_BS_[XX], named POResp_file_receiver: Adapter type: File Direction: Receiver Adapter Engine: Integration Server Target directory: D:/workshop/group[XX] File Name scheme: POResponse.xml File Construction mode: Add message ID (this will append the message ID to the name of the file being created). 3.5 Create a new receiver determination from BPM to the file adapter: Sender service: XIWS_PO_async_sync_XX Sender interface: PurchaseOrderResp_async_abstract Sender namespace: urn:xiworkshop:groupXX:webapp 3.6 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_XX - Sender interface: PurchaseOrder_out_async_BPM - Sender namespace: urn:xiworkshop:groupXX:webapp - QoS: EO - Payload: use the contents of file PORequest_template.xml and replace the vendor number with your own. 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 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 Receiver service: XIWS_legacy_BS_[XX] Inbound interface: PurchaseOrderResp_in_async Interface mapping: none Receiver agreement (communication channel): POResp_file_receiver

4.2

4.3

4.4 4.5

Open your folder \\<hostname>\workshop\groupXX. There you should find a file containing the purchase order response. 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 Within the switch step, leave the Branch 1 (outcome name: success) empty. In our case no action will be taken in case of successful PO creation. Of course, some additional process steps could be inserted here. In the bottom branch (BranchOtherwise), insert a control step: - Step name: No PO created - Action: throw alert - Alert Category: XIWSALERT - Alert Message: GROUP XX: PO was not created (or some other text of your choice.) The completed process should look like this:

5.2

5.3

5.4

5.5 5.6

Check, save and activate your process. Before testing, go to the alert inbox and subscribe to the alert category XIWSALERT. The instructor will demonstrate how to create an alert category in the system. For this exercise, it is not practical for every group to create a new alert category at the same time, because this would create a locking situation. Therefore, XIWSALERT will be used for everybody. In real life, you could create your own alert category and assign a single recipient to it.

5.6.1
5.6.2 5.6.3

Go to the alert inbox (instructor will provide the URL): http://<host>:<port>/sap/bc/bsp/sap/ALERTINBOX/index.htm Go to Alert subscription and subscribe to the alert category Alert for PO creation (classification: alerts for XI workshop) Go back to the Alert Inbox screen.

5.7 5.8

Now send a PO request with erroneous data (for example, a bad material number). Monitor your message in SXMB_MONI. 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.

5.9

In order for the alerts to be collected and delivered, two programs must be run. The instructor will execute them manually. - SXMSALERT_PROCESS_DATA_GET (to collect XI-specific alerts). - RSALERTPROC (for the delivery of alerts to the recipients). 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 everybodys alerts.

5.10

5.11

Under Subsequent Action, you will find a link to your shared folder \\<hostname>\workshop\groupXX. Look at the latest message to view the error message.

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.

Appendix: naming conventions and terminology Exercise 6 Area SLD Int. Rep. Obj. type n/a NS XSD Msg.type Msg.type Msg.int. Msg.int. Abs. int. Abs. int. Abs. int. XSLT XSLT Archive Int.map. Context BPM Cont. Cont. Alert scenario service service Comm.ch RFC folder File Object name n/a urn:xiworkshop:groupXX[00..30]:webapp PurchaseOrderCombined PurchaseOrderRequest PurchaseOrderResponse PurchaseOrder_out_async_BPM PurchaseOrderResp_in_async PurchaseOrder_async_abstract PurchaseOrder_sync_abstract PurchaseOrderResp_async_abstract POReq__Z_BAPI_PO_CREATE_req.xsl ZBAPI_PO_CREATE_resp__POResp.xsl PurchaseOrder__Z_BAPI_PO_CREATE PO_abs__ZBAPI_PO_CREATE Vendor PO_async_sync PO_req PO_resp XIWSALERT xiworkshop_groupXX[00..30] XIWS_PO_async_sync_XX XIWS_legacy_BS_XX POResp_file_receiver Z_BAPI_PO_CREATE \\hostname\workshop\groupXX[00..30] POresponse.xml Description No SLD objects Namespace for web objects Contains 2 message types Derived from XSD Derived from XSD Outbound, asynchronous Inbound, asynchronous Abstract, asynchronous Synchronous call Asynchronous response Request mapping Response mapping Archive for XSLT mappings Interface mapping Context object BPM object PO request PO response Common alert category Reuse scenario container Business process Receiver BS for PO number Receiver comm. channel RFC wrapper D:\workshop\groupXX[00..30] Output file

BPM Int. Dir

R/3 File sys