Use this topic to create and install a Service Data Objects (SDO)
repository that the service integration bus Web services enablement (SIBWS)
uses for storing and serving WSDL definitions.
This topic assumes that you have already determined the set of standalone servers or clusters on
which to install an SDO repository, and added each standalone server or cluster as a member of the bus, as described in SIBWS - Completing the installation.
If
the data source already exists, or there is a previous failed or partial installation
of the SDO repository, the installSdoRepository.jacl script
fails to complete and configuration changes are not saved. In these cases,
run the
SDO repository uninstall script.
Service Data Objects (SDO) is an
open standard for enabling applications to handle data from different data
sources in a uniform way (as DataGraphs). The SIBWS uses an SDO repository
for storing and serving WSDL definitions.
The SDO repository uses your
preferred database to store its data. For a simple configuration, you can
use the default database (embedded Cloudscape) that is supplied with WebSphere
Application Server. For all other configurations, you use a more powerful
database and configure an appropriate data source as part of the SDO repository
installation process. The specific conditions under which you can use Cloudscape
are as follows:
- If you are creating a standalone server
configuration for a distributed platform you can use embedded Cloudscape.
- If you are creating a network deployment configuration,
you cannot use embedded Cloudscape. If you want to use Cloudscape, then you
must use it with the associated Network Server application and configure an
appropriate data source.
You install the SDO repository by using the
wsadmin scripting client to run the
installSdoRepository.jacl
script. If you are creating a
standalone server
configuration for a distributed platform and you want to use embedded Cloudscape,
you run the script with the
-createDb switch. This action
creates the Cloudscape database and installs the SDO repository. If you are
creating any other configuration, you install your preferred database product,
create a JDBC provider and a data source, and run the script twice:
- One time to install the SDO application on the application server.
- One time to set the database type that the SDO application is to use.
If you are working in a network deployment environment,
you install your preferred database product, then create a JDBC provider and
a data source, then run the
installSdoRepository.jacl script
several times for each cell:
- One time to install the SDO application on the deployment manager.
- One time to set the database type that the SDO application is to use.
- Several times to install an instance of the SDO application on each server
or cluster that you plan to use for one or more of the SIBWS roles.
Note: - The SDO repository dictates the schema and table names it uses, so different
repositories must use different databases to ensure they do not access the
same data. You use one SDO repository for each cell, so if you have multiple
cells you must use multiple databases, one for each cell.
The
installSdoRepository.jacl script is
provided in the
install_root/bin directory,
where
install_root is
the
root directory for the installation of IBM WebSphere Application Server.
If you choose to run the wsadmin scripting client from another directory,
specify the full path to the
installSdoRepository.jacl script
on the command option. For example:
wsadmin.ext -f install_root/bin/installSdoRepository.jacl
where
.ext is the file extension
.bat for
a Windows system, or
.sh for a Unix or Linux system, or
nothing for an i5/OS system (because iSeries commands do not have a file extension).
To
install the SDO repository, complete one of the following optional main steps
and the associated substeps:
- Optional: To install the SDO
repository on a standalone server in environments
other than z/OS, and use the embedded Cloudscape database, complete the following
steps:
- Open a command prompt, then change to the install_root/bin directory.
- Enter the following command:
wsadmin.ext -f installSdoRepository.jacl -createDb
Note: The -createDb flag tells the command to create a default
(Cloudscape) database. If you omit this flag, the command installs the SDO
repository application without creating the database.
- Optional: To install the SDO repository on a standalone server,
complete the following steps:
- Create the database for your preferred database supplier using
the Table.ddl file from the relevant install_root/util/SdoRepository/database_type directory.
Note: - The Table.ddl file describes the database table that
is needed by the SDO repository.
- Some databases require that a user ID be created and granted permissions
to access the SDO repository database. Create a user ID for user name SDOREP before
you create the tables for Oracle, Sybase, and SQL Server databases. Because
of the way these databases handle user names and table names, the user name
must be SDOREP to enable the SDO repository to access its
table with the fully qualified name SDOREP.BYTESTORE. Make
sure you grant permission for the SDOREP user to read from,
and write to, the database.
- If you use an Informix database do not disable logging.
- You might also choose to perform other steps such as creating an index
of the primary key to improve database performance. Do not change the schema,
table and column names.
For more information, see Deploying data access applications and Recreating database tables from the exported table
data definition language.
- Create and configure a JDBC provider and data source.
Note: Use an
"XA" data source if one is available.
Create a J2C authentication alias, then set
the data source
authentication property to use it. Verify that the
authentication alias matches the login details for your database instance,
otherwise a connection is not made. Set the following data source properties:
- Select the Use this Data Source in container managed persistence (CMP) check
box.
- Set the JNDI name to a name of your own choosing (for example, SDO
Repository DataSource) with a value of jdbc/com.ibm.ws.sdo.config/SdoRepository.
- Complete the data source configuration for your chosen database.
- Optional: Test the data source connection:
- In the administrative console, navigate to your_provider
- Select the SDO repository data source then click Test connection.
Note: The
Test connection option does not work
in all configurations. The availability of this option depends on the scope
at which the data source is defined, and the scope of any WebSphere Application
server variables that are used in the data source configuration and the data
source JDBC provider configuration. For more information about testing connections
to data sources, see
Test connection service.
- Open a command prompt, then change to the install_root/bin directory.
- Install the SDO repository application on the server:
wsadmin.ext -f installSdoRepository.jacl
- Set the database type:
wsadmin.ext -f installSdoRepository.jacl -editBackendId database_type
for example:wsadmin -f installSdoRepository.jacl -editBackendId DB2UDB_V81
Note: The
-editBackendId flag determines the database type
that the repository is to use. The backend ID determines what database-specific
rules the application follows when talking to the database. To see the full
list of available backend ID values, use the
-listBackendIds flag:
wsadmin -f installSdoRepository.jacl -listBackendIds
- Optional: To install the SDO repository
for a network deployment cell, complete the following steps:
- Create the database for your preferred database supplier using
the Table.ddl file from the relevant install_root/util/SdoRepository/database_type directory.
Note: - The Table.ddl file describes the database table that
is needed by the SDO repository.
- Different repositories must use different databases to ensure they do
not access the same data. You use one SDO repository for each cell, so if
you have multiple cells you use multiple databases, one for each cell.
- Some databases require that a user ID be created and granted permissions
to access the SDO repository database. Create a user ID for user name SDOREP before
you create the tables for Oracle, Sybase, and SQL Server databases. Because
of the way these databases handle user names and table names, the user name
must be SDOREP to enable the SDO repository to access its
table with the fully qualified name SDOREP.BYTESTORE. Make
sure you grant permission for the SDOREP user to read from,
and write to, the database.
- If you use an Informix database, do not disable logging.
- You might also choose to perform other steps such as creating an index
of the primary key to improve database performance. Do not change the schema,
table and column names.
For more information, see Deploying data access applications and Recreating database tables from the exported table
data definition language.
- Create cell-level WebSphere Application Server variables:
- In the administrative console, navigate to .
- Set the scope to cell level.
- Create two new variables:
- If these variables already exist at node level, either remove them or
update them to the same values. Any values set at node level override the
values set at cell level.
- Create and configure a JDBC provider and data source. For both the JDBC provider and the data source, set the scope to cell
level. Use an "XA" data source if one is available. Create a J2C authentication alias, then set
the data source authentication property to use it. Verify that the
authentication alias matches the login details for your database instance,
otherwise a connection is not made. Set the following data source properties:
- Select the Use this Data Source in container managed persistence (CMP) check
box.
- Set the JNDI name to a name of your own choosing (for example, SDO
Repository DataSource) with a value of jdbc/com.ibm.ws.sdo.config/SdoRepository.
- Complete the data source configuration for your chosen database.
- Deploy the database client JAR files on each of the host machines
within the cell.
Note: The JAR files must be in an identical directory
structure on each machine, as defined by the your_database_JDBC_DRIVER_PATH cell-level
variable that you declared in a previous step. Otherwise remote nodes cannot
connect to the SDO repository.
- Open a command prompt, then change to the install_root/bin directory.
- Install the SDO repository application on the deployment manager
for this cell:
wsadmin.ext -f installSdoRepository.jacl deployment_manager_node_name deployment_manager_server_name
for example:wsadmin -f installSdoRepository.jacl dmgrNode dmgr
- Set the database type:
wsadmin.ext -f installSdoRepository.jacl -editBackendId database_type
for example:wsadmin -f installSdoRepository.jacl -editBackendId DB2UDB_V81
- Install an instance of the SDO repository on each server or
cluster that you plan to use for one or more of the SIBWS roles: