SAP EWM MFS Communication Customizing & Master Data
With the built-in component SAP EWM MFS, automated material handling equipment (MHE) of warehouses can be connected to and can be conducted by SAP EWM. To achieve this, information has to be exchanged between SAP EWM and the control systems of the automated MHE. This blog provides insight on how to set up the system.
Customizing Interface Type, PLC and Communication Channel
Define PLC Interface Type
For different devices like pallet conveyors, case conveyors, single load handling devices, multiple load handling devices, shuttles, robots or elevators you might want to use different telegram types and/or different telegram structures. For each different interface, you define an interface type for the warehouse. To each PLC such an interface type has to be assigned, and telegram structures have to be defined per warehouse, interface type and telegram type.
Define Programable Logical Control (PLC)
Each external communication partner (May it be PLC based, some micro controller, a PC or even a sub system) for a warehouse has to be defined.
The interface type used to communicate with this PLC
Header Data Structure
The DDIC structure of the header of all telegrams used for this PLC as defined and named in the data dictionary.
Warehouse process type used for putaway warehouse tasks. Should be defined on communication point level, which is more granular. Used as fallback in case no putaway WPT is defined for a communication point.
PType MFS – Process Type Fault
Warehouse process type used for warehouse tasks in exception cases.
PType MP – Process Type MP
Warehouse process type used for postings of movements in a case conveyor context. This WPT is usually defined with the attributes immediate confirmation allowed, immediate confirmation proposed, and storage control is not relevant.
STrans-WPT – Stock Transfer WPT
Warehouse process type used for re-arrangement warehouse tasks in a multi deep storage scenario. If a HU in a deeper bin position cannot be accessed as it is blocked by one or more HUs in the front positions of the bin, these HUs a removed with transfer movements to other storage bins.
The exception code used for warehouse task confirmation in case the actual destination bin differs from the destination bin in the warehouse task. This exception code should have the internal process code CHBD for the business context MF3 (MFS telegram) and execution step A0 (Background).
For objects like bins, communication points or resources, you might want to use different names on EWM level than on PLC levels. E.g. on EWM level bin names should be readable by human beings like <storage type>-<aisle>-<side>-<stack>-<level> whereas the PLCs mostly prefer a format like <aisle><side><stack><level>.
If mapping is switched on
- it will be checked whether the table /SCWM/MFSOBJMAP (to be maintained as master data by transaction /SCWM/MFS_OBJMAP) contains appropriate entries
- a mapping BAdI will be executed, if implemented
This identification will be used to fill the field sender in the telegram header (as the PLC name will be used to fill the field receiver in the telegram header). If the field check telegram is ticked on channel level, the content of the field receiver in the header of the received telegram will be compared with this identification.
There are three different modes.
If you are working in a push mode and driven by warehouse tasks (this especially applies for resources), you have to choose “Pallet Conveyor System and Rack Feeder”.
If you are working in a pull mode and only react on telegrams from the PLC, you have to choose “Case Conveyor System”.
If you have a hybrid scenario, you have to choose “Case Conveyor System and Rack Feeder”.
In general, it is recommended to work with PLC mode “Case Conveyor System” where possible. Although there are some restrictions like missing capacity management for communication points the benefits outweigh this. Compared to the “Pallet Conveyor System and Rack Feeder” with the “Case Conveyor System” telegram processing can be significantly faster due to a slimmer warehouse task handling. E.g. warehouse task confirmations are decoupled to an asynchronous process. Also, the rough destination bin determination allows faster processing and later warehouse task creation and bin reservations.
Define Communication Channel
Here you have to define the attributes of each single connection (named channel) that will be used.
Defines how often a telegram will be re-sent, if no handshake for the telegram was received
Interval Tel. Retry
Defines after which period of time a telegram will be re-sent, if no handshake for the telegram was received
Highest Send. Seq. No.
Highest sequence number for outbound data telegram; after this number was reached, the sequence number for outbound will start again from 1.
Highest Recv. Seq. No.
Highest sequence number for inbound data telegram; after this number was reached, the next expected sequence number for inbound will be 1.
Space characters in telegrams will be replaced by this character.
Value for the header field handshake that indicates that the telegram is a handshake telegram
Value for the header field handshake that indicates that the telegram is a data telegram
These are the valid options:
We recommend using the option A – Send Complete Telegram
Indicates that sender and receiver are switched in a handshake telegram. We recommend ticking that option.
Admits parallel processing of received telegrams. If left empty, received telegram from one channel are processed one by one in the sequence they were received. Otherwise, up to the defined number of process can be run in parallel to process received telegrams. Be aware, that the defined number of processes is in balance with the number of overall available work processes.
Life Tel. Interval
Depending on the content of the attribute Life Tel. Type this value defines the period of time
- after which a LIFE telegram will be sent, if there was no traffic on the channel
- after which the connection will be re-started, if there was no traffic on the channel
Life Tel. Type
If filled, a LIFE telegram will be sent, if no traffic was on the channel for a defined period of time.
If not filled, the connection will be re-started, if there was no traffic on the channel for a defined period of time.
Note: If you use one channel just to receive data telegrams, so that EWM sends only handshake telegrams via this channel, this channel can be monitored by the system by defining a Life Telegram Interval and leaving the Life Telegram Type empty. In this case, the communication partner should send LIFE telegrams via this channel to make sure that there is some traffic on the channel within the Life Telegram Interval.
Get Seq. No.
Indicates, whether sequence number should be used for LIFE telegrams as well. We recommend ticking that option.
You can define one or two characters that will be placed in the beginning of a telegram. If you set some start character you have to respect this in the definition of your telegram header structure.
You can define one or two characters that will be placed at the end of a telegram. This especially can be used, if you have telegrams with different length being exchanged on this channel. If you set some end character you have to respect this in the definition of your telegram structure.
If you define a value here, all telegram structures have to be defined such that the length of all telegrams is the same. This applies not only to data telegrams but to handshake telegrams as well.
If you set this attribute, sender and receiver will be checked on telegram receipt.
Here you have to define the exception code that is set for a channel in case loss of connection is detected (No acknowledgement received after data telegram was repeatedly sent). If you use an exception code with the internal process code “REST”, the system will close the connection and try to re-establish the connection.
Here you can define the error code that will be sent in an acknowledgement to the PLC in the header field Protocol Error (comm_error), when EWM detects some error for a received telegram on protocol level (invalid sequence number, wrong telegram length etc.). We recommend not to set this value, but to define specific error codes as described in one of the subsequent paragraphs. You might set this value to have a fallback in case you did not set up the value for the communication error for a specific exception situation.
You can switch off the synchronizing mechanism, that can be executed when the connection is established. We strongly recommend ticking that option.
No Alive Check
You can switch of the Alive Check. Not recommended as this disables connection monitoring by the system.
Assign Communication Channel to Objects
If you use more than one channel to communicate with one PLC, you have to set up criteria for the channel determination. The decision, on which channel EWM MFS will send a telegram, is based on objects like resource, communication point or telegram type.
These are the object types used to determine a channel for telegram sending:
Contains the name of the object for channel determination.
Define Ranking Order of Communication Channel Objects
If you use more than one channel to communicate with one PLC, you have to set up in which order the objects of a telegram will be checked in order to determine the channel for sending the telegram.
These are the object types used to determine a channel for telegram sending.
Master Data PLC and Channel
/SCWM/MFS_PLC Maintain Programmable Logical Controller
For each PLC you have to maintain the way EWM will communicate with this PLC.
These are the options:
SAP Communication Layer – You chose this option in case you use PCo as an RFC- TCP/IP converter
Proprietary Communication Layer – You chose this option in case you use an RFC- TCP/IP converter
SAP ABAP Push Channel TCP Socket Communication Layer – You chose this option, if EWM MFS communicates via pure TCP/IP with the PLC
Note: We recommend the usage of the ABAP Push channels as you do not need an additional System (like PCo) anymore. Furthermore, by using the dialogue APC TCP Log in the Warehouse Management Monitor you can directly analyze what happened on the TCP/IP level.
Further details on the communication layers can be found in the following guides:
Either a TCP/IP RFC connection (in case a RFC – TCP/IP converter is used) or an ABAP RFC connection (in case ABAP Push Channels are used) set up via SM59.
Only to be defined in case of a proprietary communication layer – Function module called for sending a telegram.
Only to be defined in case of a proprietary communication layer – Function module called for establishing a connection.
Only to be defined in case of a proprietary communication layer – Function module called for shutting down a connection.
Only to be defined in case of a proprietary communication layer – Function module called for checking the connection status.
Switch on the logging of telegrams in table /SCWM/MFSTELELOG. We strongly recommend ticking that option.
/SCWM/MFS_CCH Maintain Communication Channel
For each connection to be used, you have to define the IP address and the port of the socket server:
IP address of the socket server
Port, on which the socket server is listening
Customizing Telegram structure
Define Telegram Structure
Per warehouse and PLC interface type you have to define, which telegram types are used, and which structure is used for which type.
These are the valid options:
DDIC structure that was defined in the data dictionary
Note: If you use fields in that structure that are not member of the structure /SCWM/S_MFS_TELETOTAL, you have to define those fields in an enhancement structure of /SCWM/S_MFS_TELETOTAL as well.
Customizing Protocol errors and exceptions
Define EWM Exceptions for Communication Errors
Here you have to define exception codes for protocol errors received in handshake telegrams from the PLC:
Exception Code Communication
For each value defined for the protocol error in your interface specification you have to make an entry here – even if you do not assign an exception code. Exception code MSEQ in the example above can be used in case the PLC complains about a wrong sequence number. EWM MFS then sets the sending sequence number of the channel to zero and then re-sends the telegram with this sequence number.
Assign Telegram Errors to PLC errors
Per warehouse and PLC Interface Type, you have to define which protocol error (header field comm_error) has to be set in a handshake telegram for which exception on protocol level.
The protocol error that occurred; these are the possible values:
The value, which will be set in the protocol error field of the handshake telegram.
Here you can define, whether the connection should be reset.
In case you missed it, you can find the introduction to the entire blog series here.
- Communication to PLCs
- Receiving and processing of telegrams
- Sending telegrams
- Reliable communication (blog post coming soon)
For more information about SAP Extended Warehouse Management, please follow us on social media, our YouTube channel or our community pages:
SAP EWM Community:
SAP Digital Supply Chain Channel:
EWM LinkedIn Community:
For a complete list of Q&A from the EWM community, please access this link:
In case you do not find your specific question there, feel free to post your question via the following form: