05 April 2016
© Copyright 2003-2019 by TECHNIA AB
All rights reserved.
PROPRIETARY RIGHTS NOTICE: This documentation is proprietary property of TECHNIA AB. In accordance with the terms and conditions of the Software License Agreement between the Customer and TECHNIA AB, the Customer is allowed to print as many copies as necessary of documentation copyrighted by TECHNIA relating to the software being used. This documentation shall be treated as confidential information and should be used only by employees or contractors with the Customer in accordance with the Agreement.
This product includes software developed by the Apache Software Foundation. (http://www.apache.org/).
When a product goes from the design phase to manufacturing, it can become necessary to manage multiple structure views depending on several factors, such as:
Production site
Prototype build
Maintenance level
The XBOM Manager provides a user interface to reconfigure the engineering build (EBOM) into a series of Manufacturing builds (As built, As planned, As maintained, etc). Also included is comparing and reporting functionality, to make use of the stored information in the coming designs.
The XBOM Manager manages two types of structures:
Engineering Baseline – a snapshot of the structure as it looks at the time of creation. This function can be used to document the state of the structure at various times before it is released, e.g. for different prototype builds.
Manufacturing Baseline – A reconfigured structure based on maintenance, different assembly orders at different plants, ad-hoc updates, etc. These structures typically will document the appearance of individual products, rather than the definition of them.
The XBOM Manager is built upon the TVC Structure Browser, and the full range of usability options from there is also available in this tool.
The XBOM Manager is used to create, update, and review alternate configurations of the bill of materials for different purposes. These structures are created on Parts and their subtypes, and can incorporate Parts and Documents. There are two principle types of structures – Engineering Baselines, which are snapshots and hence not changeable after creation, and Manufacturing Baselines, which can be restructured before they are locked.
Baselines are created from the review functions’ toolbars. A baseline can be created from scratch or as a copy of a previous baseline. The new baseline will get the same number as original part, but the revision will follow a format of AA, AB, AC…ZZ. The different Baselines (of the same kind) are all revisions of each other. This also goes for baselines of different revisions of the main part.
The Engineering and Manufacturing Baselines are viewed from via two functions that typically are found in the Part types menu. The baselines are listed in (configurable) tables providing the pertinent information about them.
When a baseline is accessed via one of the links on the main review page, its structure is revealed, and in the case of an unreleased Manufacturing Baseline, this can be edited. At the time of creation, it is a copy of the EBOM. The structure can be edited in the same way as any structure in the TVC Structure Browser – Build Structure and Disconnect, by in-cell editing (NOTE: Object attributes edited in this way will update the original structure objects as well, relationship attributes are only updated in the XBOM structure). In addition, there are special, XBOM specific functions accessible from this menu.
Once baselines are created, it is possible to compare them against each other or against the source structure that is the basis for them. The comparison is based on a configurable index or key, typically the find number and name for EBOM structures, and any or all attributes are compared, and differences are presented in a table form.
When the compare function is launched, a dialog is presented where the user must select a structure to compare against. Moreover, the user can define whether or not to compare one or multiple levels, and also select a particular type of comparison configuration. There might exist several types of comparison configurations, which performs the comparison differently (different set of attributes, or the structure might be expanded differently).
From the comparison result, there is functionality available to synchronize the structure. As an example: removing items being added or adding items missing in the structure.
To configure the comparison behavior, please take a look into this chapter.
The XBOM Manager includes the code package and specific tables, views, filters and commands to display these specific structures. The configuration of these is partly open to configuration, but a good understanding of the mechanisms behind the concept is needed in order to achieve the desired effects. Unlike with the basic structure browser, some of the configuration on these items defines part of the functionality. Updating these parameters without taking this into account may result in breaking of the functionality. The objects that compose the functionality are indicated in the chart below. (For more details about the usage of the different objects, refer to the Structure Browser Administration Guide)
when you create new administrative objects (e.g., commands, menus, system tables, types, attributes) you should not prefix their names with the letters TVC as that might cause naming conflicts upon upgrading to a newer version. |
The concept behind the XBOM structures is to create a parallel shadow structure to the main structure (in this case an EBOM structure).
The mechanism behind the structure is important to understand as it affects the definitions of the tables. The basics and attribute information is retrieved from the actual objects in the structure, but the relationship information is carried in the shadow structure. Therefore, in a typical table definition as below, some information will be retrieved from the objects in the EBOM structure, and some from the relationships between the shadow objects.
The columns in the orange fields are attributes and basics from the original objects, the columns in the green field are from the XBOM structure. This means that any update of the original object’s attributes will be visible on in the XBOM, e.g. when the top object is released, the state column will read "Release" instead of "Preliminary". It also means that tables designed for the EBOM structure cannot be reused for the XBOM. The expressions for retrieving the attributes and basics will be detailed below.
All the XBOM shadow objects are stored in a separate vault, and they therefore will not interfere with searches. The installation will prompt the setup of this vault in separate Oracle tablespaces (data and index), which is strongly recommended for performance reasons.
The XBOM functions are commonly launched from Commands. This section describes how to manage these commands.
Command and Menu objects can be created and modified with the Business Administrator and MQL thick clients; however, it is recommended that you use the Business Administrator if you are not familiar with MQL.
The database schema includes commands that correspond to four functions:
XBOM Engineering Baselines
XBOM Manufacturing Baselines
XBOM Doc Used In
XBOM Part Used In
The installation will add these to Parts and Documents, as needed:
The XBOM objects themselves have a menu, with three commands:
Lifecycle
History
Structure
Lifecycle and history are unchanged AEF functions, with access control guiding the ability to promote and demote the objects. The structure pages manage the functionality to navigate the structures and make changes.
Using VPLM roles? These roles need to be added to the appropriate commands and access needs to be added to the policies used by TVC XBOM (XBOM Baseline, XBOM Engineering Baseline and XBOM Manufacturing Baseline). |
Query string parameters appended to a URL consist of name-value pairs separated by an ampersand (&) while the entire query string is separated from the rest of the URL using a question mark (?). The following example is a relative URL to the JSP page /url/to/some/page where the query string parameters param1 and param2 have been appended. The value of param1 and param2 is value1 and value2 respectively.
/url/to/some/page?param1=value1¶m2=value2
Standard ENOVIA settings will of course operate on these commands as any others. Some of the most common ones are listed below.
Setting | Description | Accepted Values/Examples |
---|---|---|
Target Location |
This setting defines the target frame when executing the command. The value should be set to "content" to ensure that the Structure Browser is loaded in the correct frame. |
content popup listHidden |
Window Height |
The height in pixels of the popup window (if Target Location is popup) |
600 |
Window Width |
The width in pixels of the popup window (if Target Location is popup) |
700 |
Access Mask |
This setting determines whether or not the command will be displayed based on the user’s current access to the main object |
FromConnect,Modify,… |
Access Expression |
This setting lets you determine whether or not the command will be displayed or not based on other criteria than access, for instance an attribute value on the active type, details about the user, etc. |
|
RowSelect |
This setting will ensure that the command is dimmed unless a selection is made in the table below. The selected object(s) will be passed as request parameters to the called function |
Single|Multiple |
Confirm Message |
This function will both ensure that the function will not execute until the user has confirmed the action (suitable for Delete, disconnect functions), and also specify the wording of the message. |
"Do you wish to delete the selected object?" |
The launch functions for Engineering and Manufacturing Baselines are simple TVC tables with preset inquiries.
(For more information on configuring this type of TVC table, please refer to the Structure Browser Administration Guide).
This section will detail the input parameters and the default configuration that is done in the installation.
${ROOT_DIR}/tvc-action/execInquiryToTable
Table with URL parameters for configuring the XBOM Engineering Baselines command:
URL Parameter | Default Value | Description |
---|---|---|
pageConfig |
pageConfig=XBOM Engineering Baseline |
This page configuration primarily includes:
These can be added to, and the other normal page configuration settings may be modified. |
inquiry |
inquiry=XBOMEngineeringBaselines |
This inquiry will run a search based on a relationship expansion. This may be modified by additional criteria, such as a filter on attribute values. |
Table with URL parameters for configuring the XBOM Manufacturing Baselines command
URL Parameter | Default Value | Description |
---|---|---|
pageConfig |
pageConfig=XBOM Manufacturing Baseline |
This page configuration primarily includes:
These can be added to, and the other normal page configuration settings may be modified. |
inquiry |
inquiry=XBOMManufacturingBaselines |
This inquiry will run a search based on a relationship expansion. This may be modified by additional criteria, such as a filter on attribute values. |
${ROOT_DIR}/tvc-action/usedInConfigurations
Table with URL parameters for configuring the XBOM Doc/Part Used In commands
URL Parameter | Default Value | Description |
---|---|---|
pageConfig |
pageConfig=XBOM Used In Configurations |
This page configuration primarily includes:
This can be updated, and the other normal page configuration settings may be modified. |
The Engineering and Manufacturing Baselines are navigated in similar ways; their construction is identical. The distinguishing difference between the two is the number of actions that are possible to run – the manufacturing baseline can be modified after creation, the engineering cannot. The call is all but identical to both commands; the page configuration is the distinguishing item.
${ROOT_DIR}/tvc-action/navigateXBOM
Table with URL parameters for configuring the Engineering Baseline Structure command
URL Parameter | Default Value | Description |
---|---|---|
pageConfig |
pageConfig=Engineering Baseline Structure |
This page configuration primarily includes:
The toolbar and view updated as per usual. Of the custom parameters, only the showRelationshipTooltip setting is appropriate to configure. The configurationClass determines the pre-processing on the structure before expansion. Updating this requires deep knowledge of the functionality. |
Table with URL parameters for configuring the Manufacturing Baseline Structure command
URL Parameter | Default Value | Description | ||
---|---|---|---|---|
pageConfig |
pageConfig= Manufacturing Baseline Structure |
This page configuration primarily includes:
The toolbar and view updated as per usual. Of the custom parameter, only the showRelationshipTooltip setting is appropriate to configure. The configurationClass determines the pre-processing on the structure before expansion. Updating this requires this deep knowledge of the functionality.
|
The main actions are run from the Structure page as defined above. These actions are designed to update the structure, test different configurations, add placeholder items before the actual ones are available, and to run comparison functions. See XBOM User Guide for more information. All these functions except Build Structure require a selection in the table to be active.
${ROOT_DIR}/tvc-action/startBuildStructure
Table with URL Parameters for configuring the XBOM Build Structure command
URL Parameter | Default Value | Description |
---|---|---|
pageConfig |
pageConfig=XBOM Build Structure |
This page configuration primarily includes:
This page configuration covers the source side of the build structure window, which does not require specific XBOM tables and filters. |
buildStructureConfig |
buildStructureConfig=XBOM Build Structure |
This build structure configuration primarily includes:
Of these, only the last three should be configured. The
The relationships used must be the specified ones, so displaying the relationship chooser is only for information. |
${ROOT_DIR}/tvc-action/disconnectXBOM
The Disconnect function is specific to XBOM and does not take parameters. Reusing the Structure Browser’s variant will cause the wrong item to be disconnected. For this reason, the TVC Visible Disconnect button must be set to FALSE in the page configuration for the structure page, to avoid unexpected errors.
${ROOT_DIR}/tvc-action/replaceWithLatestReleased
Replace with Latest Released will find the latest released revision of the selected item, and let it take the place in the structure. This command, as well as the preceding Disconnect function, will display a confirmation box before executing. The management of this is done in the Commands settings table:
${ROOT_DIR}/tvc-action/splitQuantity
The Split Quantity command will make a duplicate connection of the selected item, with the exception that the quantity attribute is set to zero. The user must therefore have FromConnect and Modify access to the parent object to perform this operation.
${ROOT_DIR}/tvc-action/createPlaceHolder
Table with URL Parameters for configuring the Create Placeholder command
URL Parameter | Default Value | Description |
---|---|---|
type |
type=type_XBOMPlaceHolder |
This parameter must not be updated or the Move into Placeholder function will not work. |
The Create Placeholder function is used to regroup BOM objects, for instance into different assembly levels at manufacture. The XBOM structure will contain an assembly level that is not reflected in the EBOM structure.
${ROOT_DIR}/tvc-action/moveIntoPlaceHolder
Move into Placeholder does not take in parameters, but does require a selection in the table to be active.
${ROOT_DIR}/tvc-action/togglePhantom
Toggle Phantom will create/destroy the substructure under the selected item in the XBOM view. This substructure is created based on the EBOM structure. Toggling back will only remove the substructure if it is labeled as a phantom – that is, structures created with the original XBOM cannot be removed this way. You can run toggle command on any of the items that are created this way, to create substructures under them as well.
${ROOT_DIR}/tvc-action/initCompare
The compare function is configured via a configuration stored inside a page object with the name "XBOM Compare Configuration". This page object is an XML definition, containing all different kind of comparison configurations.
The example below shows a comparison configuration that applies to comparison with EBOM structures.
<Configurations>
<!-- Add comparison configurations here -->
<Configuration>
<!-- Defines the types, which this configuration is valid for -->
<ForTypes>
<Type>type_Part</Type>
</ForTypes>
<!-- Defines how structures should be expanded -->
<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>
<!-- Defines the key, which is used to identify a row in the structure. -->
<KeySpecs>
<KeySpec>
<RelationshipType>relationship_EBOM</RelationshipType>
<RelationshipType>relationship_XBOMBaselinePart</RelationshipType>
<Key relationship="true"><![CDATA[$<attribute[attribute_FindNumber]>]]></Key>
</KeySpec>
<KeySpec>
<RelationshipType>relationship_PartSpecification</RelationshipType>
<RelationshipType>relationship_XBOMBaselineDoc</RelationshipType>
<Key>type</Key>
<Key>name</Key>
</KeySpec>
</KeySpecs>
<!-- Defines the display name of this config -->
<DisplayName>Default</DisplayName>
<!-- Defines fields that should be displayed and included in the comparison -->
<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><![CDATA[$<attribute[attribute_FindNumber]>]]></Expression>
<CompareIf>
<Relationship>relationship_EBOM</Relationship>
<Relationship>relationship_XBOMBaselinePart</Relationship>
</CompareIf>
</Field>
</Fields>
</Configuration>
</Configurations>
${ROOT_DIR}/tvc-action/hide
The Hide function will conceal the selected objects and their substructures from the structure browser. This is useful in large structures where all parts are not relevant at once. If there is a column using the function XBOMTableFunctions.hasHiddenChildren, the parent of the (top) hidden object will be indicated with an icon in this column.
The commands for creating, copying and deleting baselines are found on the page where the existing baselines are created.
Baseline interface
${ROOT_DIR}/tvc-action/createXBOM
Table with URL Parameters for configuring the Create Engineering/Manufacturing Baseline command
URL Parameter | Default Value | Description |
---|---|---|
type |
type=type_XBOMEngineeringBaseline type=type_XBOMManufacturingBaseline |
This will control the type of baseline create, and by extension, the attributes displayed in the window. The *Type* field in Figure 18: Create Manufacturing Baseline interface does not apply to Engineering Baselines. |
policy |
policy=policy_XBOMEngineeringBaseline policy=policy_XBOMManufacturingBaseline |
This controls the lifecycle of the created baseline. |
level |
level=100 |
This controls how many levels the baseline is created for. If no value is provided (as for Manufacturing Baselines), the value 1 is used – this corresponds to the selected part and its children and specifications. The value 100 is selected for Engineering Baselines to create a structure including all levels. This number can be adjusted for performance reasons, if the structure allows it. |
freeze |
freeze=true |
This parameter controls whether the structure should be released directly upon creation, such as in the engineering baseline. If nothing is provided, it is set to false. |
interface
${ROOT_DIR}/tvc-action/copyXBOM
Table with URL Parameters for configuring the Copy Engineering/Manufacturing Baseline command
URL Parameter | Default Value | Description |
---|---|---|
type |
type=type_XBOMEngineeringBaseline type=type_XBOMManufacturingBaseline |
This will control the type of baseline create, and by extension, the attributes displayed in the window. The *Type* field in Figure 19: Copy Manufacturing Baseline interface does not apply to Engineering Baselines. |
policy |
policy=policy_XBOMEngineeringBaseline policy=policy_XBOMManufacturingBaseline |
This controls the lifecycle of the created baseline. |
level |
level=100 |
This controls how many levels of the baseline is copied. If no value is provided (as for Manufacturing Baselines), the all levels of the original are used. The value 100 is provided for Engineering Baselines so all levels of the structure are used. This number can be adjusted for performance reasons, if the structure allows it. |
freeze |
freeze=true |
This parameter controls whether the structure should be released directly upon creation, such as in the engineering baseline. If nothing is provided, it is set to false. |
allowCreate |
allowCreate=true |
The function will verify that there are other baselines (*Copy – Specific Revision* in Figure 19: Copy Manufacturing Baseline interface) to copy. If there are none, this option controls where the user can choose create a new baseline (allowCreate = true), or whether an error message is displayed (allowCreate = false). |
The Copy to Other Part function is available for Manufacturing Baselines only, and makes it possible to attach a created Manufacturing Baseline to another part than the one that originated it. A typical use for this is to copy baselines to other revisions of the part.
${ROOT_DIR}/tvc-action/beginSearch
Table with URL Parameters for configuring the Copy to Other Part command
URL Parameter | Default Value | Description |
---|---|---|
searchConfig |
searchConfig=XBOM Find Part To Copy Configuration To |
This search configuration features primarily:
This page configuration features:
In addition, the normal Page Configuration settings apply. The view may be extended or modified, others can be added here. The custom parameters should not be updated without a deep understanding of the functionality. |
${ROOT_DIR}/tvc-action/deleteXBOM/foo.jsp
The Delete function requires a confirmation message before it is activated .
For configuration management purposes it is important to note that if the latest baseline on a given structure is removed, the next one created will bear the same revision label as the one deleted. If this is not wanted, an alternate option is to use the Obsolete state in the baseline lifecycle.
Edit Details is called from the main properties page of the baseline. It uses the standard Matrix forms page and a customized form object. The same form also defines the view page – the same attributes that are shown in the properties page can be edited. The URL for the properties page is defined as the link on the menus for Engineering and Manufacturing Baselines.
$\{COMMON_DIR}/emxForm.jsp
Table with URL Parameters for XBOM View and Edit Details command
URL Parameter | Default Value | Description |
---|---|---|
form |
form=type_XBOMConfiguration |
The form defines the fields in the interface, and which ones are mandatory. Both types of baselines use the same form; an Access Expression setting on the *Type* field ensures that it is not displayed for Engineering Baselines. |
mode |
mode=edit |
Ensuring the values can be updated. Fields such as name in Figure 23: Edit Details interface must be defined as read-only specifically. This parameter is left out in the definition of the properties page. |
toolbar |
toolbar=XBOM Details Toolbar |
Contains commands for PDF rendering and help. |
A number of views are preconfigured and included in the installation of the components. For information about views, tables, filters, and configuration objects and how to set them up, refer to Structure Browser Administration Guide.
Table with views for the XBOM Manager functions
View Name | Description | Tables | Filters |
---|---|---|---|
EBL |
The view used for navigating the Engineering Baseline Structure. The table operates on the XBOM structure |
EBL |
XBOM From |
MBL |
The view used for navigating the Manufacturing Baseline Structure. The table operates on the XBOM structure |
MBL, MBL Detailed |
XBOM From |
XBOM Build Structure View |
The view used for the source objects when adding new parts and documents to the XBOM. The tables are not specific XBOM ones, but rather included in the Structure Browser package, and the filters do not operate on the XBOM relationships either. |
TVC Basic Information, TVC Simple, TVC EBOM |
From, EBOM From |
XBOM Engineering Baseline |
The view for the review page of the different engineering baselines |
XBOM Engineering Baseline |
|
XBOM Manufacturing Baseline |
The view for the review page of the different manufacturing baselines |
XBOM Manufacturing Baseline |
|
XBOM Used In Configurations |
The view for the Used in Baselines page |
XBOM Used In Configuration |
The installation also includes completed tables. These are tailored especially for the XBOM Manager functionality, taking into account the relationships between the original EBOM and its parts and documents, and the parallel XBOM structure.
When navigating the structure, the maroon relationships are followed, and the relationship attributes are retrieved from here, but object information is retrieved as needed from the blue ones. In a very simple case with the columns name, unit of measure, and quantity, the definition would be as follows:
to.from[XBOM Baseline Of].to.name
to.from[XBOM Baseline Of].to.attribute[Unit Of Measure].value
attribute[Quantity].value
All these operate on relationships (rather than business objects). Symbolic names may be used for relationship, type, and attribute names in the expressions.
Table below shows the tables provided with the XBOM Manager component.
Table Name | Description | Columns | Functions |
---|---|---|---|
EBL |
The table used for the Engineering Baseline Structure. The table operates on the XBOM structure |
Type, name, revision, state, description, find number, quantity, reference designator, unit of measure |
Actions (Files, documents), ECO |
MBL |
The simple table used for the Manufacturing Baseline Structure. The table operates on the XBOM structure |
Type, name, revision, state, description, find number, quantity, reference designator, unit of measure, sequence order, phantom |
Actions, Has hidden children, baselines |
MBL Details |
The detailed table used for the Manufacturing Baseline Structure. The table operates on the XBOM structure |
Type, name, revision, state, description, find number, quantity, reference designator, unit of measure, sequence order, phantom, operation sequence, effectivity date from, effectivity date to |
Actions, Has hidden children, baselines |
XBOM Baseline Doc |
The table containing the relationship attributes for updating when connecting a document to an XBOM structure |
Name, operation sequence, sequence order, effectivity date from, effectivity date to |
|
XBOM Baseline Part |
The table containing the relationship attributes for updating when connecting a part to an XBOM structure |
Name, operation sequence, reference designator, find number, sequence order, effectivity date from, effectivity date to, phantom, quantity |
|
XBOM Engineering Baseline |
The table of the listing of Engineering Baselines |
Name, revision, description, site, state, originated, owner |
Navigate XBOM |
XBOM Manufacturing Baseline |
The table of the listing of Manufacturing Baselines |
XBOM Type, name, revision, site, state, originated, owner |
Navigate XBOM |
XBOM Used In Configuration |
The table showing the baselines the part or document is used in |
XBOM Type, name, revision, site, state, originated, owner |
Navigate XBOM |
Filters are used to determine how the structures are expanded, and which items are included. The filters provided with the XBOM Manager primarily manage the navigation along the XBOM structure.
Table below shows the filters provided with the XBOM Manager component
Filter Name | Description | Filter Selection |
---|---|---|
Part Specification |
The filter used to find documents in the EBOM parts of the compare function |
Relationship = Part Specification Direction = from |
XBOM From |
The filter to navigate XBOM Structures (down) |
Relationship = XBOM Baseline Part, XBOM Baseline Doc, XBOM Baseline Placeholder, Direction = from |
XBOM To |
The filter to navigate XBOM Structures (up) |
Relationship = XBOM Baseline Part, XBOM Baseline Doc, XBOM Baseline Placeholder, Direction = to |
This section describes the toolbars provided. Toolbars are defined by Menus that contains Commands, where each Command defines an action available to the users. In addition, a toolbar can contain other Menus that are displayed as pull-down menus in the toolbar. Menus and Commands can be created and modified with the Business Administrator and MQL thick clients.
It is important to keep in mind the context the toolbar is used at – will it appear in a table or structure page, or will it contain single-object functions. For usability, it is best to manage commands of the same type in toolbars together.
Table below shows the Toolbars for the XBOM Manager functions
Name | Description | Included items | Where Used |
---|---|---|---|
XBOM Build Structure Toolbar |
A button in the build structure source side to run a new search |
TVC Build Structure New Search |
|
XBOM Configuration Structure Actions Toolbar XBOM Configuration Structure Toolbar |
Action dropdown with structure related functions |
XBOM Build Structure Search XBOM Disconnect XBOM Replace With Latest Release XBOM Quantity XBOM Create Placeholder XBOM Move Into Placeholder XBOM Toggle Phantom XBOM Compare Structure |
Not used |
XBOM Details Actions Toolbar XBOM Details Toolbar |
Action dropdown with single object functions |
XBOM Edit Details |
The properties pages for the baselines |
XBOM Engineering Baseline Actions Toolbar XBOM Engineering Baseline Toolbar |
Action dropdown with create-and-connect functions |
XBOM Create New Engineering Baseline XBOM Copy Engineering Baseline XBOM Delete |
The list page containing the engineering baselines for a given part |
XBOM Engineering Baseline Structure Actions Toolbar XBOM Engineering Baseline Structure Toolbar |
Action dropdown with structure related functions |
XBOM Compare Structure |
The structure page of an engineering baseline |
XBOM Manufacturing Baseline Actions Toolbar XBOM Manufacturing Baseline Toolbar |
Action dropdown with create-and-connect functions |
XBOM Create New Manufacturing Baseline XBOM Copy Manufacturing Baseline XBOM Delete XBOM Copy Baseline to Other Part |
The list page containing the manufacturing baselines for a given part |
XBOM Manufacturing Baseline Structure Actions Toolbar XBOM Manufacturing Baseline Structure Toolbar |
Action dropdown with structure related functions |
XBOM Build Structure Search XBOM Disconnect XBOM Replace With Latest Release XBOM Quantity XBOM Create Placeholder XBOM Move Into Placeholder XBOM Toggle Phantom XBOM Compare Structure XBOM Hide XBOM Unhide Children |
The structure page of an manufacturing baseline |
The page configurations make it possible to define which views, buttons, headers, and toolbars will appear on a list or structure page. The page configurations used in for XBOM Manager functions work the same way as those for the Structure Browser, with the exception that the structure pages in the XBOM pages are called with a specific URL:
${ROOT_DIR}/tvc-action/navigateXBOM?pageConfig=My Config&...
Table below shows the Page configurations for the XBOM Manager functions
Name | Description | Included views | Notes |
---|---|---|---|
XBOM Build Structure |
The page definition for the build structure source side |
XBOM Build Structure View |
TVC Visible Disconnect must be set to False TVC Visible Filter is recommended to be set to False |
XBOM Configuration Structure |
The common structure page definition for both baseline types |
XBOM View |
TVC Visible Disconnect must be set to False TVC Visible Filter is recommended to be set to False |
XBOM Engineering Baseline Structure |
The structure page definition for engineering baseline types |
EBL |
TVC Visible Disconnect must be set to False TVC Visible Filter is recommended to be set to False |
XBOM Manufacturing Baseline Structure |
The structure page definition for manufacturing baseline types |
MBL |
TVC Visible Disconnect must be set to False TVC Visible Filter is recommended to be set to False |
XBOM Engineering Baseline |
List page for Engineering Baselines |
XBOM Engineering Baseline |
|
XBOM Manufacturing Baseline |
List page for Manufacturing Baselines |
XBOM Manufacturing Baseline |
|
XBOM Find Part For Comparison |
Search page for Compare function |
XBOM Used In Configurations |
Note common view between this and "Used In Configurations" |
XBOM Find Part To Copy Configuration To |
Search page for "Copy Baseline to other Part" |
Part View |
Provided with Structure Browser |
XBOM Used In Configurations |
List page for included in function. |
XBOM Used In Configurations |
Note common view between this and "Find Part for Comparison" |
Search configurations contain a page configuration for the search result, and for definitions for the search panels. A normal search function will be called with the URL:
${ROOT_DIR}/tvc-action/beginSearch?searchConfig=My Config&...
Table below shows the Search configurations for the XBOM Manager functions
Name | Description | Included views | Notes |
---|---|---|---|
XBOM Find Part for Comparison |
The configuration for the compare function |
XBOM Find Part For Comparison |
The compare function is not called with the standard URL. |
XBOM Find Part To Copy Configuration To |
The configuration for the search for a part to attach the baseline to |
XBOM Find Part To Copy Configuration To |
Build structure configurations define (among other things) the search panel, the relationships involved and the display of source and target side functions of a build structure operation. The appearance of these is defined by separate page configuration items also included in the URL:
${ROOT_DIR}/tvc-action/startBuildStructure?buildStructureConfig=MyConfig&pageConfig=My Other Config&...
Table below shows the Build structure configurations from the XBOM Manager functions
Name | Description | Notes |
---|---|---|
XBOM Build Structure |
The configuration for the Build Structure search panel and connect side |
The allowed relationships must not be changed |
Two TVC number generators are provided but it is only relevant to configure the one controlling the place holders (the other, for the baseline objects, controls objects that will not be seen by the end user).
Please note that TVC Number Generator objects are used, not standard eService Number Generators.
Table below shows the Number Generators for the XBOM Manager functions
Type | Name | Revision | Generates type | Prefix | Suffix | Digits | Number |
---|---|---|---|---|---|---|---|
TVC Number Generator Settings |
type_XBOMPlaceholder |
A |
Placeholder objects |
PH- |
<none> |
7 |
Starts at 0 |
TVC Number Generator Settings |
type_XBOMBaseline |
A |
XBOM Baseline objects |
BL- |
<none> |
7 |
Starts at 0 |
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. |
Scenario: We want a filter where documents are not included.
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";
Add the new filter to a view in ENOVIA
Ensure the filter chooser is visible in the corresponding Page Configuration:
Update filter definitions for all users
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. |
Page is updated
Scenario: The engineering baselines should only document the level immediately below the active object
Update Command in Business
${ROOT_DIR}/tvc-action/createXBOM?type=type_XBOMEngineeringBaseline&policy=policy_XBOMEngineeringBaseline&level=1&freeze=true
Reload cache in web application
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.
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.
Access the *XBOM Type* attribute in Business
Update the ranges
Reload the cache and view the result in the interface
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
Retrieve the table in Business and access the columns
Add a column called Make/Buy, and Define the expression
Update the cache, and view the change
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
Find the correct menu item
Find the desired command
Ensure it operates on a selected item in a table, and that it loads to an existing frame:
Reload cache and view result in toolbar
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.
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]></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]></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.
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.
In some cases, each structure of a sub-assembly is needed to be treated independently within BOM like as-built or as serviced XBOM mode. In other words, it is needed that the structure of a sub-assembly shall be modified without impacting any other instance of the same sub-assembly in BOM. This can be enabled by using the As-Built feature in XBOM.
<AsBuilt>true | false</AsBuilt>
The default value is false.
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. |
Add the new type to the Part Specification relationship.
Add the new type to the XBOM Baseline Doc relationship:
Verify that the XBOM Baseline Of relationship manages DOCUMENTS, and hence will not require updating.
An EBOM structure that contains the new type can now be baselined correctly, and includes the new type.
Baselines are supporting PLMReference type objects. |
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>$<attribute[attribute_MaterialCategory].value></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. |
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>
XBL comparison result table can be configured to exclude column(s) for comparison.
Below setting can be added at table column level to exclude the column for comparison. By Default, this setting is true.
<Setting name="Comparable">false</Setting>
As a sample, below tables dispaly the scenario when column "desciption" is comparable and when it is not.
With description comparable:
Without description comparable:
Adding Comparable = false
setting in Description column as shown below, has excluded the column from comparison result.
<Column>
<Name>Description</Name>
<Expression>description</Expression>
<Label>Description</Label>
<Setting name="Comparable">false</Setting>
</Column>
As an alternative to the traditional baseline concept that exists in the XBOM component, there is also a feature that allows you to create more light-weighted baselines (called XBL).
While the traditional baselines creates several business objects and connections in the database, as every object in the baseline is represented by a business object and every connection by a connect in the database, the XBL feature just creates one object to represent the baseline as the actual data structure that the baseline represents is stored in a XML file that is checked-in to the baseline business object.
Even though the release 2010.3.0 introduced support for modifying an XBL structure, the normal usage of XBL is to use it as a snapshot tool.
The picture below illustrates how the XBL tool stores the data.
The benefits of using the XBL feature over the traditional baseline support in the XBOM manager component are:
Speed of creation: Since only one business object is created, the time to create a baseline will be shorter than a traditional baseline.
Creating a baseline doesn’t result in duplication of business object and connections for the whole structure. It’s cheaper, from a storage point of view, to hold the data in an XML file outside from the database.
The XBL baseline can be applied to any kind of structure, with just a few steps of configurations required. The traditional Baselining tool requires a larger effort, if to apply it on other kind of structures than EBOM structures.
Allows the user to perform comparisons and see changes in a structure from one day to another quick and easily.
A command is added to the database called "TVC XBL Show Baselines". This command can be attached to the category tree menu for any type. Once attached, it will allow the user to list the baselines that have been created for the object, as well as allowing the user to create a new baseline.
The MQL code below illustrates how to add this command to the Part category menu.
mod menu type_Part add command "TVC XBL Show Baselines";
You can add the command to the category menu for any type; however, you must ensure that the types you enable the XBL support for, should have at least one configuration allowing the user to create an XBL for the specific type of object in question.
Once the user clicks on the command, the baselines page is shown in the content frame as illustrated below.
The URL that is used to show the list of baselines is:
${ROOT_DIR}/tvc-action/xblShowBaselines
Baselines are created from the top object of the structure that is supposed to be "baselined".
By default, the created baseline will get the same number as the top object with the addition of a prefix that is based upon an auto-number generator. The revision will follow the format of A, B, C…Z. The different Baselines (of the same kind) are all revisions of each other.
You can override this behavior via the XBL configuration. See this chapter for details around the configuration format. |
Below is a screenshot showing the "create baseline dialog" in the side panel.
Once the baseline is created, the new baseline will appear in the table among the other baselines.
Viewing a baseline can be achieved in a couple of different ways. These are shown below.
The differences between these are described below:
If the baseline is opened in the same window (using the blue "go-there" button), this will look like:
If the baseline is opened in a popup window, this will be shown as:
If the name of the baseline is clicked, the baseline object is shown and inserter in the category tree to the left.
The navigate view is where the user can view the "baselined" structure information.
When viewing a Baseline that was set to support edit upon creation, some additional functions in the user interface will appear (the exact functions that will appear depends on the configuration).
Examples of those are:
Toggle edit mode
Disconnect button
Create Version (Stamp version)
This command is used to tag the current baseline. For example, after a set of modification, one might want to save the state of the structure in a version. This command will save a copy of the baseline in a new version.
List Versions
Used to list the versions created. Note that there will always be at least one version; since when the baseline is created a version representing the initial baseline is always present.
Show Changelog
Creates a PDF change log for the changes made in the baseline.
Edit Menu Contaning one or more commands for doing:
Build structure
Add, replace and move
Quick Connect
Disconnect
See this chapter for details how to configure and add commands that enables build structure-, quick connect- and disconnect operations.
Since the XBL data is stored in an XML file at the bottom line; some things needs to be considered when enabling edit mode in the table.
The columns in the table that should be editable must have been configured so in the table(s) used.
Use of Cell Editor’s should be done very carefully, as there is a risk that those cell editors are performing operations against the database using ID’s of objects or connections that no longer exist. It might be OK to use a cell-editor for validation of input values, but one should carefully review that such a cell editor itself isn’t doing anything against the database.
Custom Updaters will NOT be used in the XBL
When modifying a cell, the modified value is expected to be related with the expression defined in the column. When using custom data handlers, the values in the cell doesn’t need to origin from the expression. Hence, be careful to enable edit on columns whose values are retrieved via a data handler.
Baselines can be compared in a few different ways:
Against the source object (the object, which the baseline were created for)
Against other baselines of the source object
Against another revision of the source object
Against baselines of other revisions of the source object
Against object found by configurable search
Against baselines of object found
Against the multiple parents (the objects, which the baseline connected from)
Against baselines connected from multiple parents
Baselines compared against each other are restricted to be compared to other baseline created using the same source object, and using the same definition.
Comparing a baseline to a source object will make the comparison to use the same definition that was used to create the baseline.
Important to note here is that the "Result Table" selected will determine which data is actually compared. The columns in this table define what will be compared.
Any data that is not part of the selected table will not be compared. Added or removed rows will always be detected.
The comparison result indicates any added or removed row and possibly any modifications that have been done to a field in the table.
If you want to compare a baseline without the user input for selecting settings you can use an action called "/xblQuickCompare". This will launch a compare result where selected baseline will be compared against the source object. It will use the default table and settings for "multi level".
The behavior of this action can be configured using parameters to the action:
Name | Description | Possible values |
---|---|---|
objectId |
The object id for the baseline to compare against source structure |
Any baseline object id |
tableName |
Name of table to use for comparison |
Any table name that is valid for this comparison |
multiLevel |
Use Multi Level or not |
true/false |
When you show a traditional list of object, or a structure, there is a new column type defined that allows the user to directly get access to the baseline(s) related to the object in the table (if any). If the object has a baseline, an icon will be shown that, upon click, will load the related baselines into the side panel.
From the side panel, the user can start the comparison tool, open the baseline or simply delete it.
The column type is called: "xbl-baselines".
The screenshot below illustrates how this might look like:
The actions available on a baseline shown in the side panel are:
To configure the appearance of the baseline object item in the side-panel see this chapter.
The column type "xbl-baselines" is configurable through column settings.
Setting | Description | Possible values |
---|---|---|
Order By |
The property to sort the side-panel list items on |
Select macro example: Select example: originated |
Sort Order |
Control if to sort ascending or descending |
ascending, descending |
Example configuration:
<Column>
<ColumnType>xbl-baselines</ColumnType>
<Name>xbl-baselines</Name>
<RenderAsRowAction>true</RenderAsRowAction>
<Setting name="Required Components">xbom</Setting>
<Setting name="Searchable">false</Setting>
<Setting name="Order By">originated</Setting>
<Setting name="Sort Order">descending</Setting>
</Column>
To include recent changes in a baseline there is a renew command that deletes previous baseline definition and replaces it with a new one based on the same settings and input values.
The renew command is disabled by default and can be activated by copying
the file WEB-INF/tvc/xbom/xbl/menu/BaselinesToolbar.xml
into
WEB-INF/tvc-ext/xbom/xbl/menu/BaselinesToolbar.xml
and then uncomment
the line with RenewBaseline.xml
.
An XBL configuration can be added to either the page object called TVC
XBL Configuration
, or as a resource added to the web-application
(under /WEB-INF/tvc
). If stored as a resource, the name of the resource
type associated with an XBL configuration is "xblconfig".
Independent on if the XBL Configuration is stored in the page object or as a resource on the file system, the format of the configuration is identical. The only difference is that the page-object holds multiple configurations, while a file resource represents one single configuration.
When the XBL configurations are defined in the page object, the following format is used (note that this is required as the page object holds multiple configurations).
<XBLConfigurations>
<Configuration id="xbl-1">
...
</Configuration>
<Configuration id="xbl-2">
...
</Configuration>
<Configuration id="xbl-3">
...
</Configuration>
</XBLConfigurations>
It is important that each configuration is given a unique identifier. Otherwise you are not able to refer to the configuration. |
When storing the XBL configuration as a resource (file in the application), the format looks like:
<Configuration>
...
</Configuration>
The difference is that the root element is the "Configuration" element and you should not assign the Configuration an ID, as the id will be calculated from the name of the file.
This chapter explains and describes the format of the Configuration.
Below is a sample configuration were the important sections are highlighted and numbered. The section is described in details later on in this chapter. (Note that this particular example is not usable, it’s for explanation use only).
<Configuration>
<DisplayName>EBOM Example Baseline</DisplayName>(1)
<DisplayName locale="de">Deutsche name</DisplayName>
<Description>This is an example baseline configuration used to create baselines from an EBOM structure</Description>(2)
<Description locale="de">Dies ist ein beispiel Baseline-Konfiguration verwendet, um basislinien von einem EBOM struktur</Description>
<ValidFor>(3)
<Type>type_Part</Type>
<Policy>policy_ECPart</Policy>
<Policy>policy_DevelopmentPart</Policy>
</ValidFor>
<FilterExpression>$<type.kindof[type_Part]> == TRUE</FilterExpression>
<Access>
<UserList>
<User>name of a user</User>
<User>another user</User>
</UserList>
<RoleList>
<Role>role_FirstRole</Role>
<Role>role_SecondRole</Role>
</RoleList>
<GroupList>
<Group>group_FirstGroup</Group>
<Group>group_SecondGroup</Group>
<Group>group_ThirdGroup</Group>
</GroupList>
</Access>
<ExpandSpec>(4)
<From>true</From>
<To>false</To>
<Depth>all<!-- all | 0 | 1 | 2 | 3 | 4 | 5 --></Depth>
<Relationship>
<Type>relationship_EBOM</Type>
<Type>relationship_PartSpecification</Type>
<Type>relationship_ReferenceDocument</Type>
<!--<Where></Where>-->
</Relationship>
<!--
<Object>
<Type>type_Part</Type>
<Type>type_DOCUMENTS</Type>
<Where></Where>
</Object>
-->
</ExpandSpec>
<ExpandSpec>
<Depth>2</Depth>
<Filter>First Filter</Filter>
<Filter>Second Filter</Filter>
<Role>The name of the role, which owns the filters (not needed if XML filters are being used)</Role>
</ExpandSpec>
<ExpandSpec>
<Expander>jpo:MyExpander:nameOfMethod</Expander>
<Expander>inquiry:MyInquiry</Expander>
<Expander>java:com.acme.MyExpander</Expander>
<Expander>shadow:type_ABC,type_DEF</Expander>
</ExpandSpec>
<Tables>(5)
<Table default="true">TVC XBL Baseline</Table>
<Table>TVC Basic Information</Table>
</Tables>
<NavigationExcludeFilter>(6)
<Type>type_CADDrawing</Type>
<Type>type_SomeOtherType</Type>
<Policy>policy_APolicy</Policy>
<Policy>policy_AnotherPolicy</Policy>
<Relationship>relationship_ARelationship</Relationship>
<Relationship>relationship_AnotherRelationship</Relationship>
</NavigationExcludeFilter>
<ComparisonExcludeFilter>(7)
<Type>type_CADDrawing</Type>
<Type>type_SomeOtherType</Type>
<Policy>policy_APolicy</Policy>
<Policy>policy_AnotherPolicy</Policy>
<Relationship>relationship_ARelationship</Relationship>
<Relationship>relationship_AnotherRelationship</Relationship>
</ComparisonExcludeFilter>
<Compare>(8)
<Key relationship="relationship_EBOM">
<Field appliesToRel="true">
$<attribute[attribute_FindNumber]>
</Field>
</Key>
<Key relationship="*">
<Field appliesToRel="false">type</Field>
<Field appliesToRel="false">name</Field>
<Field appliesToRel="false">revision</Field>
<Field appliesToRel="true">type</Field>
</Key>
</Compare>
<Editable>true | false</Editable>(9)
<UI>(10)
<Header>...</Header>
<SubHeader>...</SubHeader>
<CustomMenu>...</CustomMenu>
<EditMenu>
<Disconnect/>
<BuildStructure>
<Label>...</Label>
<RegisteredSuite>...</RegisteredSuite>
<Configuration>...</Configuration>
<AutoLoad>...</AutoLoad>
</BuildStructure>
<QuickConnect>
<Label>...</Label>
<RegisteredSuite>...</RegisteredSuite>
<SearchConfig>name</SearchConfig>
<Relationship>relationship_EBOM</Relationship>
<Direction>from</Direction>
</QuickConnect>
</EditMenu>
</UI>
<CreateSettings>(11)
<Type>name or symbolic name of type derived from TVC XBL Baseline</Type>
<Policy>name or symbolic name of policy to be user</Policy>
<Vault>name or symbolic name of vault to create the object in</Vault>
<IncludeSourceName>true | false</IncludeSourceName>
<Revision>Custom revision to be used</Revision>
</CreateSettings>
<ListConfig>(12)
<ShowTypeIcon>false</ShowTypeIcon>
<Action>delete</Action>
<Action>details</Action>
<Action>compare</Action>
<Action>navigate</Action>
<Row style="bold underline"><![CDATA[$<name> ($<revision>)]]></Row>
<Row style="normal"><![CDATA[$<attribute[attribute_TVCXBLPurpose]>]]></Row>
<Row style="normal "><![CDATA[$<originated>]]></Row>
</ListConfig>
<Handler>com.acme.MyHandler</Handler>(13)
<DoAsPrivileged>true</DoAsPrivileged>
<Hidden>false</Hidden>
<AutoDescriptionMacro>
${NAME}, ${ORIGINATED}, {FULLNAME}
</AutoDescriptionMacro>
</Configuration>
The configuration is built up of 12 major sections; they are explained in the sub chapters below.
The DisplayName element is used to give the configuration a human understandable name. The name should be short and precise. The display name can be localized into different languages.
The display name is used when the user creates a new XBL and is able to select what configuration to be used.
The description is used to give the user an understanding on the purpose with the configuration. This is important if you provide multiple configurations for a certain type of object as it gives the user an understanding on what configuration to choose.
The description can be localized into different languages.
The description is shown when the user is about to create a new XBL.
The section (3) in the configuration shows a number of ways how you can make the configuration valid for a particular object and for what users the configuration is valid for.
If you only want to mask a configuration for a certain object type, or for objects that has a certain policy, you can use the easier construct "ValidFor". This allows you to define one or more types, which the configuration is valid for, and/or one or more policies that the source objects must have in order for this configuration to be usable.
If you need to make more complex decision, you can use the "FilterExpression" element that allows you to define a Matrix expression that must evaluate to true for the source object. It is possible to use both a "FilterExpression" and a "ValidFor" element.
Restricting access to the configuration can be accomplished by using the "Access" element. Here you can either define named user(s) or role/groups the user must be assigned to.
The ExpandSpec element defines how to expand the structure, e.g. what objects and connections are supposed to be serialized down to the XBL data.
You can expand the structure in a number of different ways.
Expand using a pre-defined way to do the expansion
Expand by using filters
Expand using an expand-mode (a.k.a Expander) Please see the Structure browser admin guide for more information regarding how to use Expanders.
An example of the first approach is displayed below:
<ExpandSpec>
<From>true</From>
<To>false</To>
<Depth fixed="true | false">all<!-- all | 0 | 1 | 2 | 3 | 4 | 5 --></Depth>
<Relationship>
<Type>relationship_EBOM</Type>
<Type>relationship_PartSpecification</Type>
<Type>relationship_ReferenceDocument</Type>
<!--<Where></Where>-->
</Relationship>
<!--
<Object>
<Type>type_Part</Type>
<Type>type_DOCUMENTS</Type>
<Where></Where>
</Object>
-->
</ExpandSpec>
In this case you define exactly how to expand the structure, regarding relationship types and object types (optional) including possible where clauses applying to either the connections or the objects. The table below describes the elements more in detail.
Element | Description | Possible values |
---|---|---|
From |
Expand in the from direction? |
true, false |
To |
Expand in the to direction? |
true, false |
Depth |
Levels to expand NOTE: You can use the attribute fixed on this element to disallow the user to change the expand depth upon create. |
"all" or specific value (1,2,3,4,5 …) |
Relationship |
Defines the relationship settings for the expansion. Includes the subelements Type and Where |
|
Object |
Defines the object settings for the expansion. Includes the sub elements Type and Where. |
|
Type |
Defines either the relationship or object type to use for the expansion |
Symbolic or non-symbolic type name: relationship_EBOM, EBOM type_Part, Part |
An example of the second approach is displayed below:
<ExpandSpec>
<Depth fixed="true">2</Depth>
<Filter>First Filter</Filter>
<Filter>Second Filter</Filter>
<Role>The name of the role, which owns the filters (not needed if XML filters are being used)</Role>
</ExpandSpec>
In this case, you can reuse already implemented filters in order to perform the expansion. Note that you must specify the role (which owns the filters) unless you use XML based filters (see the document describing XML based definitions).
The last approach, e.g. using so called Expanders is by using a so called expander. This is defined like below:
<ExpandSpec>
<!-- Select one approach -->
<!--<Expander>jpo:MyExpander:nameOfMethod</Expander>-->
<!--<Expander>inquiry:MyInquiry</Expander>-->
<!--<Expander>java:com.acme.MyExpander</Expander>-->
<!--<Expander>shadow:type_ABC,type_DEF</Expander>-->
</ExpandSpec>
If you intend to do a full expand, you cannot expand in both the FROM and TO direction. The XBL logic will by default validate that this scenario doesn’t occur by changing to 1 level expansion if full expand isn’t possible. |
The tables in an XBL configuration define how and what data can be viewed and compared when viewing a baseline structure. The tables contains columns that either uses standard expressions, or can use so called Data Handlers that can be used to select more complex data from the database (see the developer documentation for more information regarding data handlers).
Example:
<Tables>
<Table default="true">TVC XBL Baseline</Table>
<Table>TVC Basic Information</Table>
<Table>tvc:table:namespace/XBL-2.xml</Table>
<Table>tvc:table:namespace/XBL-3.xml</Table>
</Tables>
In this example, the table "TVC XBL Baseline" will be the default table to use. The other tables will be selectable in the navigation view and the comparison view of the baseline.
The table you use when displaying XBL data can take advantage of using so called cell renderers. Please note that a cell renderer might create links to other pages, containing the ID of the object (w/wo the connection id). This might result in confusions or in worst case errors, since the page you are linking to probably will try to read information from the database (using the provided ID’s). Hence, the data shown on the target page is not originated from the XBL data. In some cases, the ID in the baseline might refer to an object that no longer exists for some reason. E.g. use cell renderers with care, especially if you create links from your table page. |
When you define your selectables in the XBL. Either it is in a table, or in another place. Either use the selectable "attribute[name]" or "attribute[name].value". Don’t mix these since if you refer to the same attribute, but are using ".value" in one place but not in the other – the XBL logic will have problems to find the desired value. |
There are two column types that can be used together with XBL date. These are:
xbl-document-file
If you have document objects in your XBL data, these will ensure that information from the document such as the current active file version (and filename) is serialized into the XBL once created. When displaying the baseline, this column will provide a link for the user in order to be able to download the version of the file, which were the active version once the XBL were created.
xbl-name
This column will display the name of the object + a link to a special page that will show information about the object in the side panel. The page shown will load the data from the XBL and not from the real data base. Depending on the tables being used, the number of basics/attributes shown on this page might however vary.
The NavigationExcludeFilter element can be used to define type, policies and relationships that should be excluded from the navigation view of a baseline. Nodes that fit any of the requirements specified in this section will not be shown in the navigation view. This means that your baseline configuration can specify to include more data than actually is being shown when navigating the structure.
The elements supported below the NavigationExcludeFilter are shown in the table below:
Element | Description | Possible values |
---|---|---|
Type |
The type to exclude |
Symbolic or non-symbolic type name: type_ CADDrawing, CAD Drawing |
Policy |
The policy to exclude |
Symbolic or non-symbolic type name: policy_ Part, Part |
Relationship |
The relationship to exclude |
Symbolic or non-symbolic type name: relationship_ EBOM, EBOM |
Example:
<NavigationExcludeFilter>
<Type>type_CADDrawing</Type>
<Type>type_SomeOtherType</Type>
<Policy>policy_APolicy</Policy>
<Policy>policy_AnotherPolicy</Policy>
<Relationship>relationship_ARelationship</Relationship>
<Relationship>relationship_AnotherRelationship</Relationship>
</NavigationExcludeFilter>
Often the settings used in this element will be the same as for the element ComparisonExcludeFilter, but the possibility to separate the two still needs to be available, which is why the two elements both exist.
The ComparisonExcludeFilter element can be used to define types, policies, and relationship that that should be excluded when comparing baselines. Nodes that fit any of the requirements specified in this section will not be compared, and they will not be shown in the result table of a comparison.
Element | Description | Possible values |
---|---|---|
Type |
The type to exclude |
Symbolic or non-symbolic type name: type_ CADDrawing, CAD Drawing |
Policy |
The policy to exclude |
Symbolic or non-symbolic type name: policy_ Part, Part |
Relationship |
The relationship to exclude |
Symbolic or non-symbolic type name: relationship_ EBOM, EBOM |
Example:
<ComparisonExcludeFilter>
<Type>type_CADDrawing</Type>
<Type>type_SomeOtherType</Type>
<Policy>policy_APolicy</Policy>
<Policy>policy_AnotherPolicy</Policy>
<Relationship>relationship_ARelationship</Relationship>
<Relationship>relationship_AnotherRelationship</Relationship>
</ComparisonExcludeFilter>
Often the settings used in this element will be the same as for the element NavigationExcludeFilter, but the possibility to separate the two still needs to be available, which is why the two elements both exist.
The way how the comparison tool matches a row from one structure in another can be configured. By default, the type, name and revision from the object and the relationship type is used for the key, which the row matcher uses. However, in some cases this will fail, especially if two objects are connected with multiple connections of the same type. In such case, one can define a different strategy for how the key should be computed. For example, when comparing EBOM structures, one might use the "Find Number" as part of the identifying key.
An example of how to construct a different key for an XBL configuration is shown below
<Compare>
<ShowMultiLevelChanges>true</ShowMultiLevelChanges>
<Key relationship="relationship_EBOM">
<Field appliesToRel="true">$<attribute[attribute_FindNumber]></Field>
</Key>
<Key relationship="*">
<Field appliesToRel="false">type</Field>
<Field appliesToRel="false">name</Field>
<Field appliesToRel="false">revision</Field>
<Field appliesToRel="true">type</Field>
</Key>
</Compare>
The ShowMultiLevelChanges
element can be used to specify if removed rows
should include all children or not. By default, the comparator will only
show the removed row and nothing below.
An XBL can be made editable by specifying the following within the configuration:
<Editable>true</Editable>
The user can override this setting upon create if the configuration defines that the baseline supports edit; otherwise not.
The UI settings control the user interface when the user is navigating the baseline data.
You can specify a custom Header and SubHeader, and these can all be localized in different languages.
Example:
<UI>
<Header>Baseline</Header>
<Header locale="de">...</Header>
<SubHeader>$<TYPE>, $<NAME>:$<REV> ($<CURRENT>)</SubHeader>
<SubHeader locale="de">...</SubHeader>
</UI>
Moreover, if the XBL has been marked to support edit; you can define custom commands that support removal of rows and adding new rows into the XBL.
This is done as shown in the example below:
<UI>
...
<ToggleEditMode>true | false</ToggleEditMode> <!-- Enables/disables toggle-edit -->
<DisconnectButton>true | false</DisconnectButton> <!-- Enables/disables disconnect-btn -->
<EditMenu>
<Disconnect/> <!-- Adds a disconnect command -->
<BuildStructure> <!-- Adds a button that invokes build structure -->
<Label>...</Label> <!-- the label for the command -->
<RegisteredSuite>...</RegisteredSuite> <!-- If your label refers a suite str. -->
<Configuration>...</Configuration> <!-- name of build structure config -->
<AutoLoad>inquiry:name_of_inquiry</AutoLoad> <!-- optional -->
</BuildStructure>
<QuickConnect> <!-- Adds a button that invokes quick connect -->
<Label>...</Label> <!-- the label for the command -->
<RegisteredSuite>...</RegisteredSuite> <!-- If your label refers a suite str. -->
<SearchConfig>...</SearchConfig> <!-- name of search config -->
<Relationship>...</Relationship> <!-- name of relationship to use for connect -->
<Direction>from | to</Direction> <!-- direction of connection created -->
</QuickConnect>
</EditMenu>
</UI>
E.g. you can add three different kinds of commands:
Disconnect
Build Structure
Quick Connect
Note however that you can have several different variants of build-structure and quick-connect to support adding different kind of objects into the XBL.
To enable add to clipboard, add to collection and/or manage collection from the XBL view, use the following configuration elements:
<UI>
<AddToClipboard>true</AddToClipboard>
<AddToCollection>true</AddToCollection>
<ManageCollection>true</ManageCollection>
</UI>
Since the XBL view might show objects that no longer exist in the database, or the user has no show access to them, errors might appear in the user interface due to enabling them. |
By default, the XBL framework will create the baseline with the following characteristics:
Property | Default Value | Notes |
---|---|---|
Type |
TVC XBL Baseline |
The value must be a type that is derived directly or indirectly from TVC XBL Baseline. |
Policy |
TVC XBL Baseline |
The policy must govern the type. The policy must also have a store and include the formats XML + generic. |
Vault |
Same as where the object, which the baseline is created for |
|
Revision |
Default revision according to policy |
|
IncludeSourceName |
True |
The name of the baseline will contain the name of the object, which it was created for, if this is set to true. |
ReviseOnCreate |
True |
A new baseline is created as a revision. If setting this to false, the baselines are not revisions of each other. |
Example configuration:
<CreateSettings>
<Type>type_MyXBLType</Type>
<Policy>policy_MyXBLPolicy</Policy>
<IncludeSourceName> false</IncludeSourceName>
<Revision>-</Revision>
</CreateSettings>
The side-panel appearance of a baseline can be configured using the ListConfig element.
Element | Notes | Possible Values |
---|---|---|
ShowTypeIcon |
Displays the type icon of the XBL object if set to true |
true, false |
Action |
Add one for each action you want included for the XBL list item |
Delete, details, compare, quickcompare, navigate |
Row |
Use the style attribute to format rows Use macros within the element text value to display object properties |
Example configuration:
<ListConfig>
<ShowTypeIcon>false</ShowTypeIcon>
<Action>delete</Action>
<Action>details</Action>
<Action>compare</Action>
<Action>quickcompare</Action>
<Action>navigate</Action>
<Row style="bold underline"><![CDATA[$<name> ($<revision>)]]></Row>
<Row style="normal"><![CDATA[$<attribute[attribute_TVCXBLPurpose]>]]></Row>
<Row style="normal"><![CDATA[$<originated>]]></Row>
</ListConfig>
The last section in the example configuration shown above, allows configuring some additional things.
Element | Description |
---|---|
DoAsPrivileged |
When creating a baseline, this is by default done using the same context as the user who is creating the XBL. This might result in that data is not included correctly, as the user might lack access. Using this setting can force the creation to be done using a context from a super-user. This has the side effect that the users might see more data that shouldn’t be visible. On the other hand, this scenario could be considered from within the table by using custom data handlers etc. |
Hidden |
Define if the configuration is hidden or not. A configuration can be made hidden in order to prevent creating new baselines with this configuration, but still be able to use the old baselines that have been created with this configuration. |
AutoDescriptionMacro |
Defines a custom macro that can be used to set an automatically generate description on the Baseline object. The macro is resolved against the source object, which the baseline is created for. An example macro is shown below:
|
Handler |
If, for some reason, you are not able to configure how to expand the structure, e.g. define what data to be included in the baseline, you can as a last attempt implement a so called Handler that will be invoked during the creation of the XBL. The value must be the fully qualified name of a class that extends from:
|
CompressData |
Can be used to override the default setting that defines if the data file should be compressed or not. Recommended is to not change this value. |
This chapter describes some miscellaneous settings available for the XBL feature.
The table below lists the available TVC init parameters, which typically are set in the web.xml file within the TVC servlet definition. These are added like the example below:
<init-param>
<param-name>name.of.parameter</param-name>
<param-value>value of the parameter</param-value>
</init-param>
Parameter | Type | Description |
---|---|---|
tvc.xbom.xbl.compare.multiLevel |
Boolean |
Whether or not multilevel comparison is default. The default value is TRUE. |
tvc.xbom.xbl.configName |
String |
The name of the page-object that holds the XBL configurations. The default value is "TVC XBL Config" |
tvc.xbom.xbl.compressFiles |
Boolean |
Whether or not if the XBL data file should be compressed when it’s being checked in to the baseline object. The default value is true. |
tvc.xbom.xbl.autoGenerateDescription |
Boolean |
If descriptions should be auto generated. |