21 March 2016

1. Configuration Scenarios

This section details step-by-step how to perform certain types of configurations.

The examples below uses filters/configuration objects stored in the database. It is recommended to use XML files instead.

1.1. Define a new filter

Scenario: We want a filter where documents are not included.

  1. Define the filter (substitute correct creator password) in MQL:

    set context user "creator" password ""; +
    set workspace user "Global User"; +
    add filter "Baselined Parts" appliesto relationship type "XBOM Baseline Part";
  2. Add the new filter to a view in ENOVIA

    image
    Figure 1. Adding a filter to a view
  3. Ensure the filter chooser is visible in the corresponding Page Configuration:

    image
    Figure 2. Resetting Visible-Filter setting on a Page Configuration
  4. Update filter definitions for all users

    image
    Figure 3. Managing filters on the view objects
    Any filters that operate on the XBOM structure should include XBOM Baseline Part and/or XBOM Baseline Doc in order to be able to navigate the structure. You cannot simply navigate objects connected to the EBOM structure when starting out navigating the XBOM.
  5. Page is updated

    image
    Figure 4. Filter selector with new filter

1.2. Make engineering baselines single-level by default

Scenario: The engineering baselines should only document the level immediately below the active object

  1. Update Command in Business

    ${ROOT_DIR}/tvc-action/createXBOM?type=type_XBOMEngineeringBaseline&policy=policy_XBOMEngineeringBaseline&level=1&freeze=true
    image
  2. Reload cache in web application

    image
    Figure 5. Reloading the cache

1.3. Change the name of Manufacturing Baselines to Builds

Changing the name of a type is easily done in Business due to the technique with symbolic names, simply access the type and change the name. In addition, some of the command labels also include the name of the type we are working with.

image
Figure 6. Updating type name on Listing page
image
Figure 7. Updating type name on Structure page

1.4. Adding a new baseline purpose

The different purposes of the baseline are defined via an attribute on the Manufacturing Baseline type.

Scenario: We want to add an As Customized option to our baseline types.

  1. Access the *XBOM Type* attribute in Business

    image
    Figure 8. Attribute edit panel
  2. Update the ranges

    image
    Figure 9. Range value edit panel
  3. Reload the cache and view the result in the interface

    image
    Figure 10. Create panel with new value

1.5. Change the table columns in an existing table

The tables are defined in business. When working with the baselines, it is not the actual objects being navigated, but rather the XBOM structure, and the attributes must be retrieved using expressions as detailed in previous chapter.

Scenario: We want to add the objects’ Product Make Buy Code to the MBL table

  1. Retrieve the table in Business and access the columns

    image
    Figure 11. Table edit panel in Business
  2. Add a column called Make/Buy, and Define the expression

    image
    Figure 12. Column edit panel in Business
  3. Update the cache, and view the change

    image
    Figure 13. Updated table display

1.6. Add a standard command to the menus

Commands are both general and object independent, or they will operate on the window’s main object, or they will operate on items selected in a list. When working with an XBOM structure, it is vital to remember that the objects in the table are actually the XBOM objects and not the EBOM objects whose attributes are displayed. Therefore, the most appropriate type of function is to work with the top object.

Scenario: We want to add an "Add to Collection" command in the list view

  1. Find the correct menu item

    image
    Figure 14. Menu object items list
  2. Find the desired command

    image
    Figure 15. Menu object item chooser
  3. Ensure it operates on a selected item in a table, and that it loads to an existing frame:

    image
    Figure 16. Command object’s settings
  4. Reload cache and view result in toolbar

    image
    Figure 17. Updated toolbar

1.7. Define a new type of comparison

The comparison that is provided OOTB use the part number and the find number as indexes. If there is a need for a different type of comparison, this can be achieved by modifying the page object named "XBOM Compare Configuration", which holds all settings for the compare function.

1.7.1. Comparison Configuration

The comparison configuration is as mentioned above stored in a page object called "XBOM Compare Configuration". This object contains XML data that defines one or more configuration. Each configuration defines how the comparison should be done.

When the user performs the comparison, the user can select (if multiple configurations exists) the desired configuration. In order to make the decision easier, each configuration should be given a human understandable name.

Below are some descriptions for how a configuration can be defined.

First of all, the basic layout of the XML looks like:

