Manufacturing execution processes require information from various sources. For example, the planning information and manufacturing orders are generated from the ERP system, whereas the actual order execution is controlled by the manufacturing execution system (MES) on the manufacturing shop floor. The actual process parameters and execution information are captured in various legacy real-time systems such as Plant Historian or legacy databases. This end-to-end scenario shows how to receive production order data from SAP ERP, send it to a manufacturing execution system (MES), and update the actuals and confirmations in ERP upon receiving confirmations from the MES or through user interfaces. It includes the use of Message Services in SAP Manufacturing Integration and Intelligence (SAP MII) with its Quality of Service (QoS) and processing rule features and Business Logic Services (BLS).  

MES Background

  One of the key requirements for manufacturing execution data management is transferring the manufacturing orders and other relevant data from ERP to the MES, as well as getting the confirmations and actual data from the MES and other legacy applications used in the manufacturing shop floor, to update in ERP. Most of the MES applications being delivered by different IT vendors are based on different data models and technology platforms. That means the information is not always seamlessly integrated out of the box with any ERP application. A typical MES application may need information from the ERP system, such as material master data, material classification, bill of material (BOM), routings, resource and equipment master, as well as transactional data, such as production orders and inventory, to manage the production process at the shop floor. Each of these details may come from the ERP application via different interfaces and at different intervals. For some of the interfaces, a strict sequence also may need to be maintained while sending the data to the MES. For example, before sending the production orders from ERP to the MES, you need to ensure that all the materials and work centers used in the production order are already sent to the MES application. Without the materials and work center information, the order may not be processed and the information is not displayed to the user for execution. The interface format for ERP and the MES may often be different, which requires a transformation of the data fields while exchanging the information. To standardize the MES interfaces, often industry standards such as ISA95-B2MML-based interfaces are used so that the same interface format can be reused. Because an ERP application may not natively support B2MML interfaces or an MES-specific interface format, the mapping between the ERP interface formats to the MES interface format and vice versa should be done before transferring to the target system. SAP MII is an application development and integration platform that enables integration to SAP ERP by supporting various protocols, such as Java Connector (JCo) and Java Resource Adapter (JRA), for connecting to an SAP ERP system via Remote Function Call (RFC) and IDoc interfaces, as well as web services, HTTP, File Transfer Protocol (FTP), and Java Database Connectivity (JDBC) for connecting to MES applications. It also provides a business logic engine you can use for data transformation, data persistency, or aggregation, all of which are required for ERP-MES integration. Apart from that, the monitoring of the interfaces can be done in SAP MII to understand any error that may occur during the message processing or transfer to the target system. SAP MII provides connectors for both inbound and outbound messages to integrate with ERP and MES applications. Message Service is the feature provided by SAP MII to receive inbound messages from external systems. It provides listener services to receive messages using HTTP Post from MES or any other system, as well as messages from SAP ERP using RFC and IDoc interfaces. SAP MII provides the connectors to execute RFCs using SAP JCo and JRA interfaces, web services, HTTP calls, and various other connectors such as JDBC (SQL Queries), File Transfer, and OPC to send data to external systems. BLS in SAP MII provides the composition and development environment. SAP MII’s BLS enables you to develop any logic for the data parsing, enrichment of the messages before sending to the target system, or any validation. The BLS in SAP MII can persist information for the messages in a custom data model, called Manufacturing Data Objects (MDOs), as required. Finally, using the visualization services of SAP MII, the monitoring of the messages received and sent to different systems can be provided. In my scenario for this article, SAP ERP sends production orders by IDoc interface to the MES. You need to map the production orders to a specific XML format before sending them to the MES by the WebService interface. The MES then processes the production orders and sends a confirmation back as an XML message either by file or by HTTP interfaces. The confirmation updates the order confirmations in SAP ERP. All the messages being passed back and forth need to be buffered for retrying in case of connectivity failures and monitoring. SAP MII acts as the middleware to transform and receive and send the messages between these two systems. Figure 1 shows the overall architecture of the solution and the features provided by SAP MII in this aspect.

