Slow SOAP receiver.. need to slow rate of message sent from PI AE to SOAP receiver

[Former Member]

Dear all,

Need your expert inputs....

Our MDM system distributes master data updates on daily basis to all our internal systems and applications(via PI).

One such receiver is an old application , which receives these updates in form of a Web service.

However as the receiver application has certain limitations, due to which it cannot handle a lot of parallel requests(only upto 5 or 10 messages max in parallel).

In order to enable this , we currently have implemented the following flow.

MDM message is mapped and saved in a file. A separate File channel reads this file and posts it to a SOAP synchronously(using RequestResponseBean and ResponseOnewayBean) and the response is captured in a response file.Once we have the response the file is deleted from the source location.

This works fine as now the receiver has to process only one message at a time.

But we still have a problem with it sometimes when this application is down.As we have a sync call, the same Source file is read again and again(as the file is not deleted due to incomplete communication with SOAP service)...and by the time we find this, we already have 1000s of error message on PI..

To keep the design simple and clean, we would like to keep the communication Asynchronous.So in case the service is down, files are simply queued up in receiver queue and sent when the receiver is up.

To be able to achieve this,we need to somehow slow down the rate at which message is sent from the PI AE to receiver.

Adapter module addition to SOAP adapter receiver.. this could be a solution, but would like to avoid it if we have a simpler solution

Any other ideas?

Thanks in advance...

[Former Member · Accepted solution]

Hello Ravindra,

How about using the extended receiver determination?

You could implement a simple messge mapping that creats the receivers message.

In this mapping you can do a look-up to your web service application and check if it's up and running. Just like a "ping".

Then if the web service is running, your mapping returns a receiver and the message goes through. The response will delete the initial source file (if I understood your scenario correctly).

If the web service is not running, your mapping would return no receiver, and the message would be ignored by the receiver determination.

The file sender channel will pick up the same file again with the next poll and the process starts from the beginning.

Otherwise, you can also increase the number of retries for the SOAP receiver, so that the message does not go into error just after 5 trys.

Regards,

Jürgen

[Former Member · Accepted solution]

Hello Jürgen,

Thanks for the input.

Here the only question is, how would PI react if the receiver determination fails and I ignore the message. Wouldn't PI delete the file assuming it is anyways ignored?

And if the file is not deleted, then it means the like today the file will be read again and again, yes but with an added benefit that we will these messages in Integration Engine as ignored messages and not error messages.

Will give it a try.. Thanks.

Ravi

[Former Member · Accepted solution]

Hello Jürgen,

I had tried a small variation of your suggestion. I called the web service as part of SOAP lookup and this certainly helped stop the issue.

However in the meantime the receiver application have upgraded their service on their end and we have introduced an EOIO mechanism to ensure a single flow of messages (and also to ensure updates are in the right order).

As a result , I did not have to implement the solution at all.

So I will close this topic.

Thanks for the help.

Regards,

Ravi