Asynchronous one-way

The Asynchronous one-way service operation are used for integrations that do not need to be real time. They help to build eventually consistent integrations. These can be outbound from PeopleSoft or inbound into PeopleSoft. They can also be publish back onto the publishing system.

• Outbound operations are the result of some “event” happening in PeopleSoft that some other external system may want to know about.
  • For outbound operations, the publishing code has no idea who the subscribers are and what they do with the data. The integration broker holds the responsibility of who should receive the event. The publishing code in the PeopleSoft component or external system just knows that some “event” occurred and that it should create a message.
• Inbound operations allow the local PeopleSoft system to subscribe to events in external systems and update the system with that data if so desired.

The Asynchronous one-way service operation is often used between PeopleSoft systems to sync data. For example, the USER_PROFILE and PERSON_BASIC_SYNC are asynchronous one-way service operation. These are generated from events in PeopleSoft that trigger a message to be sent to subscribers.

When the integration broker receives an asynchronous operation from a local event, it will determine what publications or local subscriptions should trigger. All messages are put in a queue and are processed at some point in the future. For delivered PeopleSoft sync messages like PERSON_BASIC_SYNC these are often processed in a few seconds and pushed to subscribing nodes. However, the queues could have a backlog or be paused so there is not guarantee they are processed. Additionally, someone could cancel the operation and it may never be published or subscribed to. Therefore, these types of service operation should be considered as “eventual consistent.” General Characteristics of Asynchronous one-way service operations:

• They belong to a queue
• They can have 0 to n outbound routings that trigger publication contracts
• They have have 0 to n local routings that trigger subscription contracts
• The processing of the actual data happens at some point in the future.
• When an event is published, there is no guarantee anything with happen with the data. It is “fire and forget” from the publishers perspective.
• There is no response from the integration broker or the handlers other than an “acknowledgement” that the message was received and the transaction id that was created.

There are a few different handlers that can be added to this type of service operations. The order of the subscription handler processing is:

1. OnPreNotify
2. OnNotify
3. OnPostNotify

There are two sub-categories to this type of service operations:

• Inbound - The system receives these messages from external systems and processes the result. The response to the client is just an acknowledgement that the message was received. The actual message processing happens at some point in the future (if at all)
• Outbound - These are outbound publications to the business event happening in the local database.

Generally, in PeopleSoft Asynchronous one-way are either a subscriber or publisher. However, you can see PeopleSoft system be both a subscriber and a publisher of asynchronous one-way messages. You may also see a system subscribing to local events to do additional delayed processed (See Understanding Local Integration Broker Routings)

The delivered “sync” and “fullsync” operations are all asynchronous one-way service operations.

Valid Handlers for Asynchronous one-way

• OnNotify (Inbound)
• OnPostNotify (Inbound)
• OnPreNotify (Inbound)
• OnReceive (Inbound) (OnAckReceive)
• OnRoute (outbound)
• OnRequestSend

The integration gateway returns a message to the client in these types of service operation that the message was received. Your handler code will not be able to return any data to the client.

The main handler(s) that respond to inbound messages are the OnNotify handlers. You can actually have several OnNotify handlers active in an inbound Async SO. This allows you to update different pieces of data from the same message and have that code separated.

Invoking an Inbound Asynchronous Service Operation

POST /PSIGW/HttpListeningConnector HTTP/1.1
Host: hcm-856.c.peoplesoftdemo-1470578694381.internal:8000
OperationName: CHG_ASYNC_UTEST.v1
To: PSFT_HR
Content-Type: text/xml; 

<?xml version="1.0"?>
<request>
<param1>value</param1>
</request>

The response will resemble this:

HTTP/1.1 200 OK
Date: Sun, 29 Oct 2017 23:31:50 GMT
Content-Length: 213
Content-Type: text/xml; charset=UTF-8
transactionid: 5695c49d-bd01-11e7-b7eb-c155c6e4688a

<?xml version="1.0"?>
<IBResponse type = "success">
  <DefaultTitle>Integration Broker Response</DefaultTitle>
  <StatusCode>0</StatusCode>
  <TransactionID>5695c49d-bd01-11e7-b7eb-c155c6e4688a</TransactionID>
</IBResponse>

You will see an HTTP Header called transactionid that carries the unique transaction ID created by PeopleSoft. That value is also returned in the XML body. Remeber that your publication may or may not be processed by the PeopleSoft system. It is up to the handler code to determine that.

Publication PeopleCode

If you have a component that needs to publish events you have to have some trigger to create those events and push them to the integration broker. The integration broker will determine who needs to receive the message. That code often resembles something like this:

Source: ROLEMAINT.GBL.SavePostChange

&MSG = CreateMessage(Operation.ROLE_MAINT);
If &MSG.IsOperationActive Then
   &ROLECHANGE = GetLevel0();
   If %Mode = "A" Then
      &MSG.CopyRowset(&ROLECHANGE);
      %IntBroker.Publish(&MSG);
   Else
      &MSG.CopyRowsetDelta(&ROLECHANGE);
      %IntBroker.Publish(&MSG);
   End-If;
End-If;

This code should execute fairly quickly and actually does not actually publish to the other system. It merely logs some data into some Integration Broker (Operation Instance Tables) and at some point in the future the IB application server processes will pick it up and determine what needs to happen with this.