Service Package form
Completing the Context tab

Context

Complete the Context section to indicate whether stateful or stateless processing applies to this package, and to identify an access group for listeners and requestors.

• Processing mode - Select Stateless if the services in this package can be executed by any requestor in a pool of requestors, without regard to processing that the requestor performed earlier.
  
  Select Stateful otherwise.
  
  Choose this value carefully. Using requestor session pooling may improve performance if a high volume of uniform requests arrive, even when authentication is required.
• Service access group - Identify an access group for requestors of this service package.
  
  Pega 7 Platform uses this access group, even for services that require authentication, to locate the service rule.
  
  Example of unauthenticated user's service package access group
  
  If this service is to execute without authentication, set up an access group that provides only the minimum capabilities to service requestors and reference it here. For example, you can include an access role (Rule-Access-Role-Name rule type) linked to Access of Role to Object rules (Rule-Access-Role-Obj rule type) that limits which classes the service can view or update. Also, review the service activity to ensure that no combination of input parameters allows the activity to perform more than the service needs.
  
  Click the Open icon to open the access group data instance.
• Requires authentication ? - Select if the service request requires authentication. When selected, the system expects Pega 7 Platform Operator ID and password values in the arriving request message.
  
  Example of authenticated user's access group
  
  The access group from the service package is used to find the service rules and the service activities to be executed must be accessible to requestors operating with this access group.
  
  This requires the authentication activity to be accessible to the access group specified in the service package.
  
  If authenticated, the access group of the authenticated operator is used as the context, rather than the access group of the service package, in order to find all application-specific rules. That context is reset if the service is pooled and the requestor is returned to the pool.
  
  When selected, authentication occurs only for the first request for stateful services that use pooling and don't destroy the requestor. Later service requests that include the Session ID in the request message continue with the same previously authenticated requestor session.
  
  Note: In high-volume production settings, authentication can be costly in terms of computer resources. However, unauthenticated service requestors can access the rulesets and versions conveyed by the access group in the Service Access Group field plus those assigned to the requestor type named APP. (Services run as APP requestors.) Depending on security and volume factors, for best performance you can leave the Requires Authentication? box cleared.
  
  The location and name of the Operator ID and password values vary, depending on the service type:
  
  • EJB - Username and password are passed in as arguments to the Create() method of the EJB Home interface.
  • Email - Operator ID and password are on the Properties tab of the email listener data instance.
  • JMS - Operator ID and password are on the Listener Properties tab of the JMS listener data instance.
  • MQ - Operator ID and password are on the Properties tab of the MQ listener data instance.
  • SOAP, SAP and dotNet - The arriving SOAP request message must contain a user name and password value either in the HTTP header (using HTTP Basic Authentication), or as header or parameter values of the SOAP request envelope.
  • COM - Username and password are passed in as arguments to the create() method of the COM Home interface.

  Important: The rule type rule-service-COM is deprecated. As appropriate, migrate to Service dotNET rules.
  

• Authentication type - Select the type of authentication to use. Select Basic authentication for HTTP-based services such as REST, HTTP, SOAP, and SAP. Select custom authentication to select an authentication service. When you select Custom, the Authentication service field is displayed for selecting the authentication service to use.
• Authentication service - This field appears only when Requires authentication ? is checked and Authentication type is Custom. 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.
• Use TLS/SSL (REST only) - This field appears only when Requires authentication ? is checked and Authentication type is Basic. This check box is applicable to Service REST rules that belong to this service package. When selected, all invocations of REST services belonging to this service package must use TLS/SSL, that is, using the https protocol. If the REST services are invoked using http, a code 403 status is returned with a warning, and the following message in the HTTP response header:
  
  299 <serverHost> "Use of TLS/SSL is strongly recommended for services using Basic Authentication."
  
  
• Suppress Show-HTML? - Select 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.

Methods

Use this section after completing or updating the service rules in the package to confirm that all the services rules you expect are present and are accessible before you deploy.

• 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 button uses a search to list the results. It 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 methods - (Read only) Each service rule found is listed on the grid. Each row lists the service rule key parts and the RuleSet the service belongs to. Click on a row to open the service rule.

Deployment

Use the Deployment section to generate deployment files for a SOAP, .NET, EJB, Java, Portlet (JSR168), SAP, SAPJCo, or COM service package.

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 Building EJB Services, a document on the Integration area of the PDN.
    
    Note: For information about the V2.0(SOAP) or V1.0(SOAP) options, see Building EJB Services, a document on the Integration area of the PDN.
  • 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. For information about building portlet services, see Building Portlet Services, a document on the Integration area of the PDN.
  • 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. For information, see PDN article How to deploy a Process Commander portlet as a 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 those 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 on a link to download the artifact.

Open topic with navigation