1

In my landscape, the ERP system is creating deliveries in EWM via qRFC. The setup is standard and works via a distribution model in the ERP BD64 transaction. A BAPI is called that creates a delivery replica in EWM.

Sometimes the ERP deliveries are not properly validated and don't fulfill the requirements to be distributed to EWM, but they are still sent. In that case the error stays in EWM SMQ2 queue.

I want to prevent this from happening because if the issue needs to be solved in the ERP side, the error shouldn't stay in EWM. The obvious option is to implement a BADI in the ERP before distributing the delivery that would call a EWM validation API. If the API rejects the delivery, then the distribution should be prevented.

However, if for whatever reason the validation API is not called, the ERP could still send erroneous deliveries to EWM that would get stuck in the SMQ2 queue.

Is there a way to prevent this from happening? In case of an error (when validating the ERP delivery) in EWM qRFC processing, I would like to remove the faulty record from the queue, return the error message to the ERP and mark the ERP delivery as not distributed or distribution error.

Can this be done in a more or less standard way?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
RaTiO
  • 979
  • 2
  • 17
  • 33
  • 1
    i don't know such standard flow when BAPI is called via BD64, most probably the BAPI is called on EWM side when receiving LUW from the queue. Anyway, it is a lot of hassle to return errors from receiver to the sender, no such standard tooling exists for qRFC, the queue just stucks. You should catch errors on ERP side before sending – Suncatcher Feb 03 '22 at 17:30

1 Answers1

1

This ASYNC failure pattern is known in SAP ABAP stacks. Sometimes there is a sync call for check before post calls. When this isnt present, you might consider a sync call instead. Without knowing why ASYNC inbound queue is used in the first place, it is hard to advise about workarounds or process improvements.

ASYNC inbound Queues have key weaknesses. Monitoring options are very week. No APIs to read the to be posted data. No options to "fix" the data and retry etc.

Using a wrapper function on the EWM to react to the error and send feedback is an option.

phil soady
  • 11,043
  • 5
  • 50
  • 95
  • 1
    The distribution of deliveries is a standard SAP setup and I prefer to not change it. My hope was to find something -possibly standard- to manage errors in the inbound queue with more possibilities than SMQ2 transaction. If that's not possible I will have to do the delivery validation for EWM in a separate "sync" call before it's distributed – RaTiO Jan 23 '22 at 20:56