Someone asked a question in the HEUG (Higher Education User Group):
"When generating/re-generating 'Local-to-Local' routing, there is a 'Transactional' check box that is made available. What does it do?"
And it made me realize that I have been noticing this setting in the past but had not paid much attention to it. I basically used to ignore this setting previously.
Curious, I tried to dig into PeopleBooks:
"By choosing the Transactional check box, the system routes the service operations using the OnRequest event on a single transaction". What does this mean? It is certainly not self-explanatory!
I ended up raising a SR with Oracle to ask them for clarification on what this setting does and found that it is a pretty neat feature hiding under the covers!
When we select the “Transactional” checkbox while generating the “Local-to-Local” routing, the system would automatically route the message (for the Local-to-Local transaction) to the OnRequest handler without having to go out through Integration Broker and then come back in again.
Basically, this bypasses unnecessary traffic through the IB gateway. This is a great feature for Local-to-Local synchronous services and I would certainly be using this setting in the future. There is a lot of performance value to be gained (where appropriate).
Note: Just because the messages get routed directly to the OnRequest handler does not mean that the transactions lose out on other IB functionality and features (e.g.: writing into log tables, etc.).
Hope you find this useful in demystifying this configuration!
"When generating/re-generating 'Local-to-Local' routing, there is a 'Transactional' check box that is made available. What does it do?"
And it made me realize that I have been noticing this setting in the past but had not paid much attention to it. I basically used to ignore this setting previously.
Curious, I tried to dig into PeopleBooks:
"By choosing the Transactional check box, the system routes the service operations using the OnRequest event on a single transaction". What does this mean? It is certainly not self-explanatory!
I ended up raising a SR with Oracle to ask them for clarification on what this setting does and found that it is a pretty neat feature hiding under the covers!
When we select the “Transactional” checkbox while generating the “Local-to-Local” routing, the system would automatically route the message (for the Local-to-Local transaction) to the OnRequest handler without having to go out through Integration Broker and then come back in again.
Basically, this bypasses unnecessary traffic through the IB gateway. This is a great feature for Local-to-Local synchronous services and I would certainly be using this setting in the future. There is a lot of performance value to be gained (where appropriate).
Note: Just because the messages get routed directly to the OnRequest handler does not mean that the transactions lose out on other IB functionality and features (e.g.: writing into log tables, etc.).
Hope you find this useful in demystifying this configuration!
I would like to mention here, in case anyone else comes across this post, that with the Transactional checkbox you do not get ALL the benefits of running through integration broker.
ReplyDeleteOne of the limitations of iScripts is that you cannot execute a RemoteCall. We found that by pushing the RemoteCall into a synchronous local-to-local integration broker service operation, we could call the IB service operation from iScripts which could then run the COBOL and return the result back to the iScript to resume processing from there. The drawback to this is that TWO app server processes will be consumed during this call, one for the iScript processing (while waiting for a synchronous blocking IB call) and another for the IB call. This can lead to deadlocking the entire PeopleSoft system under very high loads if the same app server domain is processing both interactive online traffic as well as the integration broker traffic, necessitating creating another app server domain solely for IB calls to avoid this pitfall.
Now, we saw this transactional flag and thought it was the solution to our problem. However, when we tested it, the same old error returned "Think-time PeopleCode event (RemoteCall), but a SQL update has occurred in the commit interval", no matter what kind of commit we did before the RemoteCall [DoSaveNow(), CommitWork(), or SqlExec("commit")]. A separate RemoteCall called from iScripts through IB reliably crashed the application server when the "Transactional" flag was set but worked fine with the flag cleared.
So, the benefit we get from the local-to-local IB call was a separate transaction, which means that when Oracle says "the system routes the service operations using the OnRequest event on a single transaction" it truly means you don't get another transaction and so that "benefit" goes away.
I see that you (Sasank) are now a director of PeopleTools at Oracle. It would be great if it were possible to trigger COBOLs from iScripts without requiring either two API calls or two app servers...