Alert Management
Exercise 4: Checking Materials in the SD System
Exercise Objectives
After completing this exercise, you will be able to:
• Use a transformation step
• Use a synchronous send step
• Use exception branches
Business Example
If a material does not exist in the customer's sales system, it must first be created. In this exercise you use a synchronous call to check whether the material exists or not.
The materials to be created are specified in the response to the synchronous call.
The procedure is as follows:
The order items are collected in the itemlist container element. The Preparation part of the integration process sends the materials to the SD system in a synchronous call.
Inbound processing in the SD system checks whether the material exist. Any materials that do not exist in the system are specified in the response to the synchronous call.
(You will create them in a later exercise.)
Furthermore, if the SD system does not recognize a material, an application error is triggered in the alert inbox.
If a system error occurs the process is canceled.
Task:
Execute a synchronous call to the SD system to check whether the missing materials have to be created.
The response message contains the materials to be created. If a material does not exist in the SD system, an application exception is created, that is, an alert is triggered. You can check this in the alert inbox.
Business System Airline_Group_One represents the SD system.
A mapping has already been created that you can use to transfer the Itemlist multiline element, which contains messages, to the list element that contains header data and the unbounded Lineitems element. The name of the mapping is itemlist2list.
The synchronous prep_sync_abstract interface, which is used for sending for the message contains a list of materials to be created. The response list is saved in the new preplist container element.
The receivers of the send step are determined in the context of the SAP Process Integration Infrastructure.
1. Minimize the ReceiveOrderItemBlock block that you created in the exercise in the Step Types (Part 1) and Correlation lesson.
2. Define a new standard block, Preparation, with two exceptions: SystemError and ApplicationError.
3. The order items collected in the itemlist container element are transferred to the list container element. First, define the new list container element followed by the transformation step.
Create a new container element with the name list that references the list_abstract abstract interface and that belongs to the process container.
4. Using the itemlist2list interface mapping, insert a transformation step with the name PrepTransformation. The source message is itemlist, the target message is list.
5. The call to the SD system is a synchronous call. The response, that is, the list of materials that have to be created is saved in the preplist container element. You have to define this element.
Create a new container element with the name preplist that references the
6. Insert the SendPreparation send step. Set the mode of the send step to
synchronous. The send step uses the prep_sync_abstract synchronous interface.
The request message is list and the response message is preplist. Create SystemError for the system-error exception, and ApplicationError for the application-error exception.
To determine the receiver, use the data for receiver determination that is defined in the Integration Directory.
7. Create the exception handling for the application and the system errors.
Using the context menu, add two exception branches for the SystemError and ApplicationError exception handlers.
8. Call transaction ALRTCATDEF in the system and create a new alert category PROCESS_##. ## stands for your group number.
EnterProcess Alert, Group ##as the alert description.
Assign your user to the alert category as a receiver.
Caution: Since multiple groups need to call transaction ALRTCATDEF at the same time, response times may be longer than expected.
9. In the exception handler, enter thePrepControlAppExceptioncontrol step for the ApplicationError exception. The control step should trigger an alert of alert type PROCESS_##. You can choose the alert message yourself. An example would be Preparation Checks Group ## failed. ## stands for your group number.
10. In the exception handler branch for the SystemError exception, insert the PrepControlSysErrorcontrol step to cancel the process.
11. Check, save, and activate the process.
12. Test the integration process by performing three different tests.
First variant: Test the situation where all three materials do not exist in the SD system.
Use the HTML client to send three individual items to your process. Check your process by calling transaction SXMB_MONI_BPE.
Use the materials 1000, 2000, 3000 to test your process.
13. Second variant: Trigger an application exception. Use material 9999 as one of your materials.
Continued on next page
Open the HTML client again and send three individual items. Ensure that one of the items has the spare part number 9999. This causes an application error. Check the workflow log and your alert inbox. The workflow log should look as follows:
Figure 35: Workflow Log with Application Error
14. Third variant: Test the material check with two materials that do not exist and take a look at the request and response message.
Execute the process again with the spare part numbers 2000, 3000, and 4000.
Since the materials 1000, 2000, and 3000 are always marked as “missing” in the system, the preparatory check creates a message that contains the spare part numbers 2000 and 3000. To check this, call transaction SXMB_MONI and select all the messages in which your process is the sender service. Select the last send message and check that all the individual items in the request message were transferred to the preparatory check. To check the response, select the messages in transaction SXMB_MONI that have your process as the receiver service and prep_sync_abstract as the receiver interface. The materials that are to be created in the next exercise are displayed.
Solution 4: Checking Materials in the SD System
Task:
Execute a synchronous call to the SD system to check whether the missing materials have to be created.
The response message contains the materials to be created. If a material does not exist in the SD system, an application exception is created, that is, an alert is triggered. You can check this in the alert inbox.
Business System Airline_Group_One represents the SD system.
A mapping has already been created that you can use to transfer the Itemlist multiline element, which contains messages, to the list element that contains header data and the unbounded Lineitems element. The name of the mapping is itemlist2list.
The synchronous prep_sync_abstract interface, which is used for sending for the message contains a list of materials to be created. The response list is saved in the new preplist container element.
The receivers of the send step are determined in the context of the SAP Process Integration Infrastructure.
1. Minimize the ReceiveOrderItemBlock block that you created in the exercise in the Step Types (Part 1) and Correlation lesson.
a) Choose ReceiveOrderItemBlock and Minimize from the context menu or choose the minus sign at the top of the block on the left.
2. Define a new standard block, Preparation, with two exceptions: SystemError and ApplicationError.
a) Insert a block step after the minimized ReceiveOrderItemBlock block.
b) Switch to the Properties area.
c) Step Name: Preparation d) Mode: Default
e) Exceptions: SystemErrorand, in a new line,ApplicationError 3. The order items collected in the itemlist container element are transferred to the
list container element. First, define the new list container element followed by the transformation step.
Continued on next page
Create a new container element with the name list that references the list_abstract abstract interface and that belongs to the process container.
a) Switch to the Container view in the Object area.
b) Name: list
c) Category: Abstract Interface d) Type: list_abstract
e) Multiline: not selected f) Scope: Process
4. Using the itemlist2list interface mapping, insert a transformation step with the name PrepTransformation. The source message is itemlist, the target message is list.
a) Drag a transformation step to the Preparation block.
b) Switch to the Properties area.
c) Step Name: PrepTransformation.
d) Operation Mapping: itemlist2list.
e) Source Messages→ item_abstract: itemlist.
f) Target Messages→ list_abstract: list.
5. The call to the SD system is a synchronous call. The response, that is, the list of materials that have to be created is saved in the preplist container element. You have to define this element.
Create a new container element with the name preplist that references the list_abstract abstract interface and that belongs to the process container.
a) Switch to the Container view in the Object area.
b) Name: preplist.
c) Category: Abstract Interface.
d) Type: list_abstract. e) Multiline: not selected.
6. Insert the SendPreparation send step. Set the mode of the send step to
synchronous. The send step uses the prep_sync_abstract synchronous interface.
The request message is list and the response message is preplist. Create SystemError for the system-error exception, and ApplicationError for the application-error exception.
To determine the receiver, use the data for receiver determination that is defined in the Integration Directory.
a) Insert a send step after the transformation step.
b) Switch to the Properties area.
c) Name: SendPreparation.
d) Mode: Synchronous.
e) Synchronous Interface: prep_sync_abstract. f) Request Message: list.
g) Response Message: preplist.
h) Receiver From: Send Context.
i) Exceptions→ System Error: SystemError.
j) Exceptions→ ApplicationFault: ApplicationError.
7. Create the exception handling for the application and the system errors.
Using the context menu, add two exception branches for the SystemError and ApplicationError exception handlers.
a) Select your Preparation block.
b) Right-click the context menu.
c) Choose Insert→ Exception Branch.
d) Repeat the last step.
e) Select the uppermost exception branch and switch to the Properties area.
f) EnterSystemErroras the value for the exception handler.
g) Repeat the last step with the second exception branch and enter ApplicationErroras the value for the exception handler.
8. Call transaction ALRTCATDEF in the system and create a new alert category PROCESS_##. ## stands for your group number.
EnterProcess Alert, Group ##as the alert description.
Continued on next page
Assign your user to the alert category as a receiver.
Caution: Since multiple groups need to call transaction ALRTCATDEF at the same time, response times may be longer than expected.
a) Call transaction ALRTCATDEF in the training system and switch to change mode by choosing Display/Change.
b) Choose the Create Alert Category icon (white sheet of paper on the right-hand side of the screen).
c) EnterPROCESS-##as the alert category. ## stands for your group number.
EnterProcess Alert, Group ##as the alert description.
d) Select the entry and choose the Fixed Recipient icon.
e) Choose New Entries and enter your userBIT430-##as the receiver.
f) Save your entries.
9. In the exception handler, enter thePrepControlAppException control step for the ApplicationError exception. The control step should trigger an alert of alert type PROCESS_##. You can choose the alert message yourself. An example would be Preparation Checks Group ## failed. ## stands for your group number.
a) Drag a control step to the ApplicationError exception branch.
b) Switch to the Properties area.
c) Name: PrepControlAppException.
d) Action: Throw Alert.
e) Alert Category: PROCESS_##.
f) Source: Alert Server
g) Alert Message: Preparation Checks Group ## failed.
10. In the exception handler branch for the SystemError exception, insert the PrepControlSysErrorcontrol step to cancel the process.
a) Drag a control step to the SystemError exception branch.
11. Check, save, and activate the process.
a) Check, save, and activate the process.
12. Test the integration process by performing three different tests.
First variant: Test the situation where all three materials do not exist in the SD system.
Use the HTML client to send three individual items to your process. Check your process by calling transaction SXMB_MONI_BPE.
Use the materials 1000, 2000, 3000 to test your process.
a) Open the HTML client.
b) Ensure that the process definition is SellSpareParts_0## (## stands for your group number).
c) Send each item three times.
Use the materials 1000, 2000, and 3000.
d) Call transaction SXMB_MONI_BPE. Choose the message for your SellSpareParts_0##. receiver service.
e) Double-click Process Selection and choose either Execute or press F8.
f) Select your process in the Work Item Type line under (Sub)Workflow, and in the Work Item Text line under SellSpareParts_0##.
g) Select the line by double-clicking. The workflow log should look as follows:
Figure 36: Workflow Log (change!)
13. Second variant: Trigger an application exception. Use material 9999 as one of your materials.
Continued on next page
Open the HTML client again and send three individual items. Ensure that one of the items has the spare part number 9999. This causes an application error. Check the workflow log and your alert inbox. The workflow log should look as follows:
Figure 37: Workflow Log with Application Error
a) Open the HTML-Client.
b) make sure that you have choosen the prozess definition SellSpareParts_0##
and ## is your group number.
c) Send three positions and change the spare part number at least once to 9999.
d) Call the transaktion SXMB_MONI_BPE .
e) Select the Process Selection by Double Click by Double Click and Execute or chose F8.
f) Select your prozess in the line Work Item Type under (Sub)Workflow and in the line Work item text under SellSpareParts_0##.
g) Select the line by Double Clicking. The workflow protocol should look as followed:
Figure 38: Workflow Log with Application Error
h) Call the Integration Builder (transaction SXMB_IFR) and navigate to the Runtime Workbench.
i) Open the alert inbox. The alert you triggered is displayed.
Continued on next page
14. Third variant: Test the material check with two materials that do not exist and take a look at the request and response message.
Execute the process again with the spare part numbers 2000, 3000, and 4000.
Since the materials 1000, 2000, and 3000 are always marked as “missing” in the system, the preparatory check creates a message that contains the spare part numbers 2000 and 3000. To check this, call transaction SXMB_MONI and select all the messages in which your process is the sender service. Select the last send message and check that all the individual items in the request message were transferred to the preparatory check. To check the response, select the messages in transaction SXMB_MONI that have your process as the receiver service and prep_sync_abstract as the receiver interface. The materials that are to be created in the next exercise are displayed.
a) Open the HTML client.
b) Ensure that the process definition is SellSpareParts_0## (## stands for your group number).
c) Send the individual items with the spare part numbers 2000, 3000, and 4000 three times.
d) Call transaction SXMB_MONI.
e) Open the Monitor for Processed XML Messages.
f) Enter your processSellSpareParts_0##as the sender service and execute the query.
g) Select the last message sent and display it.
h) The Maindocument payload of the inbound message should look as follows:
Figure 39: Request Message
i) Return to the Monitor for Processed XML Messages and create the SellSpareParts_0## process as the receiver service. Enter prep_sync_abstractas the name of the receiver interface. Ensure that the value for the sender service has been deleted.
j) Execute the query.
k) Display the last message sent.
l) The Maindocument payload of the request message mapping should look as follows:
Continued on next page
Figure 40: Response Message and Mapping
Lesson Summary
You should now be able to:
• Explain the step types transformation, send, control, and wait
• Explain the concept of exception handling in ccBPM
• Define exceptions in integration processes