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

by Apurva Tripathi on December 19, 2014

in General, PeopleSoft Integration Broker

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:

Also Read:  How the Integration Broker Handles Incoming Requests (Understanding PeopleSoft Integration Broker Part 2)

– 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.

{ 3 comments… read them below or add one }

Alexei Tetenov December 22, 2014 at 1:18 pm

I’ve have encountered this same error if the user that was used to send this msg from one peoplesoft instance to another, does not exist in the target instance. I have also encountered this error message, if the user in the target system does not have enough privileges to execute/process this msg. For some reason, the user was missing a role.
FYI, we require a user name and pwd to process most service operations, instead of relying on the user setup on each node, which allows anybody to send a message, without a username and pwd, to be processed.


PGJ October 4, 2016 at 1:47 pm

This one has done it for me!

The external alias names for the Service Operation is incorrect

Thanks a lot!


Poonam October 31, 2017 at 2:26 pm

Thanks for this blog.. it works for me as well while changing the alias name of routing.



Leave a Comment

Previous post:

Next post: