Skip to Content
Author's profile photo Sam Castro

SAP MII Messaging Services

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:

SAPMIIMessagingServicesDiagram2.png

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:

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:

MIIMessageListenerEdit.png

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):

MIIMessageListenerEdit2.png

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):

MIIMessageListenerEdit5.png

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:

MIIMessageListenerEdit6.png

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:

MIIMessageListenerEdit7.png

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

Sam

Assigned Tags

      21 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Partha Sarathi Roy Chowdhury
      Partha Sarathi Roy Chowdhury

      As usual great document Sam. Just one suggestion from my side would be to add examples of how to achieve EO and EOIO for HTTP Messages.

      Also it may be worth mentioning that EO is now properly supported for IDOC and RFC messages as well.

      Author's profile photo Sam Castro
      Sam Castro
      Blog Post Author

      Thanks Partha,

      I omitted it because it is covered in detail in the help documentation already and was really trying to focus on the admin pages and listener operation rather than the client interface, but I agree it's a worthy topic to cover.  There are other documents other than the help, like this one: SAP Process Integration Act as Adapter for SAP MII integrating with Enterprise Applications, which cover it in lots of detail.

      Sam

      Author's profile photo Former Member
      Former Member

      Hi Sam,

      In post http://scn.sap.com/thread/2124459 Michael states that the program ID's in the MII listeners are not used anymore due to changes on NW (only ERP system and client).


      What about the situation when having 1 ERP system (corporate) and multiple MII systems (per plant/site)?

      If I then have a production order idoc (LOIPRO) that needs to be send to the correct MII system (this depends on the order plant), how to configure this?

      My first idea was to setup a listener with a specific program ID, but according to above this does not work.

      Or is the listener registration done in ERP by also using the MII hostname?

      Will this be solved in new versions (using program ID's again)?

      grt Frank

      Author's profile photo Michael Appleby
      Michael Appleby

      Hi Frank,

      Just to clarify, the Program IDs are still used, but they cannot be used in the way that Italo described to have multiple connections from a single MII installation for multiple IDoc types from a single ERP system.  If you have multiple MII installations, each can have a different connection to the ERP system and would require different ProgIDs. 

      They must be unique to a single IDoc/RFC Listener! Reusing the ProgID is the single biggest mistake people make when configuring their IDoc Listeners and used to account for about 90% of the errors encountered.  Not sure if that is still true as I have been working in different areas of SAP since doing testing on MII 12.2 (long, long time ago, it seems).

      Regards, Mike

      SAP P&I Technology RIG

      Author's profile photo Former Member
      Former Member

      Hi Michael,

      Thanks for the fast response. This makes it very clear now.

      grt Frank

      Author's profile photo Former Member
      Former Member

      Hi, I was wondering...

      when it will run a configured and enabled Cleanup Rule ?

      Does it need to be triggered manually or there is a standard scheduling?

      Tnx!

      Author's profile photo Former Member
      Former Member

      ...well I think I found the answer....that should be controlled by the

      System Property

      message.XLBL_MESSAGE_CLEANUP_INTERVAL [Hours]:

      value

      I'm right?

      Author's profile photo Sam Castro
      Sam Castro
      Blog Post Author
      Author's profile photo Former Member
      Former Member

      well I spoke too early... I noticed that after waiting configured number of hours rule isn't running alone, instead if I trigger it manually, it does what expected

      Is there anything elso to be activated?

      Thank you!

      Author's profile photo Sam Castro
      Sam Castro
      Blog Post Author

      How are you "triggering it manually" you should be using the Message Services -> Message Cleanup Rules page to configure these clean-up rules which are based on connection, message type, status, etc....

      Sam

      Author's profile photo Former Member
      Former Member

      I configured it properly through Message Services -> Message Cleanup Rules page.

      I enabled the rule and I was thinking after 1 hour (due to system param config I mentioned over) to have automatic run of the rule. It didn't work.

      To check if I did the config properly I pressed the button "RUN" of Message Services -> Message Cleanup Rules page and it did the cleanup correctly.

      How to have the rule triggered automatically?

      Tnx

      Author's profile photo Sam Castro
      Sam Castro
      Blog Post Author

      This is managed by it's own thread and the details of this thread are visible in the SAP MII Menu -> System Management -> System Jobs.  This page outlines the next run time for each cleanup and MII background management routine.  So even though you waited an hour the "next runtime" of the job may have been slightly longer because your message may not have expired when the execution of the job occurred. 

      Documentation for the jobs is available here in the help (http://help.sap.com/mii -> Help Documentation -> System Management -> System Jobs).

      Sam

      Author's profile photo Former Member
      Former Member

      well, I'm sure that when I run the cleanup rule manually, it acted deleting all the expired messages.

      message.XLBL_MESSAGE_CLEANUP_INTERVAL [Hours]: = 1


      It means that in the worst case (I could have enabled the rule just after job execution)...I needed to wait almost 2 hours

      Today I repeated the exercise:

      I created and enabled a new rule since this morning (many hours ago);

      After hours and hours, no messages have been cleaned up (basing on the rule for sure already EXPIRED and looking at [SAPXXXDB.XMII_JCOMESSAGES.RECEIVEDDATETIME);

      I ran the rule manually and they have been all deleted.

      I really think for some reason system job isn't running.

      What is exactly its name? Where I can investigate deeper?

      Thank you

      Author's profile photo Sam Castro
      Sam Castro
      Blog Post Author

      Seems to me like your NW JMS engine is out of date, typically when scheduled or system jobs fail to run this is the reason.

      Sam

      Author's profile photo Former Member
      Former Member

      What is the system job I should investigate on?

      Author's profile photo Sam Castro
      Sam Castro
      Blog Post Author

      It's an MII system job so it means that it's using an XMII_* JMS queue name behind the scenes.

      Sam

      Author's profile photo Parthi Shanmugam
      Parthi Shanmugam

      Hi Sam, Cristiano,

      Not sure this thread still can be monitored, but we too see the same symptom in message cleanup rules as Cristiano mentioned, not sure the job runs to cleanup old messages as configured. ours is MII 15.0 (NW 7.4). In the previous release(12.1) we used to see the status like "

      Author's profile photo Sam Castro
      Sam Castro
      Blog Post Author

      Sounds like an issue with the NW version of JMS you have which is outlined here in this SAP Note (among others):

      1872559 - message listener performance - http://service.sap.com/sap/support/notes/1872559

      I also recommend upgrading so that you can leverage the SAP MII Dependency Checker service that we have implemented in order to ensure that you have the proper NW component versions in the future:

      2187724 - Component version checks - http://service.sap.com/sap/support/notes/2187724

      Sam

      Author's profile photo Parthi Shanmugam
      Parthi Shanmugam

      Thanks Sam for the quick response, appreciate it. As I mentioned, we're running MII 15.0 SP4 with NW 7.4 SP11. I don't find any conflicts with any of NW components. One interesting thing noted was, when I just fake edited Message Cleanup Interval property under System properties, it appeared, that triggered the job to run?! I don't see the old messages (bases on rule configured). Not sure this behavior is because the message cleanup rule was created in 12.1 version.

      We don't have any problem with message listener performance, that works fine.  Thanks!

      Author's profile photo Sam Castro
      Sam Castro
      Blog Post Author

      Good to know, please create a ticket so that this can be investigated.

      Sam

      Author's profile photo Parthi Shanmugam
      Parthi Shanmugam

      Here's SAP's response:

      Dear Customer,

      After involving our developers to the investigation I would recommend

      to delete and add the rule again.

      It should work fine if it is created on the version what you are using

      currently.