Smartplant Foundation: How To Configure The Consolidated Data Warehouse

SmartPlant Foundation
How to Configure the Consolidated Data

Warehouse
Version 2009 R4
August 2012
DSPF1-PE-200128A
Copyright
Copyright © 2012 Intergraph Corporation. All Rights Reserved.
Including software, file formats, and audiovisual displays; may be used pursuant to applicable software license agreement;
contains confidential and proprietary information of Intergraph and/or third parties which is protected by copyright law, trade
secret law, and international treaty, and may not be provided or otherwise made available without proper authorization from
Intergraph Corporation.
U.S. Government Restricted Rights Legend
Use, duplication, or disclosure by the government is subject to restrictions as set forth below. For civilian agencies: This was
developed at private expense and is "restricted computer software" submitted with restricted rights in accordance with
subparagraphs (a) through (d) of the Commercial Computer Software - Restricted Rights clause at 52.227-19 of the Federal
Acquisition Regulations ("FAR") and its successors, and is unpublished and all rights are reserved under the copyright laws of
the United States. For units of the Department of Defense ("DoD"): This is "commercial computer software" as defined at DFARS
252.227-7014 and the rights of the Government are as specified at DFARS 227.7202-3.
Unpublished - rights reserved under the copyright laws of the United States.
Intergraph Corporation
P.O. Box 240000
Huntsville, AL 35813
Terms of Use
Use of this software product is subject to the End User License Agreement ("EULA") delivered with this software product unless
the licensee has a valid signed license for this software product with Intergraph Corporation. If the licensee has a valid signed
license for this software product with Intergraph Corporation, the valid signed license shall take precedence and govern the use
of this software product. Subject to the terms contained within the applicable license agreement, Intergraph Corporation gives
licensee permission to print a reasonable number of copies of the documentation as defined in the applicable license agreement
and delivered with the software product for licensee's internal, non-commercial use. The documentation may not be printed for
resale or redistribution.
Warranties and Liabilities
All warranties given by Intergraph Corporation about equipment or software are set forth in the EULA provided with the software
or applicable license for the software product signed by Intergraph Corporation, and nothing stated in, or implied by, this
document or its contents shall be considered or deemed a modification or amendment of such warranties. Intergraph believes
the information in this publication is accurate as of its publication date.
The information and the software discussed in this document are subject to change without notice and are subject to applicable
technical product descriptions. Intergraph Corporation is not responsible for any error that may appear in this document.
The software discussed in this document is furnished under a license and may be used or copied only in accordance with the
terms of this license. No responsibility is assumed by Intergraph for the use or reliability of software on equipment that is not
supplied by Intergraph or its affiliated companies. THE USER OF THE SOFTWARE IS EXPECTED TO MAKE THE FINAL
EVALUATION AS TO THE USEFULNESS OF THE SOFTWARE IN HIS OWN ENVIRONMENT.
Intergraph is not responsible for the accuracy of delivered data including, but not limited to, catalog, reference and symbol data.
Users should verify for themselves that the data is accurate and suitable for their project work.
Trademarks
Intergraph, the Intergraph logo, PDS, SmartPlant, SmartMarine, FrameWorks, I-Convert, I-Export, I-Sketch, IntelliShip, INtools,
ISOGEN, MARIAN, SmartSketch, SPOOLGEN, SupportManager, and SupportModeler are trademarks or registered trademarks
of Intergraph Corporation or its subsidiaries in the United States and other countries. Microsoft and Windows are registered
trademarks of Microsoft Corporation. MicroStation is a registered trademark of Bentley Systems, Inc. Other brands and product
names are trademarks of their respective owners.
Contents
Preface .......................................................................................................................................................... 5
SmartPlant Foundation Product Documentation .................................................................................... 5
Documentation Comments ..................................................................................................................... 6
Consolidated Data Warehouse Overview ................................................................................................. 7

Summary of the Shared Object Technology ........................................................................................... 7
The Consolidated Data Warehouse Object ............................................................................................ 8
Migration from Shared Object to CDW ................................................................................................. 12
Consolidated Data Warehouse Model ..................................................................................................... 13

The Published Document Supporting CDW Schema ........................................................................... 13
The CDW Published Document Schema ....................................................................................... 13
The CDW Object Schema..................................................................................................................... 14
The Base CDW Object Schema ..................................................................................................... 15
Source Domain ............................................................................................................................... 16
The CDW Mapping Schema ................................................................................................................. 18
The Base CDW Mapping ................................................................................................................ 18
Additional Map Filtering .................................................................................................................. 19
Mapping Authoring Relationships to the CDW ..................................................................................... 19
Authoring Relationship Model ........................................................................................................ 20
Consolidation Implementation and Customization ............................................................................... 21

Consolidation Implementation Basics ................................................................................................... 21
Authoring Relationship Processing ....................................................................................................... 22
Classification Handling .......................................................................................................................... 22
Map Functions....................................................................................................................................... 23
Map Function Model ....................................................................................................................... 23
OOTB Map Functions ..................................................................................................................... 23
Map Function Implementation ........................................................................................................ 24
CDW Customization .............................................................................................................................. 24
Consolidation Customization .......................................................................................................... 24
Correlate by Name ................................................................................................................................ 28
How to Configure the CDW....................................................................................................................... 33

Configuring the CDW Model and Mapping ........................................................................................... 33
The CDW Model ............................................................................................................................. 33
Reuse the SmartPlant Schema as much as possible .................................................................... 34
Create a completely new CDW schema......................................................................................... 34
The CDW Mapping ......................................................................................................................... 34
New CDW Domain Group .............................................................................................................. 34
Configuring SmartPlant Foundation to Use the CDW........................................................................... 35
Configuring to Expose Consolidated Data ............................................................................................ 35
CDW Demonstration Model ...................................................................................................................... 37

The Model and the Mapping ................................................................................................................. 37
SmartPlant Foundation How to Configure the Consolidated Data Warehouse 3

Contents
The Mapping ......................................................................................................................................... 39

Exposing the CDW Data ....................................................................................................................... 39
Loading the Demonstration Model ................................................................................................. 40
Index ........................................................................................................................................................... 41
4 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

Preface
This document details How to Configure the Consolidated Data Warehouse (CDW) in
SmartPlant® Foundation and it is one of a set of "How To guides" that describe how to configure
the various components of SmartPlant Foundation and the details of the underlying data model.
It can be used as a training guide to explore the configuration of the system and as a model
reference document.
This document is intended for users who have a good familiarity with the SmartPlant Foundation
Desktop Client and have a high understanding of schema modeling techniques.
SmartPlant Foundation Product Documentation

