This blog has been drafted together with Development Architect, Tobias Adler
Introduction
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 into the underlying protocol of the SAP EWM MFS interface.
Basis of the Communication Protocol
The communication is based on TCP/IP. A stream-oriented socket interface is being used.
Note: Up to release 9.3, SAP EWM MFS communicates with RFC-calls, and thus a RFC-adapter for TCP/IP is required; SAP provides the product SAP PCo (SAP Plant Connectivity) for that purpose.
Note: In case a different interface than the stream-oriented TCP/IP socket interface has to be applied, specific agents can be developed on PCo level with according enhancements on SAP EWM MFS level.
SAP EWM MFS always acts as a socket client; the controls of the automated equipment have to act as socket server. Per defined connection (also called “channel”), which is determined by the IP address and the port number of the socket server, SAP EWM MFS establishes the connection (“connect”), whereas the control system of the automated material handling equipment waits for a and accepts a connection request (“bind”, “listen”, “accept”). A channel is working bi-directional; thus, simultaneously sending and receiving is enabled.
Format of Information
Information is transferred by telegrams. Telegrams are Byte-streams consisting of data fields with defined offset in the telegram, defined length and defined format (character field or numeric field). Only printable characters (ASCII 20H – 7EH) must be used. This facilitates readability in log files or network analysis tools.
Each telegram consists of a header part and a data part. The length of a telegram is restricted to 4096 Bytes (255 Bytes up to release 9.1). Each telegram has a fixed length defined by the structure of the telegram type (data field of the telegram header).
Character fields (CHAR) are filled left-justified with trailing blanks (“ ” – 20H); numeric fields (NUMC) are filled right justified with leading zeroes (“0” – 30H).
As an option, it can be agreed to use a fixed telegram length for all telegrams being exchanged via one channel. A fill character (“ ” – 20H) will be appended to a telegram as often as it takes to achieve the defined telegram length.
As an option, it can be agreed to use a start character and/or end character (e. g. “<” and “>”) for all telegrams being exchanged via one channel. Start and end character must not be used in regular telegram fields.
Note: It does not make sense to use both an end character and a fixed telegram length – but you either have to operate with an end character or a fixed length.
As an option, it can be agreed to use a special fill character (e. g. “~”) for all telegrams being exchanged via one channel. This fill character must not be used in regular telegram fields. On sending a telegram, all blanks (“ ” – 20H) are replaced by the defined fill character; on receiving a telegram, all fill characters are replaced by blanks (“ ” – 20H).
Reliable Data Transfer
Beyond the mechanisms of the TCP/IP protocol SAP EWM MFS offers a reliable transmission of information.
To achieve this, data telegrams and handshake telegrams (“confirmation of telegram receipt“) are used. To distinguish between data and handshake telegrams, a data field in the telegram header has to be filled. For each data telegram, the sender creates a sequence number (numeric data field in the telegram header) sequentially taken from a defined number range. This sequence number identifies a telegram uniquely for a certain period of time together with the channel and the sending direction (depending on the length of the sequence number and the transmission frequency of the channel).
The receiver of a data telegram confirms the receipt of this data telegram by sending a handshake telegram. The reference to the data telegram is established by using the same sequence number as provided in the data telegram. Usually, the header of the data telegram is copied, sender and receiver are exchanged and the data field for handshake is set to handshake. If the data telegram is not accepted due to some defined reason, the data field for communication error in the telegram header has to be set in the handshake telegram accordingly.
If the sender of a data telegram does not receive a handshake telegram for this data telegram within a defined interval (configurable – e. g. two seconds), the sender repeats sending the data telegram again with using the original sequence number. The number of telegram repetitions is configurable within EWM (e. g. seven times). If after the maximum number of telegram repetitions still no handshake telegram is received, SAP EWM MFS considers the connection as broken and re-establishes it. As an option, the usage of this handshake mechanism can be deactivated per channel.
Identification of a Telegram (Sequence number)
The sender of a data telegram is responsible of setting the correct sequence number of this telegram. Sequence numbers will be taken from a defined number range per each channel starting with 1. After a data telegram has been sent and acknowledged by a handshake telegram, the next data telegram will have the successor of the previously used sequence number out of the number range. After the highest number of the number range has been used as a sequence number, the next sequence number is 1.
The receiver of data telegrams has to keep track on the received sequence numbers, so that there always will be an expected sequence number per channel.
If an unexpected high sequence number is received, the data telegram will be accepted and the expected sequence number will be updated accordingly.
If the received sequence number is lower than the expected, the receipt of the data telegram is confirmed, but the data telegram will not be processed.
Sequence number “0“ is used to reset. Telegrams with sequence number “0“ are always accepted. The next telegram then has to have sequence number “1“.
Protocol Error
On receipt of a data telegram, the receiver may perform some checks before sending the handshake telegram and processing the telegram:
- Correct start character (if used)
- Correct end character (if used)
- Correct telegram length
- Correct expected sequence number
- Correct sender
- Correct receiver
In case such a check fails, the according communication error has to be set in the handshake telegram.
Buffering of Telegrams
When working with data telegrams and handshake telegrams, a data telegram may be sent only after the receipt of the formerly sent data telegram was confirmed by the receiver with a handshake telegram.
A sent data telegram has to be buffered as long as the corresponding handshake telegram was not received.
As per channel only one sent data telegram without received handshake is allowed, data telegrams have to be buffered by the sender until they are allowed to be sent due to the sequence of the creation and the receipt of according handshake telegrams.
If a data telegram was received and the connection broke before sending the according handshake telegram, the handshake telegram has to be sent after the connection is re-established.
If a data telegram was sent and no handshake received for that data telegram and the connection broke before repeating the telegram, the telegram has to be sent again after the connection is re-established.
De-coupling of telegram processing (application logic)
When working with data telegrams and handshake telegrams, the handshake telegram has to be sent as fast as possible after the receipt of the data telegram in order to enable the communication partner to send the next data telegram. With sending an acknowledgement via a handshake telegram, the communication partner takes over responsibility over the received telegram. With the receipt of an acknowledgement via a handshake telegram, the communication partner is allowed to send the next data telegram.
After a data telegram has been received, checked on protocol level and persisted properly, the handshake telegram will be sent with according communication error. Only after that the processing of the telegram content will be started, if the check on protocol level allows this.
Scalability
To meet high performance requirements, SAP EWM MFS can communicate with a communication partner via several channels (determined by the combination of IP-address and port number) in parallel.
The assignment of telegrams to a channel can be defined by criteria like telegram type, communication point and resource.
E.g. one channel could be set up such that only SAP EWM MFS is sending data telegrams via this channel, whereas the control system of the automated equipment just sends handshake telegrams. A second channel then would be set up such that only the control system sends data telegrams and SA EWM MFS the handshake telegrams.
Monitoring the connection
When working with data telegrams and handshake telegrams, SAP EWM MFS considers a connection as broken after the sending of a data telegram was repeated a defined number of times because no handshake telegram was received. In this case, SAP EWM MFS shuts down the connection and tries to establish it again.
Additionally, there is a mechanism checking the connection even in times, when no telegrams are transferred out of the processes: When no telegrams were transferred via a channel within a defined interval (configurable – e. g. ten seconds), SAP EWM MFS sends a LIFE-telegram and expects a handshake telegram for this.
Example for a Telegram Header
Below an example of a telegram header:
This example contains all necessary fields for a reliable communication. Lengths of the fields can be defined differently. Additional fields can be introduced to the telegram header.
Note: Field Sender
Usage is not obligatory but recommended to increase readability of telegrams; maximum length 8 characters (due to definition of corresponding field in the structure /SCWM/S_MFS_TELETOTAL, which is used for internal telegram handling).
Note: Field Receiver
Usage is not obligatory but recommended to increase readability of telegrams; maximum length 8 characters (due to definition of corresponding field in the structure /SCWM/S_MFS_TELETOTAL, which is used for internal telegram handling).
Note: Field Sequence number
Usage is obligatory; part of the key of table /SCWM/MFSTELEQ (table to persist received data telegrams for processing). Within a warehouse the sequence number uniquely identifies a telegram together with PLC, channel and sending direction for a certain period of time (depending on the frequency of telegram exchange). It is recommended to use at least 4 digits; maximum length 20 numerical characters (due to definition of corresponding field in the structure /SCWM/S_MFS_TELETOTAL, which is used for internal telegram handling).
Note: Field Handshake
Usage is not obligatory but recommended to establish reliable communication on application level; maximum length 2 characters (due to definition of corresponding field in the structure /SCWM/S_MFS_TELETOTAL, which is used for internal telegram handling).
Note: Field Protocol Error
Usage is obligatory when working with handshakes; maximum length 2 characters (due to definition of corresponding field in the structure /SCWM/S_MFS_TELETOTAL, which is used for internal telegram handling).
Note: Field Telegram Type
Usage is obligatory; maximum length 4 characters (due to definition of corresponding field in the structure /SCWM/S_MFS_TELETOTAL, which is used for internal telegram handling).
Our next topic “Communication customizing and master data” will cover how to set up the information exchange system between SAP EWM and the control systems of the automated material handling equipment.
In case you missed it, you can find our introduction to the blog series here.
Other topics that will be covered are:
- Receiving and processing of telegrams
- Sending telegrams
- Reliable communication
Thanks to author Joerg Michaelis for posting.