Basics of Integration in Pega

Integration is easy for the one who thinks it’s easy and difficult for the one who thinks it’s difficult.

This article covers all the basic concepts & terminologies which one should know before learning how Connectors and Services function in Pega. Let’s make basics familiar and then can master integration from our further posts.

From the OSP dictionary, we would define Integration as the process of communication to share data across systems.

Let us assume a common scenario where a customer walks into a bank to inquire about his/her loan eligibility. The series of action that involves during this end-end process would be,

In this scenario, customers and bank employees communicate with each other to get their work done.

What happens if the same scenario needs to be handled systematically. This means a customer wishes to inquire about their details online and the bank wishes to have an automated response to the customer rather than having a bank employee respond !!!

System A: Customer Inquiry application where customers can inquire about all their needs.
System B: Banking application that has all the customer details stored.

Now we have two systems and communication happens between systems rather than the person.

End to end integration execution involves the below process.

Let’s understand each of these components in detail below.

Service provider/Server

• Services are instances of class Rule-Service-XXXX, namely Rule-Service-REST, Rule-Service-SOAP, etc.
• As we all know, a server basically helps to store and retrieve information whenever required.
• In the same way, a service provider is a system that will have the required information which can be exposed to other clients in the form of Services.
• In our above example, system B acts as a service provider and hosts a service that system A can connect with to get the required information.

Connector/Client

• Connectors are instances of class Rule-Connect-XXXX, namely Rule-Connect-REST, Rule-Connect-SOAP, etc.
• The client is basically a system that requests information from server/service.
• In our above example, System A acts as a Client/Connector requesting data from System B. System A sends the request to System B and gets the required data.

Authentication

• In our above scenario, the Customer reaches the bank and provides his/her identity to get the required information.
• In the same way, when system A communicates with system B, it should confirm its identity in the form of Authentication.
• Authentication can be of many forms which can be discussed detail in a separate post. System A should Authenticate its identity before getting the required information from system B.

Messaging Formats

• The customer reaches the bank and communicates using the language that the bank employee understands. In the same way, system A will communicate with system B using the language that system B understands/support. System B then responds back to system A with the requested information using the same language. The language defined here is the messaging format that the system uses to communicate.
• JSON and XML are the most commonly used messaging formats.

JSON

JSON is easily readable/parseable, lightweight JavaScript Object Notation language.

In our above example, System A can request Loan Eligibility by sending the Customer detail as request in JSON format as mentioned below :

{
“CustomerID“: “A-123”,
“AccountNumber“: “11112222”
}

XML

XML is a mark up language where information is wrapped in tags.

In our above example, System A can request Loan Eligibility by sending the Customer detail as request in XML format as mentioned below :

<CustomerID>A-123</CustomerID>
<AccountNumber> 11112222 </AccountNumber>

Protocols

The most commonly used type of services is REST(Representational State Transfer) and SOAP (Simple Object Access Protocol).

SOAP

• It uses XML as its message format for exchanging information between client and server
• Soap service is a legacy way to interact with an external system.
• Soap offers more secure communication as it supports WS-Security encryption.

REST

• It uses HTTP based protocol to communicate with the server.
• It uses XML, JSON or Text format to send request/receive response.
• Pega supports Get, Post, Put, Delete and Patch HTTP methods. [We will discuss more in detail about Rest methods in the next post].
• It generally uses JSON which consumes less bandwidth and resource than XML. Hence REST is preferred over SOAP for faster communication.

Mapping Rules

Mapping rules are kind of translators which translates message formats into Pega understandable structure & vice-versa. Mapping rules can be broadly classified into two types,

• Parse rules.
• Stream rules.

Parse rules

• Parse rules are instances of class Rule-Parse-XXXX. For example, Rule-Parse-XML, Rule-Parse-Delimited, etc.
• Parse rules are used to translate the incoming message format (XML) into Pega understandable structure (Clipboard).

Stream rules

• Stream rules is available only for XML and is instances of class Rule-Obj-XML.
• Stream rules are used to translate the pega clipboard structure to common message format (XML).

Service Package

Service package in Pega are instances of class Data-Admin-ServicePackage.

Configurations specific to a service can be directly configured in the service rule itself, for example, request, response, error handling, etc. But few configurations will be common across services and hence it’s required to group those services together and get the configuration done in one place [Service Package].

Yes, Service Package in Pega is used to group similar services into one group. Service package can be viewed and created from Records Explorer->Integration-Resources category-> Service Package.

Few configurations that can be handled in the service packages are,

Processing mode

Processing mode defined in the service package defines the way service rule is executed. It can possibly be Stateful or Stateless.

Let’s consider a real-time scenario to understand stateful and Stateless processing mode rather than boring theoretical definitions.

Consider an Employee onboarding application where the employee will undergo a series of actions before getting successfully onboarded.

• Updating Basic Information.
• Updating Educational information.
• Updating Work History.

The employee will update all his/her information in an external system and Pega captures and save all the information using Services. The above series of actions are handled by different services in Pega.

• Service package to group all services related to employee onboarding with Stateful processing mode.

Service 1 in the series – Employee basic info

Let us hit the first service from the PostMan tool and observe its execution.

Service 2 in the series – Employee educational info

Since the processing mode is stateful, the system maintains the current requestor and processes the upcoming request in the same requestor. Hence EmpInfo page will already be available & hence obj-open can be skipped in the service activity.

Service 3 in the series – Employee work history

Since the processing mode is stateful, the system maintains the current requestor and processes the upcoming request in the same requestor. Hence EmpInfo page will already be available & hence obj-open can be skipped in the service activity.

Since this being the last service in the series of stateful processing, make sure we select End Requestor when done in the service rule. This option in service rule ensures that the requestor is closed after the execution of the service.

• If the execution of each service can be handled using separate requestors, then processing mode can be selected as Stateless.
• The default processing mode is Stateless. It can be updated to Stateful based on the need.

Service Access Group

Browser requestors get the application context by the access group mapped to the Operator ID. Services are executed as App requestors and from where does the application context come from during service execution?🧐

The service access-group mentioned in the service package will be used to define the application context for all the services tagged under this service package.

In our scenario Onboarding:Services access group will be used during service execution.

Requires Authentication

This option in the service package is used to define the type of authentication that is to be used for the services under this package. It can either be one of the below,

• Basic-> UserName and Password
• OAuth 2.0 -> This is an advanced type of authentication. This involves configuring OAuth client Registration which is a separate security rule in Pega.
• Custom -> Any authentication service created under custom type can be mentioned here.

It is recommended to secure our service with at least basic authentication.

Methods

Methods section in service package will give you the list of services tagged under this service package. Services will be grouped using the service type.

We hope now the basics of Integration is clear. We will soon meet with a post on step by step configuration of Service REST in Pega followed by Connect REST and other protocols..

Stay tuned and we will meet soon in our Service REST post.