Introduction
A few months ago I had what I thought was a unique problem when I was asked to process payment confirmations for a supplier. The supplier would FTP XML documents to us and the content would be used to update our R/3 system. The problem was the documents would be one of three types, which isn’t an issue in itself. However, they would have the same file name prefix (the suffix was a timestamp in case you are wondering) so it would be impossible to identify the contents by referring to the file name. As I would be using a single communications channel to import the files how would I process different XML documents through single interface? I found most of the information I needed in Weblogs and Forum postings but it took a while to put it together. So I thought I would blog the solution for future reference.
Scenario
The following example is a simple HTTP to RFC Synchronous scenario. The scenario will accept two very different XML documents, map them to one of two RFC’s and return the results to the requestor. I’m going to create four Data Types, four Messages Types and a single Message Interface. I require two outbound types, an inbound response type and a generic type. You don’t need to create a generic type, you can use one of the outbound types but I wanted make the scenario easier to support in the future. To keep things as simple as possible I’m returning the data to the requestor using a single data type.Design
1) Create the Data Types, Message Types and Message Interface as normal. Remember to create a generic Data Type/Message Type with a single element.
2) The Message Interface is shown below. You will notice that the ‘Output’ Message refers to the Generic Message Type.
3) Import the RFC’s. I’ve picked a couple of random RFC's used in the past.
4) Create two Interface Mappings. One of the IM’s is shown below. You will notice that the Source Message refers to the Generic Message Type. This isn’t a problem and I’ll explain why later.
4) Double click on the Mapping Program name to create the Message Mapping for the request. When the Message Mapping program is created the inbound Message Type will refer to the Generic Message Type. Change this to the required Message Type and map as usual. 
Now create the Message Mapping for the response. Unlike the mapping for the request the correct message type will be prepopulated. Then repeat the process for the second message.
Configuration
1) Create the Receiver Determination referencing the Message Interface you created earlier. Select the service you wish to communicate with and save the document. Expand the service under ‘Configuration Overview…’, right click and select ‘New Specific’ to create the Interface Determination.2) The interface determination will have two inbound interfaces and each will require a condition. Click on insert to add a second row to the ‘Configured Inbound Interfaces’. Add entries for the Inbound Interface and Interface Mapping.
The clever part is the condition. This is how XI decides where to send the document. In this example I’m checking for the existence of an element within the XML document. This is done using the expression editor and creating an XPath expression but there’s a problem. The structure you will be presented with will be the Generic Message Type. You’ll need to build the expression manually. Click on button in Condition which will display the Condition Editor. In the Condition Editor click on the button in the ‘Left Operand’ field to display the ‘Expression Editor’.
In the Expression Editor enter the condition in the field entitled ‘Xpath Expression’. Click on OK to return to the Condition Editor and make sure you select the ‘EX’ operand.
Then click on OK to return to the Interface Determination. Repeat the process for the second Interface. The completed Interface Determination is shown below.
3) Return to the Receiver Determination and create the Receiver Agreements as normal.
Testing
I tested this using the HTTP test tool I found here on SDN. Test with both payloads and then go to SXMB_MONI and review the results. You’ll notice that the same message is directed to different interfaces.
Summary
This is a very simple way of managing multiple documents using a single interface. It’s been in production for several months without incident. When tackling this problem I assumed the payloads were validated against the schema when the message ‘hit’ the interface. I now know the payloads aren’t checked until they are mapped. This occurs during Interface Determination. Understanding this will help you to understand how the solution works. Most problems I experienced were with the Interface Determination Conditions and it didn’t take too long to sort them out.
Bluesky
