High Level Overview of Integration Broker Publishing Steps
By Chris Malek | Fri, Jan 1, 2010
The Application Messaging / Integration Broker is a complicated PeopleSoft module and can be very confusing if you don’t know what to look for.
An application message goes from several stages in both the “publishing” system and the “subscribing” system before the integration message has completed is both publishing and subscribing systems. It also gets handed off between many different application server processes and at any point one of those processes can crash or be down and it can cause the message to not complete. This will result in passwords being out of synch for users between databases until that message can reach its destination and update the database.
For some perspective the application message goes through these high level steps with each one being a failure point. Hopefully, this information will help when looking at the Message monitor.
Application Messaging Processing Steps
- A user interacting with the application changes their password which triggers some “publication” PeopleCode that creates the message.
- The integration broker receives the publication event and creates the message in the publishing broker. The message will now only be visible in the “Message Queue” on the message monitor.
- If the Message Channel Is Paused the Publication will stop here until the channel is un-paused.
- A second app server process wakes up and looks at the new message and determines where it needs to publish to and creates the “publication contracts.” The message contracts will now be visible in the “Publication Queue” in the message monitor. For the password synch mod, for each password change there is 3 contracts created, one for each destination database.
- A third process wakes up and sees the new publication contracts and processes each publication to each database separately. For example if a user changes their password in Finance, you will see in the integration broker 3 publication contracts. One for SA, Portal and CRM.
The password at this point is still not changed in the target systems yet. If the publishing database says that the messages published you need to verify that the subscribing database had completed processing the message.
- The subscribing database broker receives the published message and creates the new message instance in the integration broker. The message will now be visible in only the “Message Queue” on the subscribing message monitor.
- If the Message Channel is paused the process will stop here until the channel becomes un-paused.
- A second subscribing process wakes up and sees the new message instance and determines what subscription contracts need to be created and they get created. The message contracts will now be visible on the “Subscription Queue” on the Message Monitor.
- Once the subscription contracts are created another process wakes up and processes the subscription contract PeopleCode.
- If all of the above contracts have been processed then the message is considered completed and both database have been updated.