AQ Question how to go about please advise

Question

Thanks. The issue with message grouping is that what do we do if more messages for the same order get added to the queue. This will not be part of the group and thus might get picked up by some other thread.
As of now, one message belongs to one transaction.
This is one approach I was thinking:
This option involves creating a custom table.
This table will store all order#s that are being processed at any given point in time, such that no other thread can pick up a mesg for the same order. Once the message for a specific order is processed, the order# is removed from the custom table.
Thanks again!!!
Given below is a high level approach:
Step 1. Peek and reserve - peek for an order in queue that is not in custom table (dequeue in locked mode with a condition). Reserves available order. (separate transaction)
Step 2. Dequeue mesg for the order# reserved in previous step, with min enqueue time (dequeue in remove mode with a condition).
Step 3. Clean custom table - separate transaction
Say we have the following orders and 5 threads
100
100
100
101
102
So all threads try to deq a mesg. Say 3rd thread is the first one to deq order 100 (LOCKED mode). It will write this to custom table and commit transaction. SInce we will have a deq condition to ignore all orders that exist in custom table, no other thread will be able to pick up order 100. Order# is primary key on custom table.
Now we will deq with condition :- order# 100 and min enq time for order 100
once mesg deq. Clean custom table.
Any thoughts???
Thanks. Is it ok if I call you at 10pm EST. If not, what time is convenient, I will call then. Thanks a lot for helping me out with this. Really appreciate!!!!
Sangeeta
This is the background incase if we need to know the entire story of the issue:
Thanks Sri. I did find this bug, but the customer is still leaning to go with triggers. They tried a few test cases with the trigger on the queue table and since they did not hit any issues, they would like to know in what situation the trigger will cause an issue.
Client wants to implement the following:
Consider there are multiple messages in the queue belonging to the same corr id.
If one thread dequeues a message (say for corr id 100), all other messages belonging to the same corr id should get locked, such that none of the other threads can dequeue those. But these threads should continue processing messages belonging to other corr id's.
Messages need to be processed in the order they were enqueued.
Only after the first message for that corr id gets processed, should the next message for the same corr id get processed, this in turn locking the remaining with the same corr id.
If any new messages for the same corr id get enqueued, then they too should get locked.
Performance is a very important factor for this application.
Any thoughts on how to implement this would be greatly appreciated..

Answer 1

UCCE is an umbrella solution that includes ICM (central controllers, PGs, AW, HDS) as ACD, then you have CVP as the IVR working with VXML GWs, CUCM as PBX, CUIC for reporting (or 3rd party), Finesse or CTI OS, or CAD for agent desktop, optional CUSP as SIP proxy and bunch of 3rd parties if needed for call recording, workfrce management, wallboard, etc, etc.
ICM can also run outside of UCCE integrated with 3rd party ACDs, but this is more rare in recent years.
HTH, please rate all useful posts.
Chris