I have a question on what is the best practice to implement Global Resource Setting in our current project.
As part of the requirements we have a REST Integration in place. It uses two separate REST Integrations for triggering data to third party app - one for offers and one for cash bids. We want to implement GRS in order to facilitate the integration maintenance.
We are considering the following options:
1) Implement the GRS in the Integration class directly and just create the required properties in the sub classes for POSTCashBid. They will be in their separate Env class within with the required property only. In the integration class we will have the Data Page and Data Transform only. If we go with this option we will reuse the Data Page and Data Transform, however we will cause a dependency between the two connectors as they will be in the same rule set.
2) Implement separate GRS in each POST class. This way we will have separate Data Page, Data Transform and Properties for each REST Integration. It will look like the attached screenshot for POSTCashBidDetails. We won't have the dependency as in 1), however we won't be reusing much of the components.
Can you suggest what is the best practice in our scenario? (any of the above or even a different suggestion)
If you are on 8.3 you can use make use of the new Application Settings feature which is intended to replace Global Resource Settings(GRS) and gives more benefit over GRS by having production-level-specific run-time settings.
We are currently on 8.2 and there is no timeline in our organization when the 8.3 upgrade will be pushed. Your suggestion looks promising and I will definitely look into it, however in the interim I'll still like to hear your thoughts on which option for the GRS will be more align with the best practices in Pega.
For sure we will need to use GRS when the application goes live as I think the 8.3 upgrade won't happen before that.
As the usage of GRS is deprecated on 8.3 onwards with the new Application Settings feature.
Also keeping in view of 8.3 upgrade at later part of the year, I would suggest you choose a simpler approach among 1 & 2 that fulfills your business requirement without weighing much on maintenance. Option 1 looks fine to me and I'm unsure what is the challenge of having two connectors in the same ruleset. I would rather perform tests on how we send/get data using these two connectors to understand the hiccups and later choose the suitable option which works for all cases and later weigh on factors like re-usability & performance.