More about Connect REST rules

Calling activity

A REST connector is called by a connector activity — an activity with the Activity Type set to Connect that applies to a class derived from the Work- base class. Such activities can be referenced in an Integrator shape () in a flow rule.

Connector activities have the following kinds of steps:

• A step that creates a named page for the class that the connector rule applies to. This page becomes the primary page for the connector.
• A step that sets property values and input parameter values that serve as the input for the connector's message sent to the external application.
• A step that calls the connector rule. This step uses the Connect-REST method. The step page is the primary page of the connector.
• A step that processes the reply message that the connector rule receives.

Attachments

Note: For information about how to handle attachments with connectors, see Using attachments with SOAP, dotNet, and HTTP connectors and services

Asynchronous execution by the Pega-IntSvcs agents

To perform REST connector processing asynchronously:

1. Create a Connector Request Processor data instance that defines the characteristics and classes of queued requests. Associate this data instance with the RuleSet that contains the Connect REST rules.
2. On the Service tab of the Connect REST rule, select queuing in the Intended for field and identify the Connector Request Processor created in step 1.
3. Update one or more Data-Agent-Queue instances to ensure that the ProcessConnectQueue agent entry within the Pega-IntSvcs agent is enabled with an appropriate time period.
4. In the activity steps that execute the Connect-REST method, set the Execution Mode parameter value to Queue
5. Test.

Working with SSL-enabled endpoints

When a customer has a Connector rule for an HTTP-based protocol such as HTTP, SOAP, REST, and sometimes Email, they may point to an SSL-enabled ("https") endpoint. The service that is connected to will provide an SSL certificate in order to identify itself and secure the connection.

Pega 7 Platform relies on the Application Server in order to "trust" the certificate that another service provided. When Pega 7 Platform is deployed in tomcat, this usually means that the default java trust store is in use. IBM Websphere has its own trust store, controlled in the Admin Console.

When the certificate provided by a service is not in the trust store, or otherwise not trusted (for instance, it is out of date or issued to a different organization), Pega 7 Platform cannot complete the connection and an exception such as "Peer not authenticated" results.

It is the responsibility of the customer to ensure that the application server's trust store is set up correctly.

Performance Statistics

For information on gathering performance information about this connector see Testing Services and Connectors, a document on the Integration pages of the PDN.

Related information

Open topic with navigation