Integrating SAP ERP with SAP MII to Send Messages

An IDoc interface is one of the common interface types used to send messages from SAP ERP to SAP MII or any external systems. It transfers the messages in Application Link Enabling (ALE) format asynchronously to the target system. An IDoc interface can also be triggered from SAP ERP on specific events, such as a production order release. Next, I explain how SAP MII can receive the messages from SAP ERP and process them for sending to the MES.

Configuring the Message Listener in SAP MII

The Message Service in SAP MII provides a framework through which messages sent from any system can be received, buffered, and processed by custom user-defined rules. It enables three different types of listeners to receive IDoc, RFC, and XML messages by HTTP Post. I explain how to configure and use the IDoc and RFC listeners to receive messages from SAP ERP using these interface types and to explore the XMIIMessageListener for receiving XML messages by HTTP Post. An IDoc listener provides the interface through which SAP MII can receive any message sent by SAP ERP or any ABAP-based system using IDoc protocol asynchronously. Similarly, messages using asynchronous transactional RFC (tRFC) can be also sent to SAP MII using the RFC listener. In a new type of listener in the latest release of SAP MII for synchronous RFC (sRFC) call, the processing rule is executed in SAP MII and the output is returned to the calling RFC in the ABAP system synchronously. To receive the messages in MII, the message listener in Message Service needs to be configured along with the RFC destination in SAP ERP. I start with the IDoc listener configuration in SAP MII. As the IDoc and RFC listeners in SAP MII use SAP JRA for the connectivity, those need to be configured in the SAP NetWeaver Administrator (NWA) in the SAP NetWeaver Java Web Application Server (AS) where SAP MII is installed. To configure the listeners, open NWA using the URL https://<host>:<port/nwa in a web browser. Host and port in the URL are the hostname/IP and HTTP port of the NetWeaver WebAS where SAP MII is installed. Follow menu path Configuration > Infrastructure > Application Resources. Filter by Resource Adapters. There are 10 predefined adapters available each for IDoc and RFC as XMIIIDOCxx and XMIIRFCxx, where xx stands for 01 to 10. Another 10 adapters are available for synchronous RFCs (sRFCs) as XMIISRFCxx. Figure 2 shows the list of the JRA adapters available in NWA for IDoc and RFC listeners of SAP MII. To configure the IDoc listener, select an IDoc listener (e.g., XMIIIDOC01). This action displays the details shown in Figure 3. Click the Properties tab displayed in Figure 3. Specify the ProgramID that is used in the RFC destination configured in the sender system. It can be any string and should be unique across all JRA connections configured in the system. Specify the MaxReaderThreadCount as 1, the SAPClient as the client of the sender system, and UserName, Password, and Language of the sender system. The ServerName should be the hostname or IP of the sender system and Portnumber is the system number of the sender system. Leave the BindingKey as is, as it should be XMIIIDOC.   Now the corresponding configuration needs to be done in the sender (ABAP) system to complete the connection. Open the RFC destination configuration by executing transaction code SM59 after logging in to the sender ABAP system. This action takes you to the screen shown in Figure 4. Create a new RFC destination of type TCP/IP by entering T in the Connection Type field. In the Activation Type section in the Technical Settings tab, select the Registered Server Program option. Specify the program ID used in the resource adapter configuration in the SAP MII server as shown in Figure 4. In the Gateway Options configuration section (not shown in Figure 4), specify the gateway hostname and the gateway service for the same server. You can find those values by executing transaction code SMGW, which displays the parameters. Select the Unicode option in the MDMP & Unicode configuration tab and save the configuration by clicking the save icon. If you want to configure the security settings such as using Single Sign-On (SSO) or Secure Network Communication (SNC) so that you can use same credentials to log in to SAP MII and the sender system and encrypt the message while transferring, specify the SSO and SNC options in the Logon & Security tab. After the resource adapter is configured in NWA and the RFC destination is set up in the sender system, open the SAP MII administration menu using https://<host>:<port>/XMII/Menu.jsp. Follow menu path Message Services > Message Listeners. Select the message listener just configured and click the Update button to update the configuration in SAP MII. You can edit the configuration to change the description text and the message name to be used for the inbound IDoc messages. You can use either the IDoc name or the IDoc type, when the IDoc is received in SAP MII. The RFC destination can be configured exactly in the same way as explained above in NWA and the sender ABAP system. After the RFC destination that is configured, you need to update the RFC listener configuration from the Message Listeners menu in SAP MII. In this menu you can edit the configuration to retain the legacy format. Retaining the legacy format ensures that the <TABLE> element remains in the XML message of the RFC, if it contains table elements in its structure. Test the connection by clicking the Connection Test option in the RFC destination in the sender ABAP system. If the connection test is not successful, check the configuration parameters and restart the resource adapter in SAP NetWeaver from the NWA. Follow menu path Operations > Start & Stop > Java Applications. If the configuration is correct and the connection is successful, the system ID of the sender system is populated in the SAP Server field along with the SAP Client and SAP Program ID as shown in Figure 5. Next, you need to create the ALE configurations to send the IDoc from an ABAP system to SAP MII. To send RFC messages, no other configuration needs to be completed. They can be sent by executing the RFC using the RFC destination created. For my scenario, production orders need to be sent to SAP MII, transformed into the MES interface, and then sent to the MES. You need to create the Partner Profile, Logical Port (the Logical Port refers to the RFC destination), and logical system and distribution model by the usual ALE configurations in the SAP ERP system. After the ALE configurations are complete, the IDoc message can be sent to SAP MII by using either transaction code POIT or by a batch job to generate an IDoc or a certain event, such as a production order release. A LOIPRO IDoc message can be used to send the production order data.

