Configuring and Deploying the CSW Engine

This topic focuses on configuring and deploying Catalog Services for the Web, specifically CSW 2.0.2.

Be sure that you have previously performed any necessary operations described in Deploying and Configuring Spatial Web Services.

The CSW APIs enable you to perform operations that include:

• Specifying information about record type domains and record view transformations

• Populating the USER_SDO_CSW_SERVICE_INFO table for DCMI (Dublin Core Metadata Initiative) or ISO records

• Unpublishing record types by dropping them from the USER_SDO_CSW_SERVICE_INFO table

• Granting to users and revoking from users privileges on CSW record types and on the XML query full text context index

Configuring the CSW engine involves the following:

• Initializing CSW

• Setting Up CSW Data Sources

• Editing the CSWConfig.xml File

• Loading Data for CSW

• Testing the CSW Deployment

• Creating and Maintaining Spatial and XQFT Indexes

Initializing CSW

Before initializing CSW, the following privileges should be granted to the CSW schema. Here, the schema of a database user named MDMETT is a CSW schema.

GRANT CONNECT, RESOURCE, UNLIMITED TABLESPACE, CTXAPP TO MDMETT;
GRANT EXECUTE ON CTXSYS.CTX_DDL TO MDMETT;
GRANT SELECT ON MDSYS.SDO_XSD_TABLE TO MDMETT;
GRANT SELECT,ALTER ON MDSYS.md_identifier_sq$ TO MDMETT;

To use Catalog Services for the Web in Oracle Spatial, you must call the SDO_CSW.INITIALIZE_CSW procedure to initialize the CSW 2.0.2 service. This procedure creates the user table if it does not already exist, and prepares the indexes. For example:

DECLARE
BEGIN
sdo_csw.initialize_csw(
  'MDMETT',
  '2.0.2', -- must be 2.0.2
  1, -- for DCMI
  'MY_CSW_CATALOG_TABLE',
  4326,
  1
  );
  END;
  /

If the CSW database instance is not instantiated, you can call the SDO_CSW.INITIALIZE_CSW procedure, which initializes a CSW schema and creates the CSW catalog table and appropriate indexes if they do not exist. For example, the preceding example will enable the MDMETT schema as the CSW schema, create the MY_CSW_CATALOG_TABLE table as the CSW catalog table, and create (spatial and XML Query Full Text) indexes on it.

The SDO_CSW.INITIALIZE_CSW procedure can also be used to just register the CSW schema and catalog table if the CSW catalog table and necessary indexes already exist. For details and examples, see the SDO_CSW.INITIALIZE_CSW reference topic.

Setting Up CSW Data Sources

After the CSW schema is created, set up a data source for the CSW engine in Oracle WebLogic Server following the instructions as explained in Adding a WebLogic Data Source.

Note:

Each database can have multiple CSW schemas, each of which corresponds to one data source in WebLogic Server. You can also have multiple data sources configured for CSW in WebLogic Server. Each data source can be accessed through a different URL, where the last part of the URL correspond to the data source name configured in WebLogic Server. The following is an example link with a CSW data source named cswdata1:

http://localhost:80/oraclespatial/csw/cswdata1?service=CSW& version=2.0.2&request=GetCapabilities

Editing the CSWConfig.xml File

You may need to modify some or all of the following settings using the CSW Administration Console:

• log_level, which accepts the following values (reflecting increasing amounts of information to be stored in the log file): OFF, SEVERE, WARNING, INFO (the default), CONFIG, FINE, FINER, FINEST, and ALL.

• size_limit, an integer that specifies an approximate maximum amount of megabytes to write to any log file before creating a new file for log rotation. If size_limit is 0 (zero), there is no limit. The default value is 10.

• file_count, which specifies how many output files to cycle through. Older log files will be deleted to limit the disk space taken by log files. The default value is 10.

• ServiceIdentification and ServiceProvider, which provide appropriate content to deliver in CSW GetCapabilities responses. If these two values are required to be different than the default values provided by the Oracle Spatial CSW service, then they must be uncommented and edited as required in order to have the correct information returned in CSW GetCapabilities responses. If this section remains commented, default content will be delivered on the client side.

Loading Data for CSW

A client-side Java loader, provided by Oracle Spatial, is in the following .jar file (assuming the default Spatial installation directory of $ORACLE_HOME/md):

$ORACLE_HOME/md/jlib/sdocswloader.jar

After the CSW schema is initialized, you can use the sdocswloader.jar Java package to load CSW 2.0.2 data. This package takes a large file containing CSW XML records and loads them into the user CSW table. For information about how to use this package, see Loading CSW 2.0.2 Data (DCMI) for the DCMI profile and Loading CSW 2.0.2 Data (ISO) for the ISO profile.

Testing the CSW Deployment

After the CSW engine is deployed and the data source is created, you can test the deployment with a set of CSW engine test queries. The following example is a GetCapabilities query for CSW 2.0.2:

http://machine-name:port/oraclespatial/csw/<data source name>?request=GetCapabilities&service=CSW&version=2.0.2

Creating and Maintaining Spatial and XQFT Indexes

In some cases you may need to manually create or maintain spatial and XML Query Full Text (XQFT) indexes. These indexes are created automatically (if they do not already exist) by the first format of the SDO_CSW.INITIALIZE_CSW procedure, in which you do not need to create them. However, in some scenarios you may need to drop and re-create the index, and/or to synchronize the index, such as the following:

• Scenario 1: The spatial index creation did not complete successfully when you used the SDO_CSW.INITIALIZE_CSW procedure.

• Scenario 2: The spatial index creation did not complete successfully when you called the SDO_CSW.CREATE_SPATIAL_IDX procedure.

• Scenario 3: The spatial index becomes invalid for any reason, such as mentioned in Exchanging Partitions Including Indexes

• Scenario 4: There have been significant insert, update, or delete operations on the CSW user data table.

If you need to re-create or rebuild the spatial index due to scenario 1, 2, or 3, then you must drop the spatial index first (by using SQL statement DROP INDEX <index_name> [FORCE]), and then re-create the spatial index using the SDO_CSW.CREATE_SPATIAL_IDX procedure.

For scenario 4, it is faster to call SDO_CSW.SYNC_INDEX for the XQFT index, in which case the existing XQFT index is automatically updated. However, if you need to re-create the XQFT index, then you can call the SDO_CSW.CREATE_XQFT_IDX procedure to drop the existing XQFT index and then create a new one.