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.
Before you begin
This topic assumes that you have already determined the set of servers on
which to install an SDO repository, and added each server 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.
Why and when to perform this task
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 server
configuration for a distributed platform you can use embedded Cloudscape.
You install the SDO repository by using the
wsadmin scripting client to run the
installSdoRepository.jacl
script. If you are creating a 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.
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:
Steps for this task
- Optional: To install the SDO
repository on a 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 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