<Configurations>
    <Configuration>
        ...
    </Configuration>
    <Configuration>
        ...
    </Configuration>
    ...
</Configurations>

E.g. the top level element is "Configurations" and each configuration is placed within the "Configuration" element below this top level element.

Looking into a Configuration, the first thing to consider is for what type of objects this configuration applies to. This is configured via the "ForTypes" element as shown below:

<Configuration>
    <ForTypes>
        <Type>type_Part</Type>
    </ForTypes>

The next thing to specify is how the data in the structure should be expanded. Below is an example:

<ExpandSpec>
    <Direction>from</Direction>
    <RelationshipTypes>
        <Type>relationship_EBOM</Type>
        <Type>relationship_PartSpecification</Type>
    </RelationshipTypes>
    <RelationshipWhere></RelationshipWhere>
    <XBOMRelationshipTypes>
        <Type>relationship_XBOMBaselinePart</Type>
        <Type>relationship_XBOMBaselineDoc</Type>
    </XBOMRelationshipTypes>
    <XBOMRelationshipWhere></XBOMRelationshipWhere>
</ExpandSpec>

This section defines how the structure is expanded. Note that you must both specify how the XBOM baseline structure is expanded and how the real structure should be expanded. This is differentiated by using the "XBOM" prefix on the elements.

The next thing to consider is how the comparison tool should be able to identify one row in one structure with the matching row in the other structure. This is accomplished by defining so called "Keys".

The key is defined within the KeySpecs element, and each key is defined under the KeySpec element. An example is shown below:

<KeySpecs>
    <KeySpec>
        <RelationshipType>relationship_EBOM</RelationshipType>
        <RelationshipType>relationship_XBOMBaselinePart</RelationshipType>
        <Key relationship="true">$lt;attribute[attribute_FindNumber]&gt;</Key>
    </KeySpec>
    <KeySpec>
        <RelationshipType>relationship_PartSpecification</RelationshipType>
        <RelationshipType>relationship_XBOMBaselineDoc</RelationshipType>
        <Key>type</Key>
        <Key>name</Key>
    </KeySpec>
</KeySpecs>

The above configuration snippet defines that for EBOM connections, the "Find Number" attribute is the only part of the key.

For Part Specifications however, the key consists of "type" and "name" of the object.

The key is used to identify rows that has been added or removed from one structure.

Further on, in order to be able to detect modifications, in addition to finding removed/added rows, one need to define one or more fields that is being used for the comparison.

A field is defined within the Fields element, example is shown below:

<Fields>
    <Field>
        <Label>Type</Label>
        <Expression>type</Expression>
    </Field>
    <Field>
        <Label>Name</Label>
        <Expression>name</Expression>
    </Field>
    <Field>
        <Label>Rev</Label>
        <Expression>revision</Expression>
        <CompareUnless>
            <Relationship>relationship_EBOM</Relationship>
            <Relationship>relationship_XBOMBaselinePart</Relationship>
        </CompareUnless>
    </Field>
    <Field comparable="false">
        <Label>Descr</Label>
        <Expression>description</Expression>
    </Field>
    <Field relationship="true">
        <Label>F/N</Label>
        <Expression>$lt;attribute[attribute_FindNumber]&gt;</Expression>
        <CompareIf>
            <Relationship>relationship_EBOM</Relationship>
            <Relationship>relationship_XBOMBaselinePart</Relationship>
        </CompareIf>
    </Field>
</Fields>

The field should be given a "Label" and an "Expression". The expression is a standard ENOVIA selectable expression.

Moreover, the field could be used for display purpose only, and not being a part of the Comparison. In that case, add the "comparable" attribute on the Field and set it to false.

In addition, a field could be defined to be comparable only for certain relationship-types. This is accomplished by using the "CompareIf" or "CompareUnless" elements.

Finally, the configuration should be given a friendly name. This is done by:

<DisplayName>Standard Comparison</DisplayName>

The display name can be specified for multiple languages, like:

<DisplayName>Standard Comparison</DisplayName>
<DisplayName locale="de">...</DisplayName>
<DisplayName locale="sv">...</DisplayName>

Note that you should always specify a display name without a locale, as this will be used for any user that uses a language that hasn’t a corresponding display name.

1.7.2. Advanced Settings

