Context

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.

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

Methods

After completing or updating the service rules in the package, use the Methods section to confirm that all the services rules you expect are present and accessible before you deploy. For Service REST rules, you can also view and delete the invocation history.

• Refresh methods – Click to refresh the list of methods. The system searches the PegaRULES database and lists rules (of the selected service rule type) with the package name as the first key part. If the Service access group field is not blank, the display includes only rules of the selected service type that are visible to a requestor with that access group. If the Service access group field is blank, the display includes only rules (of the selected service type) that are visible to your ruleset list. This field uses a search to list the results, and does not update any rules.
• Service type – To review a list of the methods (each defined by a service rule) in the package, select one service rule type. Save the form and click Refresh methods .
• Service monitoring – Click the Gear icon to configure whether to monitor this rule and if monitoring, whether to include the clipboard state. This field is displayed when the service type is Rule-Service-REST. You can configure monitoring at the service level only if the service/EnableGlobalMonitoring dynamic system setting is set to Deferred.
  • In the Select service monitoring field, select whether to enable monitoring for this rule.
  • If you turn on monitoring, in the Capture clipboard state field, select whether to include the state of the primary data page in the monitoring results.
• Clear invocation history – Click this field to delete the invocation history for all rules in the service package. This field is only displayed when the service type is Rule-Service-REST.
• Service method – In this read-only list, click the service rule to open it. Each service rule found in the service package is listed in the column. Each row lists the service version.
• View Invocation History – Click this field to view the invocation history for an individual rule. The Service request invocation history dialog box displays information about each invocation of the rule. You can view the URI template, request and response data, the clipboard state (if configured), and attachments that are included in the request and response.
• Test Endpoint – Click Test Endpoint to open a dialog box where you can enter values for the variable components of the URI template. The dialog box will not open if the endpoint only contains literal components.

Deployment

Before you deploy

1. Create the service rules that belong to this service package. Then update the list of methods and save the form.
2. Make sure that your RuleSet list provides access to all the service rules in the package.
3. If your development team uses check-out and check-in, ensure that all service rules, service activities, and other rules they reference are checked in before deploying. Rules in personal rulesets (that is, the checked-out versions of rules) are ignored when you deploy.

Completing the fields

This section describes the fields in the deployment section.

• Deployment type - The options that appear in this field depend on what the Service Type is set to in the Context section.
  • WSDL or WSDL for WebLogic - WSDL generates a WSDL file for SOAP or dotNET services.
  • V2.0(RMI) or V2.0(Local) - Generates a JAR file that represents EJB service rules. For information about deploying EJB services, see the Pega Community article Building EJB Services.
    Note: For information about the V2.0(SOAP) or V1.0(SOAP) options, see the Pega Community article Building EJB Services.
  • RemoteJavaClass or LocalJavaClass - For Service Java, to generate a JAR file that represents Java service rules.
  • JSR-168 (Portlet 1.0) or JSR-286 (Portlet 2.0) - Generates a portlet.war Web archive (WAR) file that represents a portlet service rule.
    Note:

    The rule type Service Portlet is deprecated. Use Pega Web Mashup instead.

  • WSRP 1.0 Producer - Generates a portlet.war Web archive (WAR) file that can be deployed as an OASIS Web Services for Remote Portlets (WSRP) producer.
• Service class - Specify the service class name ( Customer Class Name ) — the second key part the service rules (methods) in the package — to restrict the deployment file to represent only the service rules in that service class.
• Specify custom target namespace - You can enter a custom target namespace for SOAP and SAP service rules. By default, the target namespace has the following form: urn:PegaRULES:SOAP.<servicepackage>:<serviceclass>. Select this option to override the default.
• Target namespace URI - Enter the target namespace URI, for example, http://www.myco.com
• Deployment Results - This area provides links to the generated artifacts. Click a link to download the artifact.