Who is Altan Khendup?

A professional technologist that dabbles in innovative and interesting uses of technology, Mongolian history, philosophy and cooking ethnic foods.

Often described as part philosopher, scholar, technologist, and mentor Altan likes engaging in stimulating conversations with professionals, tackling problems in a hands-on and collaborative manner with technology, and enjoying the company of good friends and family.

 

My Twitter Stream
« Learning Something New | Main | Virtualized Teams - Applying Game Theory to the Workplace »
Monday
Oct122009

Asynchronous Messaging in PeopleSoft

In many shops that have lots of integration points between applications, asynchronous messaging is a common occurrence. In PeopleSoft applications a lot of time is spent on understanding the fundamentals such that production rollouts can be supported.

However it is well past the deployment that learning about this mechanism continues. Having been involved in large scale deployments used in a variety of interesting manners I thought I would share a few of the more helpful techniques that others can use in their PeopleSoft deployments.

Now while the PeopleSoft PeopleBooks does a really good job in going over the architecture and process, the biggest area that tends to be lacking are what I call operational insights. These are insights that as you watch the asynchronous process work helps better cement the concepts presented in the PeopleBooks:

  • Asynchronous messages leave a mark in the cache subdirectories of the application server. By that I mean certain key/dat data is actually logged. In normal operations this is of no consequence, however in rare instances when asynchronous processing appears to be using some form of older values this can be the culprit. Per any normal application server action, simply shut down the server, and delete the cache. Just make sure to place your asynchronous requests in NEW status at the minimum and insure that any outstanding requests are completely processed.
  • When one has to stop processing one of the easiest things to do is to use the PIA and simply stop the dispatchers. This will allow what is processing to continue and from that point leave everything else to finish processing. This quick tip is far faster than simply shutting down an entire domain's asynchronous messaging processes.
  • Asynchronous messages can be altered in-flight or post-flight via the PSAPMSGSUBCON table. The preferable method is to not touch in-flight requests but sometimes this simply cannot be helped. Common post-flight modifications would be resetting requests that have run into error that you would like to resubmit. Sometimes the PIA has troubles with large numbers of entries in these statuses hence it is common to use SQL to modify the values accordingly.
  • Asynchronous messaging can be also be used in places where Application Engine programs might also be used. Certain customizations can create events in the asynchronous approach such that "batch" operations can in fact be executed that would normally require an Application Engine. This approach has the benefits of creating highly scalable operations. The disadvantage is of course that such an approach does not allow for use of the normal tools and operations found in the Application Engine. In almost all cases where the asynch is used, it is has been to handle scaling and performance issues related to the application engine.
  • Make sure to regularly clear out your asynchronous data structures. There is a lot of data kept in the underlying tables of the asynch. This is common to all application servers that decide to use the database as a data store. If you have only a few hundred, then you can go quite a while. If however you do a few hundred million in a day, then this becomes very troublesome. Especially if fluctuations are such that the size can grow from say a few hundred thousand to a few hundred million and back again over the course of a week. The PeopleSoft delivered application engine job is a good process. However if you attempt to run it, "vanilla" against such large data volumes you will have issues. It is best to look at your usage, and create a modified version of the archive/purge job so that it best meets the needs of your environment.

These are some of the top items to remember about asynchronous processing with PeopleSoft. Over the course of the next few weeks I will be putting up some lower level details about this approach and how it differs and complements the synchronous approach within a PeopleSoft environment.

 

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (3)

I really like this blog post, it has some great info. Thank you and keep up good work.

algarve flight

February 8, 2010 | Unregistered Commenteralgarve flights

I really like this blog post, it has some great info. Thank you and keep up good work.

algarve flight

February 8, 2010 | Unregistered Commenterinternational flight

Thanks! I will try to post what I can. Glad someone is finding it useful!

February 16, 2010 | Registered CommenterAltan Khendup

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>