Adding a Custom Schema

Custom SMF files should only contain changes from the out-of-the-box SMF file. They should not include duplicate copies of all the administrative objects. Use the Add or Exclude sub-nodes for each administrative type. For example:

- <SchemaManifest>
   <ApplicationName>CustomApplication</ApplicationName>
   – <attribute>
      <Add>
         attribute_PartType
         attribute_PartNature
      </Add>
      <Exclude>
         attribute_PartClass
         attribute_PartSubclass
      </Exclude>
   </attribute>
   ...

In the above example, two attributes are added to the Custom Application, and two attributes (that already existed or were to be added by a different XML manifest file) are excluded (will not be installed).

For each item to be added, you need a Schema Definition File. Items to be excluded are not installed. However, if they already exist in the database they are not removed.

The <ApplicationName> node value from the SchemaMapping file must have a matching <Name> entry in the SchemaMapping.xml file.

If you want to add a custom schema or change the order or prerequisites of the schema, you need a custom SchemaMapping file. This file is named SchemaMapping.xml and is located in the CustomSchema\SchemaManifest\ directory. This file has a SchemaManifest node for each application with a corresponding Custom SMF file, or a node for each out-of-the-box SMF file that you want to customize. The custom SchemaMapping.xml file must follow the same syntax as the out-of-the-box SchemaMapping.xml file.

For example, the following SchemaManifest node is for a new custom application to be installed:

<SchemaManifest>
   <Name>Custom Application</Name>
   <FileName>SchemaManifest_CustomApplication.xml</FileName>
      <Order>2</Order>
      <Display>Yes</Display>
      <Conversions/>
      <PreRequisiteSchema/>
   </SchemaManifest>

In this node:

• The Custom Application must be defined in the SchemaManifest file name SchemaManifest_CustomApplication.xml, which must be in the CustomSchema\SchemaManifest\ directory.

• "Custom Application" will be the second schema choice listed in the schema chooser.
• No conversions need to be run to support the schema.
• The schema does not have any prerequisites.

The next node example modifies the Application Common schema, so that it becomes a choice to be installed. Normally, this schema is automatically installed when a BPS schema is installed without being a choice in the schema list.

<SchemaManifest>
   <Name>Application Common</Name>
   <FileName>SchemaManifest_AppsCommon.xml</FileName>
   <Order>3</Order>
   <Display>Yes</Display>
   <Conversions/>
   <PreRequisiteSchema>Business Process Services</PreRequisiteSchema>
</SchemaManifest>

In this node:

• The SchemaManifest_AppsCommon.xml file is in the SchemaManifest\ directory (not the CustomSchema\SchemaManifest\ directory).
• Application Common will be the third schema choice in the schema installer.
• No conversions need to be run to support the schema.
• ENOVIA Business Process Services schema are selected for installation (if not, the Application Common schema will not display in the schema list).

The last node is an example of removing out-of-the-box schema. Setting the Remove flag to "Yes" specifies that schema needs to be removed from the install list.

<SchemaManifest Remove="Yes">
   <Name>All Applications</Name>
   <FileName>SchemaManifest_BusProcApps.xml</FileName>
   <Order>4</Order>
   <Display>Yes</Display>
   <Conversions>BusProcAppsConversion.xml</Conversions>
   <PreRequisiteSchema>Business Process Services</PreRequisiteSchema>
</SchemaManifest>

You may want to remove a schema manifest to make sure it will not be installed. In the above example, the "All Applications" prompt (console mode) or checkbox (GUI mode) will not display, so user cannot accidentally install it.

When the SchemaInstaller runs, it merges the schema listed in the out-of-the-box SchemaMapping.xml file (in the SchemaInstaller\SchemaManifest\ directory) with those listed in the custom SchemaMapping.xml file (in the CustomSchema\SchemaManifest\ directory) to build the list of schema choices for installation.

Using the above example nodes as the custom schema manifest, the SchemaInstaller shows the following list of schema:

• ENOVIA Business Process Services
• Custom Application
• Application Common

ENOVIA Business Process Services is defined in the out-of-the-box SchemaMapping file; "All Applications" was removed by the custom mapping file; Custom Application was added by the custom mapping file; and Application Common, which is normally installed but not displayed in the list, is displayed based on the custom mapping file.

Note: The <Order> node must be unique. If more than one node has the same order number, only one of the options can be presented during installation.

For a new schema to be added, the custom SDF files must use the exact same format as the out-of-the-box files. However, if you want to modify an existing schema, you only need to include the changes. For example:

<SchemaDefinition>
   <AdminType>type</AdminType>
   <OriginalName>Part</OriginalName>
   <SymbolicName>type_Part<</SymbolicName>
   <VersionHistory Version="9-2-0-0" Skip="Yes">
      <CommandInfo>
         <Command Type="MQL">
            <![CDATA[
                     modify type "<SYM>type_Part</SYM>
                      add trigger changeowner action
emxTriggerManager input "TypePartChangeOwnerAction"
             ]]
         </Command>
      </CommandInfo>
   </VersionHistory>
</SchemaDefinition>

When custom SDF files are in place, the schema installer merges the changes with the out-of-the-box definition giving the custom file first priority:

• If a custom SDF has a Skip flag set, the whole version installation is skipped.
• If both SDF files have VersionHistory nodes for the same version, the section from the custom SDF is used.
• If the custom SDF has additional VersionHistory, it is processed.

When the installer builds the list of SDF files to install, it uses both the out-of-the-box and the custom schema manifest and schema mapping files to determine which SDFs will be in the list.

For example, the installer builds a list of what to install based on the SchemaMapping.xml and SchemaManifest files in the SchemaManifest directory. Then, the installer looks at the custom SchemaMapping.xml file, which includes the following node:

<SchemaManifest>
   <Name>Custom Application</Name>
   <Filename>SchemaManifest_CustomApplication.xml</Filename>
      .
      .
      .
</SchemaManifest>

The installer then looks in the SchemaManifest_CustomApplication.xml file (in the CustomSchema\SchemaManifest\ directory). That manifest file must have the <ApplicationName> node defined as "Custom Application."

The custom schema manifest file contains the following attribute nodes:

- <SchemaManifest>
   <ApplicationName>Custom Application</ApplicationName>
   - <attribute>
      <Add>
                     attribute_PartType
                     attribute_PartNature
      </Add>
      <Exclude>
         attribute_PartClass
         attribute_PartSubclass
      </Exclude>
   </attribute>
   ...

The installer then adds the schema definition files for the PartType and Part Nature attributes. (Any custom attributes to be added must have SDF files in the CustomSchema\SchemaDefinition\ directory.) The installer then removes from the list the Part Class and Part Subclass attributes, which were added to the list by another schema manifest file.