The Pega technology can be integrated as a mashup in external web applications. By doing this, Pega cases can be run embedded in another website, without the need of opening the Pega platform. This is a very useful feature, that takes advantage of the Pega BPM capabilities and adds this functionality wherever the business needs it to be displayed.
Implementing Pega as a mashup can add great value with a small development effort, because it reuses the code developed in Pega, specialized for BPM, into the code that was already developed for the external website. In this way, we are leveraging Pega at its best, delivering BPM software with a short time to market, along with the preferred web environment for the business requirements.
What we obtain with this fast integration, is a single service with a common user interface that can make use of the corporate website, so it becomes easier for the user to find what they want and work with their processes in a seamless fashion. Moreover, it adds the convenience that the users are working on the website that they are used to, making the whole process more natural.
As a best practice when developing BPM cases as mashups, the appearance should match the website where they are integrated into. This can be achieved easily in Pega by tweaking the skin to adapt the look and feel to the parent website.
A key element in mashup development is user authentication. If the user is already authenticated in the website, ideally they should not authenticate again to use the mashup. This would make the process more tedious and it would not look like the mashup is part of the web application. It’s worth mentioning that cases can be launched also without authenticating the user.
In this post, we are going to focus on the integration of a Pega BPM Case as a mashup in an external website with user authentication.
For this use case, Google acts as the Identity Provider and the Service Providers are the external website and Pega itself. The external website will make sure that the user is already authenticated, by starting the authentication process. The Pega functionality cannot be reached until the user is authenticated. Therefore, we are talking about a Service Provider initiated SSO flow.
Pega requires that the website where the mashup will be displayed is added as a trusted origin for security purposes.
This origin needs to be a domain name, not an IP.
As it was mentioned before, the authentication is a critical part for the mashup. There are different authentication services that can be used in Pega: OAuth 2.0, SAML 2.0, custom authentications. Also, the user and password could be sent directly in the mashup script, although this requires to pay special attention to any security risks.
PegaA_params={UserIdentifier:"<username>", Password:"<password>"}
For this demo, we are going to rely on the authentication services given by a 3rd party, in this case, Google Authentication using the SAML 2.0 standard. In a real scenario, the existing SSO in the company would be used, in order to achieve a total integration with the company’s infrastructure.
A servlet definition identifies the name of what authentication service is used. The file “web.xml” can be modified to change the authentication services that are needed.
The functionality of the mashup should be that, if the user exists in Pega, they will be logged in with their operator. Otherwise, an operator is created with the user details. By doing this, we are facilitating the use of the application to users that have never used it before, enabling them automatically without any delay.
In order to do that, a model user has to be created. Pega will create operators automatically from this model user, using the properties that we define in it. Therefore we can customize how the new operators will be created in Pega, adding any extra configuration that we need.
When the authentication happens, Pega will look for the model operator that corresponds to the user’s organizational structure. So, a different model operator can be created for different organizations, divisions or units.
Pega requires the following attributes to be sent by the Identity Provider: .pyUserIdentifier, .pyOrganization, .pyOrgDivision and .pyOrgUnit. The first is used to find the user in the system. If the user is not found, the other three attributes will be used to search for a model user and create a new operator to start the case processing.
The mashup code can be generated in the case that is required to be integrated. The URL for the mashup needs to match the servlet URL that we configured before.
This code can just be pasted in the external website to integrate the case functionality. In order for the script to be loaded in a secure way, it should be accessed using HTTPS with a valid SSL certificate.