Introducing a small but powerful PeopleSoft bolt-on that makes web services very easy. If you have a SQL statement, you can turn that into a web service in PeopleSoft in a few minutes.Read More & Purchase
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.
Asynchronous one-way service operation is often used between PeopleSoft systems to sync data. For example, the
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:
There are a few different handlers that can be added to this type of service operations. The order of the subscription handler processing is:
There are two sub-categories to this type of service operations:
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
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.
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.
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:
&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.