Inbound proxy scenario, the messages are getting stuck in ECC t-code smq2

[former_member233212]

Hi Experts,

Soap to XI scenario.

Here we are using XI receiver so that we can push messages to ECC.

The RFC destination which we're using in receiver channel will give status code 500 when we do test connection.

Messages are getting delivered from PI and reaching ECC successfully but as soon as we receive them it'll be stuck in queue(SMQ2). Then once release them they're changing in success status.

One more thing to add, when we keep external break point for the code written in ECC it will not trigger through that breakpoint.

We can only see messages in SXMB_MONI(ECC) which is in scheduled status.

Please help me to resolve this error.

Here if I execute it'll change the message status to success from scheduled status.

Regards,

Vidhya Nizamkar

[vadimklimov · Accepted solution]

Hello Vidhya,

1. In tx. SXMS_QREG or SXMB_ADM > Manage Queues, check that corresponding Integration Engine queues are registered - if not, register them.
2. Cross-check in tx. SMQR, that respective queues (XB*) are registered at qRFC Inbound Scheduler (by observing them in a list of registered queue names).

Regards,

Vadim

[former_member233212 · Accepted solution]

Hi Vadim,

I don't have authorization for SXMS_QREG or SXMB_ADM. So I requested basis to work on it.

Meanwhile I checked SMQR t code and added queue XBTR0001, XBTR0002, XBTR0003, XBTR0004. But each time I push message it goes to XBTR queue with new number at the end.

But my question is whenever I push a message from PI to ECC, the proxy method in ECC will not trigger.

Is there a chance that SPROXY settings are not in place?

Regards,

Vidhya

[vadimklimov · Accepted solution]

Hi Vidhya,

I would strongly discourage you from manual registration of Integration Engine specific individual queues directly in tx. SMQR - instead, queue registration shall be triggered from tx. SXMS_QREG, or SXMB_ADM, or SXMB_ADMIN, which executes necessary steps for queue groups based on queue name prefix (not individual queues) registration in qRFC Inbound Scheduler:

Regarding your question on SPROXY. No, there is no any specific setting in SPROXY, that would control this kind of behaviour and prevent automatic processing of outbound messages.

Regards,

Vadim

[former_member233212 · Accepted solution]

Hi Vadim,

The queue XBTR is now registered in SXMB_ADM but still when I push messages from PI to ECC it will not trigger the method in ECC.

It will be stuck in one of the XBTR queue (SMQ2) and once I release it, the status in SXMB_MONI(ECC) will be changed to success.

The green status will be changed to success once I release it from queue(SMQ2).

Please help me to find where is the issue, I think there is no issue at PI end as the messages are going out from PI easily.

If so, what can be the issue at ECC? Are there any settings to be done?

[vadimklimov · Accepted solution]

Hi Vidhya,

When you send the proxy message to ERP and can observe it in SXMB_MONI, please check the queue name to which it got assigned (field 'Queue Name' in SXMB_MONI messages list output) - you may also cross-check the RFC entry for this message in SMQ2 finding it in the determined queue by RFC LUW ID (message ID). Then navigate to SMQR and check if queue prefix for that queue is registered (e.g. XBT*) and what is qRFC Scheduler status - it shall be 'Inactive' if the scheduler finds nothing else to trigger processing for in registered queues.

If you see the queue prefix is registered in SMQR, there is corresponding RFC LUW for the message in RFC queue in SMQ2 (and there are no predecessor RFC entries in that queue), but qRFC Scheduler is in status 'Inactive' and does not pick up entries from that queue, then please check system log (SM21) for errors for that queue - qRFC Scheduler has mechanism of queue blacklisting which is a safety / protection feature enabling it to overcome potential performance issues when unexpectedly long running RFC entries are detected (see more details in SAP Notes 1500048 and 1745298). Please also let me know if you already tried to deregister and register queue prefix so that it gets re-registered for qRFC Scheduler.

And - yes, this is not a PI issue since you already see proxy message in SXMB_MONI, this is about qRFC Scheduler / queue handling in ERP.

Regards,

Vadim

[former_member233212 · Accepted solution]

Hi Vadim,

Thanks a lot for your reply. It helped me a lot.

Now I'm able to send messages from PI to ECC and its not getting stuck in queue anymore.

When I send messages to ECC it's receiving in SXMB_MONI in success status but when I put a breakpoint at proxy method it's not triggering that breakpoint.

I can see the logs in SM21.

I tried searching online blogs for this and I think this is related to database. I also want to mention that recently we have done the update on ECC system .

Also can you tell me if I can approch BASIS team or ABAP team to fix this.

[vadimklimov · Accepted solution]

Hi,

When debugging inbound / provider proxy implementation, ensure you set external breakpoint (and not the default session breakpoint) and the breakpoint is set for the user which is used for execution of the implemented proxy logic (and not your current user - unless your user is used when executing proxy logic). User for which external breakpoint shall be set, can be checked from destination / communication channel configuration in PO, that is used for sending proxy calls from PO to ECC, or by checking sample message for that interface in SXMB_MONI and looking into section 'Runtime', property 'SAP:User'.

Regards,

Vadim

[former_member233212 · Accepted solution]

Hi Vadim,

Now the table is getting updated and messages are not getting stuck in queue.

Thanks for helping me to fix the issue. It was very helpful.

Regards,
Vidhya Nizamkar

[nikhil_bose]

Check there are any locks in SM12 and/or check for any dumps in ST22 which give you hint about the behavior

- Nikhil Bose

[former_member233212]

Hi Nikhil,

I don't see any locks in SM12 and no dumps in ST22. Please let me know if there are any other troubleshooting steps.

Regards,

Vidhya