Injecting Parameters to Integration Solutions

When deploying integration artifacts in different environments, it is necessary to change the synapse parameters used in the artifacts according to the environment. For example, the 'endpoint URL' may be different in each environment. Without this feature, you need to create and maintain separate artifacts for each environment. This feature allows you to deploy the same integration solution to multiple environments (DEV, PROD, etc.) and then inject separate parameter values to the different environments.

There are two ways to dynamically inject parameters to your integration solutions:

Injecting parameters as environment variables

If you want to inject parameter values as environment variables, follow the steps given below.

1. Define your synapse artifacts using "$SYSTEM:<place_holder_value>" as the parameter value. Note that <place_holder_value> represents a place holder representing the parameter. For example, shown below is an endpoint artifact, where the endpoint uri configured for this feature:

   <?xml version="1.0" encoding="UTF-8"?>
   <endpoint xmlns="http://ws.apache.org/ns/synapse" name="StockQuoteEndPoint">
     <address uri="$SYSTEM:stockQuoteEP"/>
   </endpoint>

2. In a VM deployment, you can export the variables as shown below. Here VAR is the url you need to have set as environment property.
   

   export VAR=http://localhost:61616/...

Injecting parameters using a configuration file

Use separate configuration files to load the parameter values for each environment. For example, a file named dev.properties can be used to inject parameter values to the development environment and a file named prod.properties can be used to inject parameter values to the production environment.

It is possible to use a file in an NFS mount as the file path and it is useful for container deployment. We can use the environment specific configuration from the file in NFS mount and inject the parameter values to the docker container.

Using file.properties

In the the product startup scripts (integrator.sh and integrator.bat file), which are available in the <EI_HOME>/bin directory, a system variable is defined as follows and the value is set to default.

-Dproperties.file.path=default 

When the above value set to default, the system reads the parameters from the file.properties file that is available in the <EI_HOME>/conf directory. Parameters can define as key-value pair in the file.properties file.

Using custom property files

Instead of using the file.properties file, you are allowed to use the user defined configuration file similar to the file.properties file and configure the particular file path in the integrator.sh or integrator.bat file as shown below.

• In the integrator.sh file:
  

  -Dproperties.file.path=/home/user/ei_configs/dev/dev.properties

• In the integrator.bat file:

  -Dproperties.file.path="%CONFIG_DIR%\dev\dev.properties

With this feature, it is possible to inject the parameters by using the $FILE: prefix followed by the relevant key used to map the original value.

Supported parameters

Endpoint parameters

Configure the Endpoint parameters in your synapse configuration as shown below.

Data service parameters

• Driver
• URL
• Username
• Password

Scheduled Task parameters

The pinned servers parameter can be set as an environment variable for a scheduled task or proxy service. See the examples given below.

Inbound Endpoint parameters

See the list of properties that can be defined as environment variables:

• HTTP Inbound Protocol
• HTTPS Inbound Protocol
• HL7 Inbound Protocol
• CXF WS-RM Inbound Protocol

• Websocket Inbound Protocol

• File Inbound Protocol

• JMS Inbound Protocol

• Kafka Inbound Protocol

• MQTT Inbound Protocol

• RabbitMQ Inbound Protocol

Injecting proxy service parameters

The pinned servers parameter as well as all the service-level transport parameters:

• JMS parameters
• FIX parameters
• MailTo parameters
• MQTT parameters
• RabbitMQ parameters
• VFS parameters

Injecting Message Store parameters