Skip to main content
This content is now archived and is no longer updated. Progress is not calculated. Pega Cloud instances are disabled, and badges are no longer awarded.

Configuring a GRS for a connector endpoint

Configuring a GRS for a connector endpoint

When you configure a global resource setting (GRS) for an integration, you first create a class for the references to external systems. You place all GRS rules in the same ruleset as the integration rules. Next, you determine which environment references to external systems will use the feature. Then, you create a page property for each environment reference. Continue the process by creating a data transform to assign values to the environment properties using utility functions. Finally, you create a data page to tie these artifacts together.

Assume that you have generated a connector for an inventory check SOAP service using the Create SOAP Integration wizard.

Designate a class for the references

The first step in implementing GRS is to create or identify a class to contain environment properties that represent the external system references.

As a best practice, create the class in the base class of the integration. This helps avoid later confusion when users access multiple integrations, because each integration has its own data page. Create a class called Env in the base integration class.

In this case, create the Env class in the Inventory class generated by the Create SOAP Integration wizard.

grs env class

Create the environment properties

The next step in implementing the GRS is to determine which environment references to external systems use the feature. Create a page property for each environment reference. For SOAP connectors, use the class Embed-Env-SOAP.

grs env property

For a list of classes that support the GRS syntax, see the help topic Standard classes derived from the Embed- base class.

Create a data transform to assign values to the environment properties

After you create the environment properties for the integration, you must create a data transform to assign values to those properties. This data transform is used to source a data page.

Note: Hard coding the environmental variables in the data transform requires you to unlock the ruleset to update the values. As a best practice, never unlock a locked ruleset.

Pega provides several ways of specifying environmental variables without requiring unlocking rulesets. The following table provides the options with relevant utility functions used to obtain the value.

Type Function Description
Dynamic System Settings getDataSystemSetting This function reads the specified Dynamic System Settings from the database and returns it as a string.
Java System Property getJavaSystemProperty This function returns the specified Java system property as a String.
Java Properties File getJavaPropertyFromFile This function loads the specified Java properties file and returns the value of the property specified in the function's Key parameter as a String. If the property cannot be found, the function returns an empty string.
JNDI Entry getJNDIEntry This function does a lookup for the specified JNDI entry and returns the entry as a string. If the function is unable to perform the lookup, the function returns an empty string and writes an error to the log.
Note: The environmental variables should not be packaged as part of the application since that would overwrite the settings on the target system when an application is migrated.

In this example, a Dynamic System Settings is used to store the values. Because Dynamic System Settings are data, they can be updated without the need of unlocking a ruleset.

Consider a naming convention to categorize the Dynamic System Settings entries and assure their uniqueness. For example, the first entry could be GRS, a namespace for these types of entries. The second is the name of the interface, and the third is the name of the property.

grs dynamic system setting

In this example, the getDataSystemSetting utility function rule is used to obtain the value in the data transform.

grs get data system settings
Note: You must use Base64 encoding for any passwords before you use them in rules or data instances. Use the Encode() function to encode passwords.

Create a data page

The final rule you create is a data page that ties everything together. As a best practice, choose a name that includes the name of the integration to help avoid later confusion when users access multiple integrations (and each integration has its own data page).

For object type, enter the class created in the first step and select the node scope. Use the data transform created to populate the data page.

grs data page

Use the Global Resource Settings syntax for references to external systems

After you have set up the data page for GRS, use the following syntax to refer to the values:

=DataPageName.IntegrationPropertyName.FieldPropertyName

Where:

  • PageName is the name of the data page, and
  • PropertyName is one of the properties

The following image is how the reference looks if you want to refer to a SOAP Service Endpoint URL, your data page is named D_InventoryEnv, and the property is named InventoryCheck. The setting is on the SOAP Service tab of the connector.

grs env reference

Execution-time sequence

The following list shows the execution-time sequence for determining the Endpoint URL for the SOAP connector:

  1. The SOAP Connector is invoked.
  2. A data page property is referenced.
  3. The data transform for the data page is executed if the page is not already available on the clipboard.
  4. The data transform invokes a utility function to obtain the value of, for example, a dynamic system setting.
  5. The value is used by the SOAP connector to invoke the service.

This Topic is available in the following Module:

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice