Configuring the service package in the Email Wizard

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

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 by using HTTP, a code 403 status is returned with a warning.

   • OAuth 2.0 – This option is supported only for REST services for access that uses 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 can also use HTTP Basic for user authentication, or, in the case of HTTP Service you can provide the HTTP headers UserIdentifier and Password for user authentication instead of basic authentication.

• 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.

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

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.