The CommonPartDefinitions.xls workbook defines the acceptable values for common part attributes in the Catalog. The workbook is delivered to the [Product Folder]\ShipCatalogData\BulkLoad\DataFiles\StructManufacturing folder and is bulkloaded into the Catalog.
Custom Interfaces Sheet
The CustomInterfaces sheet allows you to load a custom schema into the metadata of a catalog. This sheet defines the customized user interfaces and attributes (properties) for the part classes in the workbook.
When you bulk load a workbook, the software looks at each attribute on the class sheets and uses the Custom Interfaces sheet to decode the information. When an object uses a single attribute from an interface, the object also inherits all the attributes for that interface, regardless of whether the object uses the other attributes.
The outcome of bulk loading a Custom Interfaces sheet is the GUIDs sheet. The Bulkload utility creates the GUIDs sheet if you are bulk loading a workbook for the first time. Successive attempts to load the workbook attempt to reuse the GUIDs available on the GUIDs sheet.
An interface is a collection of attributes. A complete interface definition includes one or more attribute names with associated data type, unit type, and optional symbol parameter. An attribute with the same name can exist on more than one interface. On a part class sheet, you can scope the attributes based on their interfaces and symbol parameters. The scoping syntax is Interface::UserAttribute<Symbol Parameter>. For example, for a part class Vessel, the attribute Length is a property of an Interface IJUAVessel and the symbol parameter is H. In a part class Tank, the user attribute Length is a property of an Interface IJUATank and the symbol parameter is L. Then, the complete definition of the attribute in each part class is IJUAVessel::Length<H> and IJUATank::Length<L>.
If the attribute name is unique (that is, the attribute is not shared with another interface), you only need to type the attribute name and symbol parameter on the class sheet. In the preceding example, you can type Length<H> in this case. If the attribute name is unique and the default symbol parameter is the same on the Custom Interfaces sheet and on the class sheet, then you only need to type the attribute name on the class sheet: Length.
When you are adding a new part class that uses custom interfaces, regardless of whether the custom interfaces already reside in the Catalog database, you must still include the definition of the custom interfaces for the part class on the Custom Interfaces sheet. This Custom Interfaces sheet must reside in the same workbook as the part class that you are bulk loading.
You can use the Systems.xls workbook in the [Product Folder]\CatalogData\BulkLoad\SampleDataFiles folder as a sample when you want to add customized attributes to certain objects.
An example is adding attributes to pipe runs.
InterfaceName
Specifies the custom interfaces, which are property sets. Start each interface name with IJUA. For example, if you want to define a new interface called CentrifugalPump, name the interface IJUACentrifugalPump. You should not change system-defined interfaces, which start with IJ.
CategoryName
Specifies the category for the custom interface. System-defined interfaces (starting with IJ) are in the Standard category by default.
The purpose of the category is to filter the grid on the Properties dialog box and to assist in reporting queries. When you are working on a part in the model, you can view the categories on the General or Occurrence tab of the Properties dialog box. All attributes in IJ interfaces appear in the Standard category, while the attributes in IJUA interfaces appear in their specified categories.
AttributeName
Specifies the attributes available for the part classes in the workbook. The names cannot have any blanks or special characters.
The attribute name is the UserAttribute component in the syntax Interface::UserAttribute<Symbol Parameter>. If the attribute name is unique throughout the catalog's interfaces, then you do not need to specify the Interface:: portion of the syntax statement.
AttributeUserName
Provides an easily readable name for the attribute. This name is optional and can include blank spaces. When you view a Properties dialog box or build a report query for an object, you see attribute user names, not attribute names.
Attribute user names do not need to be unique within the model.
Type
Specifies the data type for each attribute. For example, many attributes are associated with the Double data type, which is used for real numbers. Available data types include Bit, Char, Double, Short, Long, Number, Single, and String. Double and Char are the two most often used.
UnitsType
Specifies the unit type, which is defined in the software. If there is no unit type, you can leave this cell blank or type 0. The unit types are defined in the Core component of the software. For more information, see Appendix: Units of Measure in the Reference Data Guide.
PrimaryUnits
Specifies the units for the attribute. If there is no primary unit, you can leave this cell blank or type 0. Like unit types, primary units are defined in the Core component of the software. For more information, see Appendix: Units of Measure in the Reference Data Guide.
Primary units are the default units for a particular attribute if you do not specify units in the software. For example, if you only type a number for the pump flow rate on a class sheet without specifying units, the units are whatever you specified in the PrimaryUnits column for the flow rate attribute.
CodeList
Specifies a codelist for the attribute. If you want the attribute to use a codelist, type the name of the codelist in this column; otherwise, leave the column blank. The names of the codelists are listed in the "Head" line on each sheet in the AllCodeLists.xls workbook. On part sheets that use the codelisted attribute, specify the numerical value from the codelist.
For example, if you want to use a codelist for the end preparation attribute, type EndPreparation in the CodeList column on the Custom Interfaces sheet. Then, on a part sheet that uses this attribute, type 301 to indicate male ends, welded with beveled end.
Do not type a 0 in the Codelist column. Leave it blank if there is not a codelist for the attribute.
CodeListTableNamespace
Specifies the namespace of the codelist.
The CodeListTableNamespace column is presented as a sample on the Custom Interfaces sheet in the StructHandrails.xls workbook. One namespace is called REFDAT. For user-defined codelist tables, the namespace is UDP. For more information, see Select List (Codelist) Namespaces.
OnPropertyPage
Specifies whether the attribute is listed on the Properties dialog box for the part class. You can type TRUE or 1, or FALSE or 0 in this column. This column exists because you might want to prevent some attributes from being visible on the Properties dialog boxes.
ReadOnly
Specifies if the attribute is read-only on the interface. Attributes that are not read-only are generally occurrence attributes, which are marked with oa: beside their names on the part class sheets in the class definition section. For more information about occurrence attributes, see Controlling Access to Attributes in the Reference Data Guide.
SymbolParameter
Specifies a default symbol input parameter that the interface uses to drive the symbol. The symbol parameter names cannot have any blanks or special characters.
The symbol parameter name is the <Symbol Parameter> component in the syntax Interface::UserAttribute<Symbol Parameter>. If the symbol parameter name on the Custom Interfaces sheet is the same as the symbol input variable in the Visual Basic project, the Solid Edge assembly file, or the Symbol 2D cross section, then you do not need to specify the symbol parameter portion of the syntax on the class sheet.
If an attribute is used for naming rules only and is not used in a symbol, then you can leave the SymbolParameter column blank.
Custom Class Interface List Sheet
The CustomClassInterfaceList sheet maps interfaces to classes. Each interface and class must already exist in the Catalog schema database. During processing, the Bulkload utility relates the custom-defined virtual interfaces to the specified non-virtual, system classes. The utility does not recognize any of the bulkload update modes and does not create new interfaces or classes while scanning this sheet.
Class Name
Lists the name of the non-virtual class.
Interface Name
Lists the name of the custom virtual interface.
Naming Rules Sheet
The Naming Rules sheet defines rules for naming objects in the software.
Whenever you add new naming rules to the workbook, you must bulk load the workbook
in order for the new naming rules to appear in the software.
Type Name
Specifies the internal class names of objects. This name appears in the Catalog hierarchy in the Naming Rules folder.
Name
Specifies the rule name. You can use the same naming rule for more than one object type.
Solver Prog ID
Provides the identifier for the Visual Basic program that controls the rule. For more information about defining the VB programs for naming rules, see the Intergraph Smart 3D Programmer's Guide.
The following table shows an example of the Naming Rules sheet.
This worksheet is associated with the CPNameRules VB project. For more information,
see CPNameRules.vbp.
ClassNode Type Sheet
The ClassNodeType sheet defines the folder object names and corresponding user interface names.
ObjectName
Specifies the object name of a classification folder. Use this name when you reference the node on other sheets, such as the R-ClassNodeDescribes sheet. This name must be unique in the Catalog.
Name
Specifies the user interface name of a classification folder. This name appears in the Catalog task user interface and does not need to be unique in the Catalog.
R-ClassNodeDescribes Sheet
The R-ClassNodesDescribes sheet maps the classification folder names to the part classes. For example, the delivered Cabling.xls workbook lists a classification folder called CablesNode. A classification folder can have one or more part classes. The CablesNode classification folder is associated with the Power Cables, Communication Cables, Radio Frequency Cables, Fiber Optic Cables, and Hybrid Cables part classes on the R-ClassNodeDescribes sheet.
All children of a classification folder must be part classes. You cannot mix part
classes with folders beneath a classification folder.
RelationSource
Specifies the classification folder name. This name is the object name in the ObjectName column on the ClassNodeType sheet. This name must be unique in the Catalog. For more information, see ClassNodeType Sheet in the Reference Data Guide.
RelationDestination
Specifies the part classes associated with the classification folder name. Part class names are the same as sheet names in the workbook and must be unique in the Catalog. When you select a part class folder in the Catalog task, you see the contents (parts) in the right pane of the window.
CatalogRoot Sheet
The CatalogRoot sheet defines the root folder for the data in a workbook. The catalog root is the highest allowable level in the hierarchy for a discipline. For example, the Cabling.xls data is stored in the Cable root folder in the Catalog task.
Available roots are listed on the Catalog Root sheet in the AllCommon.xls workbook.
Name
Specifies the name of the root folder for that workbook. There cannot be a blank space or special characters in the name of the root folder.
R-Hierarchy Sheet
The R-Hierarchy sheet maps parent and child relationships between folders in the Catalog hierarchy. For example, in the Equipment.xls workbook, one of the parents is CatalogRoot. The child associated with CatalogRoot is RefDataEquipmentRoot.
These folder names are object names, not names that appear on the user interface. These names must be unique in the Catalog.
A parent folder can have any number of children. However, a child folder can only have one parent. A familiar example is the hierarchy of folders in Windows Explorer.
RelationSource
Specifies the parent object names.
RelationDestination
Specifies the children object names.
The R-Hierarchy sheet specifies relationships between all parent and children folders, except part
classes and the classification folders right above the part classes in the hierarchy.
These folders are related on the R- ClassNodeDescribes sheet.
GUIDsSheet
The GUIDs sheet contains Globally Unique Identifiers, which are registry identifiers. The GUIDs are visible only in the Excel workbooks; the GUIDs do not appear on the user interface in the software.
GUIDs create a connection between part classes in reference data and the occurrences created in the model from those part classes. For example, when you delete a part class, redefine it, and bulk load the new definition, you should keep the old GUID if you want any previously-created occurrences in the model to be connected to the new part class definition in reference data.
GUIDs are also used when you bulk load a spreadsheet to another, new catalog. The GUIDs for the objects in the new catalog are exactly the same as those in the original catalog.
The GUIDs sheet records the GUIDs used when bulkloading the spreadsheet the first time. This sheet is specific to a particular workbook and contains only those GUIDs of the user classes and interfaces in that workbook.
GUIDs are stored so that you can replace a Catalog database during a project. The replacement catalog must have the same name and location as the previous catalog. The GUIDs sheet prevents a replacement Catalog database from causing existing models to become invalid. If the GUIDs were not saved, this situation would be impossible because the Catalog and Model databases share the same schema.
Two utilities generate GUIDs: the Database Wizard and the Bulkload utility. The Database Wizard generates GUIDs when creating the Catalog database set from the delivered catalogdb.dat (for MSSQL) or catalogdb.dmp (for Oracle) file. The Bulkload utility generates GUIDs when creating a new Catalog database set using the New mode. When the Bulkload utility creates new GUIDs, it uses Excel to write these values to the workbooks.
The catalogdb.dat (for MSSQL) or catalogdb.dmp (for Oracle) template files contain
sample Smart 3D reference data and, while they contain many useful examples, they are not certified
for production use by Hexagon PPM.
After you have bulk loaded a catalog using Excel workbooks, you must not modify the GUID entries in the workbooks used to create the live database. Only the Bulkload utility should change data on a GUIDs sheet that is linked to a live Catalog database.
You must not manually modify any generated GUIDs.
Class/InterfaceName
Lists the part class names and interface names of the classes defined in the workbook. Custom interfaces are defined on the Custom Interfaces sheet.
PackageName
Lists the packages, if applicable, for the class and interface names.
GUID
Contains GUIDs for the part class occurrences and interface occurrences in the model. The software identifies an occurrence by this GUID when you place an object in the model.
AttributeName
Lists the user attribute names. This column is applicable only to those user interfaces for which user attributes have been defined. The column is empty for user classes.
DispID
Lists the DispIDs for the user attributes. This column is applicable only to those user interfaces for which user attributes have been defined. The column is empty for user classes.
The AttributeName and DispId columns are necessary for achieving metadata consistency between multiple catalogs.
CommonPartDef
This worksheet includes the common part definition criteria bulkloaded into the Catalog. This worksheet is associated with the CPComparisonRules VB project. For more information, see CPComparisonRules.vbp.
Definition Section
PartClassType
The part class type definition as defined on the PartClassTypes sheet of the AllShipCodeLists.xls workbook. Do not modify.
UserClassName
The user class name.
OccClassName
The occurrence class name.
Head Section
Name
Name of the object as it appears in the Catalog task.
Description
Description of the object.
Type
Code list value for the type.
CommonQuery
CommonObjects
Type of part being compared
CommonCriteria
Criteria to validate if two parts are common. This section checks for common factors.
RelationSemantic
The name of the ProgID containing criteria to validate if two parts are common. This section checks for relation factors.
SelectionExclustion
The name of the ProgID containing criteria to validate if two parts are common. This section checks for exclusive factors such as different materials or cross-sections.