Supply Chain Management Blogs by SAP
Expand your SAP SCM knowledge and stay informed about supply chain management technology and solutions with blog posts by SAP. Follow and stay connected.
cancel
Showing results for 
Search instead for 
Did you mean: 
Jörg_Michaelis
Active Participant

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 article is about the telegram sending mechanism of EWM MFS.

EWM MFS uses messages called telegrams in order to communicate with the PLC. Sending is being performed usually by sending a data telegram and waiting for the acknowledgment telegram. Then the telegram with the next sequence number is sent.


For more information about MFS protocol please refer to our second blog in the series, Communication Basics [HYPERLINK TO THE 2ND BLOG].

There are several options to send a telegram:

  • Originating from a warehouse task, which has been determined by function module /SCWM/MFS_WT_DET in pallet conveyor mode or commissioning of resources.

  • By /SCWM/MFS_RECEIVE2 sending acknowledgment telegrams

  • By a standard MFS action function module (especially in case conveyor mode)

  • Manually by calling function module /SCWM/MFS_SEND from Z-Coding


Each of these options uses, directly or indirectly, the function module /SCWM/MFS_SEND to send a telegram.

Function Module /SCWM/MFS_SEND


Importing parameters of function module /SCWM/MFS_SEND:


























































































































Parameter Name Typing Associated Type Optional Description
IV_LGNUM TYPE /SCWM/LGNUM Warehouse Number
IV_PLC TYPE /SCWM/DE_MFSPLC PLC
IV_CHANNEL TYPE /SCWM/DE_MFSCCH X Comm. Channel
IV_TELECAT TYPE /SCWM/DE_MFSTELECAT X Telegram Type
IV_SND_DIRECT TYPE XFELD X Telegram is sent directly without usage of outgoing telegram buffer (Table /SCWM/MFSDELAY)
IV_NO_CHANGE TYPE XFELD X Send telegram without changes (used for generation of acknowledgment telegrams if abap_false)
IV_PRE_SYNC TYPE XFELD X Send telegram without consideration of sync status of channel
IV_REPEATER TYPE XFELD X Used by repeater process to send telegram immediately.
IV_TSTAMP_DELAY TYPE TIMESTAMPL X Used in case of processing of /SCWM/MFSDELAY entries
IV_TANUM TYPE /SCWM/TANUM X Warehouse Task
IV_WHO TYPE /SCWM/DE_WHO X Warehouse Order
IV_NO_KZSUB_CHK TYPE XFELD X KTZUB check is not performed in case of WT processing
IS_TELEGRAM TYPE /SCWM/S_MFS_TELETOTAL X Telegram data
IS_ORDIM_O TYPE /SCWM/S_ORDIM_O_INT X Warehouse Taks
IT_ORDIM_O TYPE /SCWM/TT_ORDIM_O_INT X Warehouse Tasks
IO_LOG TYPE REF TO /SCWM/CL_LOG X Log Reference Object

To send a telegram by /SCWM/MFS_SEND,  we have to pass either one/multiple warehouse tasks (is_ordim_o, it_ordim_o) with telegram category (iv_telecat: WT or WTCR) or a telegram (is_telegram).

If the function module is called with a telegram, it

1. Checks the channel based on PLC/Channel importing parameters.
The channel is locked exclusively with “SELECT SINGLE /SCWM/MFSCCH FOR UPDATE”. No other process can use this channel for sending operations until COMMIT is executed. This is especially critical, if we receive lots of data telegrams which need to be responded with acknowledgment telegrams. To keep lock contentions at a low level, it is recommended to keep runtime of BAdI /SCWM/EX_MFS_TELE_SND (see below) as low as possible.

2. Determines the telegram category based on teletype of telegram

3. Based on iv_no_change, either an acknowledgment or a request telegram is being sent (iv_no_change = ‘ ‘ -> acknowledgment, iv_no_change = ‘X’ -> request).

4. In case of an acknowledgment telegram



    1. BAdI for Acknowledgement is called (/SCWM/EX_MFS_TELE_ACK) with option to skip step 4.2.

    2. Acknowledgment telegram is built according to the rules maintained in customizing.

    3. BAdI for Acknowledgement is called (/SCWM/EX_MFS_TELE_ACK) again with option to modify telegram created by step 4.2.

    4. Mapping of EWM to PLC Objects by function module /SCWM/MFS_TELE_MAP in case it is set up in customizing. Option to make use of BAdI /SCWM/EX_MFS_TELE_EWM2PLCOBJ.




5. In case of a request telegram, telegram data from is_telegram is taken over without changes and without mapping of EWM to PLC Objects. This option is very often used with PLC-Operation Type Case Conveyor during sending telegrams by an action function module like /SCWM/MFSACT_CASE_ROUTE.

If the function module is called with a warehouse task, it

  1. Verifies KZSUB of WT according to iv_telecat.

  2. Build telegram according to WT-data and customizing.

  3. Mapping of EWM to PLC Objects by function module /SCWM/MFS_TELE_MAP in case it is set up in customizing. Option to make use of BAdI /SCWM/EX_MFS_TELE_EWM2PLCOBJ.

  4. Determination of channel data from customizing.


The function module continues with the following execution logic, which is valid for both calling variants (with telegram or WT as importing parameters):

6. BAdI for telegram manipulation is called (/SCWM/EX_MFS_TELE_SND).

7. Various Preparation/Validation checks for telegram sending.

8. If telegram shall not be sent directly (iv_snd_direct = abap_false, this should be the default case)

  1. Check for existing entries in outgoing telegram buffer (table /SCWM/MFSDELAY) for current lgnum, plc and channel combination. If entries exist, add telegram to /SCWM/MFSDELAY and go to step 10, else continue with step 9.


9. If telegram shall be sent directly or /SCWM/MFSDELAY is empty for current lgnum, plc and channel combination:

  1. Get next sending sequence number.

  2. Build telegram string from teletotal structure. Data from teletotal structure is being moved to a telegram-type specific structure and afterwards to a string.

  3. Add start character and end character and replace “space” with fill character, if applicable.

  4. Add telegram to /SCWM/MFSDELAY if handshake mechanism is enabled in order to be able to repeat the telegram in case of missing acknowledgement from PLC.

  5. Check, whether telegram logging is activated. If yes,

    1. Try to get applicable warehouse task.

    2. Write telegram log (table /SCWM/MFSTELELOG) and commit work.



  6. Call FM /SCWM/MFS_CL_CALL. This FM hands over data to the communication layer and sends the telegram.

  7. If an error was reported, start exception handling.

  8. If an acknowledgement telegram was sent, the according record in incoming telegram buffer (table /SCWM/MFSTELEQ) will be updated.


10. Commit work.

Telegrams which were added to the outgoing telegram buffer /SCWM/MFSDELAY will be sent by MFS after receiving the acknowledgement for the previous telegram or by program /SCWM/R_MFS_PERIODCHK_PREP which is being continuously run in background.

Enhancement options in /SCWM/MFS_SEND


BAdIs (Business Add Ins)


These BAdIs are executed in the following order.

1.       Acknowledge-BAdI /SCWM/EX_MFS_TELE_ACK


Allows adjustment of acknowledgement telegram.
We can change the telegram types here for example. This is often used in retrofit-projects, where it is necessary to work with specific telegram types for ACK and NACK telegrams.

2.       Mapping-BAdI /SCWM/EX_MFS_TELE_EWM2PLCOB


Allows mapping of EWM Objects to PLC Objects. For instance, transformation of EWM storage bin to PLC coordinates. The counterpart is BAdI /SCWM/EX_MFS_TELE_PLC2EWMOB for mapping PLC objects back to EWM objects during receiving of telegrams. Those BAdIs will only work on the fields CP, RSRC, SOURCE and DEST (plus CS, CSGR and FINAL_DEST, which are hardly used).

3.       Send-BAdI /SCWM/EX_MFS_TELE_SND


Allows modification of the to-be-sent telegram.
This BAdI is very often used to perform string operations on the telegram in order to fulfill telegram requirements of the PLC.

In many projects, the information provided in the fields of the structure /SCWM/S_MFS_TELETOTAL is not sufficient

Examples for additional telegram fields:

  • Specific faults instead of just one field for MFS error like over height, overweight, overhang left, right, front or rear, footer fault, etc.

  • Flag for actions like printing, wrapping, strapping etc.

  • Flag for actions like use system pallet, “pair” half pallets on system pallet etc.

  • Special attributes like orientation (especially for totes at picking workstations), system pallet used, stacked pallet etc.

  • Information for grouping – if this is in the responsibility of the PLC – like group-ID, group type and flags like group complete or pick WO plus number of movement WTs for pick WO (goods-to-person scenario)

  • Additional fields, if information for more than one HU has to be transported in one telegram

  • Special fields claimed by supplier


