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 or clusters on which to install and configure an SDO repository as described in Planning your bus-enabled web services installation, then add each server or cluster as a member of a bus as described in Configuring the members 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

To install and configure an SDO repository, complete the following steps:
  • 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.
For more information about how to do this, first read the following notes on database usage and on the installSdoRepository.jacl script, and then complete the steps for one of these configurations:
Notes on database usage:
  • 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. In a z/OS® environment you cannot use the embedded Derby database, because this database can be accessed by only one process at a time and even a single server on z/OS can run in multiple processes.
  • For a network deployment configuration you can use either your preferred database or the supplied Derby database and associated Network Server application. However, be aware of the limitations of Derby Network Server. For example, it does not support transactions.
  • 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. Use one SDO repository for each cell, so that if you have multiple cells you use multiple databases, one for each cell.
  • [z/OS] DB2® on z/OS does not have the concept of multiple databases. On z/OS systems, each SDO repository must use a different DB2 instance to ensure that different repositories 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 be SDOREP to enable the SDO repository to access its table with the fully qualified name SDOREP.BYTESTORE. Make sure that 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.
  • 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.
  • If you are configuring this SDO repository for use with a cell that contains a mixture of WebSphere Application Server Version 6.0, Version 6.1 and later application servers, you must use a database that is compatible with all these versions.
Notes on the installSdoRepository.jacl script:
  • Use the wsadmin scripting client to run the script.
  • [iSeries] 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:[iSeries]
    wsadmin -f app_server_root/bin/installSdoRepository.jacl
    [AIX Solaris HP-UX Linux Windows] [z/OS]
    wsadmin.ext -f app_server_root/bin/installSdoRepository.jacl
    where .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:
    wsadmin -f installSdoRepository.jacl -listBackendIds
    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 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.
  • 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.
[iSeries] [AIX Solaris HP-UX Linux Windows]

Configure the SDO repository for a single server, and to use the embedded Derby database

Before you begin [z/OS]

In a z/OS environment you cannot use the embedded Derby database, because this database can be accessed by only one process at a time and even a single server on z/OS can run in multiple processes.

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

  1. Open a command prompt, then change to the app_server_root/bin directory.
  2. Enter the following command: [iSeries]
    wsadmin -f installSdoRepository.jacl -createDb
    [AIX Solaris HP-UX Linux Windows] [z/OS]
    wsadmin.ext -f installSdoRepository.jacl -createDb
    Note: The -createDb flag tells the command to create a default Derby database. If you omit this flag, the command still installs an SDO repository that is configured to use Derby, but the command does not also create the database.

Configure the SDO repository for a single server, and to use a database other than embedded Derby

About this task

If you are creating a single server configuration that uses a database other than embedded Derby, you install your preferred database product, then create a JDBC provider and a data source, then run the installSdoRepository.jacl script twice:
  1. One time to install the SDO application on the application server.
  2. 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:

Procedure

  1. 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.

    For an illustration of the process for creating tables in DB2, see Recreating database tables from the exported table data definition language. For more information, see Deploying data access applications.

  2. Create a J2C authentication alias.

    This is for use with the data source that you create in the next step. Check that the authentication alias matches the login details for your database instance, otherwise a connection will not be made.

  3. Create and configure a JDBC provider and data source.
    Set the following data source properties:
    • Set the authentication property to use the authentication alias you created in the previous step.
    • Select the Use this Data Source in container managed persistence (CMP) check box.
    • Set the Name property to a name of your own choosing. For example, SDO Repository DataSource.
    • Set the JNDI name property to the following exact value: jdbc/com.ibm.ws.sdo.config/SdoRepository.
    • Set any other properties that are required settings for your chosen database.
  4. Optional: Test the data source connection:
    Note: This 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 JDBC provider and data source configurations. For more information about testing connections to data sources, see Test connection service.
    1. In the administrative console, navigate to Resources > JDBC > Data sources.
    2. Select the SDO repository data source.
    3. Click Test connection.
  5. Configure the SDO repository:
    1. Open a command prompt, then change to the app_server_root/bin directory.
    2. Install the SDO repository application on the server: [iSeries]
      wsadmin -f installSdoRepository.jacl
      [AIX Solaris HP-UX Linux Windows] [z/OS]
      wsadmin.ext -f installSdoRepository.jacl
    3. Set the database type that the SDO repository is to use:
      [iSeries]
      wsadmin -f installSdoRepository.jacl -editBackendId database_type
      [AIX Solaris HP-UX Linux Windows] [z/OS]
      wsadmin.ext -f installSdoRepository.jacl -editBackendId database_type
      for example:[iSeries]
      wsadmin -f installSdoRepository.jacl -editBackendId DB2UDB_V82
      [AIX Solaris HP-UX Linux Windows] [z/OS]
      wsadmin.ext -f installSdoRepository.jacl -editBackendId DB2UDB_V82

