In
IBM BPM most of the configuration details are stored in 99Custom.xml file.
There are lots of instances when you need to change this default
settings/configuration to the customized one.
When
ever you modify a server configuration,always make the changes to the
100Custom.xml file,not to the original configuration file.In this way , all
customization's are captured in a single file and are readily available if you
upgrade to a new version of IBM BPM. This is the recomanded process as it is
very easy to rollback from here without forgetting what was the “out-of-box/Defualt“
value for the given parameter/tag.
For
example, the 100Custom.xml and 99Local .xml files are stored in the profile
root for the server, where the value is either process-center or process-server,
depending on which server you are configuring.
The
configuration files in the ../config/ directories are loaded
in numerical order. For example, the standard files are loaded in this
order: 00Static.xml, 50AppServer.xml, 60Database.xml, 80EventManager.xml,
98Database.xml, 99Local.xml, 100Custom.xml. By default, the first time
the element that is loaded, it will stick in the configuration. For
example, then the one in 99Local.xmlfile loads first, unless the
merge attribute is set to replace.
According to explanation on above
paragraph, you can create any file of your choice having customized tag which
replaces the default configuration.
Using
the 100Custom.xml file to add new configuration values or replace
existing values
The 100Custom.xml file is designed to hold the customization and changes that you want to make to any of the configuration files. The idea is that if you do a fresh installation of a new version, you can simply drop in your existing 100Custom.xml file and all the changes that you have made are picked up and used instead of the default values that you want to put in the 100Custom.xml file.
The 100Custom.xml file is designed to hold the customization and changes that you want to make to any of the configuration files. The idea is that if you do a fresh installation of a new version, you can simply drop in your existing 100Custom.xml file and all the changes that you have made are picked up and used instead of the default values that you want to put in the 100Custom.xml file.
For example, consider adding any additional columns or views for your task manager to the 100Custom.xml file. Any tuning options, such as for the event manager in the 80EventManager.xml file, are appropriate to put in the 100Custom.xml file. Any changes to default values, such as your system lane user, should be made in the 100Custom.xml file.
Alternatively, if you are changing your database URLs (database name, database machine name, and so on) then consider making those changes directly to the 98Database.xml file. This approach is because these values are written down correctly when you install a new version of the product.
One note on the 100Custom.xml file changes: When you move to a new version of the product, you always want to review the changes in the 100Custom.xml file to make sure that they are still appropriate in the new version. For example, some of the default settings or database queries that you use in customizing the Process Portal might change between releases. Other settings might no longer apply.
The
merge attribute
When
you load or replace values using the 100Custom.xml file, you need to be
careful which merge setting that you use for each element. The
"merge" attribute supports the following:
• "append" - This
setting appends the new tag.
• "mergeChildren" -
This setting merges the new tag with the first of the existing tags, which is the
default behavior. In other words the "mergeChildren" setting merges a
child element with the parent element. However, the "mergeChildren"
setting does not merge a child tag if it does not have any attributes and that
child tag only has text.
• "replace" - This
setting replaces all old tags with this new tag.
You can see usage examples for the "append" and "replace" settings in the 50AppServer.xml and 60DataBase.xml files, which overrides things in 00static.xml file depending on the database or application server.
For example, from the sample 100Custom.xml file, you might want to change the <environment-name> value. In the 99Local.xml file you have something like the following code:
<properties>
...
<common merge="mergeChildren">
...
<environment-name>Environment_from_99Local</environment-name>
...
</common>
...
</properties>
To change the environment name in the 100Custom.xml file, you might use the following code:
<properties>
<common merge="mergeChildren">
<environment-name merge="replace">Environment_from_100Custom
</environment-name>
</common>
</properties>
Making changes
to configuration files for a network deployment cluster
For
network deployment environments, XML configuration files on the cluster level
are templates for XML configuration files that are created when new cluster
members are added. If you make changes to the file at the cluster member level
(PROFILE_ROOT\config\cells\cell_name\nodes\custom_node_name\servers\cluster_member_name\server_type\config\100Custom.xml), make the changes at the
cluster level as well (PROFILE_ROOT\config\cells\cell_name\clusters\cluster_name\server_type\config\100Custom.xml). Making the changes to the
templates at the cluster level ensures that the changes are also created on any
new cluster member, if one is added in the future.
At
run time, only the settings from cluster member files are read. If you make
changes after deployment, you need to make them in the cluster member version
of the file for each server to have the changes take effect at run time.
Always
make changes to any of these XML configuration files on the deployment manager
server using the following steps:
1. Make changes to cluster
members, when means that you need to change the XML file for each node. See the
path name that is listed earlier in this section, but work in the deployment
manager file system.
2. Make changes to the cluster
level to ensure that each new cluster is created with your customized settings.
3. Select Full
Resynchronize to replicate the settings from the deployment manager
server to the individual nodes. If you edit these configuration files on an
individual node, the changes might be lost in the next update.
Backing up configuration files
It is always a good idea to make
a backup copy of the files that you are changing. However, these configuration
files are one area where you need to use some caution when backing them up.
Specifically, always change the extension from .xml when backing up these
files. The following information explains why you want to change the file
extension:
All of the files in the .../config directory ending in .xml are loaded by the product on startup. These files are loaded in an alphanumeric order; letters are loaded first and then numbers are loaded in numerical order. For example, if you have the following files in the ../config directory they are loaded in the order shown below:
.../config/system/Copy of 99Local.xml
All of the files in the .../config directory ending in .xml are loaded by the product on startup. These files are loaded in an alphanumeric order; letters are loaded first and then numbers are loaded in numerical order. For example, if you have the following files in the ../config directory they are loaded in the order shown below:
.../config/system/Copy of 99Local.xml
.../config/system/00Static.xml
.../config/system/50AppServer.xml
.../config/system/60Database.xml
.../config/system/80EventManager.xml
.../config/system/98Database.xml
.../config/system/99Local.xml
.../config/100Custom.xml.
.../config/system/50AppServer.xml
.../config/system/60Database.xml
.../config/system/80EventManager.xml
.../config/system/98Database.xml
.../config/system/99Local.xml
.../config/100Custom.xml.
If you want to get more details and explanation about this
topic and also about other configuration file, specially TeamWorksConfiguration.running.xml (which is merged file from all
xml configuration file created when we start the server), you can go to below
links which provides more details.