SmartPlant Foundation documentation is available as Help and as Adobe® PDF files. To view
printable guides for SmartPlant Foundation, click Help > Printable Guides in the software.
Intergraph gives its customers permission to print as many copies of the delivered PDF files as
they need for their non-commercial use. Do not print the PDF files for resale or redistribution.
Model Configuration Guides

 How To Guide Master Table of Contents - Provides a copy of the table of contents of each
"How to" document in the SmartPlant Foundation documentation set. Use this document to
locate the guide that contains a particular topic without opening each "How to" guide to
search for the topic.
 How To Configure the Consolidated Data Warehouse (CDW) - Provides information for
system administrators on how to configure the CDW in SmartPlant Foundation and
describes the underlying data model.
 How to Configure Classified Objects - Provides information for system administrators on
how to configure classified objects in SmartPlant Foundation and describes the underlying
data model.
 How to Configure Concurrent Engineering - Provides information for system administrators
on how to configure concurrent engineering in SmartPlant Foundation and describes the
underlying data model.
 How to Configure Document Management - Provides information for system administrators
on how to configure document management in SmartPlant Foundation and describes the
 How to Configure Reports - Provides information for system administrators on how to
configure reporting in SmartPlant Foundation and describes the underlying data model.
 How to Configure the Authoring and Data Warehouse Models - Provides information for
system administrators on how to configure the authoring and data warehouse models in
SmartPlant Foundation and describes the underlying data model.
 How to Configure the Data Sheet Model - Provides information for system administrators on
how to configure the data sheets model in SmartPlant Foundation and describes the
 How to Configure the GUI Model - Provides information for system administrators on how to
configure the graphical user interface (GUI) model in SmartPlant Foundation and describes
the underlying data model.
 How to Configure the Infrastructure Model - Provides information for system administrators
on how to configure the infrastructure model in SmartPlant Foundation and describes the

Preface
 How to Configure the Line List Model - Provides information for system administrators on
how to configure the line list application in SmartPlant Foundation and describes the
 How to Configure Performance - Provides information for system administrators on how to
enhance the performance of SmartPlant Foundation.
 How to Configure the Progress Model - Provides information for system administrators on
how to configure the progress model in SmartPlant Foundation and describes the underlying
data model.
 How to Configure the Security Model - Provides information for system administrators on
how to configure the security model in SmartPlant Foundation and describes the underlying
data model.
 How to Set Up and Configure SmartPlant Foundation - Provides information for system
administrators on how to set up and configure SmartPlant Foundation and describes the
 How to Configure the Workflow Model - Provides information for system administrators on
how to configure the workflow model in SmartPlant Foundation and describes the underlying
data model.
Documentation Comments
Send documentation comments or suggestions to PPMdoc@intergraph.com
(mailto:ppmdoc@intergraph.com?subject=documentation comments).

SECTION 1
Consolidated Data Warehouse Overview

The Consolidated Data Warehouse (CDW) capability was introduced in SmartPlant Foundation
2009 R3 SP2 and released with custom code for correlation, available from Intergraph Product
Center. CDW links together all data published by the tools and exposes that data in the data
warehouse and is an alternative to the shared object technology.
CDW is optional and is delivered as a demonstration model. Intergraph
recommends that it is only used on new projects, as a migration path from shared technology to
CDW is not available at this time. If you want to implement CDW then consult your Intergraph
Support Representative.
What do you want to do?

 Summary of the Shared Object Technology (on page 7)
 The Consolidated Data Warehouse Object (on page 8)
 Migration from Shared Object to CDW (on page 12)
Summary of the Shared Object Technology

For details of how the published data is stored in separate domains and linked through the
shared objects, refer to the SmartPlant Foundation How to Configure the Authoring and DWH
Models document. Those details can be summarized in the following:
 Each design tool publishes documents from which the object data is loaded into domains
that are specific just to that tool.
 When an object is created for the first time in a tool domain, a shared object is also created
in the shared domain, to which the published object is linked with a ComprisedOf
relationship.
 If this object is retrieved by another tool and republished, another object will be created in
the tools domain which is also related to the same shared object.
 If tools publish the same object without retrieving, correlation algorithms (available from the
Intergraph product center) determine if it is in fact the same object and then create the
ComprisedOf relationship to the shared object.
 There is minimal classification of the shared objects except by the instantiation of specific
interfaces such as IEquipment.
 Only the name and description are stored on the shared object which limits query
mechanisms to simple find by name or ad hoc reports.

 The information presented to the user is dynamically generated from the ComprisedOf
objects in each of the publish domains and this action is summarized by the following
diagram:
 This dynamic generation presents the latest information to the user, with respect to the
different objects published, and is known as the last in wins presentation. This data is
presented after the query by name or ad hoc report. You cannot display these properties in
list views for regular queries.
 You can navigate from the shared objects to the published objects to view them in detail.
 You can review the inconsistencies of the published data, either from the shared object, or
from inconsistency reports.
For any further information on the delivery of CDW, please contact your Intergraph support
representative.
The Consolidated Data Warehouse Object

The limitations presented by the shared object are overcome with the introduction of the CDW
object.
 The CDW object replaces the shared object by a configurable set of ClassDefs which, in the
initial demonstration model, are based on the shared object definition.
 Each ClassDef has fully modelled interfaces, properties and relationships, that are used to
store data, and they are consolidated from the published objects.
 The SmartPlant Foundation published schema is mapped to the CDW schema to control
which properties or relationships, from published objects, are consolidated to the CDW
objects.
 In the initial release (2009 R3 SP2) consolidation is again by last in wins. In future releases
there will be support for consolidation rules based on the status of ownership of the object
being published and a CDW object.
 In the initial release, correlation is limited to data published with the Same As relationship,
for example using the retrieve and publish operation. Correlation by name and other rules is
available as a project solution from the product center and this will be included in a future
release of the product.

 The structure of the CDW objects can be summarized by the following diagram:
 Query menus are fully supported.

 List view column as a fully supported.

 In addition to consolidating properties or relationships from published objects, the CDW

objects are classified and related to the classification tree.
 Relationship navigation is now easier, either individually or by edges - for example it is now
from CDW object to CDW object, such as instrument to pipeline.
 Navigation to the related published objects, viewing inconsistencies, and running

inconsistencies reports is exactly the same as when using the shared object technology.

 The CDW objects can be enhanced over and above the storage of published data. For
example purchasing, for construction status management information, could be added to the
CDW schema. This can be done by adding interfaces with properties or relationships.

Migration from Shared Object to CDW

A Consolidated Data Warehouse (CDW) is not mandatory; the existing shared object technology
is supported in parallel to the new CDW technology.
 The CDW is optional.
 A demonstration model based on the shared object definition is available and delivered as
load files with SPF 2009 R3 SP3.
 There is no out of the box capability to migrate shared object data to CDW objects. This can
be achieved by modelling and mapping the CDW, reloading the published data files, and
then deleting the shared objects once any additional relationships have been copied across
from the shared objects to the CDW objects. Tools will be developed to support
re-consolidation after the CDW model or mapping has been updated. These tools include
migrating shared objects to CDW objects depending on the demand from projects.

SECTION 2
Consolidated Data Warehouse Model

The Consolidated Data Warehouse (CDW) schema consists of extensions to the published
document and the configurable CDW schema that is used to expose the published data. This
section of the document details the CDW extensions to the published document and the key
interfaces and relationships used by the configurable CDW model and its mapping. The
demonstration CDW model is detailed in a later section of this document.

 The Published Document Supporting CDW Schema (on page 13)
 The CDW Object Schema (on page 14)
 The CDW Mapping Schema (on page 18)
 Mapping Authoring Relationships to the CDW (on page 19)
The Published Document Supporting CDW Schema

The CDW Published Document Schema
CDW published documents use the same document ClassDefs as the shared object technology.
The existing published documents use the following ClassDefs:
 SPFTEFPublishedDocMaster
 SPFTEFPublishedDocRevision
 SPFTEFPublishedDocVersion
The published document version ClassDef, SPFTEFPublishedDocVersion, has been modified
and extended as follows:
ISPFTEFPublishedDocVersionPI
This is a new primary interface for the SPFTEFPublishedDocVersion ClassDef. The
ISPFTEFPublishedDocVersion is still realized and it retains the code implementation for the
publish and consolidate mechanism using shared objects. Override mechanisms have been
added in this code for project utilization.

ISPFCDWPublishedDocVersion
The new ISPFCDWPublishedDocVersion interface is optionally realized by the published
document version. It is instantiated when a published document is loaded and the system is
configured to use the CDW, as opposed to the shared object.
The following diagram shows the relationship to this interface:
The CDW Object Schema

All CDW ClassDefs use a CDW component schema and a CDW domain. The CDW domain as
its own CDW domain group with its own set of database tables.

The CDW schema is totally configurable but all the ClassDefs have to realize a minimum set of
interfaces. The diagram below shows the model for typical CDW ClassDefs in this example, the
consolidated SPFCDWInstrument.
The Base CDW Object Schema

ISPFCDWObject
This is the main consolidated object interface which implies IObject and is required by all
consolidated ClassDefs.
There are no properties exposed on this interface.
Functionality Configured on ISPFCDWObject

The following methods are configured on this interface.
 View Consolidated Data
 Inconsistency Report

ISPFCDWClassifiedItem
This interface is realized on classified items as well as the ISPFClassifiedItem interface, which it
implies. These should be optionally realized, as the typing properties are not always published
and the classification relationships cannot be determined. See the section Consolidation
Implementation and Customization (on page 21) for more details. Code is implemented on this
interface to control the creation of the SmartPlant Foundation primary classification relationship
and associated classification level relationships used for queries.
There are no properties exposed on this interface.
Functionality Configured on ISPFCDWClassifiedItem

There are no methods configured on this interface.
ISPFTEFPublishedObjectCollection
This interface is retained because it has the ComprisedOf relationship to relate the published
tool data to the consolidated objects.
This enables the CDW to use exactly the same navigation mechanism that is used by the
shared object to view publish data.
Additional interfaces on CDW SPFCDWInstrument

The additional interfaces shown in the diagram above, including the primary interface, are just
an example of the configuration of a consolidated ClassDef. Apart from the primary interface,
which must be unique, the additional interfaces could either be copies of the SmartPlant
Schema interfaces or they could realize the same SmartPlant Schema interfaces. Creating
copies of the interfaces give more control over which properties are modelled as described in
more detail in the section on How To Configure The CDW. The details of the
SPFCDWInstrument ClassDef and the rest of the sample model is described in the section
CDW Demonstration Model (on page 37).
Source Domain
To specify the source domain on CDW relationships, a new interface is made called
ISPFCDWObjectDetail.

ISPFCDWObjectDetail
This is an optionally realized interface on the Rel ClassDef which is used to store the information
about the tool that publishes the data being consolidated.
Name Description Set On

SPFSourceDomain The source domain of the On CDW Object consolidation
data
This information is available in the
history form.
In the out of the box model ISPFCDWObjectDetail is realized for relationships only but it is
easier to make it available for objects as it is on every relationship.

The CDW Mapping Schema

The Base CDW Mapping
The following meta-schema RelDefs are used to define the mapping between integration
SmartPlant Schema and CDW schema.
 ClassDefToClassDef
 InterfaceDefToInterfaceDef
 RelDefToRelDef
 PropertyDefToPropertyDef
 MappingToSPFMapFunction
Some examples of mapping are:
<Rel>
<IObject UID="PFDControlValve.SPFCDWInstrument.ClassDefToClassDef"
/>
<IRel UID1="PFDControlValve" UID2="SPFCDWInstrument"
DefUID="ClassDefToClassDef" OrderValue="0" IsRequired="False" />
<ISchemaObj />
<IMapRel />
</Rel>
<Rel>
<IObject
UID="InstrumentType.SPFCDWInstrumentType.PropertyDefToPropertyDef" />
<IRel UID1="InstrumentType" UID2="SPFCDWInstrumentType"
DefUID="PropertyDefToPropertyDef" OrderValue="0" IsRequired="False" />
<ISchemaObj />
<IMapRel />
</Rel>
<Rel>
<IObject
UID="IEquipment.ISPFCDWEquipment.InterfaceDefToInterfaceDef" />
<IRel UID1="IEquipment" UID2="ISPFCDWEquipment"
DefUID="InterfaceDefToInterfaceDef" OrderValue="0" IsRequired="False" />
<ISchemaObj />
<IMapRel />
</Rel>
<Rel>
<IObject
UID="EquipmentComponentComposition.SPFCDWEquipmentComponentComposition.
RelDefToRelDef" />
<IRel UID1="EquipmentComponentComposition"
UID2="SPFCDWEquipmentComponentComposition" DefUID="RelDefToRelDef"
OrderValue="0" IsRequired="False" />
<ISchemaObj />
<IMapRel />
</Rel>

Additional Map Filtering

When specifying a mapping between two InterfaceDefs, integration and CDW, you can only
execute the mapping for a specific ClassDef. This makes it possible to map a common interface
like IPBSItem just for the PIDInlineInstrument ClassDef by specifying End1MapValue on
IMapRel. For example:
<Rel>
<IObject UID="IPBSItem.ISPFCDWPBSItem.InterfaceDefMap"/>
<IRel UID1="IPBSItem" UID2="ISPFCDWPBSItem"
DefUID="InterfaceDefToInterfaceDef" OrderValue="0" IsRequired="False"/>
<IMapRel End1MapValue="PIDInlineInstrument" />
<ISchemaObj/>
</Rel>
Mapping Authoring Relationships to the CDW

SmartPlant Foundation can be used as a simple data repository, an integrated data warehouse,
and an authoring tool within an integrated enterprise system. When SmartPlant Foundation is
used as an authoring tool it operates differently from other authoring tools, such as SmartPlant
P&ID. This is because SmartPlant Foundation has access to a lot more data that is common to
other SmartPlant Foundation authoring applications and the data warehouse. For example
SmartPlant Foundation may be configured to author equipment lists which may be related to
folders or suppliers. After this equipment is published to the data warehouse, it may be desirable
to have the published data related to the same folders and suppliers. It is possible to configure
mapping within the CDW to publish these relationships, without having to actually retrieve and
publish the folders and suppliers themselves. This is possible because the folders and suppliers
are created in what is referred to as a Common domain as shown in the diagram below.

Authoring Relationship Model
SPFAuthoringRelDelToCDWRelDef
This meta-schema RelDef is defined to map from an authoring RelDef to a CDW RelDef. These
are defined in the CDW schema files. If any such relationships exist to the published data, an
additional file is created and attached to the published document that contains the target
relationships to be created to the published data.
An example of where this new RelDef can be used is shown below.

SECTION 3
Consolidation Implementation and

Customization
This section provides a detailed explanation of how the mapping and consolidation process
takes place.

 Consolidation Implementation Basics (on page 21)
 Authoring Relationship Processing (on page 22)
 Classification Handling (on page 22)
 Map Functions (on page 23)
 CDW Customization (on page 24)
 Correlate by Name (on page 28)
Consolidation Implementation Basics
The consolidate process is split into two parts:

1. Mapping.
2. Load.
The input published file is taken to perform any mapping (as well as transformation based on the
mapping) and create a file in CDW format, matching the CDW schema, ready to load into
SmartPlant Foundation. The internal SmartPlant Foundation loader is used to load the CDW
data. The mapping function is comprised of an input adapter, output adapter, mapping class and
an Interpreter. The role of the Interpreter is to ask the input adapter for information on how to
decide what mapping is required and send it to the output adapter. See the section CDW

Consolidation Implementation and Customization
Customization (on page 24) which describes the customization possibilities in more detail,
including suggestions on how to do precedence; for example PID data is to take precedence
over the PFD data for the instruments or for particular properties on the instrument.
Authoring Relationship Processing

When publishing from a SmartPlant Foundation authoring application (for example a publish
from a SmartPlant Foundation application like linelist), the system looks for any relationships
using the new meta-schema RelDef SmartPlant Foundation AuthoringRelDefToCDWRelDef. If
any are found the objects being published are analyzed to see if any of them have a relationship
of the UID1 or DefUID.
If any relationships exist, a new fifth publish file is created. This has a new interface instantiated
on the file which is used in the code to identify the relationship. The new interface is called
ISPFTEFCommonRels and there is a new MethodDef on this interface called
ProcessAuthoringRels which does the following:
1. Reads the data file to work out the source component schema.
2. Reads the common relationships file looking for any relationships. This is an item that is
visible to both the SmartPlant Foundation authoring application and the data warehouse
such as a supplier.
a. Queries for published items using End1 and End2 of any of the relationships.
b. Does a bulk expansion to get the ComprisedOf relationships for all the published items
found.
c. Works out which end is the published item and finds the CDW object.
d. Creates a relationship using the mapping between the CDW item and the common item.
Classification Handling
This describes the implementation for CDW classification relationships.
The type properties on the published item are used to determine what classification the object
should have. The system finds all the EnumListType and EnumListLevelType properties on the
CDW object and expands the SPFEnumEnumObjClass relationship.
If a classification is found as the result of the expansion a relationship is created between the
CDW object and the classification (SPFPrimaryClassification).
The logic is implemented on the ISPFClassifiedItem interface, so the CDW object needs to have
that interface as well as the ISPFCDWClassifiedItem interface.
Sometimes the type properties are set on the published data and sometimes they are not. This
means the ISPFClassifiedItem interface is not required because when the software can’t find a
classification, it will throw an exception.
However, a way to know when to add the ISPFClassifiedItem interface to code is needed. A
specific map function SPFClassificationFromTyping was written just to address this. Map
functions are pieces of process logic that can be run when the CDW object is created, if this
mapping exists then the object is related to the classification tree based on the Enum – Class
Tree mappings.

Map Functions
It is possible to create a map function and relate the map function to the property mapping
relationship. This enables code to be written for the map function using the Method override
technique described in the section on Mapping customization found in the CDW Customization
(on page 24).
Map Function Model

A new meta-schema object called SPFMapFunctionDef is available with a relationship from the
IMapRel link interface to the map function.
This new RelDef allows map functions to be modelled against any PropertyDef to PropertyDef
and InterfaceDef to InterfaceDef mapping.
OOTB Map Functions

Below is an example of the out-of-the-box map functions.
<SPFMapFunctionDef>
<IObject UID="MF_SPFClassificationFromTyping"
Name="SPFClassificationFromTyping" />
<ISPFMapFunctionDef
SPFMapFunctionToInvoke="SPFClassificationFromTyping" />
</SPFMapFunctionDef>
This is related to a property mapping in the ATP schema as follows:
<Rel>
<IObject
UID="InstrumentType.InstrumentType.PropertyDefToPropertyDef"/>
<IRel UID1="InstrumentType" UID2="InstrumentType"
DefUID="PropertyDefToPropertyDef" OrderValue="0" IsRequired="False"/>
<IMapRel End1MapValue="PIDInlineInstrument" />
<ISchemaObj/>
</Rel>

