Table of Contents


Integration with external systems

Integration tools enable your application to interact with other systems. By using any of the various industry-standard protocols, you can configure Pega® Platform to send information to or receive information from an external system. The Pega Platform integration facilities provide a set of protocols that allow you to create connections to—and endpoints for—external systems. By integrating with other systems, you can leverage existing applications and services. External systems can also send information to Pega Platform, and a work object can be created based on this information.

Key integration features

Integration features include wizards, the separation of rules from data, synchronous or asynchronous execution of connectors, testing and debugging, support for several technologies and standards, and email and file processing.

Wizards automate the generation of rules from metadata

Wizards guide you through creating connectors to external services by using metadata such as an EJB class, WSDL file, or SQL statement. The accelerator automatically creates properties in your application and rules to map the incoming information to these properties.

Before generating rules, you can test the method or methods of the web service to which you are connecting. By processing the WSDL file from the SOAP service, for example, the Connector and Metadata wizard constructs a SOAP request envelope that you can populate with test data. The request envelope is then sent to the web service endpoint, processed by the external system, and a response is returned. You can examine the response to confirm that it contains the expected structure and contents.

The following images show sample request and response envelopes.

Soap Service

For SQL databases, the metadata is a table definition. For an Enterprise JavaBeans connector, the Connector and Metadata wizard accesses the remote Java classes. For example, a SOAP service in your organization might provide currency exchange rates. Your application can include a SOAP connector that creates the request XML document and parses the response XML document. In the example, the request envelope is an XML document requesting the U.S. dollar to euro conversion of $1.00. The response envelope returns the value 0.75975.

The Connector and Metadata wizard constructs the classes, properties, and connector rules that your application needs to call the service.

Using other wizards, you can also create services for your application, so that external systems can send messages or queries to your application. You can configure your service to run an activity, create a work object, or process incoming data. When the service has been created, the wizard produces a specific address or WSDL file as output, which you can distribute to the external systems that will call the service. When an external system sends a request to your service, the request is processed and a response is sent. For example, your application can include a web service that accepts a work item ID and reports the status of that work item back to the calling system. A more sophisticated web service can create a work item from text values that are contained in the service request XML document.

Separation of rules from data

The wizard creates rules to handle the mapping of inbound and outbound information, and data to define connection information. The separation of rules from data enables connectors and services to be changed from development to production environments, without altering the rules that make up the connector or service. You can also easily update the mapping information to reflect changes on the opposite side. For example, if your application sends a SOAP request to an external service and the external service adds a new field, you can update your request to provide this information.

Testing and debugging

You can unit test most connectors and services by:

  • Passing raw data (SOAP envelope, XML, and so on) to test a service from within Pega Platform at design time. View the response to verify a successful connection or any configuration errors.
  • Simulating a connector to test functionality within the application before the endpoint has been completed or implemented. If you are building a connector in your application, you can insert it into a flow before the endpoint service is active by setting static values to your connector properties.

Synchronous or asynchronous (background) execution of connectors

You can configure connectors to run in a queue in the background of normal flow execution. Running connectors from a queue allows you to specify the number of retry attempts in case the first attempt at connecting was not successful. In addition, asynchronous processing enables your application to continue while the connector's request is being processed by the external system.

Support for a variety of technologies and standards

Pega Platform supports:

  • SOAP
  • HTTP (Hypertext Transfer Protocol)
  • EJB (Enterprise Java Beans)
  • DotNet (Microsoft)
  • SQL (relational databases)
  • Email
  • Java
  • JMS (Java Message System)
  • MQ (IBM WebSphere messaging)

Email and file processing

In addition to the web service standards listed above, you can configure your application to send and process received email messages. For example, your application can send an email correspondence to an applicable party when a work object is completed. If you configure an email listener, your application can perform work based on an incoming email message. Configure your application to process a file, such as comma-separated-values file, and create a work item based on its contents sending and receiving files over FTP.

Integration terminology

The following terms are important in the Integration category:

  • Connector – Provides an interface from your application to an outside service. Most connectors are run synchronously as part of a flow execution, when the work item reaches a specific place.
  • Service – Provides an endpoint for an external client using elements within your application. Service requests are processed in the background, not as part of a flow.
  • Parse XML rule – A mapping rule that accepts an XML stream and translates its contents into Pega Platform property values.
  • XML Stream rule – Constructs an XML stream from property values within your application.
  • Listener – A rule that operates in the background and monitors a location (file system, email, JMS queue) for requests and acts in a prescribed way when a change in the monitored location is discovered.

Additional information

ArticleCalling Web services using queued execution

ArticleHow to parse a Comma-Separated-Values (CSV) file using a file service

ArticleHow to test a SOAP connector using sample data


Published January 1, 2011 — Updated December 27, 2018

83% found this useful

Have a question? Get answers now.

Visit the Pega Support Community to ask questions, engage in discussions, and help others.