Skip Headers
Oracle® Enterprise Data Quality Integrated Version Control
Release 11g R1 (11.1.1.7)

E40041-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

  PDF · Mobi · ePub

Oracle® Enterprise Data Quality

Integrated Version Control

Release 11g R1 (11.1.1.7)

E40041-02

May 2014

Oracle Enterprise Data Quality (EDQ) supports integration with Subversion, which is a version control system. This document explains how the integration works and how it is expected to be used.

Note:

EDQ currently only supports integration with Subversion 1.6 and 1.7. Attempting to integrate with a more recent version will cause an error.

This document is intended for advanced users of EDQ and administrators responsible for integrating EDQ with third-party applications.

1 Prerequisites

The Subversion server with which EDQ is being integrated must meet these prerequisites:

2 Restrictions and Limitations

When Subversion is integrated with EDQ as a store of configuration information, the following restrictions and limitations apply. Consider these items before deciding to configure integrated version control using Subversion.

3 Integration Architecture

The EDQ server can be configured to be aware of a Subversion server as a store of configuration information.

In a standard EDQ instance, configuration information, including project information, is stored in the Director database:

Note:

In this instance, configuration information means information that is managed using the Director UI; for example, projects and system-level data.

EDQ with all config data in the Director database

The following figure shows an EDQ instance integrated with Subversion:

EDQ with project data in Subversion

The Director database is still required because it contains data derived from the file-mastered configuration that has been normalized to allow querying by the applications.

With EDQ configuration files mastered and stored in a Subversion repository, a Subversion client can be used to commit or otherwise access them. Because EDQ includes an embedded Subversion client, Subversion client operations to control configuration changes can be performed directly in Director once the EDQ integration with Subversion has been enabled.

4 Setting Up a Repository

The first stage of configuration is to create a workspace directory where the checked out data will be stored:

  1. Create a directory on the disk where desired (for example, C:\MyRepository) and then add it and commit it to Subversion.

  2. Inside the newly created directory, set the following Subversion properties:

    svn propset edq:systemversion 11.1.1:base .
    
  3. Commit these changes into Subversion. Your workspace now displays these properties:

    svn proplist -v .
    Properties on '.':
      edq:systemversion
        11.1.1:base
    
  4. Create the following subdirectories in the newly created directory:

    • Data Stores

    • Hidden Reference Data

    • Images

    • Projects

    • Published Processors

    • Reference Data

  5. Add and commit these directories. The repository is now set up correctly for EDQ.

The preceding steps only need to be performed once per repository. All remaining changes can be made using EDQ.

5 Configuring EDQ

Subversion must be integrated with a fresh installation of EDQ.

Caution:

When an EDQ instance is integrated with Subversion, all pre-existing and other configuration information is lost. To retain this information, you must package and export it first. For further details, see Section 5.2, "Retaining Existing Configuration Information."

Oracle recommends that a single workspace be assigned to each instance of EDQ because it is difficult to move between workspaces in a single EDQ instance.

5.1 Configuring a New EDQ Installation

To configure a new EDQ installation:

  1. Shut down the application server.

  2. Check-out the workspace from Subversion. It is not necessary to checkout the whole tree; just the workspace directory itself is required.

  3. Add the following line to the config/director.properties file, replacing the directory path with that of the absolute path to the root workspace directory; for example:

    sccs.workspace = C\:\\MyRepository
    

    Note:

    This example demonstrates the need to escape colon (:) and backslash (\) characters in the path with a backslash. You must also escape space characters in the path with a backslash.

  4. Start the application server, and start Director.

  5. Check the top of the Main0.log file for an INFO message listing the name of the SCCS workspace; for example:

    INFO: 02-Sep-2013 10:05:21: SCCS workspace is C:\MyRepository
    
  6. If no errors follow this message, EDQ is configured to use Subversion. If there are errors, see Section 8, "Troubleshooting," for possible solutions.

5.2 Retaining Existing Configuration Information

As previously stated, Subversion must be integrated with a fresh installation of EDQ.

Therefore, any pre-existing projects and other configuration items in an EDQ installation must be packaged before integration begins and then imported to the new installation afterwards:

  1. Package all configuration items in the current EDQ instance into DXI files.

  2. Install a new instance of EDQ with the Subversion integration enabled.

  3. Import the DXI files into the new instance, and commit the files to the Subversion workspace.

  4. Check that the configuration items are all valid and working correctly.

    Note that all passwords for Data Stores must be re-entered after a configuration import.

  5. Decommission the previous instance.

6 Version Control Interface

Once EDQ is integrated with Subversion enabled, the following interface elements become visible within the Director application:

7 Deployment Example

An example deployment is presented here. In this illustration, there is a single Subversion server that holds three copies of the configuration for four EDQ installations:

Example with 3 config stores and 4 installations

The copies of the configuration are:

The four EDQ installations using the Subversion server for storing their configuration are:

In this example deployment, the laptop users develop configuration for individual projects on their own laptops and then commit changes back to the subversion repository on "trunk". Where the developers are co-operating on developing a project they will periodically update their local installation to pick up changes from the other developer.

At some point development reaches a point where it needs to be released to UAT for testing. A release manager then copies the necessary projects from "trunk" to "UAT" on the subversion server.

For example, the following Subversion command may be used:

svn cp -m"Release Project X to UAT" http://svn/repos/config/trunk/ProjectX http://svn/repos/config/branches/UAT

The test manager then updates the UAT server's projects to load the new configuration into the OEDQ server. Over a period of time testing continues. As issues are found they are fixed in the UAT environment and committed back to the subversion repository.

Once UAT environment has achieved an acceptable test level it is promoted to release. This achieved in much the same way as the release from development to UAT. The necessary projects are copied across in the version control repository and then the production server is updated to use this configuration.

8 Troubleshooting

Error Cause and Solution

Configuration database is not compatible with workspace

The database has been used with a different workspace. This error usually arises occurs when operations have been performed in EDQ before Subversion version control is enabled.There are two solutions: drop/recreate the Director database, or reinstall EDQ.

Unable to open an ra_local session to URL

This may occur when trying to commit files to an invalid repository. The EDQ integration is not compatible with file-based repositories (repositories beginning with file:/// or C:\example). A fully-declared http:// path to the repository must be made.


9 Related Documents

For more information, see the following documents in the Oracle Enterprise Data Quality documentation set:

See the latest version of this and all documents in the Oracle Enterprise Data Quality Documentation website at

http://download.oracle.com/docs/cd/E48549_01/index.htm

10 Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.


Oracle Enterprise Data Quality Integrated Version Control, Release 11g R1 (11.1.1.7)

E40041-02

Copyright © 2006, 2014, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate failsafe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.