Professional Documents
Culture Documents
Sunopsis White Paper - Import Export Best Practices
Sunopsis White Paper - Import Export Best Practices
May 2007
Import Export Best Practices
Copyright © 2006, Oracle. All rights reserved.
The Programs (which include both the software and documentation) contain proprietary information; they are provided
under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and
other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs,
except to the extent required to obtain interoperability with other independently created software or as specified by law, is
prohibited.
The information contained in this document is subject to change without notice. If you find any problems in the
documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be
expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the
United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to
U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable
Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure,
modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing
restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth
in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway,
Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous
applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other
measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability
for any damages caused by such use of the Programs.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other
names may be trademarks of their respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not
responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the
use of such content. If you choose to purchase any products or services from a third party, the relationship is directly
between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b)
fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty
obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you
may incur from dealing with any third party.
The options
This document outlines Oracle’s recommended architecture to handle several development sites on
different locations. It applies to Sunopsis v3, Sunopsis Data Conductor 4.1 and Oracle Data Integrator
10.1.3.
In the following, Sunopsis v3 and Sunopsis Data Conductor may be referred to as Oracle Data
Integrator or OracleDI.
Object Type Dependencies on other objects of Work Dependencies on objects of the Master
Repository when importing in Synonym Repository
Mode
Export Strategies
When exporting an object you can choose to do it with “Child Component Export” or not. This option
allows you to fine tune your exports if you plan to do partial imports of work repository objects.
1. Project 21555 was exported including its children. Objects referenced inside the project itself
either through parent/child relationships or through reference are consistent inside the scope
of the XML file. However, references to tables (Datastores) are not contained in the XML file.
2. Model Folder 1555 was exported without its child components. It only contains an empty
Model Folder.
3. Model 1 ID 323555 and Model 2 ID 324555 were exported with their children
Now, suppose that we plan to import Project 21555 to a new repository that has a different ID (333, for
example). If we simply attempt to import the Project XML file, it would fail with message “Interface
101555 references a table ID (190555) that does not exist in you repository”. So to make sure that the
import will succeed, we first need to import all “externally-referenced” objects. In other words, we need
to do the imports in this precise order:
1. Import the Model Folder
2. Import Models
3. Finally import the Project
To import the Model Folder, we have the choice between “Duplication” and “Synonym mode”. To
understand the difference between the 2 modes, here is what would happen if we import the Model
Folder ID 1555 to the new work repository ID 333 in either mode:
• Duplication Mode: the Model Folder in the new repository will have a freshly constructed ID:
7333. Therefore when we attempt to import Model 1 or Model 2 that both reference a Model
Folder ID 1555, the import will fail with message “Model 323555 references a Model Folder ID
(1555) that does not exist in your repository”.
Following our example, to successfully import our objects to the new work repository 333, we would
need to:
1. Import Model Folder 1555 in “Synonym Mode”: This would create a new Model Folder with the
same ID inside work repository 333.
2. Import Models 323555 and 324555 in “Synonym Mode”: Models and underlying datastores,
columns, constraints, etc. will keep exactly the same IDs thus allowing the Project to be
successfully imported as it contains external references to these objects.
3. Import Project 21555 in “Synonym Mode” to allow future updates of the same project.
Although Duplication Mode would have worked, it would have not allow you to update your
project with future releases from the 555 work repository, because your Project objects would
have new IDs ending with 333.
IMPORTANT NOTE: Oracle Data Integrator does not allow import of Knowledge Modules in Synonym
Mode. However, this action is necessary when planning to do partial manual imports of Projects. You
can do Synonym import of Knowledge Modules by following this procedure:
1. Locate the Knowledge Module XML file on your file system and rename its prefix to “TRT_”
instead of “KM_”
2. Right-click on any Folder of your Project and select “Import…> Import Procedure..” menu
3. Select “Synonym Mode INSERT_UPDATE”, go to the directory where your KM is stored on
your file system and select your KM, then click OK.
Important Note: Models can reference each other if you have created Foreign Key references
between 2 Datastores of 2 different Models. If this is the case, you’ll have to export the “referenced”
Models as well.
At this stage, you should have export files starting with the following prefixes:
• “PROJ_”: Project – small file size as it was exported without its children
• “KM_”: Knowledge Modules
• “VAR_”: Variables
• “UFN_”: User Defined Functions
• “SEQ_”: Sequences
• “FOLD_”: Folders – small file size as they were exported without their children
• “POP_”: Interfaces
If you execute this Procedure by setting the options to a valid Folder Id and a valid Directory on your
file system, it will query the Work Repository to retrieve the name and Id of every Interface of your
Folder, and export each of them to the Directory you have specified. The names of the XML export
files will be POP_<Name of Your Interface>.xml
By following this procedure you will successfully setup your environment in the new repository to
continue your developments in parallel.