Skip to Content
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).    image
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Johan Göthberg
    A very good blog indeed. I just want to comment about the handler list of the ICF service for the plain HTTP adapter…

    Since the handler list supports multiple handlers you can Instead of copying the standard class CL_HTTP_PLAIN_INBOUND to your own class and change the implementation you could easily register a new class before the standard class in the handler list. The task of the new class would be simply to set the required parameter in the URL. The benifit would be that SP upgrades of class CL_HTTP_PLAIN_INBOUND would still take effect even though you have modified the behaviour of the HTTP Adapter.

    Rgds Johan

    rgds Johan

  2. Vijayashankar Konam
    You mentioned in the blog that, it should work with almost all the adapters. Does it work with SOAP sender, given that, SOAP sender adapter does not support adapter module beans?


    1. Alessandro Guarneri Post author
      Hi VJ,
      I know that modules are not “officially” supported in SOAP sender adapter, so the answer to your question is just inside yourself 😉

      That said, there’s a way in which you can adjust common modules code to run inside SOAP sender channels (it’s hacking once again, but it works: SAP won’t support it, but it’s up to you and your customer at the end of the day).

      See this one I’ve just written for you and the Community! 🙂


  3. Alejandro Pertierra

    Allessandro, I am facing a similar problem but i need, if you have it, the snipped code you implemented in the adapter_plain service as you mentioned in the blog “…so I built my custom http plain adapter.



Leave a Reply