Installing and configuring the SDO repository
Service Data Objects (SDO) is an open standard for enabling applications to handle data from different data sources in a uniform way, as data graphs. Service integration bus-enabled web services use an SDO repository for storing and serving WSDL definitions. Use this task to create and configure your preferred database to store SDO data, and to install and configure an SDO repository on each server that you plan to use for bus-enabled web services.
Before you begin
Determine the servers on which to install and configure an SDO repository, then add each server as a member of a bus.
An SDO repository can work with most database products. For specific information about choosing and configuring your preferred database, consult your database administrator or database product documentation, and read the notes in this topic on database usage.
About this task
- Install your preferred database product.
- Create a JDBC provider and a data source for your database.
- Run the
installSdoRepository.jacl
script one or more times, to install the SDO application on each server and to set the database type that the SDO repository is to use.
installSdoRepository.jacl
script,
and then complete the steps for one of these configurations:
- For a single server configuration, you can use either your preferred database or the embedded Apache Derby database that is supplied with WebSphere® Application Server.
- The SDO repository dictates the schema and table names that it uses, so different repositories must use different databases to ensure that they do not access the same data.
- Create the database for your preferred database supplier by using the Table.ddl file from the relevant app_server_root/util/SdoRepository/database_type directory. The
Table.ddl
file describes the database table that is needed by the SDO repository. - The -editBackendId flag on the installSdoRepository.jacl script determines the database type that the repository is to use. The back-end ID determines what database-specific rules the application follows when talking to the database. See the associated
note on the
installSdoRepository.jacl
script. - Some databases require a user ID that has been 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 beSDOREP
to enable the SDO repository to access its table with the fully qualified nameSDOREP.BYTESTORE
. Make sure that you grant permission for theSDOREP
user to read from, and write to, the database. - If you use an Informix® database, do not disable logging.
- The SDO repository does not require XA support. In most cases you can use either an XA or a non-XA data source. However, if your database is Oracle 8 or 9, you must use the Oracle JDBC driver (non-XA) for the SDO repository data source.
- You might also choose to complete other steps such as creating an index of the primary key to improve database performance. Do not change the schema, table and column names.
- Use the wsadmin scripting client to run the script.
- Run the script from within QShell.
- The script is provided in the app_server_root/bin directory, where app_server_root is the root directory for the installation of WebSphere Application Server. If you choose to run the wsadmin scripting client from another directory, specify the full path to the script on the command option. For example to work with a profile other than the default profile, change to the app_server_root/profiles/profile_name/bin directory then specify the following path to the script:
wsadmin -f app_server_root/bin/installSdoRepository.jacl
wherewsadmin.ext -f app_server_root/bin/installSdoRepository.jacl
.ext
is the file extension.bat
for a Windows system, or.sh
for a UNIX, Linux® or z/OS® system. - The -editBackendId flag on the installSdoRepository.jacl script determines the database type that the repository is to use. The back-end ID determines what database-specific rules the application follows when talking to the database. To see the full list of available back-end ID
values, use the
-listBackendIds
flag:
All the back-end ID values in the list can be used when the SDO repository is installed on one or more WebSphere Application Server Version 7.0 or later application servers. Values marked with (*) cannot be used when the SDO repository is installed on Version 6.0 servers. Values marked with (**) cannot be used when the SDO repository is installed on Version 6.0 or Version 6.1 servers.wsadmin -f installSdoRepository.jacl -listBackendIds
The back-end ID that you select must be the same as your database vendor and the version that most closely matches without exceeding your actual database software version. For instance, if you use distributed Db2 UDB V11.5, pick the latest back-end ID in the DB2UDB family up to V11.5, which is the
DB2UDB_V97
back-end ID. If you use Db2 V9.5, then theDB2UDB_V95
back-end ID is the closest match. If you use Oracle V19c, then pick theORACLE_11G
back-end ID. - If the data source already exists, or there has been a previous broken or partial installation of the SDO repository application, the installSdoRepository.jacl script fails to complete and configuration changes are not saved. In these cases, run the SDO repository uninstall
script, fix the problem, then rerun the
installSdoRepository.jacl
script.
Configure the SDO repository for a single server, and to use the embedded Derby database
About this task
If you are creating a single server configuration and
you want to use embedded Derby, you run the installSdoRepository.jacl
script
with the -createDb
switch. This action creates the
Derby database and installs the SDO repository.
To configure the SDO repository for a single server and to use the embedded Derby database, complete the following steps:
Procedure
Configure the SDO repository for a single server, and to use a database other than embedded Derby
About this task
installSdoRepository.jacl
script twice:- One time to install the SDO application on the application server.
- One time to set the database type that the SDO repository is to use.
To configure the SDO repository for a single server and to use a database other than embedded Derby, complete the following steps: