Ok, what's all this about? Say you need to serialize XI messages using EOIO quality of service, but a serialization for Service/Message Interface is not enough: in fact, in this case, you would simply put a suitable queue name on the sender channel, that each message for that peculiar service/interface would go into. That was not enough for me, as I needed a serialization for service, message interface and some content inside the message: we could call this technique CBS (Content Based Serialization), which goes arm in arm with the standard CBR (Content Based Routing) one would use in Routing Objects. h3. A Real Life Example Suppose you're uploading goods movement to SAP ECC (the receiver) with IDoc, and the sender is a legacy system dumping a flat file. The legacy is allowed to create a new goods movement, but also to reverse it (if needed), and finally send the correct goods movement again. Well, we all know that this is a sequence of documents that must get into SAP ECC in the right order, so why not using EOIO? And more, if you are in SAP ECC you have a 6.40 WebAS working behind the scenes, so you can use IDoc Serialization over there, which perfectly suites in this scenario (you can problably use other techniques such as the SERDAT IDoc in older SAP releases, but I won't cover them here). Now you may be wondering why not using the std EOIO stuff... Well, if you put all the goods movement messages (and possibly reversal) in one queue only, when the first error occurs - be that mapping error on XI or application error in SAP ECC during IDoc inbound process - you're gonna have the whole queue stopped, with all other "potentially good" messages waiting over there until someone doesn't realize the situation and fix the problem. Very annoying in this case, and not even correct from an application standpoint. Now say you have a "reference document " field (or element, xml speaking) you can use inside your related messages: for instance, in the case of Goods Receipts, you'll probably have a Purchase Order number as reference. So the story goes like relating messages based on this field. h3. Assumption The magic won't happen if one basic rule is not guaranteed by the sender system: in case of dumping flat files, the sender system must at least use a file naming convention that will let an XI File Sender Communication Channel have the chance to process them in order. file naming convention should simply do the job, given the timestamp in a suitable format, such as YYYYMMDDHHmmSS (also milliseconds, if available, won't hurt). h3. Which Adapters Can Be Used? As you will shortly see, I had to make this thing working almost everywhere. So I had to develop two pieces: 1. an Adapter Engine module that can be used basically on any Sender Channel 2. a custom http plain adapter on the ABAP stack. h3. The Module As in other weblogs o' mine, I'm not delving here into the technical details of building up and deploying a module (browse SDN and you'll easily find tons of documentation on this topic) but just pasting the code. There's nothing special to mention (I've done no hacks this time ;), except the need for an external library I used for XPath processing: Apache Xalan. You can donwload it from {code:html}here{code} and include it in your EJB project as an external library, so that it'll be packaged and deployed along with the module itself in the final .EAR file. +Note for TechGurus+: in this case I just needed the queue name to be set, and so I used a msg.setConversationId(qid) statement, but very very easily other important message attributes could be set as well, such as msg.setCorrelationId(corrID) msg.setRefToMessageId(rmsgID) and so on. I little change in the code and parameters handling is needed for this to happen... h3. The custom http plain adapter Wow. Why should you ever need this kind of stuff when dealing with such an evolved application that is able to send XML messages via http protocol? Well, you know, the world is not that perfect and, at least in my case, the external application was indeed capable os sending XML messages over http directly to XI ABAP stack via plain adapter, but not enough smart to look inside the XML message and build up the correct URL. As a matter of fact you probaly know (this must be stated somewhere in the doc) that the URL for http plain adapter can be built like this: * call-syntax: XI 3 * http://hostname:port/path * ?namespace=??? * &interface=??? * &service=??? * &party=??? * &agency=??? * &scheme=??? * &qos= EO (BE) * (&msgguid=???) * (&queueid=???) * [&trace=[1|2|3]] What does this suggest us? That whenever you set a "qos" (quality of service) to EOIO (Extacly Once In Order), you should as well set the "queueid" parameter with a suitable value. But in my case, as I said, the sending application was not managing this itself, so I built my custom http plain adapter. Behind XI http plain adapter there's an interesting ICF (Internet Communication Framework) service. You can have a look at it going to trx SICF (/sap/xi/adapter_plain). 
9 Comments
