Discover SAP EWM MFS
The MFS node in the Warehouse Monitor? (Part #1)
This blog is part of the series ‘SAP EWM meets Automation – Discover EWM MFS’. I will unwrap the MFS warehouse monitor node for you and explain
- what kind of data you can access with each sub-node
- what you can do with the methods given for each sub-node in EWM standard
As with all posts of this series, 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!
Before I start with my part I have to mention that some high-level information about the standard MFS nodes is provided here already by SAP:
- https://help.sap.com/saphelp_SCM700_ehp02/helpdata/en/4f/0e9aa14aa16c7ce10000000a42189b/content.htm?no_cache=true
- https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/9832125c23154a179bfa1784cdc9577a/b02618545685024be10000000a44176d.html?locale=en-US&version=2021.002
However, I promise to dig deeper, provide lots of insights that are not given by SAP. Technical details as well as practical examples which will make it easier for you to understand everything.
Having said that, for some of the details that I explain I do expect a base knowledge about the objects used in EWM MFS. If you are a beginner in this area, it is helpful for sure in case you study the following blog posts before you consume this one here:
Within the first part of my blog post about the MFS node in the warehouse monitor I will cover the nodes ‘Communication Channel’ until ‘Handling Unit’. The 2nd part will cover the nodes ‘Handling Unit Move’ until the ‘Telegram Buffer’.
Communication Channel
This sub-node shows the current communication channel data (which is basically the content of table /SCWM/MFSCCH):
Four methods are given for further processing:
Start Channel: FM /SCWM/MFS_CCH_START_MON
- Opens socket to the PLC via FM /SCWM/MFS_CL_CALL in order to enable communication (depending on the way of communication > RFC Converter vs. direct TCP/IP via APC)
- Updates the status in channel table /SCWM/MFSCCH
- Schedule background job running report /SCWM/R_MFS_PERIODCHK_PREP
Stop Channel: FM /SCWM/MFS_CCH_STOP_MON
- Close socket to the PLC via FM /SCWM/MFS_CL_CALL in order to disable communication (depending on the way of communication > RFC Converter vs. direct TCP/IP via APC)
- Updates the status in channel table /SCWM/MFSCCH (e.g. in order to prevent further communication via this channel)
Reset Send SeqNo: This method will reset the send sequence number in table /SCWM/MFSCCH via /SCWM/MFS_CCH_RESET_SQSND_MON which calls FM /SCWM/MFS_CCH_SEQNO_RESET for the reset
Reset Receive SeqNo: This method will reset the receive sequence number in table /SCWM/MFSCCH via FM /SCWM/MFS_CCH_RESET_SQRCV_MON which also calls FM /SCWM/MFS_CCH_SEQNO_RESET for the reset
Check this post (The communication from EWM to the PLC) in case you want to learn more about the usage and purpose of the channel sequence numbers.
Communication Point
This node basically combines the communication point customizing and application data (which is only the storage bin assignment). You can create or change this data here:
In addition to this, this sub-node offers the following features:
Set Exception: It allows the user to set an exception on the communication point (which basically locks the communication point in order to prevent MFS to send tasks from/to this CP).
- Done via FM /SCWM/MFS_CP_SET_EXCC_MON
Send Status Request: This method allows the user to send a status request telegram to the PLC. IT calls FM /SCWM/MFS_CP_QRY_STAT_MON which prepares everything in order to send a telegram via FM /SCWM/MFS_SEND (check this blog post in order to learn what happens within FM /SCWM/MFS_SEND). The result could look like shown in the screenshot below (GRQ is the status request from EWM to the PLC and GSR is the status telegram with the answer from the PLC to EWM > note that the telegram type will differ depending on the subsystem vendor)
Trigger Telegram Processing: Here we call FM /SCWM/MFS_WT_DET_PREP via FM /SCWM/MFS_CP_WT_DET_MON in order to check explicitly for the given communication point whether there is a HU standing at the CP having an open WT which has not been sent yet to the subsystem. If yes, EWM checks whether the WT can be sent (FM /SCWM/MFS_WT_DET) and if possible, send it via /SCWM/MFS_SEND:
Telegram
Along with the data string sent to / received from the subsystem, we have timestamps as well as information related to the communication channel (channel number, sequence number etc.).
In addition to this, EWM provides buttons in order to show corresponding warehouse tasks and application logs in the lower navigation part of the screen.
The following methods can be applied to the given records:
Resend Telegram: This function obviously is only possible for outgoing telegrams. You have the choice to trigger the resend with a new or with the existing sequence number. FM /SCWM/MFS_RESEND_TELEGRAM_MON is called and prepares the data string for the telegram before it calls FM /SCWM/MFS_SEND for the submission (check this blog post in order to learn what happens within FM /SCWM/MFS_SEND).
Simulate Telegram: FM /SCWM/MFS_TELE_SIMULATE_MON gives the options to change some fields of the telegram via a pop-up screen and then send/receive the telegram again with the changed data
The buttons can be used to display application log records based on the object (HU or WO) or the time frame (plus/minus 5 seconds, application log or TCP communication log).
APC TCP Log
In case you are using ABAP-Push-Channels you can use this sub-node in order to analyze what happened on TCP/IP level. FM /SCWM/MFS_APC_TCP_LOG_MON reads TCP log files via FM READ_TCP_LOG. For those of you who are interested in the technical details here I would recommend to check the SAP documentation of FM READ_TCP_LOG (or report RS_READ_TCP_LOG) and SAP note ‘2258103 – Interface for reading TCP log files’:
This sub-node offers a button that can be used in order to display the application log for object /SCWM/WME (sub object ‘MFS’) in the lower part of the screen based on the time of the selected TCP log (it will show application log files plus/minus 5 seconds here > a longer time period can be enforced by selecting multiple records):
Warehouse Task
This node shows all warehouse tasks which are relevant for MFS based on /SCWM/ORDIM_L-WTCODE (this is different from the famous KZSUB > I did not analyse in detail how this is being set but assume that it is set for all WTs where source and/or destination is a CP). FM /SCWM/MFS_WT_MON is responsible for the selection:
calls standard WT node with special parameter IV_MFS at first to
get only (!) the selection screen
this parameters causes the WT node to only select WTs with
sub system relevance
additionally the node will select only open and inactive WTs by
default
The methods are rather simple here and only reflecting the hotspot feature that you know from other notes. E.g. ‘Destination HU’ opens the work center transaction with the HU details or ‘Product’ opens /SCWM/MAT1 with the product master data. Same for all the other methods here – only to display further details – no additional features:
Handling Unit
EWM reduced the selection to MFS relevant storage types and then selects all HUs on bins in these storage types which are also assigned to a communication point. In addition to this, it collects HUs which are currently being moved from/to one of the given storage types:
The following methods can be applied to the HUs in the grid:
Set MFS Error: This method uses FM /SCWM/MFS_HU_SET_MFSERR_MON in order to write an exception code into HU header field via /SCWM/HUHDR_ATTR_CHANGE. The exception code will be considered while processing the next telegram/WT for the given HU and potentially route it towards the next clearing bin.
Trigger Telegram Processing: Via FM /SCWM/MFS_HU_WT_DET_MON
- In case the HU is on a communication point: Call FM /SCWM/MFS_WT_DET_PREP to check explicitly for the given communication point whether there is a HU standing at the CP having an open WT which has not been sent yet to the subsystem. If yes, EWM checks whether the WT can be send via /SCWM/MFS_WT_DET and if possible, send it via /SCWM/MFS_SEND
- In case the HU is on a resource: Call FM /SCWM/MFS_WT_DET_PREP to check explicitly for the queue of the given resource whether there is a telegram for any of the WTs in the queue can be sent to the subsystem
Create Warehouse Task: Opens transaction /SCWM/ADHU, pre-filled with data for the selected HU
At this point I am closing the first part of my blog post about the MFS node in the warehouse monitor. The 2nd part will cover the nodes ‘Handling Unit Move’ until the ‘Telegram Buffer’.
I hope this blog post provides value to you and you could learn something. Please feel free to subscribe to my blog updates or my youtube channel in case you want to be notified about new posts!
Get my monthly blog-updates!
Subscribe to my Youtube channel!