Configuring Message Processing Rule

If the LOIPRO IDocs are sent from SAP ERP to the RFC destination pointing to SAP MII, you can see that SAP MII receives the messages and displays them from the Message Monitor menu available under the Message Services menu category in SAP MII (Figure 6). However, note that the messages are marked as No Rule in the Status column. This is because no processing rule has been defined so far, and the messages are received in SAP MII and just buffered without any subsequent processing. For my scenario, you need to map the IDoc messages for production orders received in SAP MII to the MES format. The format is a Business to Manufacturing Markup Language (B2MML) XML format provided by an XML Stylesheet Document (XSD). To enable processing the messages in SAP MII for mapping or any enrichment or transformation, you need to define a processing rule in message services that will do the necessary transformation of the message as required and send the message to the target system. To create a message processing rule, open the Message Processing Rules menu under the Message Services option as shown in Figure 7. Click the Create button. Specify a name of the processing rule with an optional description text. Select the message listener for which the rule will be used (messages received by that listener will be processed by this rule). Depending on the type of listener selected, the message type is selected automatically. You can either specify * or a specific message name, which signifies whether the processing rule will be used for all types of messages received in the message listener (e.g., different IDoc messages such as LOIPRO, LOIROU, or MATMAS) or for a specific message type. For processing the message there are two options available: a transaction-based processing rule or a category-based rule. A transaction-based rule requires a BLS transaction developed on SAP MII, which will be executed immediately when the message is received in SAP MII with the message content along with some other attributes of the message passed to it. Depending on whether the processing transaction is executed successfully or not, the status of the message will be determined as Processed or Failed. A category-based processing rule just needs a category name to be specified in the processing rule. When the message is received in SAP MII, it is tagged to the specified category with the message status set to Categorized. A categorized message can be queried by the BLS transactions for further processing.  (I cover this process later.) For a transaction-based processing rule, the processing transaction must have an input parameter of type XML to receive the message content of the incoming message. Additionally, it can also have the input parameters of the type string to get the Message ID and Message UID of the message being processed. Message ID is a unique identifier assigned automatically to each message received in an SAP MII message listener, whereas MessageUID is the message identifier assigned by the sender system. A sample processing rule configuration to process a LOIPRO IDoc message is shown in Figure 7.

Developing Processing Rule Transaction

