WebSphere Enterprise Service Bus, Version 6.2.0 Operating Systems: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Messaging engine database configurations

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.

The messaging engine database is used by the message engines for Service Component Architecture (SCA) and Common Event Infrastructure. The default database name for the SCA messaging engine is SCADB, for the other messaging engines it is MEDB. For the Derby Embedded database, each messaging engine will have its own database or schema. The default schema name is IBMWSSIB.
Note: Multiple schemas are not supported by all database types, refer to your database documentation for details.

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.

Supported Database Types

The messaging engine database can use the following database products:
Table 1. Supported database products
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
DB2 for z/OS v9

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)
DB2 for i5/OS (Native)

Used as a local database for standalone profile.

DB2 UDB for iSeries (Toolbox)
DB2 for i5/OS (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
Oracle 10g
Oracle 11g

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.
Important: On i5/OS, there is a single global database in which you define all schemas for all functional components. You must make sure that all schema names are unique within the logical partition (LPAR).

User ID privileges

The user credentials that you provide in the Profile Management Tool must have the permissions necessary to create table spaces, tables, schemas, indexes, and stored procedures. For the Create new database option, the user identity must have the necessary privileges to create a new database. See "Users and schemas for databases" and "Database privileges" for more information.
Note: If the user running the script has enough authority to create tables, the script will not require an authentication ID within the script.

For network deployment environment, you need all necessary permissions for user privileges specified during configuration from the administrative console.

Database Management Service (DBMS) instances

Each messaging engine has its own database or schema:
  • One is used to host each messaging engine for the Service Component Architecture system bus.
  • Another is used to host each messaging engine for the Service Component Architecture application bus.
  • Another is used to host each messaging engine for the Common Event Infrastructure bus.
The naming convention for the JDBC data source that the messaging engine uses to interact with the database is:
  • System bus: <node><server>|<cluster>-SCA.SYSTEM.<cell>.Bus
  • Application bus: <node><server>|<cluster>-SCA.APPLICATION.<cell>.Bus
  • Common Event Infrastructure: <node><server>|<cluster>-CommonEventInfrastructure_Bus
The Derby database naming convention is shown below:
  • System bus: install_root/profiles/profilename/databases/com.ibm.ws.sib/(<node>.<server>|<cluster>)-SCA.SYSTEM.<cell>.Bus
  • Application bus: install_root/profiles/profilename/databases/com.ibm.ws.sib/(<node>.<server>|<cluster>)-SCA.APPLICATION.<cell>.Bus
  • Common Event Infrastructure: install_root/profiles/profilename/event/DerbyEventBusDB/(<node>.<server>|<cluster>)-CommonEventInfrastructure_Bus
  • Business Process Choreographer bus: install_root/profiles/profilename/databases/com.ibm.ws.sib/(<node>.<server>|<cluster>)-BPC.<cell>.Bus
The default for <cell> is the cell name in most cases. However, when a stand-alone profile is federated (only allowed when it is the first node of the cell) then <cell> is the name of that stand-alone profile. You can override this with your own bus identifier name. Use the command line ($AdminTASKS) to create customized names. You cannot use the administrative console to create customized names.

Configuration actions during profile creation

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.

The following administrative tasks are performed during profile creation:
  • Remote Destination Location:
    • configSCAAsyncForServer, configSCAJMSForServer (remoteMELocation is true)
    • configSCAAsyncForCluster, configSCAJMSForCluster (remoteMELocation is true)
  • Local Destination Location:
    • configSCAAsyncForServer, configSCAJMSForServer
    • configSCAAsyncForCluster, configSCAJMSForCluster

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.

SQL scripts

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.

JDBC provider

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.

Data source names:
  • System bus: : _(node.server|cluster)-SCA.SYSTEM.cell.Bus/cel/cluster/server/node
  • Application bus: _(node.server|cluster)-SCA.APPLICATION.cell.Bus/cell/cluster/server/node
  • Common Event Infrastructure: _(node.server| cluster-CommonEventInfrastructure_Bus/cluster/server/node
Data source JNDI names:
  • System bus: jdbc/com.ibm.ws.sib/(node.server|cluster)-SCA.SYSTEM.cell.Bus/cell/cluster/server/node
  • Application bus: jdbc/com.ibm.ws.sib/(node.server|cluster)-SCA.APPLICATION.cell.Bus/cell/cluster/server/node
  • Common Event Infrastructure: Jdbc/ com.ibm.ws.sib /(node.server|cluster)-CommonEventInfrastructure_Bus/cluster/server/node

Restrictions

There are no known restrictions.

Tables

For information on the tables, see the topic "Data stores" in the WebSphere Application Server Network Deployment information center.

Exported scripts

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.


concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cins_messaging_engine_db_specs.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).