Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Configuring advanced details for a SOAP Connector

Updated on April 6, 2022

Use the Advanced tab to change which version of Axis or SOAP is used, to associate a compensating action with the connector, to specify the data transforms that define the schema, and to enable Web Service Security for the connector.

  1. In the navigation pane of Dev Studio, click Records.
  2. Expand the Integration-Connectors category, and then click Connect SOAP.
  3. In the list of Connect SOAP instances, select the instance for which you want to configure advanced settings.
  4. Click Advanced tab.
  5. In the Client properties section, use the fields in this section to specify settings for the Axis client.
    The Pega Platform SOAP connector architecture uses an Axis client to make the SOAP call and process the SOAP response.
    Note: The Axis Version field is read-only. Connect SOAP rules that were created in Pega Platform 5.5 and later use Axis version 2. Axis version 1.2.1 is a legacy version and should only be used for Connect SOAP rules that were created in Pega Platform version 5.5 and earlier.
    1. In the SOAP Version field, specify the SOAP specification implemented by the Web service with which this connector communicates.
      If you used the Create SOAP Integration wizard to generate this connector, and selected a SOAP 1.2 binding port, it is set to 1.2.
      Note: If you need to use SOAP 1.1, you can change this setting on the Connector record.
    2. In the HTTP Version field, select a version known to be compatible with the server that the connector is connecting to.
      As a best practice, because HTTP Versions are backward compatible, set the HTTP Version to the lowest known compatible version. For example, if you don't know whether the server is 1.1 compatible, set the connector HTTP Version to 1.0.
    3. To enable the Message Transmission Optimization mechanism for this connector, select Enable MTOM.
    4. Optional: Leave the Normalize type attributes namespaces check box unselected in most cases, for example, if you are manually configuring your soap messages. This check box affects the way that the system produces complex autogenerated soap messages.
  6. In the Secure protocol configuration section, in the Lowest allowable SSL/TLS version field, select the lowest version of the protocol that you want to allow to communicate with an external server.
    The default value is TLS version 1.2.
  7. If your application requires a secure SOAP connection, in the Web services (ws-*) configuration section, you can enable Web Services Security (WSS).
    1. To enable WSS on this connector, select Enable ws-security.
    2. If the web service exposes a ws-policy, to specify the policy by using a Webservice Policy data instance to interact with the service, select Enable ws-policy.
    3. If Enable ws-policy is not selected, in the Security profile field, specify the WS-Security Profile instance to use to communicate with WS-Security enabled web services.
      This security profile is also used for SSL enabled SOAP services. In the Security profile you specify a truststore that contains the server certificates to use in the SSL handshake, and a keystore that stores the client’s private/public key pair used by the server to authenticate the client. See About WS-Security Profile data instances.
    4. If Enable ws-policy is selected, in the Service policy field, specify the Webservices Policy instance to use.
  8. In the WS-addressing section, configure the SOAP addressing headers.
    1. To include routing information in the SOAP header, select Enable ws-addressing.
    2. In the Must understand field, select True to instruct the SOAP service to process this header element and fail if the SOAP service does not recognize the element.
      The default is False, allowing all SOAP header elements to be optionally processed by the receiver.
    3. In the Reply to field, enter the location to which the reply to the message should be sent. If left blank, the reply is sent back to the endpoint from where the request came.
      • If the server is to respond to the sender synchronously, enter http://www.w3.org/2005/08/addressing/anonymous
      • If the message is a one-way request, enter http://www.w3.org/2005/08/addressing/none
      • Use property references to override this field dynamically.
    4. In the Namespace field, specify the WS-Addressing namespace to be used with WS-Addressing and the STS token service.
      If you do not specify a namespace, the following namespace is used as the default: http://www.w3.org/2005/08/addressing

      The SmartPrompt lists the standard namespaces from Addressing Final and Submission namespaces.

      Note: The WS-Addressing namespace takes precedence over the dynamic system setting wsa/versionURI.
    5. In the Fault to field, enter the fault endpoint reference that indicates where the fault message should be sent.
      If not present, the fault is sent back to the endpoint from which the request came.

      Use property references to override this field dynamically.

    6. In the Action field, enter the unique identifier for the intent of the request.

      The entry in this field should match the SOAPaction header field on the Service tab if WS-Addressing is enabled.

      If the SOAP Action field is blank, this field's value is calculated based on the default action pattern mentioned in the WS-Addressing specification.

      Use property references to override this field dynamically.

    7. In the Relates to field, enter a previously sent message to which to relate, so that the service can determine who sent the message.
    8. In the To field, enter the information about the message receiver.
    9. If the Relationship type field is not otherwise populated, for Submission Namespace, enter wsa:Reply.
      This field is used in conjunction with the Relates to field. The type of relationship is identified by an absolute IRI. The related message is identified by an absolute IRI that corresponds to the related message's [message id] property.

      Use property references to override this field dynamically.

    10. In the From field, enter information about the message sender.
    11. In the Message ID field, enter a unique identity for the message.
      You can use this identity for many purposes, including duplicate detection and message correlation.
  9. Optional: To use Secure Token Service, in the Secure token service (STS) configuration section, complete the following fields:
    1. In the STS service policy field, specify a Webservices Policy instance that uses the policy exposed by Security Token Service.
    2. In the WS trust version field, select the appropriate WS-trust version to be used to construct the RequestSecurityToken:
      • Version 1.0 corresponds to http://schemas.xmlsoap.org/ws/2005/02/trust
      • Version 1.3 corresponds to http://docs.oasis-open.org/ws-sx/ws-trust/200512
  10. If your connector uses a Java Message Service (JMS) binding to connect to an external service, in the JMS transport section, in the Transport name field, select the JMS transport instance used to connect to the external service.
  11. Optional: To associate a compensating action with a work item when the connector rule succeeds, in the Compensating action section, complete the following fields:
    1. In the Work page name field, specify the name of the page that holds the work item. Typically this is pyWorkPage.
    2. In the Action label field, enter a string that describes the purpose of the compensating action.
      For example: If you enter the string, "Cancels Flight Reservation," PublicAPI methods can use this label to identify this compensating action within a Java step of an activity.
    3. In the Action activity class field, identify the Applies to class (first key part) of the activity that performs the compensating action.
    4. In the Action activity name field, identify the activity name (second key part) of the activity that performs the compensating action.
  12. In the Compensating action data field, click the none button and enter the name of a parameter used by the compensating action activity. Then, in the value field, select the property that is to be the source of the parameter value.
    Use the Compensating action data section to store information about the current state of the work item as parameter-value pairs when the purpose of running the compensating action activity is to restore the work item to the state it is in directly after the connector rule runs.
  13. Click Save.

Related articles

Connect SOAP rulesCreating a Connect SOAP ruleConfiguring asynchronous processing for SOAP connectors

Tags

Pega Platform 8.7 Data Integration

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Visit the Support Center

Did you find this content helpful?

Yes
No

Want to help us improve this content?
Suggest an edit

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us