Exercise 2: Preparations

In this exercise the itemlist is transformed to a list, which is send synchronously to the business system Airline_Group_One. The response message contains the materials which must be created in the next exercise. This exercise also demonstrates exception handling for application and system errors. In case of an application exception, an alert is thrown, which can then be reviewed in the alert inbox. 1. To collapse the ReceiveOrderItemBlock block you created in the first exercise, choose Collapse from the context menu:

2. Define a new block Preparation with two exceptions SystemError and ApplicationError:

3. Create a new container element list:

4. Insert a transformation step PrepTransformation using the interface mapping itemlist2list. The source message is itemlist, the target message is list:

5. Create a new container element preplist, which contains the result of the preparation call:

6. Insert a send step SendPreparation:

Set the mode of the send step to Synchronous. The send step uses the synchronous Interface prep_sync_abstract. The request message is list and the response message is preplist. For the Exception System Error enter SystemError, for the exception Application Fault enter ApplicationError. 7. Add two exception branches for the exception handlers SystemError and ApplicationError by calling the context menu.

8. Add a control step PrepControlAppException into the exception handler for the exception ApplicationError:

Select the Throw Alert action and the PROCESS ALERT alert category. Enter an appropriate alert message (e.g. Preparation Checks group XY failed). 9. In the exception handler branch for the SystemError exception, insert a control step PrepControlSysError to cancel the process.

10. Save and activate your process. 11. Send three line items to your process using the Web Dynpro user interface and check your process instance by calling transaction SXMB_MONI_BPE. The workflow log should look as follows:

12. Send three line items to your process. Make sure that you send spare part number 9999, which causes an application error, at least once:

The process catches the application error and triggers the alert defined in the process:

You can check whether the application error has been thrown by the receiver ABAP proxy by calling transaction SXMB_MONI:

If your user is registered for the Alert Category PROCESS ALERT and your user in client 800 has an email address assigned to it, you can review the alert in the alert inbox: http://<server>:<port>/sap/bc/bsp/sap/ALERTINBOX/index.htm

13. The instructor will cut the connection between the Integration Server and the business system Airline_Group_One by manipulating the corresponding SM59 RFC destination:

If you now run your process, the system error exception is triggered and the control step in the corresponding exception branch cancels the process. Check this in the Workflow log:

You can check whether a system error was thrown by calling transaction SXMBI_MONI:

Make sure, that the RFC-Destination is working again before you proceed. 14. Run the process with the spare part numbers 2000, 3000, and 4000. Since the materials 1000, 2000, 3000 are always marked as missing in the system, the preparation check will return a message with the spare part numbers 2000 and 3000. To check this, call transaction SXMB_MONI and select any messages where the sender service is your process:

In this request message you should see all spare part items transferred to the preparation check:

If you select the message in transaction SXMB_MONI the receiver service is your process and the receiver interface is prep_sync_abstract - you can check the preparation response.

In the response you can see which materials will be created in the next exercise: