Executive Summary

The ecosystem of products at SAP is continually evolving and expanding to cover new and exciting new areas everyday.  The thing that they all have in common is that they are based on the use of the HTML5 UI technology which makes them extremely flexible and user friendly for the end-users.  However, not all data exists or originates from the enterprise and more and more data is being generated from the machines that make up the operations layer (especially now that automation sensors and controls have come down so far in price).  The question and challenge for the business is where do you invest in upgrading existing or replacing equipment to provide the largest ROI or prevent the next big unplanned outage from occurring.  The adoption of new thinking methodologies like Industry 4.0 or Smart Manufacturing are founded on the linkage between the enterprise and operation(s) layers.  As this linkage matures away from non-integrated approaches of manually aggregating and reporting offline data to fully automated, real-time, and web/cloud accessible data on demand will quickly identify the holes in your data.  This realization of what you actually have and what you need is what will drive re-investment in your operations technology and in turn this will accelerate the efficiency of your overall business from the ground up.

I have also recently completed and architectural deployment options document on how and why various deployments of MII in a HANA/ESP/Lumira environment make sense and how MII fits into your overall organization; the link is here: SAP MII, HANA/ESP and Lumira (Technical)

For a more technical view of "how-to" directly leverage your MII Content inside of the Lumira product see my technical BLOG here: SAP Lumira and MII (How to)

Introduction to the Products

The realization of end to end flows of data that not only drive workflows and business processes but also provide insight into priorities and live data from manually collected data enable decisions to not only be made faster but with greater confidence and transparency across the organization.  However, the data itself has to have linkage and common terms and methodologies to get at it in an intelligent and self-service way.  This means it has to be available to business and power users so that the IT department can keep up with all of the various reporting demands.

What is SAP Lumira

SAP Lumira (Data Visualization | Business Intelligence & Analytics) is the primary tool from SAP to explore big and small data in your enterprise.  This self-service data visualization software makes it easy to combine data from multiple sources, visualize it, analyze trends, and share insights on the BI platform or in the cloud.  It's primary use case is around visualization of HANA data but it can be easily extended to reach into other systems to retrieve data and this includes the SAP MII product.  There is a vast ecosystem already around this product and is available here: http://scn.sap.com/community/Lumira

What is SAP MII

SAP Manufacturing Integration & Intelligence (MII: Manufacturing Integration and Intelligence) is the fastest and easiest way to link manufacturing processes with business operations to enable collaborative manufacturing and get the visibility you need to run your business in real time.  It's primary use cases are to service-enable the existing plant operations systems in a non-disruptive way to locally report and automate the integration between the enterprise back-end and shop-floor environments.  It has been around SAP for almost a decade now and has wide ranging usage across every industrial vertical and region that SAP covers.  A simple diagram of what MII is and how it's commonly used is here:

With some of the newer releases of the SAP MII product we have included additional features and functionality around UIs (http://scn.sap.com/docs/DOC-55991) and their development, but also around how the MII engine can expose data generically to other SAP products, like Lumira, and also to third party ISVs (like Microsoft: SAP Enterprise Manufacturing Intelligence (EMI) Solution for Microsoft Office 365).  Exposing manufacturing operations data can often pose challenges unless there is a common platform for generically exposing these heterogeneous and vertical systems.  As you found this document you should already know that there is an enormous community around the SAP MII product and the main landing page for this is here: http://scn.sap.com/community/manufacturing/mii

Use Case Scenario

When the Lumira product was first introduced inside of SAP we went over various ways that it could be integrated across and enterprise and linking live manufacturing/operations data with an enterprise UI tool was one of our primary scenarios.  This on-demand access to live manufacturing/operations data means that big data from HANA can be quickly combined with or drilled into the raw/live data at one or many manufacturing plant locations.  This provides powerful insights into manufacturing performance.  The full power of this tool has yet to be realized by many, but those out there who have started to use this have quickly realized it's potential.  To take this one step further, what if you combine asset health data from the existing CBM RDS (http://scn.sap.com/community/manufacturing/mii/blog/2014/09/09/let-s-set-the-record-straight-on-the-cbm-rds) solution to drive data into HANA around Asset Health monitoring.  Then you start to run and utilized our predictive modeling libraries inside of SAP HANA (PAL, R, & Infinite Insight) on this vast set of operations data that can be continually streamed into the HANA database (http://scn.sap.com/community/manufacturing/mii/blog/2014/09/02/streaming-data-in-the-sap-industrial-space-miipcohanaesp).  From this set of data (big data) you can drive and color code common failure points in various key assets and potentially visualize them in our 3D modeling product; visual enterprise.  Alongside of this you can quickly identify assets (and their location in your business) that are 'likely' to fail and require maintenance and reach into the live manufacturing operations environment to visualize the current operational usage and conditions for that asset.  Sounds pretty far out right, well this is maybe not as far away as you think...it is actually quite a common scenario that we hear from our customers, so common that folks within SAP have already done this; see below:

The above example combines all of the data and capabilities outlined so far in order to provide an integrated and holistic view across various systems and types of data in order to provide information to the end-user.  An important concept to gather from the scenario is that the components involved in this type of top-floor to shop-floor data analytics story are the same regardless if the topic is around asset health, quality, or operations/production forecasting.

I hope that you enjoyed this BLOG and please let me know if you have further questions or comments.

Thanks again,

Sam

Overview

It's great to see the growing interest in the way visibility from the top-floor (enterprise) can be extended to the shop-floor (operations) levels in an automated and secure fashion.  The growing maturity of end-user tools, like Lumira, for data analytics on Big Datasets contained within HANA is a fantastic way to gain insights in your business operations.  As you already know the Lumira tool can retrieve data from the HANA environment but did you know that Lumira can also retrieve data directly from the MII Query Templates?

For a higher-level view of how to leverage manufacturing operations data inside of the Lumira product see my business level BLOG here: SAP MII, HANA/ESP, and Lumira (Business).  For a step by step walk-through of how to access and re-use your MII Content from inside of Lumira go here: SAP Lumira and MII (How to)

The following document will outline the various features and the deployment options that are now available as part of the SAP MII 15.0 release and will even highlight some options available with previous releases.

Deployment Options

The above scenario is common practice to see these days and more and more customers are demanding access to central and remote data simultaneously.  There are a couple of scenarios as outlined in the aforementioned link that require coverage, but to focus on the technology and software capabilities let's focus on what deployment options are now possible with the SAP MII solution.  The positioning with the SAP enterprise story around SAP MII and HANA:

1. MII 15.0 on NetWeaver (AS Java) using HANA as the DB
   • MDO, KPI & PIC all utilize the HANA DB
2. MII 15.0 on NetWeaver (AS Java) in the HANA Enterprise Cloud (HEC)
   • By the time that you read this the term Cloud has probably already been replaced by a new term: Software Defined Networking (SDN) http://en.wikipedia.org/wiki/Software-defined_networking
3. MII 12.1 and newer pushing data to HANA Tables
   • JDBC direct via HANA JDBC Driver
   • HTTP(S) via DSXI services on HANA
4. PCo 2.3 streaming data to SAP ESP and ESP pushing into HANA
   • Manages data in-flight to create snapshots of important datasets
5. PCo 15.0 streaming data to HANA Tables
   • Manages snapshots of machine/automation data
6. Lumira native interface to MII to synchronously retrieve data from MII 14.0 and newer Query Templates
7. HANA Smart Data Access (SDA) interface to synchronously retrieve data from MII 15.0 Query Templates

All of these architectural options provide new and interesting industrial use cases but leverage the same core set of technologies to achieve them.

Architecture(s)

For those of you familiar with the SAP MII product already you already know that it's not so much a one deployment option fits all product.  Rather it will scale up and down depending on the maturity of your implementation and the use-cases you are trying to address.  Some deployment options are better suited for various industry specific use-cases and these overlap with maturity of the deployment as well...what is meant by this is that it is common to see architectures for different reasons.  There are of course pros and cons to both approaches and I do outline these here: SAP Manufacturing Implementation Architecture around limited survivability and latency of reporting built into the network but these may not matter for the specific scenario that is attempting to be addressed.  This is also covered in this document here when positioning with other SAP products, like SAP PI: SAP MII and SAP PI in the Industrial Space

Central Deployments

A centrally deployed MII environment (Note: MII 15.0 supports the HEC environment) is common to see for the handling the following scenarios:

1. Maturity - New customer looking to pilot the software, central data centers are quick and cheap to setup SAP instances and require low overhead to kick off a project and prove out value.  Please note that as the deployment matures there is a gravity that the plants/operations centers generate that pull MII closer.  See the On-Premise Deployments section for more details.
2. Maturity - Customer has multiple deployments of MII across various locations and wants to leverage the ability of a central MII instance to security communicate with other instances of MII for reporting across the various locations
3. Industry Use Case - For certain industries (ie: Utilities or Upstream Oil & Gas) there is no such thing as an on-premise deployment as the assets they are interacting with are not concentrated in a plant location but rather across various locations but these assets still interact with the same DCS/SCADA/Historian systems as the plant automation systems do, so the standard MII/PCo products are still used to collect & contextualize the data.
   • For Upstream Oil & Gas it is important to point out that we do provide an Upstream Operations Management (UOM) application that leverages SAP MII/PCo in this same architecture; details are here: Upstream Operations Management (UOM) - Upstream Oil & Gas

On-Premise Deployments

This is the most common deployment option and a locally deployed (or on-premise model) SAP MII is also very common to see in more mature customer implementations and provides the most benefit for the organization.  There is a gravity that starts to form that typically pulls MII instances towards the more mature plants as a local server provides a lot of various capabilities that are often required by the local plant employees that require a low-latency and highly-availability environment.  These two requirements almost always lead to an on-premise deployment of SAP MII and this provides a nice and easy way to scale out a deployment to accommodate many scenarios.  You can still of course keep the central instance (Note: MII 15.0 supports the HEC environment) of MII for lower volume or smaller scale plant support and also for the larger locations with more mature requirements you can also move an MII server instance to the local site.  This gives a secure footprint at the local site and also provides local visibility to the local systems along with store and forward capabilities and synchronous remote access between the central and local servers via the Virtual Data server interface for secure and lightweight MII Peer-to-Peer communication.

Architecture Diagrams

As a reference here are various architectural deployment diagrams that you can use to outline the how and why each deployment option makes sense to you and your business and they help to reinforce the above points around deployment options and the types of users interacting with the various MII application(s) you have:

SAP MII & ME : On-Premise (Discrete Manufacturing)

SAP MII : Central and On-Premise (Process & Continuous Manufacturing)

SAP MII : Central Only (Typical for Pilots, Upstream O&G, and Utilities)

SAP Lumira and MII

When working with the SAP Lumira product (Data Visualization | Business Intelligence & Analytics) it is very easy to see the value of the overall solution and how it enables enterprise business users to interact with a wide range of products and I have already outlined this in other documents here on the SDN at both a business and technical level:

     Business:SAP MII, HANA/ESP, and Lumira (Business)

     Technical:SAP MII, HANA/ESP and Lumira (Technical)

How-to Steps For Accessing SAP MII from Lumira

The first step is to download and install Lumira onto your PC and then open up Lumira:

Once Lumira starts, the next step is to select the Acquire Data option:

Select the Query with SQL option in order to browse the various SQL Data acquisition options:

Next, select from the SAP section the SAP MII option (Note: there was nothing required to load into Lumira to get this option):

From here fill in the options for your SAP MII instance like this and please note the Data source entry has a colon separating the server name and port and press the "Connect" button:

Once connected, Lumira will browse all of your content on the MII server and display a tree view of your projects and query templates and write your SQL statement:

Please note the following:

1. The MII project name cannot have spaces in it
2. Lumira today is not compatible with trending out time fields, only date is possible (This is planned for a future release of Lumira):

Example SQL: SELECT "P"."DateTime", "P"."AssetUtil1" FROM "Examples"."QueryTemplates/PCoSimTagInterpolateQuery" "P"

Finally, you can now create your visualization objects inside of Lumira and define how you would like to display your MII Query Template data:

Hope this helps,

Sam

Dear All,

When someone joins in the UI5 clan, one of the very first area of interest observed is charts and dashboards. So here's a simple demonstration of how one can create charts for a dashboard.

Prerequisites:

1. A raw data set

2. Flattened data sets(one each for a chart)

Steps:

1. Create a raw data set like:

var oData1 =  {TechKPI:[{date:new Date("2014-02-01T09:28:56"),TotalAvailability:87.3, WindAvailability:33.3, EngineAvailability:81.1, TotalEFOR:12.2, WindEFOR:5.2,EngineEFOR:15.9},

  {date:new Date("2014-02-02T09:28:56"),TotalAvailability:87.4, WindAvailability:34, EngineAvailability:81.1, TotalEFOR:11.5, WindEFOR:1,EngineEFOR:16.3},

  {date:new Date("2014-02-07T09:28:56"),TotalAvailability:87.8, WindAvailability:33.1, EngineAvailability:81.5, TotalEFOR:13.7, WindEFOR:8.7,EngineEFOR:15.7},

  {date:new Date("2014-02-15T09:28:56"),TotalAvailability:87.1, WindAvailability:33.1, EngineAvailability:81.4, TotalEFOR:13.2, WindEFOR:8.1,EngineEFOR:15.2},

  {date:new Date("2014-02-28T09:28:56"),TotalAvailability:87.1, WindAvailability:33.5, EngineAvailability:81.1, TotalEFOR:13.2, WindEFOR:8.1,EngineEFOR:16.4}]

};

2. Create a flattened data set: A viz chart needs a flattened data set to have it portrayed on the html page. A flattened dataset consists of dimensions and measure. Dimensions are mostly for axis and measures are for value trends.

var oDataset = new sap.viz.ui5.data.FlattenedDataset({

  dimensions:[

  {

  axis:1,

  name: "Date",

  value: {

  path : 'date' ,

                        formatter : function(fval) {

  jQuery.sap.require("sap.ui.core.format.DateFormat");

  var oDateFormat = sap.ui.core.format.DateFormat.getDateTimeInstance({pattern: "dd-MM"});

  return oDateFormat.format(new Date(fval));

                        }

  }

  }

  ],

  measures : [

  {

  name : 'Total Availability', // 'name' is used as label in the Legend

  value : '{TotalAvailability}' // 'value' defines the binding for the displayed value 

  }

  ],

  // 'data' is used to bind the whole data collection that is to be displayed in the chart

  data : {

  path : "/TechKPI"

  }

  });

Formatter function is used to display date as labels in a particular format.

Note: A pie chart has only one measure. Similarly for other charts, no of measures depends on the chart type.

3. Bind flattened data set to viz chart.

lib required: sap.viz, sap.ui.commons

var oLine = new sap.viz.ui5.Line({

  width:"770px",

  height:"300px",

  selectData: function(oEvent) {

  // get the event data as provided by the native sap.viz library

  var oSelectData = oEvent.getParameter("data");

  // let the dataset convert the event coordinates back to a UI5 model context

  var oContext = this.getDataset().findContext(oSelectData[0].data[0].ctx.path);

  updateChart1();

  },

  title : {

  visible : true,

  text : 'Capacity Factor (CF %)'

  },

  dataset : oDataset          //Flattened data set being referred

  });

4. Clone the data set: Even if your raw dataset is same and you want to say show one line and one area chart, though the structure of flattened data set is same still you cannot use same data set. This has one dataset per chart mapping. To facilitate in such scenarios, you can use clone() method to create clone of and existing dataset and bind it to a chart.

Simply,

var oDataset1 = oDataset.clone();

Once you have cloned data set, you can proceed as step 3.

Points to note:

1. Dimensions and measure depends on the type of viz chart.

2. One-to-one mapping between flattened dataset and viz charts. Use clone() if dealing with same data set.

Hope this helps!!

Warm Regards,

Swaroop

How to debug a SAP MII Custom Action

This document was made based on the following softwares and versions:

Server side:

• SAP MII 14.0 SP5 Patch 13
• SAP Netweaver 7.31 (VM Java Version: 1.6.0_65, VM Runtime Version: 6.1.058 24.45-b08, Kernel Version: 7.31.3301.349564.20130627115115)

Client side:

• SAP NetWeaver Developer Studio ( SAP Enhancement Package 1 for SAP NetWeaver Developer Studio 7.3 SP05 PAT0000 )

Follow these steps if you have MII Custom Actions and you need to debug its execution on server side:

1.   Configure SAP AS Java in NWDS

NWDS -> Menu -> Window -> Preferences -> SAP AS Java -> Add -> (Fill out those fieds with your MII server host ans instance number, like the figure bellow)

After that, press OK button, the server will be shown in the table:

2.   Start the debug session in NWDS

NWDS -> Menu -> Open Perspective -> Other (select SAP Management Console, like bellow)

In the left view, select your server instance and open the tree menu until find the “Process Table”.

In the center view, click with the right button in the server item to see its menu options.

Select “Start Debug Session...”

Leave the “Code Isolation” checkbox selected and press “Next” button, and after that, “Finish” button.

If the system asks you a password, use “<system>adm” user and password, in my case the user is “miqadm”, your basis team should have this password.

Wait about 1 minute and see still in the content view, the “Debug“ column, to know your debug port, like that:

My debug port is “50021”

3.   Create the debug configurations

NWDS -> Menu -> Run -> Debug Configurations.

Select “Remote Java Application” click in the button     (New launch configuration) and fill out the fields like I did:

Press “Debug” button.

NWDS -> Menu -> Window -> Open Perspective -> Other -> Debug

If everything worked, you will see the debug view like that:

4.   Create the break point in your custom Action and execute it

In your custom action java class, put a break point where you want to debug:

You need to identify your internet explorer (or your prefered browser) session as a debug session, to do it you will need to open a new internet explorer tab (in the same window that you are using MII workbench) and put there your debug url, something like this:

https://srvsqmii01:50001/@@@DEBUG@@@-20845202/

To get your debug session url, come back to SAP Management Console perspective, and do like I did:

Now, you just need to execute the MII Transaction that have your custom action, and NWDS will catch up the execution and let you to debug it.

Example of my debug session in execution:

My NWDS has catched up that execution in its debug session and now it is like this:

I hope it helps you.

The purpose of this document is to outline the most common issues which occur when connecting SAP MII to SAP ERP systems. This document outlines the configuration settings which can be checked in case these issues occur. The symptoms, the causes and the possible solutions are as stated below.

1) IDOCs sent from ECC are not received in MII. Netweaver logs have the following error:

com.sap.conn.jco.JCoException: (104) RFC_ERROR_SYSTEM_FAILURE: IdocException occurred

caused by: com.sap.conn.idoc.IDocMetaDataUnavailableException: (3)

IDOC_ERROR_METADATA_UNAVAILABLE: The meta data for the IDoc '<IDOC name>' is unavailable.#

This issue is generally caused because of an authorization problem at ECC. External systems such as MII do not usually know the current structure of the IDoc type used. You therefore need to load the meta data for these systems. This is normally done using a remote call of the SAP IDOCTYPE_READ_COMPLETE function module.

This function module returns structure information for an IDoc type and a specified release. However, if this information does not exist or if the user who makes the call does not have sufficient authorizations, the error message mentioned above is issued.

A quick check on whether an authorization issue exists can be done in MII by using JCO function action block trying to call IDOCTYPE_READ_COMPLETE. A possible resolution to this error is to ensure that the user has correct authorization objects assigned at ECC level. SAP note 16642 has a detailed introduction to IDOC authorization concept.

2) Program 'XXX' is not registered error message when connection is tested. "XXX" is program id defined when creating the TCP/IP connection.

This error message means that the program has not been registered on the SAP gateway due to some error in configurations.The resource adapter may have stopped due to this configuration error.Please make sure that you have not used rfcexec is not used to register server program.

In order to solve this issue the below steps should be tried out:

1. Clear all fields except Binding key, Language and MaxReaderThreadCount. These should remain XMIIIDOC, En and 0 respectively.
2. Restart the resource adapter which is in error condition
3. Fill in the configurations again. Please make sure that MaxReaderThreadCount is greater than 0.
4. When this adapter is saved, it should become green if all configurations are correct. The program will get registered on the gateway automatically.

3) IDOCs sent by ECC are not received in MII. The error "Bean IDOC_INBOUND_ASYNCHRONOUS not found on host" is logged in SM58.

The function module 'IDOC_INBOUND_ASYNCHRONOUS" is looked up for application link enabling. It is called by ERP system when you are sending or receiving IDOCs. If open ABAP workbench is opened in ECC you will find the function module does exist in ECC. In order to trouble shoot this issue here are a few settings which should be verified at MII and ECC.

     a) Check max reader thread count setting at the resource adapter configured at Netweaver. It should be greater than 0.

     b) The binding key of the configured resource adapter is the default one (XMIIIDOC)

     c) Destination system as configured at ECC is set as unicode.

     d) Program id configured on ECC and MII listener is same and is unique across landscape.

4) Connection test in SM59 was successful. When IDOCs are sent, the error "no Beans listening for name IDOC_INBOUND_ASYNCHRONOUS registered for <Listener name> on system <system name>

     This issue indicates a problem with settings in MII listener configuration. As stated for previous error, here also, it should be made sure that program id is unique across landscape. Also, it should be made sure that the program id is not registered manually in Netweaver. In addition the program id is unique across system landscape.

5) Connectivity test succeeds in ECC. MII listener also shows "Server Connected" status. However, when IDOCs are sent,the error RFC_ERROR_PROGRAM: 'ashost' is missing" gets logged in Netweaver.

This issue indicates that Netweaver java application server is not able to reach ECC system. Check if the configured parameter at Netweaver is correct.The below steps can also be tried in order to resolve this error:

In all probability the configured resource adapter should be in 'Red' status.

     1. Login to http://<J2EE Engine HostName>:nwa

     2. Navigate to the path Operations Management - > Start and Stop

     3. Select the Tab "Java EE Applications"

     4. Filter on Name 'tc~sapjra~temp".

     5. Stop and Start this application.

     6. Filter on the Name of the resource adapter.

     7. Stop and Start this application as well.

Check if the Adapter works fine now. An application server restart also helps in some cases.

6) IDOCs originating from ECC do not reach MII. No error gets logged.

The most common cause of this issue is duplication of program ids on multiple systems. The thumb rule to be followed while configuring program ids is that it has to be unique. Deletion of program id at one place(in case it is configured at two places) also does not work.

Another common mistake is manual registration of program ids which should never be done. Also, at MII end the Message listener status should be checked. It should be "Connected".

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

Introduction

In the past I have talked about how to leverage the power of HTML5 within MII (SAP MII and HTML 5 Demystified) and now I am going to go a step deeper and talk about how to build an HTML5 web page that can interact with and control equipment.  In this document I will explain step by step what it takes to write an HTML5 interface to the SAP MII Logic Engine.  Then from here you have the ability to process multiple commands to any of the systems that MII communicates with, including TagStore (Writes to Control Tags) commands which are used to affect the operation of your equipment.

