Painful because it is unfortunately not uncommon for a company to be confronted with this topic only after the EWM go-live, not to have been adequately prepared for it and now to feel overwhelmed and left alone. We often observe that system errors, which can be solved within a few minutes, are chased through unnecessary and costly process bureaucracy due to a lack of knowledge. This may be due to unnecessary requests for emergency user authorizations, disputes about the cause of the error and the corresponding responsibility for error resolution between SAP module administrators, or due to unnecessary handover to debugging-affine offshore or nearshore support.
There are some tips and tricks that make working through errors within the message queue much easier, which we would like to address in this blog. Before we get to this part, we need to briefly go into the technical basics.
Technical basics
The ERP/EWM communication of the transaction data runs technically via qRFC (Queued Remote Function Call). This applies to both the embedded EWM and the decentralized EWM. The movement data, such as the posting of the goods issue from EWM, is reported back to the ERP and passes through the message queue. If errors occur during data processing, the confirmation remains in the message queue and must be analyzed and manually processed by the person responsible.
The qRFC is an extension of the tRFC (Transactional Remote Function Call), which allows tRFC calls to be serialized via a queue. The actual sending of the calls is done via a tRFC call.
- Serialization has the advantage that the calls must be in a fixed order to avoid inconsistencies.
- The transactional RFC has the advantage that the system does not necessarily have to be available at the time of the call. All associated data is stored and can be executed again at a later time.
This also applies to error cases!
Monitoring the message queue
![[Translate to English:] EWM Queue](/fileadmin/_processed_/8/8/csm_Queue_1_be3dcd3ced.png)
The qRFCs to be executed can be processed via an inbound or an outbound queue. Whether inbound or outbound depends on whether the queue processing is controlled by the sending or receiving system. By default, the inbound queue is selected in Customizing. Therefore, the inbound queue is the means of choice for monitoring incoming errors. The transaction for calling the inbound queue is SMQ2.
As an alternative to SMQ2, a node for monitoring queues exists in the warehouse management monitor. The function proves to be considerably more user-friendly compared to SMQ2. It offers a clearer error display, enables selection at warehouse number level and offers additional functions such as filter options. In addition, the error description here is less cryptic.
Display of the queue data container
In addition to the introductory words, it should be mentioned that even after learning the tips and tricks, not every error in the message queue can be solved within a few minutes. In particular, finding the cause of the error is and remains the supreme discipline in queue processing. However, thanks to the following tools, correcting the error is a different matter.
It is not always possible to correct the error by customizing or adjusting the master data, since the transaction data is permanently stored in the queue data container. In the following it is shown how this data container can be displayed and even adjusted if necessary, without having to intervene via debugger and emergency user.
Note: If the error is in the data container, it is unnecessary to request an emergency user!
In the warehouse management monitor you can get to the queue data container via the following function:
The display of the data container is also possible via transaction SMQ2, but must first be set up in each system.
Editing the queue data container
The transaction data, which is stored in the data container, can be adjusted as required and the incorrect queue entry can then be triggered again. For example, in the case of a posting error due to an expired posting period, the posting date can be set to a value within the active period.
To enable the processing of the data container, some steps have to be performed beforehand.
These are to be carried out via two central transactions:
- /SPE/MQWL_CUS
- /SPE/MQWL_APPL
In these, the queue container field that is to be changed must be maintained. The maintenance is done on the following levels:
- The function module which is called
- The data table that contains the data field to be changed
- The data field to be changed
This information can be found out via the data container itself:
Ultimately, both transactions serve the same purpose, however:
- the /SPE/MQWL_CUS changes are transported via Customizing requests, the -APPL changes immediately in the current system. However, this system must be a productive system.
- The /SPE/MQWL _CUS allows only certain fields to be set as changeable in the data container, whereas the /SPE/MQWL _APPL allows every field in the data container to be set as changeable.
- From this it can be concluded that the /SPE/MQWL _APPL can be seen as an emergency transaction for production systems.
Finally, a special authorization object is required: /SPE/QEDIT. This must be assigned to the user, otherwise it is not possible to change the data container.
If everything has been maintained correctly, the data container can be changed:
With a few tips and tricks, the errors within the message queue can be processed much more easily, making the request for an emergency user obsolete.
