You can access information in a database
to enhance, or influence the operation, of the message flow. You can also
modify the contents of a database by inserting new information or by removing
or replacing existing information.
You can access a database from a
message flow using the following nodes:
- Compute
- Database
- DataInsert
- DataDelete
- DataUpdate
- Filter
- Mapping
- Warehouse
For more details of these nodes, and how to configure them in message
flows, see Built-in nodes.
If you
want the actions that the message flow takes against the database to be coordinated
with other actions, configure the message flow to support global coordination
of transactions. For information on how to do this, see Configuring globally coordinated message flows.
To access a database from a message flow:
- Identify the database that you want to access. This
can be an existing database or a new one that has been created for this purpose.
See Data sources on z/OS for more information on what
to call a z/OS user database.
If
you want to create a new database, follow the instructions given in Creating the databases.
If you want to use a database
other than DB2, refer to the database product documentation for detailed instructions
on how to do this.
Supported databases lists
the database managers that are supported by WebSphere Message Broker.
- Define an ODBC data source name (DSN) to enable a connection to
the database, if one does not already exist.
For more information,
see Enabling connections to the databases.
On Linux (zSeries platform) and Linux (POWER platform),
the only supported database manager is DB2 and ODBC is not used; the broker and message flows connect to the databases directly. When
you configure message flows, use the DB2 alias of the database as the DSN.
- Authorize the broker to access the database.
Access
to a user database from within a message flow is controlled by user ID and
password.

On z/OS, you
can specify these values:
- When you create the broker.
The broker started task ID is used to
access user databases, irrespective of the user ID and password specified
on the mqsicreatebroker command
in the BIPCRBK JCL in the customization data set <hlq>.SBIPPROC.
- After you have created the broker.
Use the BIPSDBP JCL in the customization
data set <hlq>.SBIPPROC to customize the mqsisetdbparms command
to specify a user ID and password for a specific database. This changes the
default values that were set when you created the broker (described above).
You
can create a user ID and password for any database (identified by DSN) that
is accessed by a message flow. You can, therefore, control access to a database
at an individual level if you choose. This includes databases that you have
created and configured on distributed systems that are accessed by z/OS DB2
remote database access.
On distributed systems, you can specify these values:
- When you create the broker.
The mqsicreatebroker command
has two parameters -u DataSourceUserid and -p DataSourcePassword that
you can use to identify the user ID that the broker uses to access its own
database. If you specify these parameters, they are used as the default access
control parameters for user databases that are accessed by message flows.
If
you do not specify DataSourceUserid and DataSourcePassword,
the broker uses the values specified for the parameters -i ServiceUserID and -a
ServicePassword (which identify the user under which the broker runs)
as the default values.
- After you have created the broker.
Use the mqsisetdbparms command
to specify a user ID and password pair. This changes the defaults that were
set when you created the broker (described above).
You can create a
user ID and password pair for any database (identified by DSN) that is accessed
by a message flow. You can therefore control access to a database at an individual
level if you choose. This includes databases that you have created and configured
on z/OS that are accessed by brokers on distributed systems.
If the user that created a table in a database is not the user that
the broker is using to access the database, you must specify the user ID that
created the database as the schema name in relevant ESQL statements, unless
you have set up an alias or synonym.
Note: If you access a database from a message
flow using a Compute, Database or Filter node, use the Data perspective to
enable a connection to the appropriate database.
The final step of this process imports the database SQL into the message flow
project.
The Message Routing sample, the Data Warehouse sample, the Error Handler sample,
and the Airline Reservations sample access databases
from message flows. The Message Routing sample and Data Warehouse sample
use Compute nodes to access the database, the Error Handler uses Database
nodes to access the database, and the Airline Reservations sample uses both
Compute and Database nodes.