Now you need to develop the logic inside the processing rule transaction to transform and send the message to the MES as required. Open the SAP MII workbench from menu path Content Development > Workbench menu and create a new transaction. Add the three input parameters in the BLS transaction as MessageID, MessageXML, and MessageUID as required by the processing rule. You add three main logics inside the transaction: store the message details with status information for monitoring, transform the IDoc message structure to the XML structure required by MES, and send the transformed XML message to MES. To store the message information for monitoring, use MDOs. An MDO is a data persistency layer available in SAP MII. It uses the underlying SAP NetWeaver database. The data model using an MDO has to be developed for each application with the corresponding queries to insert, update, and query the data as required. You create a new MDO from the SAP MII workbench with the attributes to store the message information as shown in Figure 8. The objective is to store the basic information of the message such as plant code, order number, material number, and start and end time of order so that it can be searched later by these parameters. The mapping status and dispatch status store the status information and timestamp of the message transformation and dispatching operations, respectively. In the processing rule BLS transaction, first you use an MDO query with insert mode to insert the message or order information into the MDO. Then the logic for mapping or transformation of the IDoc message has to be executed. You include that logic in a separate BLS transaction and call it from the parent transaction created for the processing rule. After the mapping transaction call, you check the status from that transaction’s output parameter to check whether the mapping or lookup has been executed successfully. If this mapping was successful, the dispatch function is executed as a separate transaction call again. If the mapping or dispatch fails, the corresponding status of the message is updated in the MDO using an MDO update query. Otherwise, the status is updated as successful. On any error, a throw action is used to raise an exception. A catch action is used to catch any technical exception that may occur during the execution and after logging, throwing an exception again so that the status of the message in the message service becomes failed. The BLS transaction structure is shown in Figure 9. You can incorporate the mapping logic either by BLS transaction actions or by using XML Style Language Transformation (XSLT). XSLT is an XML file with the logic to transform from one structure to another with the XPath of the source and target XML elements. It is better to use XSLT for large XML messages as the performance of XSLT is better for handling large messages instead of BLS actions. The XSLT mapping can be executed by the XSL Transformation action block available in the BLS workbench. For the dispatch function, the corresponding action for the required protocol of the MES should be used. Usually MES applications support SOAP WebService or HTTP through which the message can be sent. Table 1 shows some of the protocols you can use to send a message to MES from SAP MII.

Protocol	Description
Simple Object Access Protocol (SOAP)	If the MES provides SOAP Web services, the WebService action available in BLS can be used to send the message. For a WebService call, the target application (i.e., MES) needs to provide a Web Services Description Language (WSDL). The WSDL enables the WebService interface to be executed to send the message in the request payload.
HTTP Post	The HTTP Post action block in BLS transaction can be used to send an XML message as payload in HTTP Post. This can be used to call Java Servlet applications as well.
Write File or FTP	The Write File action or the FTP Input action enables the message that is going to be sent to the MES to be transferred to a directory in the file system from where the MES application can read it.
Queue Write Topic Publish	The Java Messaging Service (JMS) Queue Write or JMS Topic Publish actions enable messages to be sent to an MES application asynchronously through a JMS service. From there, the MES application can read the messages based on the queue or topic.
SQL query	If any of the above protocols are not supported and the database access to the MES application is available, then SQL queries can be used to directly insert the data in the MES database via an IDBC (JDBC) connector in SAP MII.

After the processing rule is developed, you can send messages again and check the Message Monitor. When the message is received in SAP MII, the transaction specified in the processing rule will be executed and the message should be processed successfully. You can check it from the Message Monitor menu under Message Services in SAP MII as shown in Figure 10.           If required, you may also develop a logic to receive an acknowledgment message from the MES asynchronously to ensure the message sent to the MES is successful. The asynchronous acknowledgment message can be sent by the MES to the SAP MII message service using HTTP Post, referring to the original message ID that is sent to the MES. In the next section, I explore how the MES or a non-SAP external system can send a message to SAP MII. Similarly, other interfaces for material master, work center, routing, and inventory can be sent to the MES from SAP ERP via SAP MII as required. If required, you can develop a logic to process messages sequentially when multiple messages of different interfaces are sent together (e.g., processing material master before production orders). To enable that, it is better to use category-based processing instead of transaction-based processing of messages.

