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.
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.
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.
In this example, the getDataSystemSetting utility function rule is used to obtain the value in the data transform.
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.
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.
Execution-time sequence
The following list shows the execution-time sequence for determining the Endpoint URL for the SOAP connector:
- The SOAP Connector is invoked.
- A data page property is referenced.
- The data transform for the data page is executed if the page is not already available on the clipboard.
- The data transform invokes a utility function to obtain the value of, for example, a dynamic system setting.
- The value is used by the SOAP connector to invoke the service.