How to make synch SOAP-Calls coming from an IDoc persistent

[Former Member]

Hello,

we have the following challenge:

Outbound Message: IDoc

Inbound Message: synch SOAP-Call

Processing: Integration Process

We implemented the IP under the following assumtions (we're hopefully right):

1. The Receive Step of the IDoc is automatically asynchron. This means, ther is no chance to let the Idoc on the RFC-Queue of the sending system under no circumstances as long as the XI-System is available.

2. since we cannot resend the IDoc, we have to implement our own logic in order to ensure that sooner

or later all SOAP-Calls will be processed successfully in the destination system. This means: Leaving the process without having made the data persistent somewhere is not an option!

3. The SOAP-Call can fail due to 2 reasons: technical error or application error. We have to capture both situations.

4. Depending on the type of error we wait and try again later, let's say up to 3 times. For some paticular application error (is.e. "customernumber does not exist"), we have to solve this problem in the receiving application and try the call later.

Now the questionable step: in case the call fails after the 3rd trial we send the Idoc-controldata asynchron to an XI-SAP-Table in order to collect them. Thus we can resend these Idocs by looping over this table and set the status of all these Idocs back to '30' (ready to send) so that they will be resend automatically the next time.

This happens periodically for thousends of Idocs - so it's not a good idea, to keep the Integration Process alive and try unlimitted.

This approach sounds a bit strange but we didn't find any other solution in order to migrate the same process from the SAP Business Connector to XI. With SAP BC it was much more easy since a failed SOAP-Call let the IDoc simply on the RFC-queue of the sender, so you just have to restart them wit TA sm58.

Did we oversee any other trick in order to achieve the same goal?

Appreciate any hint because due to an IP the performance is even worse than with SAP BC!!!.

Regards Gunnar.

[Former Member]

Gunnar,

Although you have explained very well, I could still not understand a few things.

Can you rephrase your scenario a bit?

I would like to know you end to end scenario. Idoc - IP - Synch WS -Response ?

Do you send any kind of acknowledgement back to IDOC?

In case of an error during SOAP call (first time). How are you retrying currently?

After 3 times, you send these to a table in XI and set the IDOC status to 30. I dont understand this part. Do you mean you have a a field in the table status and update the status as 30?

How do check if the record count is 1000 and retry all the records again?

Can you upload the screen shot of the BPM and give us the link here if possible. It will be easy for us to understand the end-to-end flow. I hope we can crack this together.

Regards,

Jai Shankar

[Former Member]

Hello Jai,

in our IP after the IDoc-Receive-Step we make our mapping and start a new Block: within this block, we make the SOAP-Call and we care about 2 situations:

1. Application error - the SOAP-Responde says error

2. HTTP-Error - i.e. System no available

In both cases we wait 1 minute. In order not to queue further requests too long (there are mostly thousends of such Idocs) we retry max. 3 times. If the problem persist we

1. send IDocNumber and some other information asynch to an SAP-DB-Table in the sending SAP-System,

2 Log the error message text with status 40 in the IDoc-Sender asynch

3.raise an Alert so that we get informed

4. terminate the IP.

The mentioned table can be regarded as our "request-for-idoc-resend"-Table. There is a job in the SAP-System which peridocally selects all Records of this table and sets the status of all these IDocs from 03 to 30 so that they will be resend automatically with the next time. This work is done by our own function module.

It's probably important to know that our destination Application can handle just one SOAP-Call at the same time. In order to avoid multiple requests we send all SOAP-Calls via an specific Adapter Engine which has been configured to max one request for the SOAP-Adapter.

All in all a rather complicated scenario, i must admit. The point is not that it doesn't work. But there is probably a better approach

we don't know.

To be honest, i don't know how i can make a local jpeg- or gif- file available for you here in the forum...

Best regards

Gunnar