<Rel>
<IObject
UID="InstrumentType.InstrumentType.PropertyDefToPropertyDef.MF_SPFClass
ificationFromTyping"/>
<IRel UID1="InstrumentType.InstrumentType.PropertyDefToPropertyDef"
UID2="MF_SPFClassificationFromTyping" DefUID="MappingToSPFMapFunction"
OrderValue="0" IsRequired="False"/>
<ISchemaObj/>
</Rel>
Map Function Implementation

The mapping classes tell the interpreter that there is a map function which needs to be run. The
interpreter calls the MethodDef ExecuteMapFunction on the ISPFMapFunctionDef interface.
The property SPFMapFunctionToInvoke on the map function definition is compared and if it
matches any of the predefined mapping class values, the method is called.
The ExecuteMapFunction method returns a string that is used to set the property defined by the
mapping relationship. In the example the map function is passed the source object property
value for InstrumentType. Then the value returned is used to set the InstrumentType property on
the target object.
CDW Customization
Consolidation Customization
The following MethodDefs have been defined against the new ISPFCDWPublishedDocVersion
interface:
 PerformMappingAndTransformation.
 ConsolidateChunkOfObjects – Takes a set of items from the input source and decides
how to process them, filling up the SPF transaction.
 ConsolidateChunkOfRels – Acts the same as ConsolidateChunkOfObjects.
The Methods above, as well as those defined below, can be overridden once you have done the
sideways override of ISPFCDWPublishedDocVersion.(See the SmartPlant Foundation
Customization Guide for details on sideways override).
 ConsolidateDataContainer – Takes the data file and runs through the consolidation
process.
 ConsolidateInstructionContainer – Processes delete instructions.
To see each inividual method available, use the object browser to view them.

The Consolidation Process

This is pseudo code to describe the current process for CDW consolidation. The following steps
describe the consolidation process:
1. ConsolidateDataContainer calls MethodDef PerformMappingAndTransformation
2. Using the output stream from the mapping function, process the file.
a. Extract the component schema and SameAs mappings.
3. Create a container to isolate the consolidate process.
4. Read the file in chunks (default 1000 items).
a. For each chunk call ConsolidateChunkOfObjects and ConsolidateChunkOfRels.
b. Inside these functions, process the objects.
5. Commit the transaction to the database.
Delete Instructions
Three MethodDefs are implemented on ISPCDWObject to allow control of the behavior when a
delete occurs.
1. ProcessItemBeforeToolDelete – Sees how many ComprisedOf relationships exist and
then call:
a. OnProcessItemWithSingleComprisedOfRel - Checks to see if the CDW object last
updated date is more recent than the creation date of the ComprisedOf relationship. If
the last updated date is more recent, it indicates the CDW object has been updated and
will not delete the CDW object. If the object hasn’t been updated it looks to see if there
are any relationships to other objects that are not part of the mapping. If there are
relationships it will not be removed.
b. OnProcessItemWithMultipleComprisedOfRel – Terminates any current properties
that have a source domain equal to the domain of the tool data being removed. For each
of the properties being terminated it looks to see if it had a previous value with a
different source domain and re-instates it.
Precedence Customization
The out-of-the-box precedence process always updates the data on the CDW object as new
data is published. This process makes the published data represent the last in wins data. This
can be changed through customization.
On the ISPFCDWPublishedDocVersionDefault code class there is an override method called
OnSetProperty. This method is called each time we set a property on a new or existing CDW
object.
The inputs into this function are currently:
OnSetProperty(ByVal pobjTargetIDef As IInterface, ByVal
pstrPropertyDefUID As String, ByVal pobjValue As Object)
Access the properties collection from pobjTargetIDef then find the PropertyDefault object for the
property of interest and see the existing value and the source domain.
There are two properties, TargetDomain and SourceDomain which help with precedence.

Mapping Customization
The PerformMappingAndTransformation MethodDef on ISPFCDWPublishedDocVersion
controls mapping. You can perform a sideways override on the
ISPFCDWPublishedDocVersionDefault interface to be able to override the following Methods:
 OnCreateInputAdapter – Allows you to write a new class and inherit from InputAdapter,
must implement ISPFInputAdapter.
 OnCreateOutputAdapter – Allows you to write a new class and inherit from OutputAdapter,
must implement IOutputAdapter.
 OnCreateMappingClass – Allows you to write a new class and inherit from
SPFMappingClass, must implement ISPFMappingClass.
 OnCreateInterpreter – Allows you to write a new interpreter class and inherit from
Interpreter, must implement Interpreter class.
The Methods above allow any project to replace any of the above classes completely with their
own custom version of the class. This is only for mapping. The mapping output class does not
consider about SameAs. It simply maps the properties using the same UID’s. The consolidate
code performs the required logic for SameAs for example.
Input Adapter
To override the GetNextObject and GetObject methods as well as construct custom
AdapterObject (IAdapterObject), use the CreateAdapterObject method.
Output Adapter
Ten Methods can be overridden. Six are defined on the IOutputAdapter interface.
SPFMappingClass
The role of this class is to interrogate the database to provide mapping information by ClassDef
or RelDef. Several Methods can be overridden, allowing customization around what mapping is
returned. The IMapClass interface is used to send back instructions (property mapping) and
IDefInstructions (interface mapping).
Interpreter
The interpreter is a simple class that asks the input adapter for an object (IAdapterObject). If it is
an object, the interpreter calls the function OnExecuteObj which is an override function. If it finds
a relationship the interpreter calls OnExecuteRel.

OnExecuteObj
The process logic is:-
1. Ask mapping class for the mapping for this ClassDef.
2. If no mapping found then ignore this input item.
a. The current setup means it will always default to CDWObject.
3. Call bringcreate on the output adapter which creates a new object using the map to
ClassDef.
4. Set output object name and description from input source.
5. Process each of the SetInstructions (properties).
a. Ask input for source property value.
6. Tell output to write target property with value.
a. Process each of the ISetInstructions (interface).
b. If target interface realizes source interface then create it.
7. Call finish create on output class.
OnExecuteRel
The process logic is:-
1. Extract the relationship definition UID.
2. Ask mapping class for the mapping for this RelDefUID.
3. If no mapping found then ignore relationship.
4. Extract the UID,UID1 and UID2 from the input source.
5. Ask the output adapter to create a new relationship using the mapto RelDefUID, UID, UID1
and UID2 (BeginCreateRel).
6. Process each of the SetInstructions (properties).
a. Ask input for source property value.
b. Tell output to write target property with value.
7. Process each of the ISetInstructions (interface).
a. If target interface realizes source interface then create it.
8. Call finish CreateRel on output class.
Map Function Customization

You can perform a sideways override of ISPFMapFunctionDefDefault and override the
ExecuteMapFunction MethodDef. This function takes the return value and uses it to set the
target mapped property.

Correlate by Name
In the out of the box implementation the SameAs relationships manage correlation between two
objects. For example objectA in the PID domain is the same as objectB in the IDX domain.
These special relationships are placed inside the published xml file and are generated when
manually correlating after retrieve. The Auto-Correlate workflow matches on name and creates
the SameAs relationships; however, this workflow is not certified on CDW.
For those projects that use non-Intergraph tools for authoring data or SmartPlant Foundation for
authoring, there is no mechanism to correlate. To plug this gap and to provide more flexibility
than just name correlation, we have written custom code to use the unique key definition to
define where two objects are the same. This custom code can be modified as required to fit the
needs of your business.
In the example below, we use a unique key definition on the CDW ClassDef to define how we
correlate.
<ClassDef>
<IObject UID="SPFCDWInstrument" Name="SPFCDWInstrument"
Description="Instrument (Planned Material)" />
<IClassDef />
<ISchemaObj DisplayName="Instrument (Planned Material)" />
<ISPFClassDefExt SPFIsConfigurationControlled="True"
SPFUniqueKeyDef="CDWInst,CurrentConfig,Name"/>
</ClassDef>
In the example above, we specify that the configuration and name are the uniqueness. You can
look at related information and include that in the key as well.
The Method to override is called OnCreateNewObjectAndMergeWithInputs. This method is on
the ISPFCDWPublishedDocVersionDefault interface.
The process logic is:
1. Look to see if the CDW ClassDef has a unique key.
2. Create a temporary object and set all the properties.
3. Call the GenerateKey function which returns a unique key.
4. Look in the database for another CDW object with the same unique key.
a. If one found then update it and return it.
b. Otherwise create a new CDW Object and return it.
5. The Comprisedof Rel will be created between the tool data and the object returned.
Public Overrides Function

OnCreateNewObjectAndMergeWithInputs(ByVal pobjPublishedItem As
Generated.IObject, ByVal pobjExistingCDWItem As Generated.IObject, ByVal
pobjCDWObject As StreamingSchema.Model.SchemaObjectDef, ByVal pstrCDWUID
As String) As Generated.IObject
'
' Note:- ExistingCDWItem is nothing
'
' NOTE: Need to do this bit below.
' If this object is a document then attempt to link the document
to its doc master instead of creating a CDW object for it.
'

If pobjPublishedItem IsNot Nothing AndAlso

