Links may not function; however, this content may be relevant to outdated versions of the product.
Service Request Processor data instances
When an EJB, HTTP, Java, JMS, MQ, or SOAP service rule is configured to process service requests asynchronously, or is configured to requeue failed service requests for a later execution attempt, service request information is stored as a persistent object in a request queue in the PegaRULES database.
- How to handle the queued service request objects
- Which queue to use
- How many times to run the requests if they fail the first time
- Whether to store the request object with the results of the processing after the processing is finished.
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
agent are used for the second and subsequent retries, if
configured. Queuing also occurs when configured through a
condition on the
the service rule.
For more information, see these Pega Community articles:
- How asynchronous service processing works
- Configure a service to process requests asynchronously
- Configure a service to queue a failed service requests for another attempt
AccessCreate the Service Package data instance before creating any service rules with that package name.
In Dev Studio, in the navigation panel, clickto access the Service Request Processors in your system.
CategoryThe Data-Admin-RequestProcessor-Service class contains service request processor data instances. This class is part of the Integration Resources category.
- Service Request Processor – Completing the New or Save As form
- Service Request Processor form – Queuing Options tab
- Service Request Processor form – Dequeuing Options tab
Previous topic MQ Server form – Completing the Environment tab Next topic Service Request Processor – Completing the New or Save As form