SAP Extended Warehouse Management (EWM) has evolved over the period, and hence the integration design and mechanisms with Manufacturing Execution System (MES) too has witnessed substantial development over the period. This progressive evolution took place right from the beginning of the erstwhile classical EWM deployment on SCM servers to the latest EWM deployments on S/4 HANA.
In classical EWM deployments before version 9.1 the most commonly used method was "Delivery Based Integration" for the production Integration (i.e. for EWM-PP Integration) and hence during that period the EWM-MES Integration too had an influence on the usage of such Delivery Based Integration method for the Interface design. However, over the period, with an introduction and popular adoption of "Advanced Production Integration" in EWM, the MES Integration design too started evolving to adopt and leverage on this new and advanced integration method. Advanced Production Integration has tried to bridge some of the old pitfalls of Delivery Based Integration and also paved the way for the introduction of the SAP provided out-of-the box APIs (Application Programming Interfaces) using Advanced Production Integration. These APIs are also proving to be good enablers for the seamless communication techniques like webservices instead of an older IDoc based communication.
In this article, I would be sharing with you my experiences and learnings while designing a robust EWM-MES process Integration pattern and technical Interface design. As depicted in the schematic below the essential components of EWM Integration with MES are falling into 5 main business process areas: Goods Issue (Consumption), Goods Receipt, Staging, Packaging sync-up and Inventory sync-up.
EWM-MES Process Integration
| # | Process Integration Components | Use |
| 1 | Goods Issue (Consumption) | MES posts the consumption of components staged to the production supply area and communicates the message to EWM for posting the goods movement. |
| 2 | Goods Receipt | MES posts the Goods Receipt (GR) of finished or semi-finished products and communicates the message to EWM for posting the goods movement. |
| 3 | Material Staging | For supply of components to the shop floor which would be eventually used in the production execution, there can be two ways: either push based staging or pull based staging. In a push-based staging, EWM pushes the components to MES based on planned production dates in PMR (Production Material Request, this is possible by executing the staging report in EWM. Staging can be for a specific production order for which components are reserved (called as single-order staging) or the staging can be consolidated for multiple production order quantities together (called as cross-order staging). Another form is crate part replenishment, which is a kind of push-based staging whereby components are staged periodically based on PSA replenishment criteria. In a pull-based staging, MES pulls the components to production supply area by sending messages to EWM, staging is performed according to the actual production requirements and planning needs communicated by MES. |
| 4 | Packaging Sync-up | In a Handling Unit (HU) driven process, it is essential that both EWM and MES are in sync with each other when HUs are staged, consumed and received. This is required whenever there is any repacking like handling unit consolidation or deconsolidation taking place at the production shop floor and hence the updated packaging structure has to be reflected in EWM based on communication from MES. |
| 5 | Inventory Sync-up | EWM being a WMS system, acts as a Single Point of Truth (SPoT) system for the warehouse “Stock/Inventory Management”, hence in similar lines of ERP-EWM stock synchronization, the same is expected for the EWM-MES stock syn-up, since both the systems are tightly Integrated for the production goods movement. EWM typically being a SPoT system, any Inventory differences with MES needs to be posted and settled in the leading system. |
Best practices in the design of EWM-MES System Integration
- Establish clearly which system is “Consumer” and which system is “Provider” for each of the process integration components and interface messages.
- Identify what is an exact trigger for the interface message and the related business process step or event, and when the Interface will be invoked, like at specific period or the real time trigger etc.
- Communication between two systems should be based on message response/confirmation from either side so that feedback loop is complete; for example once the message is transferred to the consumer system, the acknowledgement/confirmation would be sent back by API to the provider system or to a middleware.
- Graphically depict an end to end message flow with a feedback mechanism so that all events and stages in the process integration is clearly represented without ambiguity on the system communication part.
- Leverage as much as possible the standard EWM out-of-the box technical objects, this would make sure that the evolving EWM system post-system upgrades and during maintenance cycles is not facing stability issues and shorter life cycles of the Integration data models.
- Following important aspects related to the error communication should be considered during the design:
- It is very essential that the sender system needs to be informed when the message transmission to the target system goes into error. This error communication can be a direct or to be handled by the middleware layer, if it is used.
- Interface-related errors have to be stored for specific periods and a specific target user group can be informed.
- In case of planned or unplanned outages in the both partner systems, either the sender or the middleware needs to have the ability to stop the Interface and trigger the dispatch of non-transmitted messages again to the receiving system. When systems are up and running after the outage is over and the system is recovered, the messages must be restarted and flowing in the same sequential manner with time stamps considered.
- The complete list of data fields for each interface message should typically cover both import and export data field structure in the Interface program of EWM and the field to field mapping between EWM and MES systems should be based on such exhaustive list. One can choose to map only mandatory fields to process the message, however from the future scalability and design foolproof ness, it’s also important to cover and map the optional fields that are important from the process integration point of view. Data fields listed for the specific message should clearly state the reference database table in which data value is finally stored (both in the source and target systems), along with its technical properties in terms of data field length, decimal and type.
- Selection of a right technical method for Interface programming technique is extremely important, because choosing the right technical objects and methods for both the message trigger and message consumption decides how robust is the Integration from both the system performance and efficiency point of view. For example, SOAP web services provide better cloud readiness for future cloud migration perspective and SOAP/REST webservices provides the synchronous message processing capability as against IDoc which is asynchronous one.
- Message monitoring and re-processing capability in EWM is another important factor in the Interface design. The way ERP-EWM transactional interface is queue based (i.e. qRFC based), which gives ability to monitor as well as re-process the message in a specific sequence; like that even MES-EWM Integration can be based on a queue mechanism. For example, if queue concept is decided to be used then one can simply call the standard SAP provided out-of-the box function module inside the Interface program, to generate a queue as soon as the message is received or sent from the EWM system. In case of errors found in message, one can simply go to the transactions like SMQ1 and SMQ2 to re-process the failed queues and re-trigger the message processing. The EWM warehouse monitor can also be configured for queue monitoring. Monitoring and error handling mechanisms like SAP AIF (Application Interface Framework) is quite user friendly and desirable for asynchronous message processing. In case of SOAP webservices are used, one can also use SRT_UTIL tool natively integrated in the EWM system for monitoring and error handling of web services.
- Message packet structure and size should be a critical factor in the technical design of the Interface, to determine if the message exchanged between EWM and MES would be based on each message item or a complete message itself. For example, while sending consumption data from MES to EWM, it should be known and decided prior if the consumption message should be sent to EWM per single HU or for the whole pallet based on the master handling unit. If the whole pallet information is sent, then if any of the single HU for which consumption posting goes into the error, it may risk the whole message for a master pallet going into error.
Summary: There are basic foundational elements or the best practices for building a robust design of EWM-MES process integration and technical Interfaces. When these foundational elements are treated like guiding principles then one can surely achieve the very basic objective of having a design which is completed in all aspects.
References:
My blog on EWM-MES Direct Integration For Receiving HUs in EWM
Thanks to author Prakash Pol
