Global Resource Setting Management
Hi,
I'm currently working through the 8.2 CSSA training course, and I have some questions about the design pattern described in the course.
The pattern the course describes uses a data page, a data transform, and dynamic system settings in order to set up the global values.
However, I'm puzzled by what is gained by using the data page as opposed to just using a direct reference to the DSS.
I'm unable to see what the performance benefit would be, and I'm also unable to see what the structural benefit is.
For example, some projects I've worked on have used DSS settings to set URL's that are different between production and development systems. In our case, we used a simple DSS setting, then fetched that setting with getDataSystemSetting where required. However, if we were to use the data page model, the only immediate difference would be that now we have to maintain a data-page, a data transform, and the DSS, and that every time we want to reference the property, we have to go to the data page.
Hi,
I'm currently working through the 8.2 CSSA training course, and I have some questions about the design pattern described in the course.
The pattern the course describes uses a data page, a data transform, and dynamic system settings in order to set up the global values.
However, I'm puzzled by what is gained by using the data page as opposed to just using a direct reference to the DSS.
I'm unable to see what the performance benefit would be, and I'm also unable to see what the structural benefit is.
For example, some projects I've worked on have used DSS settings to set URL's that are different between production and development systems. In our case, we used a simple DSS setting, then fetched that setting with getDataSystemSetting where required. However, if we were to use the data page model, the only immediate difference would be that now we have to maintain a data-page, a data transform, and the DSS, and that every time we want to reference the property, we have to go to the data page.
While I can see this being useful in specific situations, it seems like in order to have that data page always be up to date, we would either have to instruct the production support team to wipe the data page every time we make a change to a DSS setting (and thereby force it to be reloaded), or to have the page reload every time we reference it, at which point, there's no caching benefit to the page, and all the other values will get fetched at the same time, making the whole trip to fetch a single value that we want longer.
As such, it seems like we'd be doing more work, for a harder to maintain system, that requires more power to complete a specific task, which doesn't make any sense to me.
Could someone clarify this to me, if I'm missing something, or maybe give examples to the benefits of using this structure overall?
TLDR;
Why are we expected to use a Data Page/Data transform reference pattern in 8.2 for global settings as opposed to just referencing to them directly?
Thanks
Pegasystems Inc.
US
This is a good question.
I'm not 100% sure of the answer, so I'll try to do some additional research into the issue. But I think the answer boils down to the Service endpoint URL field on the connector record: it doesn't appear to support the function syntax necessary to access the DSS directly. (Specifically, the quotes break the field validation.) It's not a great reason why, but it does appear to be the reason.
The pattern has been around for a while; I remember it tracing back to at least PRPC 6, so it's possible that changes in the product haven't been reflected on the connector record to allow referencing the DSS directly.
Pegasystems Inc.
US
OK, I managed to do a little more digging and have some additional information.
Another benefit of using the data page approach (assuming that referencing the @getDataSystemSetting function is a viable alternative) would be to collect multiple properties/settings. The exercise (and the lesson) focus on a SOAP connector, which allows the global resource setting pattern in only one field - the Service endpoint URL field. The forms for other connectors extend the pattern to other fields.
For example, a Connect-JMS rule allows you to use the pattern in four fields:
- JNDI Server
- Connection Factory
- Destination Name (Request section)
- Destination Name (Response section)
In this case, providing a single point of reference means that the developer configuring and maintaining the Connect-JMS rule doesn't need to know the four DSS records that might be used to store the connection parameters; they only need to know the one data page that contains the values at runtime.
OK, I managed to do a little more digging and have some additional information.
Another benefit of using the data page approach (assuming that referencing the @getDataSystemSetting function is a viable alternative) would be to collect multiple properties/settings. The exercise (and the lesson) focus on a SOAP connector, which allows the global resource setting pattern in only one field - the Service endpoint URL field. The forms for other connectors extend the pattern to other fields.
For example, a Connect-JMS rule allows you to use the pattern in four fields:
- JNDI Server
- Connection Factory
- Destination Name (Request section)
- Destination Name (Response section)
In this case, providing a single point of reference means that the developer configuring and maintaining the Connect-JMS rule doesn't need to know the four DSS records that might be used to store the connection parameters; they only need to know the one data page that contains the values at runtime.
Another potential benefit would be the ability to reference different servers in different areas of the world. For example, you could have one server for requests from North America, and another for requests from APAC. In this case, you could create a DSS for each region, and use a circumstanced data transform (or conditional sourcing on the data page) to populate the data page on nodes in each geography with the appropriate server endpoint, and pass that result to the Connect-SOAP rule.
I'm not saying that this last configuration is necessarily advisable. But it's possible, and wouldn't be feasible if the Connect-SOAP rule referenced the DSS directly, unless you made copies of the Connect-SOAP rule for each geography, which introduces a (bigger) maintenance issue.
So, in summary, the global resource setting pattern does require a little more overhead in the configuration, but is more flexible in terms of adapting to deployment environments. As a result, it's probably going to be the only option for passing values in to the Service endpoint URL field, at least for the foreseeable future.