Question
Vodafone
IN
Last activity: 29 Sep 2020 7:54 EDT
Any idea on how we can cisrcumstance the rule based on Environments like Dev, Stage , Prod ?
Any idea on how we can cisrcumstance the rule based on Environments like Dev, Stage , Prod ?
Accepted Solution
Updated: 29 Sep 2020 7:54 EDT
Pegasystems Inc.
US
Updated: 14 Jun 2021 7:38 EDT
.
IN
Based on the pzProductionLevel property you can circumstance. It will be 1,2,3,4,5 based on the environment.
Please find the below screenshot for more details.
Vodafone
IN
Thanks Bro. I have used it based on pxProcess.pxSystemName. which will be the best solution ?
OR shall I use pzProduction Level ?
Updated: 14 Jun 2021 7:38 EDT
.
IN
If you have multiple environments with the same production level and if you want to circumstance for each of them, then I think it would be better to use "pxSystemName".
Vodafone
IN
okay, thanks
Accepted Solution
Updated: 29 Sep 2020 7:54 EDT
Pegasystems Inc.
US
You probably do not want to use system name. This is something that can and should change based upon what you want to call your system. Here an example pipeline:
| SystemName | Production Level |
|---|---|
| Development | 2 |
| UpgradeTesting | 2 |
| QA | 3 |
| Staging | 4 |
| Performance | 4 |
| Production | 5 |
I would strongly recommend having your code use the Production Level concept so you don't have to predict forever what they exact system name is going to be.
I don't know what your use case is, but I just want to make sure you know about "Application settings" (8.4+) which were known before as "System Settings"
Configuring production-level-specific run-time settings by using application settings rules
One thing missing from this documentation is that you can get your system setting from Utilities • getRuleSystemSetting function.
You probably do not want to use system name. This is something that can and should change based upon what you want to call your system. Here an example pipeline:
| SystemName | Production Level |
|---|---|
| Development | 2 |
| UpgradeTesting | 2 |
| QA | 3 |
| Staging | 4 |
| Performance | 4 |
| Production | 5 |
I would strongly recommend having your code use the Production Level concept so you don't have to predict forever what they exact system name is going to be.
I don't know what your use case is, but I just want to make sure you know about "Application settings" (8.4+) which were known before as "System Settings"
Configuring production-level-specific run-time settings by using application settings rules
One thing missing from this documentation is that you can get your system setting from Utilities • getRuleSystemSetting function.
I would recommend away from referencing either system name or production level directly in your code. If possible, use Application Settings (aka System Settings not Dynamic System Settings) and reference the outcome of that.
If you actually want to have different logic and processing between different environments, I'm very concerned about your Quality Assurance process. There will be no real way to test your code until after it is in production.
You probably do not want to use system name. This is something that can and should change based upon what you want to call your system. Here an example pipeline:
I would strongly recommend having your code use the Production Level concept so you don't have to predict forever what they exact system name is going to be.
I don't know what your use case is, but I just want to make sure you know about "Application settings" (8.4+) which were known before as "System Settings"
Configuring production-level-specific run-time settings by using application settings rules
One thing missing from this documentation is that you can get your system setting from Utilities • getRuleSystemSetting function.
You probably do not want to use system name. This is something that can and should change based upon what you want to call your system. Here an example pipeline:
I would strongly recommend having your code use the Production Level concept so you don't have to predict forever what they exact system name is going to be.
I don't know what your use case is, but I just want to make sure you know about "Application settings" (8.4+) which were known before as "System Settings"
Configuring production-level-specific run-time settings by using application settings rules
One thing missing from this documentation is that you can get your system setting from Utilities • getRuleSystemSetting function.
I would recommend away from referencing either system name or production level directly in your code. If possible, use Application Settings (aka System Settings not Dynamic System Settings) and reference the outcome of that.
If you actually want to have different logic and processing between different environments, I'm very concerned about your Quality Assurance process. There will be no real way to test your code until after it is in production.