Show
all
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).
C-2438
- checkPrintErrors
- checkFaxErrors
- purgeRequestsTable
- ProcessServiceQueue
- ProcessConnectQueue
PegaDISTRIBUTION Manager is a small, optional Windows server
application used to support a Process Commander 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.)
checkFaxErrors
The checkFaxErrors agent checks the PegaDISTRIBUTION
Manager database and updates the history of a work object if faxing of
the outgoing correspondence was not successful.
checkPrintErrors
The checkPrintErrors agent checks the PegaDISTRIBUTION
Manager database and updates the history of a work object if printing
of the outgoing correspondence was not successful.
purgeRequestsTable
The purgeRequestsTable agent removes completed and stale
requests from the PegaDISTRIBUTION Manager database.
ProcessServiceQueue
Proj-318 5.4 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 Process Commander 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.ABLAL 11/14/08
GRP-500
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. ABLAL
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. ABLAL
1/9/09
For more information, see the Pega Developer
Network article PRKB-25029 How asynchronous service processing
works.
ProcessConnectQueue
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
Connect SOAP rules.5.5 GRP-255
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. ABLAL
1/9/09
Concepts