Introduction

There have been a lot of enhancements to the SAP MII Messaging Services over the last couple of releases where we have introduced a few new features for both the IDoc and HTTP Message Listener.  This document will cover in detail the various options for the SAP MII Messaging Services and will include examples on how this feature works but it is the recommended way to receive messages from SAP or third-party messaging systems (ie: SAP PO, Microsoft BizTalk, TIBCO, etc…).  Additional detail and documentation is available online here: Message Services – SAP Manufacturing Integration and Intelligence

Overview

The first “I” in MII stands for “Integration” and this is exactly the topic that will be covered in the below and will center around the topic of asynchronous messaging between systems using HTTP (Yes, HTTPS & SSO are supported but this needs to be configured in the ICM layer of NetWeaver) and it is cluster safe.  The basic process flow for incoming messages through this interface is:

1. Message Listener – Receives a message and identifies the message Name & ID
2. Message Processing Rule – Based on the Name, message is processed based on the processing type defined.  There are two Processing Types:
   1. Transaction – Message is processed to a queue and then a transaction is immediately triggered to process the message
   2. Category – Message is processed to a queue where it waits to be processed by a scheduled job

Visually the flow looks like this:

Detailed Operation

It is well known that the Messaging Services have two types of listeners, an ABAP listener (IDoc & RFC) and a generic HTTP listener (Any XML).  All messages upon receipt from a listener are copied and persisted in the MII database, to ensure that data is not lost.  This also enables MII to track the state of the message for an infinite amount of time to ensure proper tracking and handling.  In order to cleanup messages (based on their state) from the MII database a set of “Message Cleanup Rules” has to be configured in order to remove documents.  This must be configured or you run the risk of filling your database since MII, by design, will not remove any messages on it’s own.  If you want to see documents based on various filter criteria that have been received and their state you can use the “Message Monitor” page to view the documents received and their contents.  This page is essentially providing a view into the following MII table in the NetWeaver database: XMII_JCO_MESSAGES.

IDoc and RFC Listeners

These listeners are well defined and documented on how to set them up and were among our first use cases to receive information from the SAP ERP environment.  It also support Best Effort and Exactly Once (EO) messaging with ERP.  There are a lot of documents out there that explain how this works so I will not get into detail in setting these up other than to point to them:

• SAP Library – MII Message Services (Recommended) – Sending IDocs and RFCs to SAP MII
• SAP Process Integration Act as Adapter for SAP MII integrating with Enterprise Applications
• IDOC Listeners in MII 12.1 (and 12.2)  (Please reference SAP Note 1494757 for additional configuration & setup information).
• How to Send an IDoc from SAP ECC to SAP MII IDoc Listener (MII 12.0 and ECC 6.0)
• How to Send IDocs from the SAP R/3 Enterprise to the SAP xMII 11.5 IDoc Listener OR How to Send an IDoc from the SAP R/3 Enterprise… | SCN

HTTP Message Listener

This message listener is however not talked about quite as much but is very important to the overall integration and messaging capabilities of the SAP MII product.  It also supports the following quality of service options Best Effort, Exactly Once (EO), and Exactly Once In Order (EOIO) in order to guarantee consistency in processing and also the tracking of messages.  In order to setup these features one must first understand how they work and what the various parameters involved look like and they are outlined in the help documentation here: Message Listeners – Message Services – SAP Library

Please note that in order to ensure that a message sent to MII over this interface does not create a session each time a request is made, be sure to include the &Session=false parameter in your URL. This is very important as you can exhaust the number of concurrent sessions very quickly which will cause NetWeaver (and therefore MII) to stop responding to all  subsequent web requests.

Configuring the Listener

There are two primary ways to specify the message name and unique identifier for each incoming message (in the IDoc/RFC listener this is captured automatically) over the HTTP interface and one is to specify it in the URL and the other is to pull it from the contents of the XML message.  The first scenario is easy and well documented in the MII Help here: Quality of Services – Message Services – SAP Library

The second option of pulling these values from the received XML document is lesser known but also very important to work with.  This feature requires that you have an XSD (All IDocs in ERP have XSDs you can generate via TCode: we60) and it is imported into one of your MII projects.  Then in the MII Listener administration page select the “XMIIMESSAGELISTENER” from the table and press the Edit button:

From here, lower on the page, you will see the configuration settings available to add an entry that will be used to determine the Message Name and Message UID values based on the payload of the document.  Select the Browse button for the Schema and pick an XSD for a document you expect to get via this interface (My example uses the MATMAS01 XSD generated by we60):

Next step is to specify the XPath to the “Name” of the document (in my case the document type is mapped as the name) and yes complex XPath syntax can be used here (ie: Concatenation of multiple values).  Then from here also choose the path for the “Message UID” field (I choose the Document Number field):

Now that this is completed the HTTP Listener now knows how to determine the name and UID fields from the message contents.  In the case where the incoming document does not have these XPaths the listener will go on to the next schema mapping until it finds a match.  If no match is found then the message is stored but in a state of “No Rule”.

Configuring the Processing Rule

As previously mentioned there are two types of Processing Rules that can be defined and they are Transaction and Category.  The Processing Rules are defined the same way for IDoc, RFC, and HTTP listeners but are defined specific for each listener interface.  They can contain the wildcard character of “*” in the name in order to “catch-all” messages coming in on this interface, even if nothing is done with them, so that they can be tracked and eventually implemented.  It gives a nice way to know what else is coming in on this interface in case you need to limit what is sent or implement a new message handler.  They are processed for a listener in the order that they appear in the Processing Rules table and the wildcard entry should be the lowest on the list.  So your entry should look something like this:

Please note that if you have multiple inputs to the transaction handler you can map them to various inputs from the message and use them in your processing logic…MessageUID, MessageID, and Received XML are all available options for this.

Configuring a Cleanup Rule

Finally, the last step is to setup cleanup rules so that you do not overload the NetWeaver database since as previously mentioned all received XML documents are persisted in the XMII_JCO_MESSAGES table until a cleanup rule removes them.  You can set a variety of cleanup rules and here’s an example of how to ensure that nothing over 20days is kept in the table and of course you can fine tune this based on the message processing status:

Hope this helps and please feel free to comment…thanks,

Sam