Some additional settings exist in order to allow doing more advanced configurations.

  • Considering the Phantom attribute. This is configured like below:

    <Configuration considerPhantom="true | false">

    This can be used define if to consider if the phantom attribute has be set on a baseline object. When set to true, the comparison engine will (if a baseline is compared to the real structure) not process levels that has "Phantom = No".

    Default is true.

  • Showing multi level changes; e.g. also showing rows below added or removed rows as being added or removed. This is configured like below:

    <Configuration showMultiLevelChanges="value">

    Possible values are

    • always | yes | true

    • when-comparing-xbom-xbom

    • when-comparing-xbom-ebom

    • never | no | false

      The first and last value is self explaining. The other values results in that the "showMultilevelChanges" evaluates to true in the case when the user is expanding an XBOM structure against another XBOM structure, or in the second case when comparing an XBOM structure against the "real structure".

  • Editing of changes within the comparison result can be enabled. By default, there is a built-in table that can be used for this purpose. However, it is possible to override this and use a custom table by specifying the name of the custom table:

    <Configuration editTable="Name of table">

  • In some cases, when the comparison engine tries to match a row from the source structure with a row in the target structure, there might be multiple matches. This could typically happen if the data is not correct or for some other reason. You can specify how these rows should be treated. They can either be treated as being "invalid" or the comparison engine can match one of the rows and mark the others as being added. This is configurable through:

    <Configuration treatInvalidRowsAsAdded="true | false">

    The default value is true.

1.8. Extend baseline functionality to additional types of documents

The baseline functionality will traverse the Part Specification link to include documents. If the Part Specification link has been amended to include other types of documents than the OOTB CAD Model, CAD Drawing and Drawing Print, these new types can also be included in the baseline.

using a new type as a reference document will require other UI and policy updates not covered in this document. Doing this incorrectly can lead to follow-on errors in parts of Engineering Central, especially concerning Releasing and ECOs.
  1. Add the new type to the Part Specification relationship.

    image
    Figure 18. Part Specification relationship edit page
  2. Add the new type to the XBOM Baseline Doc relationship:

    image
    Figure 19. XBOM Baseline Doc Relationship edit page
  3. Verify that the XBOM Baseline Of relationship manages DOCUMENTS, and hence will not require updating.

    image
    Figure 20. XBOM Baseline Of relationship edit page
  4. An EBOM structure that contains the new type can now be baselined correctly, and includes the new type.

    image
    Figure 21. Baseline now includes the new type
Baselines are supporting PLMReference type objects.

1.9. Real time data in column

There can be a situation when it is needed to show basline data mixed with some real time data from Enovia database. To support this, a setting XBL Data can be configured on table columns to control whether the data should be pulled from xbom baseline or fetched from Enovia database.

<Setting name="XBL Data" value="false"/>

Default value of XBL Data is true, which means by default column data will be pulled from xbom baseline. Set XBL Data to false, if column data should be fetched from Enovia database.

Example -

	<Column>
	    <Name>Material Category</Name>
	    <Expression>$&lt;attribute[attribute_MaterialCategory].value&gt;</Expression>
	    <Label>Material Category</Label>
	    <RegisteredSuite>EngineeringCentral</RegisteredSuite>
	    <Setting name="XBL Data" value="false"/>
	</Column>
Columns showing real time data cannot be edited from XBL table. When using a custom datahandler, make sure cell values are also updated for empty non editable cells. When an object is deleted or connection is removed in Enovia database, no real time data will be shown for that row.
image
Figure 22. Column with real time data

1.9.1. Disable lazy loading

When column data is fetched from Enovia database, to avoid performance overheads, table column data is lazy loaded by default. Real time data from Enovia database is fetched as user navigates through pages for visible rows only. If it is desired that data for all rows should be fetched in one go, evaluation of current page only can be disabled by setting evalCurrentPage parameter to false in pageConfig.

<PageConfig>
    ...
    <Parameters>
		<Parameter name="evalCurrentPage" value="false" />
	</Parameters>

When baseline is opened via table link navigation, it can be set with parameter gothere:evalCurrentPage as shown below on baselines table pageConfig -

    <Parameters>
        <Parameter name="tableLinkFactory" value="com.technia.tvc.xbom.xbl2.util.BaselinesLinkFactory"/>
        <Parameter name="gothere:evalCurrentPage" value="false"/>
    </Parameters>