Architecture

The basic flow of this scenario is that a user logs into MII and opens up a web page that has been designed to pass parameters to the equipment layer via writes to the tag controls (Level 1) system.  These systems can be very tightly controlled in the industrial space and are often separated out for a wide variety of reason all of which are valid but limit the amount of interaction that plant operations personnel can have.  This restriction can very often prevent workers and operations folks from efficiently performing their job, the SAP MII product is designed to securely alleviate this disconnect.

MII Content Design

When developing content for MII always look for ways to reuse and parameterize your content in order to improve the turn-around time for future development tasks and topics.  For example if you plan on handling multiple commands or are looking for ways to quickly interact with ERP, MES, or Automation system then it's best to build out standard components and re-use them across your dashboards and applications (basic, I know ).  Anyway, I built the following transaction in order to ensure that my web page or any other HMI-like page could pass a command parameter that could easily be handled and passed to an execution or automation system.  The transaction at a minimum should have the following Transaction Properties as Inputs and Outputs:

Of course in the real-world you will probably need to have additional context passed in such as Plant, Work Center or Equipment ID in order to properly identify where the control signal will go.  In this example I will omit this in order to keep it simple, but the best solution to manage this mapping is using the SAP MII Plant Information Catalog (PIC) and leverage the search service to identify the tag to use.

