Problems with a asynchronous interface, due to blocked objects.

[Former Member]

Hi gurus,

I'll try to explain my problem with an asynchronous interface that it's turning me crazy.

I'ts an interface from SOAP (Axis) to Proxy. The scope is to register material documents via estandard BAPI.

Sometimes, several messages are sent at the same time from the legacy system to my webservice and, after that, to SAP ECC for document creation. But, sometimes, some of this messages are not succesfully processed due to blocked objects when they affect the same purchase order, for example.

In SXMB_MONI on ECC we can see the message with 'green ray' icon and the following content: 'The Purchase document is already being used by XXX user'.

I am trying to solve this issue, because is really annoying to get this messages. On PI, the Axis Sender Channel is set to 'Exactly One', and receiver is the standard XI Proxy Channel. There is no opperation mapping.

I've been trying to implement some ABAP Code in proxy for manage this situations, using blocking objects manually (FM's ENQUEUE, and DEQUEUE), WAIT sentences, updating Z tables...but I did not solve this at all.

Do you have any ideas? I'm thinking about perform some delay time in PI processing and avoid all ABAP code in proxy...on sender or receiver channel. Sender one is an Axis, and I know it´s possible to set some parameters for processing.

There is any parameter for stablish a delay? Or in receiver proxy channel?.

Thanks in advance!

[udo_martens · Accepted solution]

Hi,

standard to solve the issue is use of qos EOIO. But this has to done by the sender. If this is not possible, it is more complex, coz a simple delay would not help: You would delay each instance and therefore process at the same time (but later). You might consider then a correlating BPM which is receiving messages in loop (controlled by a timeout) and sending messages with an interval (this process is not easy to implement and will cost you some effort).

/Udo

[Former Member · Accepted solution]

Hi Udo,

Do you think EOIO in sender channel will solve it?  I saw in PI MONI some messages sent by the same queue and the second one has the problem with blocked objects...so one unique queue for all messages does not look like as solution...do you agree?

Regards!

[udo_martens · Accepted solution]

Hi,

EOIO means one by one in sequence. That should solve your problem. EO and EOIO queues are different.

If one message fails the following messages will be stopped. You should consider the consequences.

/Udo

[Former Member · Accepted solution]

Hi Udo,

I've set the channel to EOIO.

In URL from WSDL, I've added the following parameter &queueid=GPT.

However, when a message is launched from the other system, it gets the following error:

The one-way operation returned a fault message.  The reason for the fault was 'The XI SequenceId must be uppercase and 1-16 characters long.

What's wrong? I think the new parameter in URL is correct...doesn´t it? The sender SOA Channel is AXIS.

Any ideas?

Thanks! 🙂

[Former Member · Accepted solution]

Solved! 🙂

The correct sintax for this parameter is &queueName (Case sensitive!)

[Former Member · Accepted solution]

And finally...solved issue!!. There are not more problems with blocked objects.

A lot of thanks!!!!

[ambrish_mishra]

Hi,

If you have the luxury to change the design a bit, you can change the design to IDoc instead of proxy.

Change the partner profile to collect IDocs and run a report to process these IDocs at an agreed interval.

This won't require EOIO in PI and will sort out all locking issues but the only drawback is the processing won't be real time. I can suggest on the details of this design.

If you want to go with existing design, Udo has already suggested using EOIO with pros and cons.

Hope it helps!

Ambrish

[Former Member]

Do you actually have to send a SOAP response back to the legacy system with data from the posting in ECC (e.g. material doc. number)?

If not, set the quality of service in SOAP sender to EOIO. You also have to change the service interfaces to asynchronous and regenerate your proxy. Like this, your proxy messages will be processed sequentially in ECC.

The legacy system will still receive an empty SOAP response with HTTP status 200 from the SOAP adapter, meaning that the message has been received by your system.

Regards, Martin

[allamudi_loordh]

Hi,

Give time delay in mapping

{ try

   {           Thread.sleep (30000);

    }

catch (InterruptedException ie){}

}

30000 will give you 30sec delay.

Regards,

Loordh

[Former Member]

I've thinked about this but my interface has not mapping.

Regards.