Discover SAP EWM MFS 

The communication from EWM to the PLC

This blog is part of the series ‘SAP EWM meets Automation – Discover EWM MFS’ and describes the communication between EWM and the PLC. Specifically, the communication from EWM to the PLC.
As a practical example I picked the creation and communication of a stock removal warehouse task from an automated storage & retrieval system to describe this communication:

.
However, the general approach is also applicable for other kinds of telegrams which are being sent from EWM to a subsystem via TCP/IP.
Note that with this post we will limit the scope to an APC (ABAP Push-Channel) communication based on the TCP/IP protocol suite. Up to EWM release 9.3 a TCP/IP-RFC converter is required which will not be in scope of this post.

Also note that the communication steps for the direction from the PLC to EWM will not be part of this post. For everybody who wants to understand how EWM receives telegrams I highly recommend the blog post published by Joerg and Tobias here.

The content provided here has been created in cooperation with the SAP EWM team at Swisslog. Feel free to visit their website in case you want to learn more about the services offered by @ Swisslog or to browse open positions within their EWM team!

Agenda

– Communication protocol
– Preparation of telegram creation
– Telegram creation & transmission
As an introduction, let us have a look at the VDI 3962 layer model for computer installations in automated storage systems:

The red arrow highlights the part of the communication which is in scope of this post:

Quick recap at this point –
In the previous blog post we already learned that the queue determination induces the MFS relevance for a given warehouse task:

Technically, EWM marks open warehouse tasks for MFS processing via the field KZSUB:

This is being set based on the queue configuration. FM /SCWM/QUEUE_DET_PREP reads the queue customizing from table /SCWM/T346:

Here you can see that it is empty in the ltap structure initially and then set to ‘Y’ (~ relevant but not sent to the subsystem yet) based on the constant in line 261 in the screenshot below:

…recap completed.

At this point, EWM has decided that a given task has to be processed by the subsystem. We assume this to be our initial situation here. So we start with a queue which is
– customized as being MFS relevant
– carrying multiple WTs in status ‘Y’ (relevant for subsystem but not sent to subsystem yet).

So how do we get from here to actually have the subsystem receiving one of those tasks?

The important components are shown in the overview above and described in this post in detail. We will now have a step-by-step look at the important technical details of the communication (bear with me if I skipped some that you consider to be important!).
Before we start with this deep-dive I would like you to understand the protocol which is responsible to ensure a reliable communication. While EWM is communicating with a subsystem we want to make sure that telegrams of a given channel are processed sequentially. This is realized by the handshake mechanism which is the main pillar of the PLC communication protocol:
– The sender sends a telegram and stores is in its outbound buffer in status ‘sent’ but ‘not acknowledged yet’.
– The sender repeats a message sending a telegram as long as it is not acknowledged in a defined period of time (X times every Y seconds)
– The next telegram of the given channel is only sent once the previously sent telegram is acknowledged.
– The receiver sends an acknowledge message for every message it receives
– The receiver processes a message only once (~ only the first time it receives it)

Analogy –
Imagine you are trying to communicate with your kids. Those of you having young kids will know that they like to ignore you in case you tell them something they do not like to hear.

So imagine the handshake mechanism here as an approach where you only proceed with the next sentence once your kid has confirmed that he/she actually heard the previous sentence. As long as he/she ignores you, you will just proceed saying the same thing all over again. Not sure though how we can incorporate the restart of the channel after X attempts in this analogy. However, you might want to think about opening an additional channel and e.g. start communicating via Whatsapp only .

Step 1: Which WT to be processed?

As mentioned above, MFS-relevant tasks are assigned to queues. Subsequently, in the first step we need to decide which of the WTs from the given queue is selected as the next one to be processed (~ sent to subsystem). This is done via FM /SCWM/MFS_WT_DET. This FM is called directly in the context of posting the WT creation and WT confirmation to the DB:

The check during the confirmation is required e.g. in case the telegram for a new