Configuring the service package in the Email Wizard

Configure the service package to define a package name, define access for listeners, and support deployment of services.

1. From the Processing Mode list, select Stateless if the services in this package can be run by any requestor in a pool of requestors, without regard to processing that the requestor performed earlier. Otherwise, select Stateful.

Caution! Choose this value carefully. Using requestor session pooling may improve performance if a high volume of uniform requests arrive, even when authentication is required.

2. In the Service access group field, enter the access group for the service package. This access group is used during rule resolution to find the correct service rule at run time. This field is required.
3. If the service request requires authentication, complete the following steps:
   1. Select the Requires authentication check box.
   2. From the Authentication type list, select the type of authentication to use.  
   Select one of the following options:

   • Basic authentication – Select for HTTP-based services such as REST, HTTP, SOAP, and SAP. The system expects Pega Platform operator ID and password values in the arriving request message.

   Select the Require TLS/SSL for REST services in this package check box if you want to use TLS/SSL for service REST rules that belong to this service package.

   When you select this check box, all invocations of REST services belonging to this service package must use TLS/SSL, which uses the HTTPS protocol. If REST services are invoked using HTTP, a code 403 status is returned with a warning.

   • OAuth 2.0 – This option is supported only for REST services for access using open authorization.
   • Custom authentication – Select to provide an authentication service.

   If you are using LDAP authentication, select an authentication service (a Data-Admin-AuthService instance) when the service type is SOAP (Rule-Service-SOAP) or HTTP (Rule-Service-HTTP), SAP (Rule-Service-SAP, or REST (Rule-Service-REST).

   Note: Authentication service is required only for custom authentication including LDAP and SAML 2.0 authentication. You could also use HTTP Basic for user authentication, or, in the case of HTTP Service you could provide the HTTP headers UserIdentifier and Password for user authentication instead of basic authentication.

For more information, see the following topics:

• Example of unathenticated user's service package access group for an example of an unauthenticated user's access group.
• Example of authenticated user's access group for an example of an authenticated user's access group.

4. Select the Suppress - Show HTML? check box to cause the system to skip over any activity step that calls the Show-HTML method in the service activities that execute through service rules that reference this service package instance.

   This feature lets you reuse or share an activity that supports both interactive users and services.

5. Expand the Pooling section to configure a requestor pool for the services in this service package.

   Set the appropriate values in the following fields.

   • Maximum Idle Requestors – Specify the maximum number of idle requestors that can be in the pool for services from this package.

     If an active requestor becomes idle and is returned to the pool when the current number of idle requestors is at this limit, the requestor is deleted.

     To allow an unlimited number of idle requestors, set this value to -1;, the system does not delete idle requestors until they time out.

   • Maximum Active Requestors – Specify how many concurrent requestors can be created and in use for the services in this package. Set this value to 1, even if you have disabled requestor pooling (that is, Maximum Idle Requestors is set to 0).

     If a service request arrives when the number of active requestors is at this limit, the system waits for an idle requestor. It does not create a requestor for the request.

     To allow an unlimited number of active requestors, set this value to -1.

   • Maximum Wait (in seconds) – Specify how long, in seconds, the system waits for a requestor to return to the pool when a service request arrives, but the number of active requestors has reached the Maximum Active Requestors value.

     If this time interval passes before any requestor returns to the pool, the request fails. The system sends a failure message to the external client system.

     Use a value of -1 to indicate that requests never wait. If the pool has no idle requestors, a new one is created.

Open topic with navigation