You are trying to set an environment variable specific to each integration node running in the same physical server. According to the IIB Knowledge Center you can do this by placing profile files (.sh) under work_path/config/broker_name/profiles directory.
Please see this topic for further details:
Broker-specific command environment: Linux and UNIX systems
After placing the integration node profile in the correct directory, you restarted the
integration node but when you review the environment variables you do not see them
defined in the environment. This could be a little bit confusing, so in this article we attempt to explain how IIB reads the additional profiles to better understand what to expect when the environment is setup.
The primary principle is: child shells/processes will inherit the environment variables from the parent. This is also true for IIB.
The mqsistart shell script will source any profiles configured for the integration node and then start the bipservice process. The bipservice process being a child will inherit all the environment variables from the parent mqsistart script. The bipservice process starts the bipbroker process. The bipbroker process starts biphttplistener and the DataFlowEngine processes. All these processes will inherit the environment from the mqsistart shell.
The parent IIB command console shell that launched the mqsistart shell will not inherit those integration node profile variables. If you do an “echo” command to validate the integration node environment, it will not return the value set in the node profile (as this console shell is not a child of mqsistart). Whereas, if you ‘sourced’ the integration node profile from your original command shell, then you will have those variables set.
You can use this command to validate the environment variable is set for the processes spawned by mqsistart:
ps ewww PID | tr ‘ ‘ ‘\n’ | grep ENVIRONMENT_VARIABLE
This is also true for the profiles configured at the integration server level (work_path/config/broker_name/server_name/profiles). The integration server profiles get sourced by the ‘startDataFlowEngine’ script which is launched as a separate shell by bipbroker.
Please see this topic for further details:
Integration server-specific command environment: Linux and UNIX systems
This can be illustrated with a simple example:
You can try it in any shell. Do ‘export WMB_A=hello’.
Then type ‘sh’ to start a new shell.
In the new shell ‘export WMB_B=world’.
Then run ‘env | grep WMB_’ which will show both variables set.
Then ‘exit’ or Ctrl-D to end that shell and return to the first one
and type ‘env | grep WMB_’ and you’ll only see the first environment variable set.
Conclusion: Children inherit from the parent.
Here is another example to illustrate the above behavior in IIB:
This is the common profile to all broker:
This is the broker profile specific to v9broker:
Executed mqsiprofile to set the environment. The mqsiprofile script will source any profiles located in work_path/common/profiles/*.sh. This is why you see the echo for “commonprofile”:
Restarted the integration node to source the node profile:
Per the explanation above, the profiles located in work_path/config/broker_name/profiles are sourced when mqsistart is executed. You can see this because of the echo of “brokerprofile” and “/temp/new_odbc.ini”. Only the processes spawned by mqsistart will inherit this node profile and that does not include the current shell. This is why the echo commands do not return any value. This shell is not a spawn of mqsistart so it does not have any of the environment variable defined by the broker specific profile:
If you review each of the mqsistart “children” processes, you can see that the variables are defined correctly:
We do realize that there is a limitation when the mqsicvp check if you chose to set the ODBCINI variables in a integration node specific profile or an integration server profile. The mqsicvp command does not run those profiles. You would have to manually source the node profile before running mqsicvp. For example:
Creating additional profiles provides you with the flexibility to customize and extend your IBM Integration Bus environment and having a better understanding on how they work and what to expect will help you better configure your system to meet your specific needs and requirements.