“If you find a path with no obstacles, it probably doesn't lead anywhere. “ - Frank A. Clark True but in this weblog we try to make things ‘obstacle free’ by using XPath in receiver determination to route a message to different systems. Let’s take a real time scenario where a file is needed to be routed to different systems according to the result of some validations on the same. The file , say comes from System A and after validations performed if found valid is to be passed onto System B else if it is found to be an error file its sent back to System A. The Data type of the incoming file is as shown below: 
Assume the validations to be done are • Check whether the field FILENAME has the value ‘RDFILE’. • The total of all the amount fields (DT_RECORDS) is required to be equal to the value in the field SUM (DT_TRAILER). If the above stated conditions are satisfied it’s termed a valid file (to be sent to System B) else it’s an invalid one (sent to System A). The target message date type is as shown below: 
The field SET will be populated during the message mapping. The value in this field will later be used in determining the receivers. We will need to have 3 message interfaces. 1. MI_RD_OUTBOUND (outbound asynchronous of type source [DT_RDtest] ) 2. MI_RD_ABS (abstract asynchronous of type target [DT_RDtestoUTPUT] ) 3.MI_RD_INBOUND (inbound asynchronous of type target [DT_RDtestoUTPUT]) We would be using an Integration process, a simple receive and sent so as to get the target structure (RDtestoUTPUT) in the condition editor during the receiver determination. The following screenshots will give an idea about the IP. 
The Container Declarations: We have RDMESSAGE of type MI_RD_ABS (Abstract Interface). 
The Properties of Receive and Send steps: Receive: 
Send: 
The message mapping is as shown below: 
The below screenshot describes the logic of populating the value for the field SET: 
With text function equalsS , the FILENAME is compared against a constant ‘RDFILE’. The code of the user defined function “ChkSum” calculates the sum of all the AMOUNT entries and then compares it to the value in SUM. If they are equal it returns a value of 0 else 1. The “AnyError” function returns 0 if all the validations are successful else it returns 1. Note: The Context of the AMOUNT field is set to the root node MT_RDtest so that all the amount values are available in an array during computation of the sum. 
The next step is the Interface mapping as shown below: 
We use the Target Interface as MI_RD_ABS. Now let’s move to the Integration Directory: The two Business Services are BS_RECEIVER_ShabZ and BS_SENDER_ShabZ. If the file is found to be valid we route the message to BS_RECEIVER_ShabZ else it is sent back to BS_SENDER_ShabZ. The overall Configuration Scenario is as shown: 
After we have configured the Communication channels (in this case there are 3 of them, one sender and two receivers), we configure the Sender agreement (Sender: BS_SENDER_ShabZ, Interface : MI_RD_OUTBOUND, CC: CC_RD_SENDER_SHABZ). Since we are using a BPM and there are two receivers, we would be configuring two receiver agreements for the same 1. Sender: IP_RD_TEST, Interface: MI_RD_INBOUND, Receiver: BS_RECEIVER_ShabZ. 2. Sender: IP_RD_TEST, Interface: MI_RD_INBOUND, Receiver: BS_SENDER_ShabZ. Now we come to the Receiver Determination. The first receiver determination features the sender service as BS_SENDER_ShabZ with the interface as MI_RD_OUTBOUND and the receiver as IP_RD_TEST. 
The Interface mapping IM_RD is specified in the same.
The second Receiver determination has the sender as IP_RD_TEST. In the configured receivers, we add the services BS_SENDER_ShabZ. We then open the Expression editor and using XPath select the SET field.
Then using the condition editor we specify the condition. In case of the invalid file we have the SET field with the value 1. 
We repeat the same steps after adding another service BS_RECEIVER_ShabZ, the only difference being the value of SET would be 0 for the valid file. 
Once the interface determination is done for these, and each component is activated , the message finds its path without any obstacles. NOTE: It is also possible for us to use XPATH functions in the editor itself and hence reduce the effort in writing logic in term of lines of code. Please refer to the following forum thread for more information on the same
Assume the validations to be done are • Check whether the field FILENAME has the value ‘RDFILE’. • The total of all the amount fields (DT_RECORDS) is required to be equal to the value in the field SUM (DT_TRAILER). If the above stated conditions are satisfied it’s termed a valid file (to be sent to System B) else it’s an invalid one (sent to System A). The target message date type is as shown below: The field SET will be populated during the message mapping. The value in this field will later be used in determining the receivers. We will need to have 3 message interfaces. 1. MI_RD_OUTBOUND (outbound asynchronous of type source [DT_RDtest] ) 2. MI_RD_ABS (abstract asynchronous of type target [DT_RDtestoUTPUT] ) 3.MI_RD_INBOUND (inbound asynchronous of type target [DT_RDtestoUTPUT]) We would be using an Integration process, a simple receive and sent so as to get the target structure (RDtestoUTPUT) in the condition editor during the receiver determination. The following screenshots will give an idea about the IP. The Container Declarations: We have RDMESSAGE of type MI_RD_ABS (Abstract Interface). The Properties of Receive and Send steps: Receive: Send: The message mapping is as shown below: The below screenshot describes the logic of populating the value for the field SET: With text function equalsS , the FILENAME is compared against a constant ‘RDFILE’. The code of the user defined function “ChkSum” calculates the sum of all the AMOUNT entries and then compares it to the value in SUM. If they are equal it returns a value of 0 else 1. The “AnyError” function returns 0 if all the validations are successful else it returns 1. Note: The Context of the AMOUNT field is set to the root node MT_RDtest so that all the amount values are available in an array during computation of the sum. The next step is the Interface mapping as shown below: We use the Target Interface as MI_RD_ABS. Now let’s move to the Integration Directory: The two Business Services are BS_RECEIVER_ShabZ and BS_SENDER_ShabZ. If the file is found to be valid we route the message to BS_RECEIVER_ShabZ else it is sent back to BS_SENDER_ShabZ. The overall Configuration Scenario is as shown: After we have configured the Communication channels (in this case there are 3 of them, one sender and two receivers), we configure the Sender agreement (Sender: BS_SENDER_ShabZ, Interface : MI_RD_OUTBOUND, CC: CC_RD_SENDER_SHABZ). Since we are using a BPM and there are two receivers, we would be configuring two receiver agreements for the same 1. Sender: IP_RD_TEST, Interface: MI_RD_INBOUND, Receiver: BS_RECEIVER_ShabZ. 2. Sender: IP_RD_TEST, Interface: MI_RD_INBOUND, Receiver: BS_SENDER_ShabZ. Now we come to the Receiver Determination. The first receiver determination features the sender service as BS_SENDER_ShabZ with the interface as MI_RD_OUTBOUND and the receiver as IP_RD_TEST. The Interface mapping IM_RD is specified in the same.The second Receiver determination has the sender as IP_RD_TEST. In the configured receivers, we add the services BS_SENDER_ShabZ. We then open the Expression editor and using XPath select the SET field.
Then using the condition editor we specify the condition. In case of the invalid file we have the SET field with the value 1. We repeat the same steps after adding another service BS_RECEIVER_ShabZ, the only difference being the value of SET would be 0 for the valid file. Once the interface determination is done for these, and each component is activated , the message finds its path without any obstacles. NOTE: It is also possible for us to use XPATH functions in the editor itself and hence reduce the effort in writing logic in term of lines of code. Please refer to the following forum thread for more information on the same
4 Comments