If telegram sending is triggered by standard, (created WT for resource or in case of layout oriented routing or by using a standard case conveyor action module) additional telegram fields won’t be filled; the send-BAdI /SCWM/EX_MFS_TELE_SND (method tele_snd) has to be used for this purpose.

Most commonly, the information for the additional fields will be retrieved from enhancement fields of /SCWM/HUHDR and /SCWM/ORDIM_O, a class attribute or even by using constant values.

Processing of additional fields in received telegrams can either be done in the receive-BAdI /SCWM/EX_MFS_TELE_RCV (method tele_rcv) or in a customer specific action module for telegram processing.

Many suppliers have a different standard for field content than SAP has. Examples:

  • Fields CP and RSRC are not filled by supplier

  • Coordinates follow a different scheme like
    PLC: AASXXXYYZ (aisle, side, X-coordinate, Y-coordinate and Z-coordinate) versus
    MFS: TTTT-AA-S-sss-ll (storage type, aisle, side, stack, level) plus logical position

  • Resource movements (two-step-ordering, two-step-confirmation):
    Suppliers like to have LAM and LAM position in the field dest in the pick cycle and in the field source in the drop cycle whereas SAP standard expects those fields to be empty

  • The information orientation of tray or tote often is encoded in the HU-Ident (more than one barcode on a tray / tote)

  • Hardware suppliers often use different HU types (sometimes simple types plus additional attributes) than those used in SAP


These fields can be modified in the send-BAdI /SCWM/EX_MFS_TELE_SND for sending telegrams and in receive BAdI /SCWM/EX_MFS_TELE_RCV during receiving of telegrams.

PLC<->EWM Object mapping has already been performed before execution of this BAdI. It is mandatory, to work with PLC Objects here inside.

COMMIT WORK must not be used in this BAdI. Neither explicitly nor implicitly by saving logs in custom z-coding classes for example.

Usage of proprietary communication layer


It is possible to use a proprietary communication layer instead of the recommended ABAP push channel connection. In transaction /SCWM/MFS_PLC a function module can be defined, which is used for sending telegrams in this case.

Call locations of Function Module /SCWM/MFS_SEND


Function module /SCWM/MFS_SEND FM is called by the standard at

  • Include /SCWM/LL03AF48 (Form mfs_wt_det_canc), to send WT-cancellation request telegrams.

  • /SCWM/MFS_WT_DET. Determines the next to be sent warehouse task.

  • /SCWM/MFS_SYNC. Syncs the PLC.

  • /SCWM/MFS_RECEIVE2. FM for receiving telegrams. /SCWM/MFS_SEND is used to send acknowledgment telegrams.

  • /SCWM/MFS_PERIODCHK. Used by endless-running MFS-Job to send life-telegrams or not yet sent telegrams.

  • /SCWM/MFS_ACK_EXCEPTION. Used for telegram resending during exception handling.

  • Form send_telegram included in various MFS Action Function Modules (e.g. /SCWM/MFSACT_CASE_ROUTE) to send telegram with new routing destinations.

  • Warehouse Management Monitor function for resending and simulation of telegrams.


Remarks


Please note that a sending attempt of a telegram using a stopped channel or using a channel with an exception will not work. The telegram will not be saved in outgoing telegram buffer by standard. This has to be done in z-coding.

For the other topics in the MFS blog series, please visit one of the following blog posts:


To make sure you are notified of new parts of this blog series, please follow our assigned tag, SAP Extended Warehouse Management and see an overview of all related blog posts published for this series here.








This blog has been drafted together with Development Architect, Tobias Adler


For more details on SAP MFS capabilities and select customer examples you can access our latest presentation on MFS.

For more information about SAP Extended Warehouse Management, please follow us on social media, our YouTube channel or our community pages:

SAP EWM Community:

https://www.sap.com/community/topics/extended-warehouse-management.html

SAP Digital Supply Chain Channel:

https://www.youtube.com/channel/UCELmE2CEAkcwqpBLnuZHufA

EWM LinkedIn Community:

https://www.linkedin.com/groups/1952257/

For a complete list of Q&A from the EWM community, please access this link:
https://answers.sap.com/tags/01200615320800000705

In case you do not find your specific question there, feel free to post your question via the following form:
https://answers.sap.com/questions/ask.html?primaryTagId=01200615320800000705






5 Comments