Now, the next step is to define a transaction that can handle multiple different types of commands and send them to one or more systems.  I recommend using the Logic -> Switch action so it is very easy to identify commands and handle unsupported ones gracefully, and it should look something like this:

In the OutputDoc XML definition, used for my response XML structure I have two columns "Command" and "Response" both of type String so that I can not only verify the command that was passed in but also capture the response message from the underlying system.  From here the next step is to simply create an Xacute Query template, point to the transaction and map the inputs.  For my example the Xacute Query template looks like this:

From here it's easy to test the technical operation of the system integration you are performing and extending it to work across one or many different MES or Automation systems.  This can be achieved via a wide range of different integration protocols such as HTTP services, PCo (OPC or Native), PAPI, SQL/JDBC, FTP, Flat Files, etc...

Web Page Design

When designing a dashboard or an application for use with the SAP MII product there are a few key design criteria to keep in mind. The main one is that everything in the MII content is exposed as a REST service via the MII Query Template layer (OData and MII XML formats).  This makes developing UIs and dashboards a quick and easy task.  In the above content example I showed a stub of how to create the structure for handling various commands.  The next step is to show how a web page can be used to link HTML buttons and events to the content and pass it a user initiated "Command".  This command parameter will be used to determine what signals are written to the Execution or Control system.

The web page you define for your content will depend on the path to your above defined query template, which I will point out as the area that will vary for you.  Here is my code snippet for an HTML5 page, that will even work on a mobile device:

<!DOCTYPE HTML><HTML><HEAD><TITLE>Kepware Control HMI</TITLE><META http-equiv="X-UA-Compatible" content="IE=edge"><META http-equiv='cache-control' content='no-cache'><META http-equiv='expires' content='0'><META http-equiv='pragma' content='no-cache'><SCRIPT type="text/javascript" src="/XMII/JavaScript/bootstrap.js" data-libs="i5Grid"></SCRIPT><link rel="StyleSheet" type="text/css" href="/XMII/CM/CustomerExamples/Common/SAP.css"><script type="text/javascript">
var debug = false;
function captureButtonCommand(btnCommand) {
try {  // Perform the call to the i5Grid Query Object  var notifsGrid = new com.sap.xmii.grid.init.i5Grid("CustomerExamples/Control/EquipmentControl5Grid","CustomerExamples/Control/EquipmentControlXQuery");  notifsGrid.getQueryObject().setParameter("Param.1", btnCommand);  notifsGrid.draw("commandGrid");  if(debug) {  // Retrieve the response from the system:  var command = notifsGrid.getGridObject().getCellValueByName(1, "Command");  var response = notifsGrid.getGridObject().getCellValueByName(1, "Response");  // Pop-up a box that shows the results of the command  alert("Successfully called command: "+btnCommand+"  Command: "+command+"  Response: "+response);  }
} catch(err){  alert("Error: "+err.message);
}
}</script></HEAD><BODY onload="captureButtonCommand('DoNothing');"><table border="1" class="SAPTable" width="90%"><tr>  <th align="center" class="PageSmHeader">Control Equipment</th></tr><tr>  <td>  <input type="button" value="Reset Environment" class="buttons" onClick="captureButtonCommand('Reset');">  </td></tr><tr>  <td>  <input type="button" value="Test" class="buttons" onClick="captureButtonCommand('test');">  </td></tr></table></div><br><div id="commandGrid" style="display:none"> <!--style="position:relative;top:0px;bottom:0px;left:0px;right:0px;overflow:auto;;" height:1;width:1 --></BODY></HTML>

The fun part about the above page is that it is very extensible and will work for any HMI scenario and you can of course add additional items to this page; or even embed other HMI pages and include this as an extra function to extend your existing operator screens.  In the case of the above scenario the page looks like this (please note I have a CSS defined which controls the look and feel and I purposely omitted this since you will likely have your own requirements):

In my case I am simply writing a value to a Kepware OPC server tag to prove out the operation of the tag store command.  Your scenario can vary widely but is ultimately up to you to decide how you wish to use the MII product in your environment.

I hope that this simple example and the HTML5 JS code snippet is useful for your future SAP MII implementations and as always comments are appreciated.

Sam

Introduction

SAP Plant Connectivity provides a Socket Source System Agent as part of its standard Source Systems agents. The Socket Agent provides a direct connection between a remote Server that exposes data on a TCP Socket, and PCo as the TCP Client. The Agent supports the Notification in an Agent Instance, but not the Query Interface directly. However, it is possible with the Agents Custom Functions from with SAP MII to open, write to, and close a Socket from an MII BLS Transaction.

Configuration

Agent

Each Socket Agent can be configured to connect to multiple TCP Connections as shown in this example:

Each Connection is identified by the following characteristics:

• Type -- IPV4 or IPV6
• Check Connection -- periodically check to see that the Server Port is open. the Check frequency is defined in the Retry Interval specified in the Reliable Connection Tab for the Agent. Each connection uses the same interval.
• Name -- a unique name for each connection
• Address -- the IP address or host name of the TCP Server
• Port -- the Port to connect to at the IP Address (Note: the IP Address - Port combination must be unique)
• Terminator -- the String of text or control characters that indicate the end of the data stream for a message. Control characters (like the CR LF terminator in the Tester connection above, are entered as HEX bytes prefixed by \.
• Length -- the number of characters that will constitute a message. (Note: Either Terminator or Length can be specified, but not both.)

Agent Instance

After creating an Agent Instance that uses a defined Socket Agent, you can create a Subscription Item for each Connection in the Socket Agent. To do so, simple use the Agent Instance Subscription Items Browse button to browse to the desired named Connection:

Each "tag" is named <connectiionName>.message, where <connectionName> is the name of the Connection in the Source Agent.

Once you have subscribed to the tags, each tag can be used in an Agent Instance Notification to receive the contents of the connection message after the terminator or length extraction has been executed, and then use that value to send to a Destination, such as an MII Transaction.

Writing to a Socket Agent Instance

The Socket Agent does not directly support the Query Interface that MII uses to read and write Tags from PCo.  However, the Socket Agent exposes some Custom Functions that can be executed from within an MII BLS Transaction to Access a server socket.  These functions are:

• GET_AGENT_STATE
• START (opens a specified IP address and Port)
• SEND (sends a stream of text data to an open IP/Port)
• STOP (closes the IP Address and Port START’ed above)

MII BLS Transactions provide the PCoQuery template for accessing PCo tags, and one of the Modes now supported is TagFixedQuery.  This mode is used in a transaction to construct the command to execute an Agent's Custom Function.  For details about how this is accomplished, Please see the New MII PCoQuery Fixed Query Mode document in SCN.

Limitations of the Socket Agent

• The data stream that the Socket Agent reads and writes is currently limit to Text.
• There is no security supported for the connection. PCo makes a direct TCP Socket connection to the server.

As always, comments and questions are welcomed.

Steve