Several services of InterChange Server use a database. Table 9 lists the services that use a database and describes their
use.
Table 9. Databases use by InterChange Server
The following sections describe how to set up the databases for these services to use.
To specify the databases that you want InterChange Server to use, you must enter their names in the InterchangeSystem.cfg file. InterChange Server interacts with the databases by means of JDBC, so you specify the name of the target database as a JDBC data source.
The format for specifying a JDBC data source is a uniform resource locator
(URL) that describes a database. The URL contains the following
elements:
The protocol is always jdbc, and subprotocol can be db2 or IBM-branded driver.
The subname is a vendor-specific connection string.
Table 10 provides general recommendations for the database disk space
needed by InterChange Server. The requirements are different in a run
time and in a collaboration design environment, because design sites use the
repository more.
Table 10. InterChange Server database requirements
Service | Run time | Design |
---|---|---|
Repository | 20 MB | 50 MB |
Event management | 20 MB |
|
Transaction | 5 MB |
|
Flow Monitoring | 10 MB |
|
These numbers are guidelines only. Your actual numbers are affected by the number of collaborations and adapters you are using, the number of events that your applications are generating, and the size of the business objects that your data requires.
In most environments, one DBMS server can meet all InterChange Server requirements, especially in sites that are new to using collaborations. You can use a single DBMS server if it has the necessary disk capacity and can support the additional connections that InterChange Server needs.
By default, Installer assumes that one DBMS can meet all InterChange Server needs. When you install the software, the Installer program prompts you for the name of one JDBC data source. It adds that name to the configuration file as the data source for all fourInterChange Server services that use databases: repository, event management service, transaction service, and flow monitoring.
If you are using one database for InterChange Server, your configuration file might look like on of the the following examples, depending on your database.
SQL |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server1:1433; DatabaseName=CwldDB [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server2:1433; DatabaseName=CwldDB [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server3:1433; DatabaseName=CwldDB |
DB2 |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:db2:CwldDB [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:db2:CwldDB [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:db2:CwldDB [FLOW_MONITORING] DATA_SOURCE_NAME = jdbc:db2:CwldDB |
Oracle |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@myserver:1521;SID=cwld [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@myserver:1521;SID=cwld [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@myserver:1521;SID=cwld [FLOW_MONITORING] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@myserver:1521;SID=cwld |
In the example, InterChange Server is using the IBM-branded driver for the SQL Server to access the DBMS server, where the database called wicsrepos is located.
To change the name of the data source that you are using, edit the configuration file, change the value for all three services, then restart the server.
You can partition the database use across two, three, or four databases. Each service can use a separate database. This section describes several partitioning options.
Partitioning InterChange Server load across four DBMS servers spreads the connection load across four servers, which may help with bottlenecks.
The following is an example of a configuration file that provides different data sources for the repository, event management, transactions, and flow monitoring services:
SQL |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server1:1433; DatabaseName=ReposDB [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server2:1433; DatabaseName=EventDB [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server3:1433; DatabaseName=TransDB |
DB2 |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:db2:ReposDB [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:db2:EventsDB [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:db2:TransDB [FLOW_MONITORING] DATA_SOURCE_NAME = jdbc:db2:F lowDB |
Oracle |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server1:1521;SID=ReposDB [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server2:1521;SID=EventsDB [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server3:1521;SID=TransDB [FLOW_MONITORING] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server3:1521;SID=FlowDB |
Partitioning InterChange Server's database allows you to have various types of configurations. For example, you can use one database for three of the four services, as the following SQL Server configuration file example shows:
SQL |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server1:1433; DatabaseName=ReposDB [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server2:1433; DatabaseName=EventDB [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:sqlserver://server3:1433; DatabaseName=EventDB |
DB2 |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:db2:ReposDB [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:db2:EventsDB [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:db2:EventsDB [FLOW_MONITORING] DATA_SOURCE_NAME = jdbc:db2:EventsDB |
Oracle |
---|
[REPOSITORY] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server1:1521;SID=ReposDB [EVENT_MANAGEMENT] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server2:1521;SID=EventsDB [TRANSACTIONS] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server3:1521;SID=EventsDB [FLOW_MONITORING] DATA_SOURCE_NAME = jdbc:ibm-crossworlds:oracle://@server3:1521;SID=EventsDB |
You can use various databases in the same DBMS server, but place the databases on separate disk drives. This setup places all crucial data on the same machine and sends all connection requests to a single DBMS server.