4

Unable to Find a Routing Corresponding to the Incoming Request Message (158,505)

PeopleSoft Integration Broker has several settings, which you need to remember. Many a times when an issue remains unresolved for long, I end up thinking – this is such a trivial issue and still I’m unable to resolve it. What did I do the last time? I wrote a post on one such issue some time back – Integration Broker Messages Stuck in New State. In this post, you will find troubleshooting steps for a similar topic – Unable to find a routing corresponding to the incoming request message (158,505).

This error usually happens when you’re trying to send messages belonging to a Service Operation from one PeopleSoft database to another PeopleSoft database. The error in the message details is “PublicationContractManager::ProcessError/RetryResponse(): ‘Integration Service: Unable to find a routing corresponding to the incoming request message. (158,505)’.”

How to Resolve “Unable to find a routing corresponding to the incoming request message (158,505).”

There are a number of possible causes for this error. Go through each of the possible causes:

1. The obvious one is that the receiving system does not have an inbound routing for the given Service Operation.

Verify on the publishing and receiving database that the routing for the particular Message/Service Operation is defined.

Go to PeopleTools -> Integration Broker -> Integration Setup -> Service Operation and click on the Routing tab to verify.

2. The external alias names for the Service Operation is incorrect.

On both the databases, go to PeopleTools -> Integration Broker -> Integration Setup -> Service Operation
Choose the Service Operation in question, click on the Routing tab:

– Make sure the applicable routing is active

– Click on the Parameter tab and note the External Alias name. By default it is the Service Operation Name and Version Number unless it has been updated.

External Alias Name and Version number on the receiving database should be the same as the External Alias Name and Version on the sending database. 

Many a times this is the primary culprit, especially when not using the default values. Typos like VERSION1 instead of VERSION_1 cause issue and are very easy to overlook.

3. Verify that you’re able to ping the nodes from both the sending and receiving databases. A simple way to verify if the Node passwords match is the run the following SQL against both databases.

select MSGNODENAME, IBPASSWORD from PSMSGNODEDEFN where MSGNODENAME in (‘<nodename1>’,'<nodename2>’);

And compare the IBPASSWORD fields for each node – they must match.

4. Some of the not so common errors can also result in this error. For example:

i. The Message is being sent to the wrong database. Verify the routings.

ii. Sometimes the routings get corrupt – delete the routing and create it again.

 

If you still face this error – let us know in the comments below.