CA Tuesday Tip: What is the NMS_MESSAGES table used for? (and more)

Discussion created by Shawn_Moore Employee on Mar 22, 2011
CA Clarity Tuesday Tip by Shawn Moore, Sr. Principal Support Engineer for 3/22/2011

This tip suggestion came in from Steve Seaney, "NMS Messages... What it is, what it does, and why is it so darned promiscuous. "

NMS_MESSAGES is a fairly complex area of the product, so I've compiled some information (quite a bit from development) and added clarification as well.



Clarity's process engine generates events to progress a process. Events can apply to the process, the object governed by the process or activities generated by the process. With each event, a record is created in the NMS_MESSAGES table with corresponding records in the NMS_MESSAGE_DELIVERY table. Here are some examples of scenarios that cause events to be generated:

[*]Starting a process
[*]Cancelling a process
[*]A process completes a step action
[*]A Process Updates an Object
[*]Marking an Action Item done for a process

Since 7.5.3, process engine events are persisted in NMS_MESSAGES table. Once they are received by an Event Manager in the cluster, a record will be inserted into NMS_MESSAGE_DELIVERY table for each Event Manager in the cluster. There will be 1 event manager for every app or bg server in a cluster. Therefore, if your environment has 2 app services and 2 bg services, there would be 4 records stored in NMS_MESSAGE_DELIVERY table for each event raised in the application.

The persistence of the events in these tables is to make sure events that cannot be consumed instantly can be retrieved and handled later. Though JGroup offers guaranteed message delivery, we still need a data store to persist these messages to handle the following situations:
(1) When there is heavy process load. In this case, the events will likely be consumed long after they are delivered.
(2) When Process Engines are not available. (i.e. during background service downtime.)

The events and event delivery records stored in these tables are purged after the "Message Time-to-Live" amount of time configured in NSA. By default, it is 120 minutes. Some process-heavy customers require the events to be persisted longer than 2 hours. (i.e. up to 24 hours)

These 2 tables, especially NMS_MESSAGE_DELIVERY, can generate significant activity when there are a large number of daily transactions and within complex environment configurations. Multiple fixes have been done to enhance the performance of these 2 tables (e.g. removing orphaned records, adding indexes). Development is also reviewing this method of persisting events from an architectural standpoint.

I hope you enjoy the tip and I hope it makes this area a bit more clear at least as to why it exists!