Integrating the MES with SAP MII to Send and Process Messages

After receiving the production order data from ERP, the MES starts the execution process. After the execution is over or perhaps during the execution, the confirmation for the production orders and other related messages, such as goods movement information, batch characteristics, and quality inspection results, may be sent by the MES to be updated in ERP. The MES may send the information in an XML message. The format can be an industry standard such as Business to Manufacturing Markup Language (B2MML) or a format specific to the MES. The information can be updated in SAP ERP by executing a Business API (BAPI) or RFC. SAP MII again acts as the middleware in this scenario to receive and buffer the messages and transform and execute the RFC in SAP ERP to update it. SAP MII can receive messages from an external system asynchronously through an HTTP listener, which is called XMIIMESSAGELISTENER. Unlike the RFC and IDoc listeners, there is a single listener provided in SAP MII for receiving XML messages through HTTP calls, as the same listener can receive messages from different external systems at the same time. An XML message can be sent to an SAP MII HTTP listener by sending it to the following URL by HTTP Post: https://<server>:<port>/XMII/Illuminator?service=WSMessageListener&mode=WSMessageListenerServer&NAME=<UniqueMessageName>, where the host and port are the IP or hostname and the web port of the SAP MII server. A name of the message can be specified in the message URL itself to the parameter NAME. This SAP MII message listener supports Exactly Once (EO) QoS to ensure a message is processed only once, even if it is sent multiple times. For example, if the same message is sent twice by mistake from the source system, the second message is flagged as a duplicate in its status and is not processed. This is enabled by sending a MessageUID in the URL while sending this message: https://<server>:<port>/XMII/Illuminator?service=WSMessageListener&mode=WSMessageListenerServer&NAME=<UniqueMessageName>&MESSAGEUID=<UniqueMessageUID> The MessageUID value must be unique across all messages sent to the same SAP MII server. For RFC and IDoc messages, the UID is automatically taken from the transaction ID generated by the sender SAP system. For messages sent through HTTP listener, the UID must be specified by the sender application in the URL. This feature is useful as the sender system may send a single message multiple times due to a manual or program error, such as a production order confirmation or goods movement information. Updating the same information multiple times in ERP from multiple messages can cause serious issues, which can be prevented by this feature. The HTTP listener also supports an Exactly Once in Order (EOIO) QoS to ensure the messages are processed once and in a strict sequence, if required. This is useful when multiple messages are sent that are dependent on each other, such as a production order confirmation and goods movement. The scenario can be that unless the order confirmation is processed, the goods movement should not be sent to the ERP system. However, due to network latency, although the messages are sent in the same order from the source MES application, they may be received in SAP MII in different order. To ensure that the messages are processed in the sequence defined by the source system, a sequence name and a sequence number can be specified in the URL while sending the message to SAP MII: https://<server>:<port>/XMII/Illuminator?service=WSMessageListener&mode=WSMessageListenerServer&NAME=<UniqueMessageName>&MESSAGEUID=<UniqueMessageUID>&SEQUENCENAME=<SequenceName>&MESSAGENUMBER=<MessageNumber> The sequence name becomes a category name in the SAP MII processing rule and the sequence number is used to process the message in a strict sequence in that category. The sequence number must be an integer with incremental count. Unlike IDoc and RFC listeners, the XMIIMESSAGELISTSNER does not need any specific configuration for setup, as it is not specific to any system. It is a generic servlet program running in the SAP MII server to which any external system, including a program from SAP MII, can send an XML message by HTTP Post. The only configuration required for this listener is whether you want to specify the message name and message UID dynamically. In the message listener from the Message Services > Message Listener menu, you can specify an XML schema document (XSD) available in the SAP MII workbench to specify the message structure that is sent to the listener. Then you can specify the XPath (i.e., the element in the XML document), the value for which is used to get the message UID and message name dynamically. One such example is shown in Figure 11 with a B2MML ProductionPerformance message. After SAP MII receives the message, it is available in the message service buffer, which can be processed by a processing rule. In this case, as production order confirmations are needed to be processed sequentially for different operations in the orders, you use a category-based transaction rule to process it. Figure 12 shows the configuration of the processing rule, where a category named ProductionConfirmationQueue has been used. The message is sent with EOIO QoS using the URL  https://<server>:<port>/XMII/Illuminator?service=WSMessageListener&mode=WSMessageListenerServer&NAME=ProductionPerformance&MESSAGEUID=<UniqueMessageUID>&SEQUENCENAME=ProductionConfirmationQueue&MESSAGENUMBER=<SequenceNumber> When the ProductionPerformance messages are received in SAP MII, they are tagged to this category and not processed by any transaction automatically, as shown in Figure 13. Note that the processed time is still blank, which indicates the messages are not processed yet and the status is categorized. These messages are supposed to be queried and processed by a separate custom BLS transaction. This is useful in this scenario, as you want to ensure the messages are processed sequentially even though they may have been received in a different order due to network latency. Now I show how to develop a BLS transaction to query and process the messages. First, create a new MDO from the SAP MII workbench for storing the order confirmation details as shown in Figure 14. Here only the basic information and status of the message are stored. The rest of the information can be obtained by querying the message with the message ID as well as by joining with the OrderStatus MDO created earlier by the order number, which is the foreign key between these two MDOs. You need to create MDO queries to insert and update the details. Typically, OrderNumber and MessageID are inserted initially, and the ProcessingStatus, DispatchStatus and ErrorLog attribute values are updated later. Create a new BLS transaction in the SAP MII workbench and add a Query Message action available under Message Services action category. Specify the parameters in the action block configuration as shown in Figure 15 to query the categorized messages only for the specific category. Note that the message status is selected as Categorised, indicating that only the messages assigned to the specified category and in categorized (not processed) status will be queried. From the link configuration of the Query Message action block in the BLS transaction that you can open from the context menu of the action, specify the StartDate link expression as dateaddhours (datenow, -1) and EndDate as datenow. This sets the date range as current time to last one hour. The Query Message action will query and return an XML document with a list of all messages satisfying the selection criteria. The message metadata information for the output XML message is shown in Table 2.

