Skip to main content


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

Deployment models for connectors

Updated on November 9, 2021

Connectors fetch data from your remote application to publish this data to the Pega Process Fabric Hub. For example, by using connectors, you can publish assignment data from your application to the Pega Process Fabric Hub. Before you deploy connectors, consider which deployment model suits best your scenario.

Connector as a module in a remote application

When you run a connector as a module in a remote application, the connector has the following characteristics:

  • The connector logic is based on the remote application technology, and the connector runs on the same server as the remote application.
  • The connector has access to all data of the remote application.
  • The connector registers the remote application, publishes all the existing data, and moves the registered application to the Active state.
  • The connector detects any data changes and publishes real-time data to the Pega Process Fabric Hub.
  • As a best practice, use this deployment model when you can run the connector logic in the same remote application.

Before you deploy the connector as a module in a remote application, consider the following factors:

  • Connector as a module decreases processing time because of lack of any immediate system between the Pega Process Fabric Hub and your remote application.
  • As the remote server also performs transformation and publication of data to the Pega Process Fabric Hub, you can experience a performance impact.

The following figure shows a how a connector runs when you choose the deployment as an application module:

Connector as an application module
A diagram that shows a schema of a connector deployed as an application module

Connector as an independent service

When you run a connector as an independent service, the connector has the following characteristics:

  • The connector interacts with a remote application through the interfaces, for example, services, a publish-subscribe pattern, and an event bus.
  • The connector registers the remote application, publishes all the existing data, and moves the registered application to the Active state.
  • The connector detects any data changes and publishes real-time data to the Pega Process Fabric Hub.
  • As a best practice, use this deployment model when you cannot run a connector logic in your remote application.

Before you deploy a connector as an independent service, consider the following factors:

  • Processing does not impact a server of the remote application as the connector processes data externally.
  • The connector is an intermediate system between your remote application and the Pega Process Fabric Hub, and as a result, might require maintenance effort in order to run correctly.

The following figure shows how a connector runs when you choose the deployment as an independent service:

Connector as an independent service
A diagram that shows a schema of a connector deployed as an independent service

  • Previous topic Publish Operators in Batch Pega Process Fabric Hub endpoint
  • Next topic The Pega Process Fabric Hub troubleshooting

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

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