Configure the SDO repository for a network deployment cell

About this task

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:
  1. One time to install the SDO application on the deployment manager.
  2. One time to set the database type that the SDO repository is to use.
  3. 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 bus-enabled web services roles.

To configure the SDO repository for a network deployment cell, complete the following steps:

Procedure

  1. 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.

    For an illustration of the process for creating tables in DB2, see Recreating database tables from the exported table data definition language. For more information, see Deploying data access applications.

  2. Create the following node-level WebSphere Application Server variables on all affected nodes, including the deployment manager node.
    Note: You can set these variables at either node or cell scope, depending upon your configuration. However for multi-platform nodes you cannot usefully set WAS_INSTALL_ROOT at cell scope, because the nodes have different installation directories.
    1. In the administrative console, navigate to Environment > WebSphere variables then set the scope to node level.
    2. Check that the WAS_INSTALL_ROOT variable exists, with a value of the root directory for the installation of WebSphere Application Server.
    3. Create a new variable your_database_JDBC_DRIVER_PATH, with a value of the location under which your database JAR files will be stored (in a later step) on each of the host machines within the cell.
  3. Create a J2C authentication alias.

    This is for use with the data source that you create in the next step. Check that the authentication alias matches the login details for your database instance, otherwise a connection will not be made.

  4. Create and configure a JDBC provider and data source.
    Set the following data source properties:
    • Set the authentication property to use the authentication alias you created in the previous step.
    • Select the Use this Data Source in container managed persistence (CMP) check box.
    • Set the Name property to a name of your own choosing. For example, SDO Repository DataSource.
    • Set the JNDI name property to the following exact value: jdbc/com.ibm.ws.sdo.config/SdoRepository.
    • Set any other properties that are required settings for your chosen database.
  5. Deploy the database client JAR files on each of the host machines within the cell.

    The JAR files must be deployed to the location given by the your_database_JDBC_DRIVER_PATH variable that you declared in a previous step, otherwise remote nodes will not be able to connect to the SDO repository.

  6. Configure the SDO repository:
    1. Open a command prompt, then change to the app_server_root/bin directory.
    2. Install the SDO repository application on the deployment manager for this cell: [iSeries]
      wsadmin -f installSdoRepository.jacl deployment_manager_node_name deployment_manager_server_name
      [AIX Solaris HP-UX Linux Windows] [z/OS]
      wsadmin.ext -f installSdoRepository.jacl deployment_manager_node_name deployment_manager_server_name
      for example:[iSeries]
      wsadmin -f installSdoRepository.jacl dmgrNode dmgr
      [AIX Solaris HP-UX Linux Windows] [z/OS]
      wsadmin.sh -f installSdoRepository.jacl dmgrNode dmgr
    3. Set the database type that the SDO repository is to use:
      [iSeries]
      wsadmin -f installSdoRepository.jacl -editBackendId database_type
      [AIX Solaris HP-UX Linux Windows] [z/OS]
      wsadmin.ext -f installSdoRepository.jacl -editBackendId database_type
      for example:[iSeries]
      wsadmin -f installSdoRepository.jacl -editBackendId DB2UDB_V82
      [AIX Solaris HP-UX Linux Windows] [z/OS]
      wsadmin.ext -f installSdoRepository.jacl -editBackendId DB2UDB_V82
    4. Install an instance of the SDO repository on each server or cluster that you plan to use for one or more of the bus-enabled web services roles:
      • For each server that is not part of a cluster, repeat the following command:[iSeries]
        wsadmin -f installSdoRepository.jacl node_name server_name
        [AIX Solaris HP-UX Linux Windows] [z/OS]
        wsadmin.ext -f installSdoRepository.jacl node_name server_name
      • For each cluster, repeat the following command:[iSeries]
        wsadmin -f installSdoRepository.jacl -cluster cluster_name
        [AIX Solaris HP-UX Linux Windows] [z/OS]
        wsadmin.ext -f installSdoRepository.jacl -cluster cluster_name
Task topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 10:04:34 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-mp&topic=tjw_install_sdo
File name: tjw_install_sdo.html