|Description||Publishing case types from an older version of Pega Platform to an application on the newer version of Pega Platform|
|Version as of||8.5|
|Capability/Industry Area||Case Management|
Co-existence is an approach that helps customers use cases from their older versions of Pega Platform™ before updating to the latest version in a single migration approach. With co-existence, application can roll out in batches and avoid a single migration and its associated effort by initiating legacy case creation from updated Pega Platform version.
Co-existence is based on Pega Web Mashup infrastructure.
Steps to achieve co-existence
- Create a new remote case type. Remote case types represent cases, that are created, processed, and stored in an application in a remote system. Remote case types act as shell case, or a wrapper, by using Pega Federated Case Management features.
- Configure Remote System form to connect using mashup.
- Complete remote case configuration by completing Remote System details, class name, and starting flow. Additionally, specify parameters that need to be passed to the remote system.
- Launch newly a created case. Case will be launched by using Pega Web Mashup.
Remote System Configuration
- Update pyDefault data transform of the case to consume parameters, as discussed previously.
As co-existence is based on Pega Web Mashup in Pega Platform, the system must authenticate the user before it displays the application mashup on the external web page.
Pega Platform provides a standard authentication service named Internet Application Composer (IAC) Authentication for Pega Web Mashup configurations. The standard web.xml contains a servlet named
IAC that references this authentication service instance. The instance references standard IAC authentication activities by default. Unlike other custom authentication services, you do not need to create an IAC authentication service and add a reference to it in web.xml.
When users log in to the mashup application, the standard IACAuthentication activity extracts values from custom HTTP headers in the HTTP request header to identify a corresponding Pega Platform operator ID record.
If an operator ID record for the user does not exist, the activity creates a record for the user. The activity customizes a template Operator ID or model operator using information in the HTTP request header to create an operator ID record for the user.
For example, consider a U+Bank application with a Pega Web Mashup. The U+Bank database includes login credentials for its customers, but the Pega application does not have login credentials for new application users. When a new user logs in, the system creates a guest ID, which is an operator ID based on a model user template containing relevant user attributes. This process enables new users to start working in their applications immediately. Users do not have to wait for their operator records to be manually created in Pega.
The IACAuthentication activity requires that the HTTP request provides the following information to create an Operator ID:
- pyuseridentifier – Operator's identifier
- pyusername – Operator's full name
- pyorganization – Operator’s organization name
- pyorgdivision – Operator’s division name
- pyorgunit – Operator’s organization unit name
The organization, division, and organization unit information in the header is used to identify the appropriate organization unit record in Pega Platform. The model operator associated with that organization unit is the template for creating an operator ID record for the new user. The identifier and full name are used to customize the operator ID for the user.
- Co-existence is supported in Firefox, starting from Pega Platform version 7.1.8.
- For Pega Platform versions from 7.2 to 7.4, hotfix and samesitecookieattributevalue dynamic system setting update are required to support co-existence in other major supported browsers. For more information, see CORB error with Chrome 80 SameSite cookies.
Application on latest version of Pega Platform can launch remote cases that reside in older version of Pega Platform.
As a best practice, always update your instance of Pega Platform to the latest available version.
Starting with Pega Platform version 8.6, you can use out-of-the-box remote case types, that you can conveniently employ to launch case types from one application in another application. Also, starting from Pega Platform version 8.6, Federated Case Management features are deprecated and no longer supported. For more information, see Remote case types.