Cloud Native Design Pattern —Implementing In Pega PRPC …

“External Configuration Store” — Pattern

9 min readOct 17, 2020

--

Configuration is anything that varies/changes between deployments to different environments. It is suggested that store config in an environment not within your code base. These configurations which change with time and target environments, requires strict separation of config from code and should not be placed/maintained in the application code or any config file in the package bundle, rather it should be in external central config server/repo.

Problem Statement :

Majority of the Pega applications maintain configuration in local Pega Data Table (Data Store), DSS, RSS, DataTransform, which are deployed to different target environments along with the application ( as part of product rule package extract). And in most of the cases, it is edited after deployment to change that environment specific configuration. But this approach against the cloud native design principle (please refers this link for details) and not sustainable in true cloud native platform, because of below

This approach results in unnecessary downtime, because application users should not access the application unless those configuration changes are complete in the target environment, even if the deployment is complete.
Sometimes you may need to restart the server/node after the config changes.
Need human touch after the deployment for those config changes, which restrict you from implementing zero-touch automated platform provisioning and application deployment. Also will be a road block for auto-scaling of your Pega application instances.
Has administrative and operational overhead. Hard to manage and control of configuration.
Generally don’t support different versions of the configuration ( except Pega RSS, or any custom rule you created for config storing), so rolling back again a manual task to perform. Against the automated rollback.
Local configuration (within application code/package) limits the configuration of a single that specific application, hard to share among applications for common configuration.

Solution :

Store the configuration in the external store/storage system which should provide an easy and efficient interface to read the configuration from Pega application code.

The type of external store/storage depends on the hosting and runtime environment of your Pega installation/instance. You can use a public or enterprise Git or cloud based storage servicer or it could be a database. Choose an external store/storage system which has at least below characteristics.

It should expose the config information in readable, correctly and in structured format (json, xml, yaml, etc.) and in a secure manner.
Has an easy and efficient interface (REST, SOAP) to fetch information.
Provides mechanism to authenticate and authorize access to protect configuration data. It should support strict separation between the read and write permission of configuration data.
Should support storage of multiple versions of the config data.
It might be helpful if it supports review management process, to administrate config data change.
It might be helpful if it has any caching mechanism, it is nice to have features.

Store config in external store/storage system, and fetch from Pega application.

When to use this pattern :

This pattern is useful for

Your Pega application will be deployed automatically and in an auto-scaling platform where you will not get a chance to change configuration after deployment which will happen in any environment and in any number of instances. Zero touch and auto scaling deployment is your goal.
You want a version management of the configuration setting to track changes and also utilize during rollback via DevOps pipeline in case of failure due to new configuration values.
You want to keep a strict review process of the configuration change as your Pega application is sensitive to those configurations. Keeping configuration in Git will allow you to utilize the reach feature of Git such as branching, Pull Request and merge, etc. to enforce a strong review process for any change in config.
When your configuration is shared among many Pega applications and that configuration is frequently changing. ( e.g. trading rate, currency rate, daily rotating manager for set of groups, etc.)
When you want your configuration management to be abstracted from application developers. Your Pega application developer should concentrate on the Pega application code rather than setting, storing, changing configuration. A way of simplifying administration/operation of multiple applications.
Need of a complementary store for some of the settings/config for application, allowing application to override some or all of the centrally stored settings.

Possible implementation techniques :

There could be different ways of implementation of this external config store pattern, but the below few points are common in any approaches you take.

Configuration needs to be stored in an external central versionable repository.
Single common repository to store configuration related to a specific application deployable in any environment. There should not be a different repository environment for different Pega applications or different for different target environments ( DEV/SIT/QA/PROD).
At the end, it needs to be loaded in the Pega Data Page ( preferably Node level), which will be referred from different sections of your Pega application code.

Below are the different possible implementation techniques, out of which we will discuss a few in detail.

Storing config in GitHub, fetching from Pega via REST connector.
Storing in GitHub, Git clone in local storage volume, read via PRFile or FileInputStream.
Storing in GitHub, map to ConfigMap, read via PRFile from Pega function.
Store in Openshift ConfigMap, read via PRFile from Pega function.
Store in JFrog/ AWS S3, fetch via Pega Repo or connector.

Implementation Sample 1 :

Storing config in GitHub, fetching from Pega via REST connector

Whether your Pega instance is deployed as a container in Kubernetes platform or deployed in bare metal physical box /VM, this approach can be taken in your Pega application for any possible Pega installations.

