cancel
Showing results for 
Search instead for 
Did you mean: 

Messages Rejecting in SOAP Sender

Former Member
0 Kudos

Hi Experts,

My Scenario is SOAP-->PI-->RFC

All the messages triggered goes successfully with out any problem, but some times when the messages are triggered these gets rejected in from SOAP sender itself, with message status-2 but this message status 2 means The message was sent, but the destination application returned an error. The Integration Manager does not attempt to resend. Message doesnot came to PI, but I'm unable to understand what might be the issue with..

When the messages are rejected load is also not very high. I checked with network team also whether any disconnections. If the load is very high I can try by changing FCAServerThreadcount.

Can anyone help me out with this issue why the messages got rejected

Thanks in advance,

Regards

Bharath

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Bharath,

The "Maximum Connections" value in the RFC Receiver Channel (under Adapter-Specific -> Target tab) configuration might not be sufficient. By default the value will be 1. Increase this values based on the possible concurrent SOAP Request.

Former Member
0 Kudos

Hi Shreyansh Shah,

Thanks for your reply

I already tried doing this by changing the maximum connections to 10 but my problem is not sorted out.

Former Member
0 Kudos

Bharath,

In this case, you may need to increase the max concurrent channel instances by changing the "messaging.connectionDefinition" property in NWA. By default, it is 5 and you can increase as per your requirement. Steps are as below:

  1. Navigate to NWA -> Configuration -> Infrastructure -> Java System Properties -> Services
  2. Select ZATPL_AIO template
  3. Go to Services Tab
  4. Search for “XPI” and Select “XPI Service: AF Core” service
  5. Search for “con” and select “messaging.connectionDefinition”.
  6. Change the value as below:

(name=global, messageListener=localejbs/AFWListener, exceptionListener=localejbs/AFWListener, pollInterval=60000, pollAttempts=60, Send.maxConsumers=20, Recv.maxConsumers=20, Call.maxConsumers=20, Rqst.maxConsumers=20)

The original default value:

  (name=global, messageListener=localejbs/AFWListener, exceptionListener=localejbs/AFWListener, pollInterval=60000, pollAttempts=60, Send.maxConsumers=5, Recv.maxConsumers=5, Call.maxConsumers=5, Rqst.maxConsumers=5)


Note that this change is at the global level. You can make the changes at channel level by mentioning appropriate channel.

Check the link below for more information on these parameters.


Properties for XPI Service: AF Core - Configuring Process Integration After Installation - SAP Libra...


Problem with queues. Soap adapter | SCN

Former Member
0 Kudos

Hi,

The question you are asking is extremely difficult question to answer, because we dont have access to your system and dont know your landscape or third party.

But these are just come of the things that could go wrong.

1. There is a drop on the network and that cause the interface to fail. You can test this.

     On Commandline type in the following. tracert -d -w 100 <target>

2. The third party might be down or experiencing high volumes. Remember you are probably not the only person sending to there system.

3. Might be reject on incorrect data.

4. Web Service might be down for a few seconds.

And the list goes on and on.

You can try and build in a fail over to resend the messages if the messages didnt reach the intended host.

Good luck,

Jannus Botha

iaki_vila
Active Contributor
0 Kudos

Hi Bharath,

Have you tried with any sniffer to check until where the messages reach?, in this way you can check if there is any port close, problem with dns and so on. For example: http://geekswithblogs.net/EltonStoneman/archive/2009/01/29/debugging-soap-messages-with-wireshark.as...

Regards.

Former Member
0 Kudos

Hi Inaki Vila,

Thanks for your reply..

>> where the messages reach?

Those messages are rejecting in SOAP sender itself.

>>check if there is any port close?

Unfortunately we strictly dnt have any access to logon to SOAP Sender system to check.