Global resource settings

Before an application is live, it moves through many environments. Typically, applications go through development, staging, QA, and production. When migrating an application from one server or environment to another, references to the external systems connected to the application (such as endpoint URLs and JNDI servers) typically change. The information required to connect to these external systems must be modified, depending on your environment.

In this example, you have a web service connector that accesses a web service. There is also a configuration for the email server used to send and receive email in the application. When the application moves from the staging environment to the production environment, the URLs and host names all have to change because the production web service and email server have different values.

The example provides only two sets of settings, but an application could have dozens of connectors and setting information. You do not want to have to remember all of the different resources and update each one individually. Additionally, some of the values are in rules — these belong to locked rulesets. You do not want to unlock your ruleset after promotion. The risk is that you would miss one or two settings and delay the application going live.

To avoid missing a setting, use the Global Resource Settings pattern to reference the external systems. Global Resource Settings allow you to define values for settings that can vary depending on the environment, without requiring the update of integration rules and data instances.

In this pattern, you create a class that contains the configuration settings for an integration that has values able to change from one environment to the next. You then have your resources access a data page to load those settings. This data page allows you to have a place to maintain and update these settings.