Understanding the Pega-IntSvcs agents
Understanding the Pega-IntSvcs agents |
|
Five agents in the Pega-IntSvcs RuleSet process queued service and connector requests and perform maintenance for PegaDISTRIBUTION MANAGER (formerly called Correspondence Output Server, or COS).
PegaDISTRIBUTION Manager is a small, optional Windows server application used to support a PRPC system for printing and faxing of Microsoft Word documents. PegaDISTRIBUTION Manager can also convert Word documents to Acrobat PDF format.
If your system does not use PegaDISTRIBUTION MANAGER, the checkPrintErrors, checkFaxErrors, and purgeRequestsTable agents do not need to run. To disable them, clear the Enabled? option in those rows on the Schedule tab of every Agent Schedule data instance in your system.
Because these are legacy agents (agents created before V5.4 and not updated to use the Queue Manager infrastructure), if your system does use PegaDISTRIBUTION Manager, enable these agents by selecting the Enabled? option for them on one node only. When enabled, these agent activities interact with the COS database every three minutes to check for errors and purge records from the COS database. (If your application uses PegaDISTRIBUTION MANAGER to convert Word DOC files to PDF format, an agent in the Pega-ProCom agents rule — not the Pega-IntSvcs agents rule — handles the upload and attachment processing.)
The checkFaxErrors agent checks the PegaDISTRIBUTION Manager database and updates the history of a work item if faxing of the outgoing correspondence was not successful.
The checkPrintErrors agent checks the PegaDISTRIBUTION Manager database and updates the history of a work item if printing of the outgoing correspondence was not successful.
The purgeRequestsTable agent removes completed and stale requests from the PegaDISTRIBUTION Manager database.
Service requests of any of seven service types can process service requests asynchronously. When configured to do so, EJB, HTTP, Java, JMS, MQ, SOAP and File services use the Queue Manager infrastructure to store service requests as persistent objects in the PegaRULES database.
The class, queuing and dequeueing options for the service request are determined by a Service Request Processor data instances. See About Service Request Processor data instances.
The first execution of an asynchronous service request occurs in the service requestor, but in a separate background Thread that executes after, rather than before, the service response is set. Queuing and the ProcessServiceQueue agent are used for the second and subsequent retries, if configured. Queuing also occurs when configured through a Queue When condition on the Fault tab or Response tab of the service rule.
The ProcessServiceQueue agent is disabled by default. To enable it, select the Enabled? option for it on the Schedule tab of the agent schedule instances (Data-Agent-Queue class).
When the ProcessServiceQueue agent executes a queued service request, the execution is performed with the authorization profile of the service/listener.
For more information, see PDN article How asynchronous service processing works.
Beginning with V5.5, SOAP and HTTP connector requests can be processed asynchronously. The class, queuing and dequeueing options for the service request are determined by a Connect Request Processor data instances. See About Connect Request Processor data instances and More about SOAP connector rules.
The ProcessConnectQueue agent is disabled by default. To enable it, select the Enabled? option for it on the Schedule tab of the agent schedule instances (Data-Agent-Queue class).
When the ProcessConnectQueue agent executes a queued connector request, the execution is performed with the authorization profile of the service/listener.
|
agent, PegaDISTRIBUTION Manager, Queue Manager |
|
Agents Overview
About Agents rules About Agent Schedule data instances About the Correspondence Output Server |
|
Atlas — Standard Agents |