Scenario is that an incoming message to update a Project needs to check if Project currently exists (via Component Interface PROJECT_GENERAL) and, if not, needs to retry.
First attempt was to put subscription code into sleep loop using: GetJavaClass("java.lang.Thread").sleep(milliseconds). PeopleTools 8.49 incoming message in sleep loop remains in Working status and blocks all other queues. Messages in the other queues get stuck in status Started. Not good.
Experiment was done setting Load Balance Interval to 1 with the expectation that the incoming message in the sleep loop would block other queues for up to 1 minute and then processing would be forced to look at other queues.
Results:
Note that implementing change to Load Balance Interval required recompile and bounce of the entire application server.
Started "Project update api message" (Puam) published from 3rd party application into PeopleSoft with 5 minute sleep loop in the subscription code. The subscription code looks for the existance of the Project 10 times with 30 seconds of sleep between.
Started two "Express Asset Capitalization api messages" (EACam) published from 3rd party application into PeopleSoft that should process in near real time. What these messages do is not important, they are only to test if messaging will work through other Integration Broker Queues (formerly Channels).
PeopleSoft Integration Broker monitor in targeted PeopleSoft region showed Puam message in Working status for 5 minutes and then going to Error status.
Within those 5 minutes, the first EACam message was in Started status and went to Done as soon as Puam went to Error.
Incoming api message needing to delay
Scenario is that an incoming message to update a Project needs to check if Project currently exists (via Component Interface PROJECT_GENERAL) and, if not, needs to retry.
First attempt was to put subscription code into sleep loop using: GetJavaClass("java.lang.Thread").sleep(milliseconds). PeopleTools 8.49 incoming message in sleep loop remains in Working status and blocks all other queues. Messages in the other queues get stuck in status Started. Not good.
Experiment was done setting Load Balance Interval to 1 with the expectation that the incoming message in the sleep loop would block other queues for up to 1 minute and then processing would be forced to look at other queues.
Results:
Note that implementing change to Load Balance Interval required recompile and bounce of the entire application server.
Started "Project update api message" (Puam) published from 3rd party application into PeopleSoft with 5 minute sleep loop in the subscription code. The subscription code looks for the existance of the Project 10 times with 30 seconds of sleep between.
Started two "Express Asset Capitalization api messages" (EACam) published from 3rd party application into PeopleSoft that should process in near real time. What these messages do is not important, they are only to test if messaging will work through other Integration Broker Queues (formerly Channels).
PeopleSoft Integration Broker monitor in targeted PeopleSoft region showed Puam message in Working status for 5 minutes and then going to Error status.
Within those 5 minutes, the first EACam message was in Started status and went to Done as soon as Puam went to Error.
Did not monitor second EACam message.