Question

Queuing a Advanced Agent using Queue-For-Agent method

Can we queue an Advanced Agent using Queue-For-Agent Method. I tried passing Advanced Agent parameters such as Ruleset and Name of the Agent to Queue-For-Agent method in an activity and able to save the activity. But did not try the behavior (executing the activity).

I want to know how it will work like will it queue the record (insert a record in pr_sys_queue table) and will it process it like locking the work object ? or will work same as Standard agent with the Auto queue management checkbox not selected ?

Can you please explain me ?

Comments

Keep up to date on this post and subscribe to comments

January 23, 2019 - 9:06am

Pega
January 24, 2019 - 2:05am
Response to MarcLasserre_GCS

Hi,

I had gone through that, But my question is different. How Advanced Agent will work if I do Queue-For-Agent for it.

Pega
February 8, 2019 - 11:45pm

Hello All,

Can you please help me with this.

April 17, 2019 - 3:22am

Even i have the same query..any help is appreciated.

July 31, 2019 - 3:54pm

An advanced agent can definitely utilize the agent queue (Queue-for-agent), but unlike Standard agent, you need to cover following points in your agent activity -

Step 1: Retrieval of tasks from Agent queue - If you use Queue-For-Agent method or OOTB QueueForAgent rule to queue the work object, PRPC will basically create an instance of System-Queue-DefaultEntry class (OOTB agent queue class). The corresponding table of this class has following fields exposed. Use Obj-Browse or Report def to look for (pzInskey of) queued item of your agent against this column pyAgentName that holds the name of the agent of your queued record (Open xml of any of the instance of this queue class to get familiar with the attributes of this class). Your query should be same as 

select pzInsKey

from pr_sys_queues

where pyAgentName = 'your_agent_name' and PYITEMSTATUS != 'Broken-Process'

Columns on pr_sys_queues

  PXCOMMITDATETIME    TIMESTAMP    7 

  PXSAVEDATETIME    TIMESTAMP    7 

  PXCREATEDATETIME    TIMESTAMP    7 

  PXINSNAME    VARCHAR    128 

  PXLASTEXECUTIONDATETIME    TIMESTAMP    7 

  PXOBJCLASS    VARCHAR    96 

  PYAGENTNAME    VARCHAR    255 

  PXPROCESSINGNODEID    VARCHAR    64 

  PYATTEMPTS    DECIMAL    18 

  PYITEMID    VARCHAR    255 

  PYITEMSTATUS    VARCHAR    32 

  PYMAXATTEMPTS    DECIMAL    18 

  PYMINIMUMDATETIMEFORPROCESSING    TIMESTAMP    7 

  PYPRIORITY    DECIMAL    18 

  PYSELECTID    VARCHAR    255 

  PZINSKEY    VARCHAR    255 

  PZPVSTREAM       4000 

 

  1. Step 2: Open the queued record using its pzInsKey with lock. Remember to either run your agent on single node across all server instances, or do proper 'Unable to Lock' exception handling here to avoid task contention scenario where your agent on different nodes will try to process the same queued task at the same time (this is the reason why Standard agent is always easy to work with). In the opened task instance, look at .pyInsHandles() value list. (Ideally, PRPC can associate multiple instances of different classes, but normally only pzInsKey of work object is mapped here). 1st entry on this value list normally holds the pzInsKey of work object that you queued using Queue-For-Agent.
  2. Step 3: At this point you have the information to open the work object and start the required processing (resume flow, send corr etc.). But remember that in advanced agent, system won’t automatically take a lock on the work object; you need to write your code to do so, and also handle the work object ‘already locked’ scenario.
  3. Step 4: Assuming at this point you managed to open the work object and lock it, do the required processing. Make sure that you ‘deferred save’ changes to all instances (work/data) that you have done in your processing.
  4. Step 5: Deferred delete the queue instance that opened at step 2. This is important as you are responsible to purge the queued entry upon successful processing of task; system won’t do it for you (unlike standard agent).
  5. Commit all deferred changes with proper exception handling, i.e. – if commit fails you need to keep the queued task (opened at step 2) for another try later on. Ideally, you should do rollback your changes (deferred save + deferred delete), plus any additional exception handling. You may/should also update the following two attributes of queued entry (opened at step 2) .pyAttempts, .pxLastExecutionDateTime in case of failure in processing. You might also check if .pyAttempts is now equals to .pyMaxAttempts. In that case, you might set .pyItemStatus = "Broken-Process".

But, if commit is successful, you’re all done. As current queued task is removed now from queue, it will not be picked up by your agent on next run.

 

Moral of story - unlike Standard agent, Advanced agent can't automatically dequeue ququed task, open work object with lock and commit all changes at the end of your processing; you need to handle all of those in your agent activity. So, if your Business requirement permits, switch to Standard agent to make your design less complex.