pobjPublishedItem.Interfaces.Contains("IDocument") Then
Me.CoreModule.QueryRequest.AddQueryInterface("ISPFTEFPublishedDocMaster
")
'
' As the Doc Master and the 2 tier document have the same
UID then it is better to find by UID
'
Dim lobjDocMasters As IObjectDictionary =
CoreModule.QueryRequest.RunByUID(pobjPublishedItem.UID)
If lobjDocMasters IsNot Nothing AndAlso
lobjDocMasters.Count > 0 Then
Return lobjDocMasters(0)
End If
'
' If a document master has not been found then the code
continues to create a regular CDW object for this published object.
'
End If
'
' Extract the config
'
Dim lstrConfig As String = ""
If pobjExistingCDWItem IsNot Nothing Then
lstrConfig = pobjExistingCDWItem.Config
End If
If String.IsNullOrEmpty(lstrConfig) Then lstrConfig =
CoreModule.Server.Context.CreateConfiguration.ToString
'
' Append an _S on the end so we can distinguish from Tool object
plus we are consistent with the original implementation. Use function so
we
' can change this in just one place should it be wrong.
'
Dim lstrNewUID As String = pstrCDWUID
'
' Make up your own correlate rules here....
'
Dim lobjClassDef As IClassDef =
CType(Me.CoreModule.ProcessCache.Item(pobjCDWObject.ClassDefinitionUID,
"SCHEMA").Interfaces("IClassDef"), IClassDef)
If String.IsNullOrEmpty(lobjClassDef.SPFUniqueKeyDef) =
False Then
'
' Create a temp object so we can call the generate key method
'
Dim lobjTempObj As IObject =
Utilities.GeneralUtilities.InstantiateObjectNoFootprint(Me.CoreModule,
lobjClassDef.UID, "", "", "")
lobjTempObj.Config = lstrConfig
'
' Need to call the base function that will set the
properties on the temp object from the tool representation

'
OnSetPropertiesFromSource(lobjTempObj, pobjCDWObject)
'
' Now call the GenerateKey
'
Dim lstrUniqueKey As String =
CType(lobjTempObj.Interfaces("IObject"),
IObjectDefault).GetClass.GenerateKey(lobjClassDef.SPFUniqueKeyDef)
'
' Now search the database looking for unique key
'
Dim lcolUniqueKeys As New Specialized.StringCollection
lcolUniqueKeys.Add(lstrUniqueKey)
'
' Look for objects with these unique keys
'
Dim lobjDataMgr As New
DataAccess.DataManager(Me.CoreModule)
Dim lcolExistingOBIDs As Generic.Dictionary(Of String,
ArrayList) =
lobjDataMgr.GetExistingOBIDsForDomainAndConfigAndUniquekey(lcolUniqueKe
ys, Me.TargetDomain.UID, lstrConfig)
'
' If there are existing obid's then use that object
'
If lcolExistingOBIDs.Count > 0 Then
Dim lobjCDWExistingItems As IObjectDictionary =
Me.CoreModule.QueryRequest.RunByOBIDCollection(lcolExistingOBIDs(lstrUn
iqueKey))
If lobjCDWExistingItems.Count > 0 Then
Dim lobjExistingCDWItem As IObject =
lobjCDWExistingItems(0)
'
' Perform the mapping
' Call function to update the CDW Object
'
Dim lobjUpdatedItem As IObject =
OnUpdateObjectAndMergeWithInputs(lobjExistingCDWItem, pobjCDWObject)
'
' Send back the first item
'
Return lobjExistingCDWItem
End If
End If
End If
'
' Call the mybase code
'
Return
MyBase.OnCreateNewObjectAndMergeWithInputs(pobjPublishedItem,
pobjExistingCDWItem, pobjCDWObject, pstrCDWUID)
End Function


SECTION 4
How to Configure the CDW

As already mentioned, SmartPlant Foundation release 2009 R3 SP2 and SP3 delivers the base
CDW capability and a demonstration model. The out-of-the box product does not supply a CDW
database, nor does it contain any "smart" tools to help configure a database. The Schema Editor
or off the shelve editors can be used to configure the database.
 Use Schema Editor or a similar tool to generate the CDW model load files.
 Use TextPad or a similar editor to generate the CDW mapping load files.
 Use TextPad or a similar editor to generate methods, menus and user access to expose the
CDW model.
There are spreadsheet-based tools developed in projects which can be used to facilitate this
process until a modelling and mapping GUI is delivered with the product.

 Configuring the CDW Model and Mapping (on page 33)
 Configuring SmartPlant Foundation to Use the CDW (on page 35)
 Configuring to Expose Consolidated Data (on page 35)
Configuring the CDW Model and Mapping

The CDW Model
The recommended configuration is the same as the configuration used within the demonstration
model. This is where one CDW ClassDef has been created for each SmartPlant Schema
SharedObjectDef.
There are two alternative approaches to modelling the interfaces properties or relationships:
1. Reuse the SmartPlant Schema as much as possible.
2. Create a completely new CDW schema.
There are advantages and disadvantages of using each of these approaches, as
explained in the following sections.

Reuse the SmartPlant Schema as much as possible

This keeps the schema small as the CDW ClassDefs simply realize their own unique primary
interfaces and the desired SmartPlant Schema interfaces.
 Most importantly, as each SmartPlant Schema interface is realized, it automatically adds in
all the exposed properties and relationship definitions configured from that interface. These
can be excluded from the mapping but care is needed if any of these are required properties
or required relationships as they will need mapping to ensure that there are populated.
The first approach is recommended as this gives far greater control over the exposure of
RelDefs and PropertyDefs. (CDW users will have access to navigating the integration RelDefs if
the same ones are used).
Create a completely new CDW schema

 Gives full control over which properties or relationships are exposed as these are created
along with new interfaces that match the desired SmartPlant Schema interfaces.
 The schema would take longer to create and could significantly increase the size of the
schema in the system, ultimately duplicating the SmartPlant Schema if a 1:1 model was
required although this would be very unusual.
The CDW Mapping

Any properties or relationships that need consolidating from publish objects to the CDW objects
require mapping as does the CDW model. The following components of the model require
mapping:
 ClassDefToClassDef
 InterfaceDefToInterfaceDef
 RelDefToRelDef
 PropertyDefToPropertyDef
This mapping has to be created in xml load files. It is relatively straight forward especially if it is
1 : 1 mapping to the SmartPlant Schema interfaces.
New CDW Domain Group

A new CDW Domain group is created. The new model update is:
<SPFDomainGroup>
<IObject UID="DG_CDW" Name="CDW"/>
<ISPFAdminItem/>
<ISPFDomainGroup SPFTablePrefix="CDW"/>
<ISPFSubscribableItem />
</SPFDomainGroup>
The Relationship points to this new domain group:
<Rel>
<IObject UID="CDW.CDW"/>
<IRel UID1="DG_CDW" UID2="CDW" DefUID="SPFDomainGroupDomain"/>
</Rel>

Configuring SmartPlant Foundation to Use the CDW

SmartPlant Foundation can be configured to use CDW by enabling the setting for the attribute
CDWEnabled to True. This is located in the appSettings section in the SmartPlant Foundation
Server web.config file.
<add key="CDWEnabled" value="True"/>
A CDW Domain group is created and the relationship points to this CDW domain group. The
new model update is:
<SPFDomainGroup>
<IObject UID="DG_CDW" Name="CDW"/>
<ISPFAdminItem/>
<ISPFDomainGroup SPFTablePrefix="CDW"/>
<ISPFSubscribableItem />
</SPFDomainGroup>
The relationship that points to the CDW domain group is:
<Rel>
<IObject UID="CDW.CDW"/>
<IRel UID1="DG_CDW" UID2="CDW" DefUID="SPFDomainGroupDomain"/>
</Rel>
Configuring to Expose Consolidated Data

Once the published data has been loaded and consolidated, users will want to find, view,
navigate, and interrogate the consolidated data. If this is required, you need to create methods
and menus, and then configure user access configuration on relationships for navigation. The
details of how to do this are provided in the How to Configure the GUI document with the overall
guidelines provided here.
You can make the CDW GUI easier for users to navigate by:
 Providing find and query menus for the main objects; for example, for equipment and
instruments but not nozzles.
 Try to use CDW only interfaces when querying for data, this will ensure that the queries
are more efficient.
 Generate the forms for all objects.
 Use form lists or the view related items method to display the primary object information and
some information on the related object. This may be more convenient for the more complex
objects; for example to display equipment and a list of its nozzles.
 Create a column sets to display the key information for objects commonly queried. Avoid
adding every property and relationship because these can slowdown client performance.
 Manage user access to expose relationships as required.
 Create edge definitions to navigate across intermediate objects such as process points. For
example create edges to navigate from equipment to pipelines to instruments.

Good examples of the above are provided in the CDW Demonstration Model (on page 37).

SECTION 5
CDW Demonstration Model

In SmartPlant Foundation release 2009 R3 SP3, the demonstration model is delivered as a set
of load files in the models directory:
C:\Program Files (x86)\SmartPlant\Foundation\2009\Models\CDWDEV

 The Model and the Mapping (on page 37)
 The Mapping (on page 39)
 Exposing the CDW Data (on page 39)
The Model and the Mapping

The demonstration model uses one CDW ClassDef for each SmartPlant Schema
SharedObjectDef. It also uses its own interfaces, properties and relationships so it could just as
easily reuse the SmartPlant Schema.
The following ClassDefs have been created:
 SPFCDWBranchPoint
 SPFCDWBulkPhase
 SPFCDWCable
 SPFCDWCableRun
 SPFCDWCableSchedule
 SPFCDWCableTrayPort
 SPFCDWCableway
 SPFCDWCablewayPort
 SPFCDWCircuit
 SPFCDWConduit
 SPFCDWConduitPort
 SPFCDWConduitRun
 SPFCDWControlSysIO
 SPFCDWDuct
 SPFCDWDuctRun
 SPFCDWElectricalConnector
 SPFCDWElectricalPanel
 SPFCDWEquipment
 SPFCDWEquipmentComp
 SPFCDWEquipmentFoundation
 SPFCDWEquipmentFoundationPort

 SPFCDWFilter
 SPFCDWFooting
 SPFCDWGasket
 SPFCDWHangerSupport
 SPFCDWHVACPort
 SPFCDWInstrument
 SPFCDWInstrumentLoop
 SPFCDWIOCard
 SPFCDWLadder
 SPFCDWLineListRecord
 SPFCDWNozzle
 SPFCDWPhaseChemicalComponent
 SPFCDWPipe
 SPFCDWPipeBoltSet
 SPFCDWPipeClamp
 SPFCDWPipeline
 SPFCDWPipeRun
 SPFCDWPipeSpool
 SPFCDWPipingComponent
 SPFCDWPipingPort
 SPFCDWPipingSystemConnector
 SPFCDWPipingSystemConnector_Process
 SPFCDWPort
 SPFCDWProcessCase
 SPFCDWProcessDataCase
 SPFCDWProcessPoint
 SPFCDWProcessPort
 SPFCDWProcessPort_Process
 SPFCDWRackSlot
 SPFCDWSignalChannel
 SPFCDWSinglePhase
 SPFCDWSlab
 SPFCDWSteamTrap
 SPFCDWStructuralPort
 SPFCDWStructure
 SPFCDWTerminalItem
 SPFCDWTrunk
 SPFCDWValveOperator
 SPFCDWVent
 SPFCDWWeld
 SPFCDWWiringTray

The Mapping
The mapping is a simple 1:1 mapping between the SmartPlant Schema and the CDW
demonstration schema.
The demonstration schema also includes mapping for any interface that contains type properties
and a set of PID interfaces to use in the demonstrator.
 IDifferentialProducer
 IEnergyPort
 IEquipment
 IInstrument
 IPipingComponent
 IEquipmentComponent
 IProcessPointCase
 IPipeCrossSectionItem
 IInlineComponent
 IPipingSpecifiedItem
 IFluidSystem
 IPipingConnector
 IPipingConnectorComposition
The following RelDefs are also mapped across the SmartPlant Schema and CDW
demonstration schema. The mapping involved creating new CDW interfaces and then mapping
and realizing those.
 EquipmentComponentComposition
 PipingPortComposition
 PipingEnd1Conn
 PipingEnd2Conn
 PipingConnectors
 PipingTapOrFitting
Exposing the CDW Data

The following configuration exposes the published data in the demonstration model:
 A single query menu option is configured that makes use of the fact that all the consolidated
objects are classified. Different forms can be configured for different levels of the
classification tree. In the demonstrator the different forms are for equipment and
instruments.
 Column sets have been defined for equipment, instruments, pipelines and nozzles.
 The View Shared Object command and inconsistency reports are available on the shortcut
menus for consolidated objects and the published documents.
 The following edges have been created to make navigation easier:
 CDWPipelineToEquipment
 CDWPipelineToInstruments
 CDWPipingPortToPipeLines

Quick Find menus are provided for all objects but the less common ones are available
under Find > Consolidated Data > Other as per the following example:
Loading the Demonstration Model

Details on loading the files and settings are located in web.config. More information on the
web.config file is covered under the section Configuring SmartPlant Foundation to Use the CDW
(on page 35).

Index
The Consolidated Data Warehouse Object •
A 8
The Mapping • 39
Authoring Relationship Processing • 22 The Model and the Mapping • 37
The Published Document Supporting CDW
C Schema • 13
CDW Customization • 24
CDW Demonstration Model • 37
Classification Handling • 22
Configuring SmartPlant Foundation to Use
the CDW • 35
Configuring the CDW Model and Mapping •
33
Configuring to Expose Consolidated Data •
35
Consolidated Data Warehouse Model • 13
Consolidated Data Warehouse Overview • 7
Consolidation Implementation and
Customization • 21
Consolidation Implementation Basics • 21
Correlate by Name • 28
E
Exposing the CDW Data • 39
H
How to Configure the CDW • 33
M
Map Functions • 23
Mapping Authoring Relationships to the
CDW • 19
Migration from Shared Object to CDW • 12
P
Preface • 5
S
Summary of the Shared Object Technology
•7
T
The CDW Mapping Schema • 18
The CDW Object Schema • 14

Smartplant Foundation: How To Configure The Consolidated Data Warehouse

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Smartplant Foundation: How To Configure The Consolidated Data Warehouse

Uploaded by

Copyright:

Available Formats

SmartPlant Foundation

How to Configure the Consolidated Data

Consolidated Data Warehouse Overview ................................................................................................. 7

Consolidated Data Warehouse Model ..................................................................................................... 13

Consolidation Implementation and Customization ............................................................................... 21

How to Configure the CDW....................................................................................................................... 33

CDW Demonstration Model ...................................................................................................................... 37

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 3

The Mapping ......................................................................................................................................... 39

4 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

SmartPlant Foundation Product Documentation

Model Configuration Guides

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 5

6 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

Consolidated Data Warehouse Overview

What do you want to do?

Summary of the Shared Object Technology

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 7

The Consolidated Data Warehouse Object

8 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

 Query menus are fully supported.

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 9

 In addition to consolidating properties or relationships from published objects, the CDW

 Navigation to the related published objects, viewing inconsistencies, and running

10 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 11

Migration from Shared Object to CDW

12 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

Consolidated Data Warehouse Model

What do you want to do?

The Published Document Supporting CDW Schema

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 13

The CDW Object Schema

14 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

The Base CDW Object Schema

Functionality Configured on ISPFCDWObject

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 15

Functionality Configured on ISPFCDWClassifiedItem

Additional interfaces on CDW SPFCDWInstrument

16 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

Name Description Set On

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 17

The CDW Mapping Schema

18 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

Additional Map Filtering

Mapping Authoring Relationships to the CDW

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 19

Authoring Relationship Model

20 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

Consolidation Implementation and

What do you want to do?

Consolidation Implementation Basics

The consolidate process is split into two parts:

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 21

Authoring Relationship Processing

22 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

Map Function Model

OOTB Map Functions

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 23

Map Function Implementation

24 SmartPlant Foundation How to Configure the Consolidated Data Warehouse

The Consolidation Process

SmartPlant Foundation How to Configure the Consolidated Data Warehouse 25