Thursday, February 22, 2018

Global Resource Setting (GRS)

How PRPC connector URL's are configured, so that they can be globally used in application across multiple environments without manual changes in higher environments.


Consider a PRPC application interacting with 2 external different services to fetch some information as part of its process/operation. For each service, we would be hitting a different URL w.r.t each environment.
Let's say there are four environments : [Dev, QA, UAT, PROD]
Number of external services are : 2
This gives a combination of 8 URL's(4 URL's for each environment) to be stored in our PRPC system. How efficiently we can store these URL's in our environment ?

  • If user logs in to Dev, only DEV URL's should be loaded into clipboard.
  • If user logs in to QA, only QA URL's should be loaded into clipboard.
Design discussed in this post:

Step by step illustration to design "Global Resource Setting"

#1 Create a new data type

     Data-ServiceConfig : {ServiceName, ServiceEndpoint, ProductionLevel}

Navigate to Data Explorer >> Add data type

Select New Data Type; and provide the class detail. In this example, we are chossing the below:
Class name : Data-ServiceConfig
Click Submit
Navigate to "Records" tab of Data type and click on "Configure Source".

Add required columns to this table, by selecting the appropriate key. Click Submit.

#2 Store all the external service URL's in the data type local storage
     Using the "+Add Record" in the records tab of data type, we can input the records.

#3 Create one more property "Value Group" in Data-ServiceConfig class.
     Why Value Group is chosen to bring the desired structure with key value pairs

      D_ServiceConfig.Endpoint(ServiceName) = ServiceURL // key value pair
      Since we need this representation, we preferred Value Group over other alternatives.

#4 Write logic in an activity to fetch records for current environment (pyProductionLevel)
     Note: Current production level can be found in below location from Clipboard.

A closer look at step 2 of above activity where we are filtering the URL's of the appropriate environment (lets say if user logged in Dev, it should fetch only Dev Service URLs. Same way, if user logged in QA, it should fetch only QA Service URLs).

A closer look at Pages & Classes tab of activity:

#5 Add Data page to our data type and source it with activity created in previous step.
     We can usually keep this scope to Node level since these URL's won't be changed often.
     Make sure you provide the access group which would have access to the rules required.

Run the Data page standalone to see the output:

We followed the steps and achieved to populate the external Service URL's on a Data Page, which can be used globally across the application.
We can apply Global  Resource Setting (for example) in a connector rule, refer Data Page we created with the above steps to map endpoint URL :

Other Approaches/Routes:
  • If we take Rule System Setting for each service, we would endup creating 100 System Settings for 100 external service URLs, which would be difficult to maintain.
  • If we take Data System Setting, again we have to maintain n number of DSS for n number of Services. And again for each environment, we need to include the different URL.
  • With the approach of Data type, we have kept all the URL's in a single place. And each record would be a data instance.

Developer Notes:
Class, data instances of the class need to be added to the RAP while promoting to higher environments.

Hope this helps!!!
Feel free to comment/share your thoughts.


  1. We can apply Global Resource Setting (for example) in a connector rule, refer Data Page-- could please tell about this configuration- Please

    1. Sure. I have another post where I started on Connect-SOAP. I would like this to the other article once it is ready. Will let you know on this reply comment.

  2. In a connector rule, refer Data Page we created with the above steps to map endpoint URL/--

    Do we need to mention the Datapage in every environment individually or dynamically it will get set

    In the above step you mentioned endpionturl as serviceone
    If I need service two - I need to update the Dpage with service 2? manually after deployment.
    Looking for reply

    1. Hi,
      In this example, we are maintaining this datatype w.r.t each service and its respective endpoint URLs (Dev URL, QA URL, .., PROD URL) on the basis of Productional Level.

      And we refer this data Page in the connect-REST rule's endpoint as =D_ServiceConfig.endpointURL(ServiceOne)

      Once we do this changes in Dev. Connect-REST picks dev ServiceOne endpont URL.
      And in the same way, in QA Connect-REST picks QA ServiceOne endpoint URL.
      Likewise in the same way, in PROD Connect-REST picks PROD ServiceOne endpoint URL.

      So we need not to update any rules manually in higher environments post deployment.

      Only point is you need to maintain the datatype with all the environments serviceone endpoint URLs.

      Likewise you can apply the same concept to other connect-REST also which connects to ServiceTwo endpoint URL.

      Hope this answers your question.

  3. How Pega set the PyProductionLevel property for each environment?

    1. can be configured in rule available in SysAdmin records

  4. Wow Great Article :) . i could easily get hold the Content, even being a beginner :)


HowToPega : All rights reserved and the contents are copyrighted to Pavan Kumar Naidu