The messaging engine database specifications lists supported database type; scripts and their locations; profile creation types; and necessary user ID privileges.
The messaging engine database is used to store operating information. Also stored are essential objects that the messaging engine needs for recovery in the event of a failure.
In a standalone environment, you can configure your SCA messaging engine using the administrative console Servers -> Application servers -> server -> Business integration -> Service component architecture configuration page. In a patterned network environment, the messaging engines are configured during installation. However, for a custom network environment, you need to configure the messaging engines manually. See "Custom deployment environment layout configuration" for more information.
You have a lot of control over the messaging engine databases, for example, you can create a database for each messaging engine or you can use a single database for all the messaging engines. Each messaging engine must have either its own database or schema.
Database Types | Considerations |
---|---|
Derby Embedded | Used as the default database type for standalone profile. |
Derby Network Server | Used as the default database type in network deployment environment. |
DB2 Universal | Used as the database in network deployment configurations. Optionally, can be used as the database in stand-alone server configurations. |
DB2 for z/OS v8 |
Important: When creating a profile
for a server that uses DB2 for z/OS v9,
the server must be able to connect to the DB2® database.
Used
as the database in network deployment configurations. Optionally,
can be used as the database in stand-alone server configurations. |
DB2 UDB for iSeries (Native) |
Used as a local database for standalone profile. |
DB2 UDB for iSeries (Toolbox) |
Used as a remote database for network deployment environment or as a local database for a standalone profile.Used as the database in network deployment configurations. Optionally, can be used as the database in stand-alone server configurations. |
DB2 Universal Runtime Client | Used as the database in network deployment configurations. Optionally, can be used as the database in stand-alone server configurations. |
Informix Dynamic Server | |
Microsoft SQL Server (Embedded) | |
Microsoft SQL Server (DataDirect) | |
Microsoft SQL Server (Microsoft) - Support for the Microsoft SQL Server JDBC Driver, version 1.2 was added in WebSphere Process Server, version 6.2.0.1 | |
Oracle 9i |
You need sysdba privilege to create the database, tables and schemas. Failure to have the correct sysdba privilege can result in errors creating and accessing the tables and schemas. |
For network deployment environment, you need all necessary permissions for user privileges specified during configuration from the administrative console.
Stand-alone profile
The default messaging engine database for a stand-alone server is Derby Embedded. You can choose to use a file store for the messaging engine database or you can use another supported database. During profile creation using the Profile Management Tool, you can use the Common database for all messaging engines.
Network deployment
No messaging engine databases are created automatically.
After the profile is created, you can configure a server or a cluster for the Service Component Architecture using the guided activity: Configure your Network Deployment Environment. Access this guided activity from the administrative console of the deployment manager by expanding Guided Activities and clicking Configure your Network Deployment Environment.
You can view the SCA configuration of your server from the Application servers > servername > Service Component Architecture panel of the administrative console.
Details of the use of these tasks can be found in "configSCAAsyncForCluster command" and "configSCAAsyncForServer command."
Performing asynchronous SCA configuration for a server or cluster causes a messaging engine to be created for the SCA system bus. Performing the JMS element of the SCA configuration for a server or cluster causes a messaging engine to be created for the SCA application bus. Both the messaging engines require a database or schema to be created.
For Common Event Infrastructure messaging engine configuration use deployEventService administrative task to configure the event server and the Common Event Infrastructure bus.
No SQL scripts are created as part of the product. You can use existing base WebSphere® Application Server scripts to create database and tables if necessary. The MEDB must be created manually before it is configured using the Application servers > servername > Service Component Architecture panel of the administrative console.
Service Component Architecture
The JDBC provider is reused when the JDBC provider implementation class has to match with the one chosen in the advanced configuration. This usually means that if the same database types are used, then the implementation classes usually match. If no matching JDBC provider is found in the resource.xml file, then the jdbc-resource-provider-templates.xml file under templates/system (profiles configuration) is searched for a matching JDBC provider. The provider is matched also against the implementation class.
Common Event Infrastructure
The JDBC provider creation for messaging engine database is similar to the approach followed in the creation of the CEIDB database. See "Common Event Infrastructure database specifications" for more details.
There are no known restrictions.
For information on the tables, see the topic "Data stores" in the WebSphere Application Server Network Deployment information center.
The sibDDLGenerator script in WAS_INSTALL_ROOT/bin can be used to create the SQL scripts for messaging engines database. Use the sibDDLGenerator script for creating SQL scripts for use in production environment especially on z/OS® platform. See the "The sibDDLGenerator command" for more information.
These scripts only contain basic create database/tablespace/table statements. A database administrator may still need to tailor these scripts to meet their database needs, especially on z/OS.