Element Name	Description
MessageId	Message ID assigned to the message by SAP MII message service
MessageUID	Message UID that is provided by the sender system in URL parameter while sending the message
JcoServerName	Message listener where the message is received. In this case it is XMIIMESSAGELISTENER. For IDoc and RFC messages, it will be the corresponding XMIIIDocxx and XMIIRFCxx.
MessageName	Name of the message
Category	Category or sequence of the message if available
MessageNumber	Sequence number of the message if available
MessageType	Type of message indicated (IDoc, RFC, or WebService [HTTP XML]). It provides a numeric value indicating 1 for IDoc message, 2 for RFC, and 3 for HTTP XML.
Status	The status of the message specified by a numeric value as follows: RECEIVED = 1 PROCESSSED = 2 FAILED = 3 NORULEDEFINED = 4 RUNNING = 5 CATEGORIZED = 6 DUPLICATE = 7
DocNumber	Document number is relevant only for IDoc messages.

The messages list is returned in ascending order of received time and message number, if present. You can parse the XML document of the message list to get the individual messages and process them as required. To access a list of messages that the query selected, add a Repeater action below the Query Message action and specify the XPath for repeating from the output XML of Query Message action (Figure 16). To get the XML document for each message, add a Read Message action below the Repeater action and map the message ID from the Repeater action to the Read Message action using the Read Message action link configuration, as shown in Figure 17. You can also add an additional check to ensure the message number is sequential, checking the last and current message number. If there is a problem, you can stop the processing to wait for the missing message. The Read Message action has an output parameter named MessageDocumentXML that provides the XML document of the message it reads. Using XPath expressions, you can read the data from the XML messages. Add a Reference Document with a sample message or XSD for the message to this property of the Read Message action so that the XML document structure becomes available on this property at design time. This step helps in the mapping. After this, the BLS transaction logic is the same as the BLS transaction developed for processing the production order messages. You need to execute an MDO query to insert the message information in the OrderConfirmation MDO. Then execute a BLS transaction to transform the MES message structure into the BAPI structure as required to create a production order confirmation in SAP ERP. Based on its execution status, update the processing status of the confirmation message in MDO by executing the MDO query. If it is successful, execute the BLS transaction to update the data in SAP ERP by executing the RFC or BAPI interface. You can execute the RFC or BAPI using either SAP JCo or SAP JRA interface actions available in the BLS workbench. The transformed message generated from the MES XML needs to be passed to the Request parameter of the JCo or JRA action. As BAPI calls are synchronous, check the response message returned by it, and if there is no error, update the dispatch status of the confirmation message. If required as part of the mapping, you can also enrich the message with additional details, probably queried from another system or database. One such scenario might be that you are getting production order confirmation messages from the MES and goods movement information from a material handling system or in-process quality inspection result from a LIMS application. You can query the additional information from the other systems based on some key value, such as an order and an operation number, while processing a message. Then you can merge these messages and execute the BAPI to update them. You can get the additional data from the external system by WebService or SQL query interfaces available in SAP MII from the processing transaction. Finally, you need to update the status of the message in message service using the Update Message action available under the Message Services action category. Specify the message status depending on the success or failure of the mapping and dispatch actions on the Configuration of Update Message action as shown in Figure 18. Link the message ID from the Repeater action to the input parameter MessageID of the Update Message action. This updates the status of the message in Message Services accordingly. You can also specify a message status text, such as Successful or Failed. After the BLS transaction is complete, add that in a scheduler job to execute periodically from System Management >Scheduler menu in SAP MII by selecting the BLS transaction just created and specifying a time period to execute. You can specify an interval in the scheduler configuration for executing the BLS transaction depending on the message-receiving frequency to query the categorized messages from the Message Services and process them.  Now you can see that the messages from the Message Monitor menu under Message Services in SAP MII have been processed as shown in Figure 19. Check in SAP ERP to ensure the order confirmations have been updated. You can also develop a custom message monitor on SAP MII to search and monitor the messages flowing through SAP MII. You can customize your message monitor as required and incorporate search fields and display fields from the message content, such as plant code or order number. You cannot incorporate these fields in the standard Message Monitor available in SAP MII. In a custom message monitor, you can also query the message information from the MDO and display the same in a web page developed using SAP UI5. You can store the additional message parameter values that are required to be displayed for each type of message, such as plant code or order number, in a separate MDO related to the order status or confirmation status MDO by the message ID. One such example of a custom message monitor is shown in Figure 20. You can develop the logic to provide a guaranteed delivery mechanism by querying the messages in Failed status as well and retry processing. If there is no MES application that can send the confirmation messages directly to SAP MII, you can develop a custom user interface on SAP MII based on the production order information received from SAP ERP and a transaction user interface for manually recording the confirmation details. You can store the manually entered data in MDO and can update to SAP ERP by the RFC call. You can develop the user interface using SAP UI5 by querying the MDO via an MDO query or by creating a BLS transaction and Xacute query (to add additional logic and validation over the queries). Execute it from the SAP UI5 web pages using an XML model with the Illuminator service. An example of a custom production order dashboard is shown in Figure 21. SAP MII provides a platform in which you can develop a composite application to easily integrate SAP ERP with any MES application, develop the mash-up logic to aggregate data from different applications, and provide a central platform from which you can monitor the ERP-MES integration. You can configure IDoc and RFC message listeners in SAP MII to receive messages from SAP ERP. You can use HTTP listener to receive XML messages from external systems, such as an MES by HTTP Post. In SAP MII you can create business logic transactions to process the messages to validate the data, transform the interface format, and send to ERP and MES applications via various connection protocols, such as RFC, WebService, HTTP, FTP, and JDBC. You can also develop custom dashboards on SAP MII to manually collect the data and update that to the target systems as well as to the custom message monitor to track the status of the messages flowing through it.