More about SOAP connector rules

Axis2, SOAP attachments, XML Literal data type, SOAP 1.2

The Pega Platform SOAP connector architecture uses an Axis client that serializes and deserializes the SOAP messages. Connectors created in PRPC Version 5.5 or later use the Axis2 Axis client. However, SOAP connectors created in releases before PRPC Version 5.5 can continue to use Axis 1.2.1.

As described in Pega Community article How to verify and troubleshoot rules created from XSD or WSDL by Accelerators, some XSD constructs are too ambiguously defined to be interpreted by the Accelerators. For many of these issues, a work-around is to modify the generated Parse XML or XMLstream rule yourself so that it interprets the data as you intended. For SOAP connectors, however, XML objects are mapped to and from XML Page parameters whose schema is described in data transforms, not Parse XML and XML stream rules. If the generated data transforms cannot handle the XSD constructs in your WSDL file, complete the following steps to map the data to and from Parse XML and stream rules instead:

Use Connector and Metadata wizard to generate Parse XML and stream rules from the WSDL.
Open the connector rule, select the Advanced tab and ensure that Axis2 is specified in the Axis Version field.
Still on the Advanced tab, delete the rows in the Schema Definitions sections.
On the Request tab, change the data type of the parameters being mapped from XML Page to XML Literal, change the Map from option from Clipboard to XML Stream, and then identify the stream name in the Map from key field.
On the Response tab, change the data type of the parameters being mapped from XML Page to XML Literal, change the Map to option from Clipboard to XML Parse, and then identify the stream name in the Map to key field.

Note: You can also map the values to and from single-value clipboard properties and then call the parse or stream rule from the connector activity.

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

Asynchronous execution by the Pega-IntSvcs agents

To perform SOAP connector processing asynchronously:

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 SOAP rules.
On the Service tab of the Connect SOAP rule, select queuing in the Intended for field and identify the Connector Request Processor created in step 1. Leave the Response tab blank.
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.
In the activity steps that execute the Connect-SOAP method, set the Execution mode parameter value to Queue.
Test.

Performance statistics

For information on gathering performance information about this connector see Testing Services and Connectors on the Pega Community.

SOAP dynamic system settings

You can use the following dynamic system settings to modify the behavior of Connect-SOAP processing on your system.

Owning ruleset	Setting purpose	Description
Pega-IntegrationEngine	EnableJCIFSEngine	When `true`, uses JCIFS engine for NTLM authentication when connecting to SOAP services. When `false`, uses the system's default NTLM mechanism.
Pega-IntSvcs	wss/MustUnderstand	Set the WS-Security Must Understand header
Pega-IntSvcs	wsa/versionURI	Set the Addressing Version
Pega-IntSvcs	wsa/MustUnderstand	Set the Addressing Must Understand header

For information about how to use dynamic system settings, see Using dynamic system settings.

For a simple example of a dynamic system setting that replaces a prconfig.xml file setting, see the Pega Community article How to set prconfig values in a Dynamic System Setting value.

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 Platform relies on the Application Server in order to "trust" the certificate that another service provided. When Pega Platform is deployed in Tomcat, this usually means that the default java truststore is in use. IBM Websphere has its own truststore, controlled in the Admin Console.

When the certificate provided by a service is not in the truststore, or otherwise not trusted (for instance, it is out of date or issued to a different organization), Pega 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.