Step1:

Choose your choice of public or enterprise git repository ( gitHub, bitbucket, etc). and keep the configuration file in the master branch. Use private mode of the repository.

Keep an indicator (dev, prod, QA ..) in the filename to identify the target environment where those specific config files will be used.

Config file in a private repository in Git.

Make sure the environment indicator in the file name match with the production level name of your Pega system.

Production Level Name of your Pega Instance.

Step 2:

Keep the content of the config file in json format (preferably), Define the structure and keys as per your application requirement. Below is a sample of the content of the config file for DEV and PROD environment.

Step 3:

Setup Developer setting in GitHub to generate Personal Access token or OAuth token, which will be used to authenticate while fetching the content in Git from your Pega application.

While connecting GitHub to fetch the file content, you can use GitHubAPI (https://api.github.co) or directly access using the file raw url (https://raw.githubusercontent.com/…)

We will use raw file url here as example.

And check via Postman or SOAPUI, whether you are able to fetch the config file from gitGub, via REST.

Step 4:

Now build the required class, a rest connector, data transform ( may be using Pega REST Connector wizard) in Pega. And create a DataPage sourced from that REST connector.

DataPage to hold the configuration, calling the Git to get the config

REST connector, filename as dynamic. And authorization token as header

Build the config filename dynamically based upon the ProductionLevelName

Final DataPage in clipboard view, which will be used from your application code.

Note: don’t keep secrets or password related configuration in the Git, use Vault from Hashicrop or similar tools.

The url of the Git repository and the security token you can pass as JVM argument. Read that argument from the Pega function using System.getProperty() and pass it to REST connector either as parameter or as Global Resource Syntax (GRS).

Pass the central external git url and access token via JVM parameter

……………………………………………………………………………………..

Implementation Sample 2:

Storing config in GitHub, Git clone in local storage volume, read via PRFile or FileInputStream (from Pega Function).

When your Pega instance is deployed as a container in Kubernetes platform then this approach can be taken in your Pega application.

Step 1: Step 2: Step 3:

Follow the same steps 1,2,3 mentioned in the Sample-1 (above) to configure private git repo and the configuration file specific to each target environment and the config file in json format.

Step 4:

To provision a container with a git repo, mount an EmptyDir into an InitContainer that clones the repo using git, then mount the EmptyDir into the Pega Pod’s container.

Customize the the Pega StateFulSet object, to perform below 3 steps

Create a volume of type EmptyDir ( temp volume).
Using InitContainer, git clone your repo in that newly added volume.
Mount the volume in the Pega container.

Using InitContainer, git clone your repo in that newly added volume. Use the git access token to authenticate.

Validate and ensure that the cloning has been done successfully.

all config files downloaded into container volume

Step 5:

Now this volume mounted at container level will be available to Pega application as file path, for use from the Pega application.

Perform below steps in your Pega application to fetch the file content.

Using a custom Pega function read the file content.
Write a DataTransform to call that function to fetch file content and use the out of the box pega function pxConvertStringToPage to parse the json.
Create a DataPage to call this DataTransform to populate the config, which will be used from your application code.

Pega custom function to read the config file from the volume path

Data Transform 1st step — to determine config filename based on ProductionLevelName

Data Transform 2st step — to call the custom function to fetch config file content from volume, and 3rd step to parse the json content in step page which will be copied in caller DataPage.

Data Page which calling the DataTransform and will hold the config values.

Thought Tablets:
Below are some points for your design thinking and finding a solution, Please share your thoughts as comments.
-> Why not to use Pega Application Settings ( Rule-system-settings) where you can provide different config values based on the production level (dev, qa, prod, etc), why need to make things complex as described in this article?
-> How changing in Git will automatically reflect in Pega App ? Do you need to restart Pega node/jvm/pod to get the new config reflected ? Do you need to flush the data page every time there is a change in Git? Automation possible?
-> if the External Configuration store is down or the config content contains error, then how will you handle the exception? hope you will not allow your application to stay down or auto scaling falling because the external configuration store/site is down.
-> In the above “Sample-2" implementation, git url and token is hard coded in the satefulset manifest file, how to make it dynamic and encrypted?
Note: Opinions and approaches expressed in this article are solely my own and do not express the views or opinions of my employer, Pegasystems or any other organization.
Please: post your comment to express your view where you agree or disagree, and suggestions.