Editing configurable properties in a BAR file with MQSIAPPLYBAROVERRIDE

A bar file's configurable properties can be customized without editing and rebuilding the message flows or the resources that they use.

This can be achieved in the following ways:

1. Editing configurable properties with the IBM Integration Toolkit.
2. Editing configurable properties with the mqsiapplybaroverride command

In this post I will concentrate on editing the configurable properties using the mqsiapplybaroverride command.

1. Use the mqsireadbar command to determine which propertes can be configured.

mqsireadbar -b <barfile> -r

e.g. mqsireadbar -b c:\myBarFile.bar -r

The above command will display the properties on the screen.

2. Use the mqsiapplybaroverride to change the properties

Command Syntax
 mqsiapplybaroverride -b barFileName [-p overridesFile] [-m manualOverrides] [-k applicationName] [-y libraryName] [-r] [-o outputFile] [-v traceFileName] 

Command options: 
 '-b barFileName' - The name of the BAR file (in zip format) to be overridden.
 '-p overridesFile' - The file name of the plain text file that contains one of these items: the integration node properties to be overwritten, the entire new deployment descriptor, or a BAR file that contains the entire new deployment descriptor.
 '-m manualOverrides' -  A comma separated list of key=value pairs that describe the overrides to apply. On Windows systems, the list must be enclosed in quotation marks (""). If used in conjunction with -p, the overrides that are specified with the -m parameter are performed after all overrides that are specified by the -p parameter have been made.
 '-k applicationName' - The name of the application to which the overrides will be applied.
 '-y libraryName' - The name of the static library or shared library to which the overrides will be applied.
 '-r' - requests that overrides are applied recursively through applications and libraries.
 '-o outputFile' - The name of the output bar file to which the bar file changes are to be made. If this name is not specified, the input file is overwritten.
 '-v traceFileName' - Verbose internal trace is sent to the specified file.
 Note: Overrides must be supplied either in the form FLOW#NODE.PROPERTY=NEWVALUE or in the form OLDVALUE=NEWVALUE. If the latter form is used, OLDVALUE must already be an overridden value in the deployment descriptor. Specify FLOW#NODE.PROPERTY on its own to remove an override.

Create a text file, and list the properties that you want to change in the following format:
property=newValue.

mqsiapplybaroverride -b <barfile> -p <overridesFile> -k <application name>

Spefify output file parameter if you dont want the bar file to be overwritten.

mqsiapplybaroverride -b c:\temp\test.bar -p c:\temp\BarFileOverride.txt -k c:\temp\test.bar

Alternatively instead of using the command console, the bar file can be overridden by using the overrides file in the web console by clicking the Overrides button and selecting the overrides file.

N.B - the user running this command should be an administrator of the machine.

Environment and Local Environment in IIB

Environment

The environment tree is a part of the logical message tree in which you can store information while the message passes through the message flow. The Environment folder is created at the start of a thread. It stays with the thread until the thread dies.
All data that is stored in the Environment tree is stored in memory during the whole message flow and is not freed after it is out of scope. Therefore, if you need space to store local data for node work, then use the LocalEnvironment tree and avoid high memory consumption.

The environment tree differs from the local environment tree in that a single instance of it is maintained throughout the message flow. If you include a Compute node, a Mapping node, or a JavaCompute node in your message flow, you do not have to specify whether you want the environment tree to be included in the output message. The environment tree is included automatically, and the entire contents of the input environment tree are retained in the output environment tree, subject to any modifications that you make in the node. Any changes that you make are available to subsequent nodes in the message flow, and to previous nodes, if the message flows back (for example, to a FlowOrder or TryCatch node).

LocalEnvironment

The local environment tree is a part of the logical message tree in which you can store information while the message flow processes the message.
The local environment tree is made up of the following structure:
Anything in the format of LocalEnvironment.Destination.output_or_request_node_name, for example; LocalEnvironment.Destination.Email, decides what happens when information is going into an output or request node.
Anything in the format of LocalEnvironment.WrittenDestination.output_or_request_node_name, for example; LocalEnvironment.WrittenDestination.FTE, gives you information about the processed output of an output or a request node.
Anything in the format of LocalEnvironment.input_node_name.input, for example; LocalEnvironment.Adapter.Input, contains information that has been stored by an input node.
Use the local environment tree to store variables that can be referred to and updated by message processing nodes that occur later in the message flow. You can also use the local environment tree to define destinations to which a message is sent.

Conclusion

Use the Environment for scratchpad work where you need to maintain the content beyond the scope of the current node, and use the LocalEnvironment for larger scratchpad areas that are only required during the current node, and you need to release the memory after use.
If you want to keep your own values, create it in the environment tree in a subtree called Variables.

Source: IBM® Integration Bus Version Information Center

You may also be interested in these posts: Environment Tree || Populating Destination in the local environment tree