How to update a Pega system's AES/PDC URL outside of the GUI?
I am currently in the process of migrating from on premise AES to PDC. Currently to update the URL we have to go to System->Predictive Diagnostic Cloud ->Endpoint SOAP URL via the GUI. Is there a way to update this url outside of the gui, so that automation can be utilize to update all of our instances?
Pegasystems Inc.
US
To be sure, when you update the url through GUI, it applies to all pega instances for that environment (defined by a single database). How many environments are we talking about here? Seems like a over kill to try to automate unless you have hundreds of environments. BTW, the DASS setting is: pdcconfig/altsoapurl.
Moody's Corporation
US
Thanks for responding Kevin. We are talking about 20 + envs. We want to use automation for speed and to reduce errors that can be introduced by doing it by hand. Also going forward with any environment builds, meaning it can be added to the automation of the build and have it already set using automation, versus manually setting it up prior to delivery.
Pegasystems Inc.
AU
You could leverage the /data endpoint of the Pega API, and wire this into your Deployment Manager, Jenkins or other Continuous Deployment pipeline.
The /data API is ultimately a wrapper for running a Data Page. Its intent is for data retrievals, e.g.
/prweb/api/v1/data/D_StartingFlows
... but so long as the Access Group of the user your authenticate to Pega API with has Open and Modify access to the class you were looking to update, you could create a new Data Page that should be able to run an Activity that does an Obj-Open, Obj-Save and Commit on the Dynamic System Setting instance. Then you reference the Data Page in the /data API like the above example. See the Pega API help docs from Dev Studio for examples on how to pass parameters to the Data Page via the /data API.
Assuming you go down this path, you need to be very careful about the access control you grant to this channel. Only your Continuous Deployment orchestrator should be authorized to run this particular Data Page:
You could leverage the /data endpoint of the Pega API, and wire this into your Deployment Manager, Jenkins or other Continuous Deployment pipeline.
The /data API is ultimately a wrapper for running a Data Page. Its intent is for data retrievals, e.g.
/prweb/api/v1/data/D_StartingFlows
... but so long as the Access Group of the user your authenticate to Pega API with has Open and Modify access to the class you were looking to update, you could create a new Data Page that should be able to run an Activity that does an Obj-Open, Obj-Save and Commit on the Dynamic System Setting instance. Then you reference the Data Page in the /data API like the above example. See the Pega API help docs from Dev Studio for examples on how to pass parameters to the Data Page via the /data API.
Assuming you go down this path, you need to be very careful about the access control you grant to this channel. Only your Continuous Deployment orchestrator should be authorized to run this particular Data Page:
- Apply a Privilege to the Activity of the Data Page;
- Grant the Privilege to a new Access Role;
- Add that Access Role to a new Access Group;
- Create an Operator specific for this privileged operation which is the only Operator configured to use this Access Group.
This Data Page could then be leveraged by your CD pipeline to perform privileged updates to other Dynamic System Settings that hold environment-specific values that your pipeline is best placed to apply.
Please report back your findings if you choose to adopt this.