q-plm dispatcher configuration (q-plm dsp.xml) configuration...

Q-PLM Dispatcher Configuration

(Q-PLM_Dsp.xml)

Configuration Guide

ENOVIA V6 + CT5 Configuration

Release 5.4.0

2016-04-14

Markings in this document

CAUTION marks important information. If you ignore such information, you risk a loss of data or other

undesirable consequences.

NOTE marks important information, e. g. dependencies of a function or requirements thereof.

INFO marks additional information.

TIP marks information for the practical use of the software.

This symbol marks step-by-step instructions.

Copyright 2000–2016 Dassault Systèmes

CATIA, ENOVIA, Q-Checker are registered trademarks of Dassault Systèmes or its subsidiaries in the

US and/or other countries.

CONTENTS

Copyright Dassault Systèmes Q-PLM_Dsp.xml ENOVIA V6 + CT5 Release 5.4.0

2

Contents

1 General introduction 5

2 XML Editing with Xerlin 8

3 Quick Start for Standard Installation 10

4 MatrixOne node 13

4.1 General setting nodes ............................................................................................................................. 13

4.1.1 General ................................................................................................................. 13

4.1.1.1 TmpDir................................................................................................. 13

4.1.1.2 DspSingleCall ......................................................................................... 14

4.1.1.3 PluginName ........................................................................................... 14

4.2 PDM/PLM System Settings ...................................................................................................................... 15

4.2.1 ENOVIASettings ..................................................................................................... 15

4.2.2 CheckFormat ......................................................................................................... 16

4.2.3 CheckFileExtension ............................................................................................... 17

4.2.4 RelationshipNameProperty .................................................................................. 18

4.2.5 AttributeNameProperty ........................................................................................ 19

4.3 Attribute Settings .................................................................................................................................... 19

4.3.1 PDM/PLM attribute value settings ............................................................................................ 19

4.3.2 AttributeDefReset ................................................................................................. 20

4.3.3 AttributeDefProgress ............................................................................................ 21

4.3.4 AttributeDefFailure ............................................................................................... 22

4.3.5 AttributeDefTimeOut ............................................................................................ 23

4.4 Report Settings ........................................................................................................................................ 24

4.4.1 ReportFromat ....................................................................................................... 24

4.4.2 ReportError ........................................................................................................... 25

4.4.3 Attaching Q-Checker Report ...................................................................................................... 25

CONTENTS


3

4.5 Check behavior ........................................................................................................................................ 27

4.5.1 ManualMx_Check, …............................................................................................. 27

4.5.2 CheckInTrigger ...................................................................................................... 29

4.5.3 MXBackGroundJob ............................................................................................... 30

4.5.4 AddJobWhereQuery ............................................................................................. 32

4.5.5 AdminRelease ....................................................................................................... 33

4.6 PDM Save Settings ................................................................................................................................... 34

4.6.1 PDMSave ............................................................................................................... 34

4.6.2 PDMSaveCheckStamp ........................................................................................... 35

4.7 Copy CATIA files out of ENOVIA V6 ......................................................................................................... 35

4.7.1 nodes ......................................................................................................................... 36

4.7.2 Further CopyOut settings ........................................................................................................... 37

4.8 Action settings ......................................................................................................................................... 38

4.8.1 ActionExtentions ................................................................................................... 38

4.9 PLM/PDM attribute conversion and mapping......................................................................................... 40

4.9.1 LookupAttrReplExclude......................................................................................... 40

4.9.2 TypeConvert .......................................................................................................... 41

4.10 Distributed Systems ................................................................................................................................. 42

4.10.1 DspServiceStart ..................................................................................................... 42

4.10.2 LocationEPRMap ................................................................................................... 43

4.11 Dispatcher Start ....................................................................................................................................... 44

4.11.1 ................................................................................................................................... 44

4.11.2 ................................................................................................................................... 47

5 nodes 50

5.1 NativeLibs ................................................................................................................................................ 50

5.1.1 License type ............................................................................................................................... 50

5.1.2 node ............................................................................................................................. 51

CONTENTS


4

5.1.2.1 nodes ..................................................................................................... 52

5.2 nodes ................................................................................................................................ 53

5.2.1 CATIA Q-Checker default sub node ............................................................................................ 53

5.2.2 Result judging and validation ..................................................................................................... 54

5.2.2.1 / node ................................................................... 54

5.2.2.2 / node ................................................................... 55

5.2.2.3 / node ................................................................................. 56

5.2.2.4 / and / node ............................... 57

5.3 Actions ..................................................................................................................................................... 59

5.3.1 General ....................................................................................................................................... 59

5.3.2 Attributes for ProfileData and Q-Checker Profile ...................................................................... 60

5.3.3 Condition Attribute .................................................................................................................... 61

5.3.4 Vault Attribute ........................................................................................................................... 62

5.3.5 Attaching Q-CHECKER Report ....................................................................................................... 62

5.3.6 Defining Result Attributes .......................................................................................................... 62

5.3.6.1 Standard attribute definition .................................................................................... 62

5.3.6.2 Date / time attribute definition ................................................................................ 63

5.3.7 Defining Q-CHECKER Report File Names ...................................................................................... 65

5.3.8 Enable Q-CHECKER model save .................................................................................................... 66

5.3.9 Show Message Boxes ................................................................................................................. 67

6 ENOVIA V6 General 68

6.1 Admin Type.............................................................................................................................................. 68

GENERAL INTRODUCTION


5

1 General introduction

Q-PLM_Dsp.xml is the configuration file for the Q-PLM products.

ATTENTION

If paths contain whitespaces, the whole path has to be enclosed in quotation marks.

In the XML file, the quotation marks must be written in HTML syntax: "

The following examples are for ENOVIA V6 with CATIA V6. But they are similar to the other ENOVIA

and CATIA versions. This chapter should only give an overview. The specific nodes and settings for

the ENOVIA and CATIA version are described in the other chapters of this document.

The root node of the Q-PLM_Dsp.xml is . This node contains three main XML nodes:

: global settings

: PLM-system-specific settings

: Settings for check execution

Globals: global settings

These settings can be used in most of the other XML nodes.

Example of global settings for ENOVIA V6 with CATIA V6:

Fig. 1: node



6

PLMSystems: PLM system-specific settings

The sub node contains the special settings for the PDM systems or DX. This node

contains different entries for the different PLM systems. The name of the node is the name of the

system.

Example of PLM Settings for ENOVIA V6 with CATIA V6:

Fig. 2: node for ENOVIA V6



7

QCheckerPLM: Settings for check execution

ProfileDatas: Settings for check execution used be QCheckerPLM node.

This node defines CATIA / Q-CHECKER definition and execution, result judging, attribute settings,

Q-CHECKER report attachment, …

Example of QCheckerPLM and ProfileDatas for CATIA V6:

Fig. 3: node

Please refer to refer to the following documentation for more information about the

Q-PLM_Dsp.xml:

Q-PLM_XML-DspReference_5.x.x.pdf

XML EDITING WITH XERLIN


8

2 XML Editing with Xerlin

We suggest editing the XML file with Xerlin 1.3. This is an Open Source tool which can be

downloaded from:

http://www.xerlin.org/

XERLIN takes care of the DTD definitions. It allows to add only sub nodes, which are available for the

parent node. Only the defined number of sub nodes can be added. Only attributes, which are defined

in the node, are displayed. In case that it is not allowed to leave a node or attribute empty, an error

message will be displayed. If nodes collide with the DTD definition, they are displayed in a different

colour. XERLIN helps to avoid failures and corrupt XML files. However, note that XERLIN validates only

the structure, but does not check if the content and values are suitable.

Example of the use of Xerlin for the node:

///

Steps:

Example, using XERLIN:

(1) In Xerlin, open the QCheckerDsp.xml file (File > Open f i le )

(2) Select the node:

////

/

(3) Right-click the node and

select

"Add" > "OKAssessment".

XML EDITING WITH XERLIN


9

A new sub node has been added.

Fig. 4: node created

(4) Enter the name value.

Fig. 5: Enter the value

QUICK START FOR STANDARD INSTALLATION


10

3 Quick Start for Standard Installation

Standard installation:

ENOVIA V6 and CATIA V5 and all Q-PLM depended modules are installed only on Windows

platform.

The execution of all Q-PLM ENOVIA V6 integration modules (Q-PLM Dispatcher, Q-Checker V5, …)

is on the Windows machine where the ENOVIA V6 application server is running.

The execution of all Q-PLM CATIA V5 client modules (Q-PLM Dispatcher, Q-Checker V5, …) is on

the Windows machine where the CATIA V5 client is running.

CATIA / Q-Checker is installed on the ENOVIA V6 application server

CATIA / Q-Checker installation is identical (incl. same installation directory, …) on client and

ENOVIA V6 application server.

Q-PLM_Dsp.xml is the same for the Q-PLM installation on ENOVIA V6 application server and

CATIA V5 client.

Only one Q-Checker profile will be used.

ENOVIA V6 standard customization for Q-PLM, no special attributes etc. Refer to documentation

Q-PLM_EV6CT5_Customization.doc.

Following check functions will be supported:

PDMSave

Manual check from Web Interface

Check of PDM attributes for Maturity Change

Quick start for standard installation

(1) Open the XML editor.

(2) Choose the node /.



11

Fig. 6: node (Xerlin editor)

(3) Customize the following nodes:

Setting name Description and values

TmpDir Directory for temporary processing files and trace files.

Default value:

%QPLMPATH%\tmp

In general, the environment variable %QPLMPATH% is not set on the

application server. Therefore this value must be replaced by the full

path. Example:

C:\Q-Checker\Q-PLM_V5.4.0\tmp

CATEnvV5 Name of the CATIA V5 environment. Example:

Q-PLM__V5-6_R2013_5.4.0

CATEnvDirV5 Path to the CATIA V5 environment, this environment must contain the

settings for Q-Checker. Example:

C:\ProgramData\DassaultSystemes\CATEnv

CATStartV5 Path and name of CATIA V5 CATSTART.exe. Example:

C:\Program Files\Dassault Systemes\B23\win_b64\code\

bin\CATSTART.exe



12

QCEnv Name of Q-Checker environment. Example:

Default

QCProfile Name of Q-Checker profile. Example:

Sample-Profile

EV6ServerURL Full qualified URL of ENOVIA service including protocol, server name,

port, and service name. Example:

http://myV6Server:8080/enovia

(4) Select the default profile data node for CATIA V5 checks:

///

Fig. 7: Default profile data node with subnode (Xerlin editor)

(5) Customize the following nodes according to your Q-Checker profile:

Node Description

/ Valid assessments. Any assessment not

defined here is not OK (check failed).

/ Valid return codes. Any return code not

defined here is not OK (check failed).

MATRIXONE NODE


13

4 MatrixOne node

4.1 General setting nodes

4.1.1 General

The general settings are subnodes of this node:

///

4.1.1.1 TmpDir

The TmpDir node defines the directory for temporary files, except for protocol and trace files. The

temporary directory is defined by the following node:

///

/

Fig. 8: Definition of the "TmpDir" node (Xerlin editor)

NOTE

Other modules of the PLM integration also need access to some of these files. Modify this

value only if it is assured that all the shared files are accessible.

For the standard installation, we recommend using the "TmpDir" node of the global settings.

MATRIXONE NODE


14

4.1.1.2 DspSingleCall

This node defines how the Q-PLM Dispatcher module is called. The Q-PLM Dispatcher can be called

either once for all check executions, or one Q-PLM Dispatcher call for every check execution.

The Dispatcher call is defined by the following node:

///

/

Fig. 9: Definition of the "DspSingleCall" node (Xerlin editor)

Value Description

no Q-PLM Dispatcher will be called for all selected documents at once.

Default setting

yes Separate Q-PLM Dispatcher call for every check run.

4.1.1.3 PluginName

The "PluginName" setting defines which ENOVIA V6 release dependent Q-PLM jar file to load. This jar

library contains the ENOVIA V6 specific behavior for the different ENOVIA releases.

The plugin name is defined by the node:

///

/

MATRIXONE NODE


15

Fig. 10: Definition of the "PluginName" node (Xerlin editor)

Value Description

ev6r2014xplugin Library name for ENOVIA V6 R2015x and higher.

ev6r2014xplugin Library name for ENOVIA V6 R2014x until V6 R2015x.

ev6r2012xplugin Library name for ENOVIA V6 R2012x until V6 R2014x.

4.2 PDM/PLM System Settings

4.2.1 ENOVIASettings

General ENOVIA V6 settings for login and vault are subnodes of:

///

Fig. 11: "ENOVIASettings" subnodes

MATRIXONE NODE


16

Table 1: "ENOVIASettings" subnodes

Node Name Default Value Description

DefaultVault localhost ENOVIA CBP vault

Needed e.g. for checkin / checkout files on ENOVIA CBP server

localhost is used by default if node is not set

LoginDlg no Defines if the shadow agent user or a defined user should be used:

no = Shadow agent user

yes = User with login name defined by actLoginName

actLoginName User name for background process in case if LoginDlg is yes

actPassword Crypted password of background process in case if LoginDlg is yes

actServer Reference to

node EV6ServerURL

Full URL of the default ENOVIA V6 service.

4.2.2 CheckFormat

The check formats are defined under the following subnode:

///

Fig. 12: "CheckFormat" subnodes (Xerlin editor)

Only formats defined in this node are checked with Q-PLM. Formats not defined in this node are

ignored by Q-PLM.

Table 2: CheckFormat default values

Name Default Value

type_CATVersionedDrawing drw

MATRIXONE NODE


17

type_CATVersionedProduct asm

type_CATVersionedPart prt

The value is the format of the ENOVIA V6 object which should be checked.

Default formats for CATIA V5 of ENOVIA V6:

Fig. 13: ENOVIA V6 Business, formats to CATIA V5

4.2.3 CheckFileExtension

The check file extension is defined under the following subnode:

///

Fig. 14: " CheckFileExtension " subnodes (Xerlin editor)

The definition of “CheckFormat” might not be enough because to one format several file types can

be assigned (e.g. the format “prt” has “CATPart” and “csv” files related, the “csv” file for part tables).

MATRIXONE NODE


18

The files that are defined with “CheckFormat” are narrowed by the file extension defined with

“CheckFileExtension”.

Only files that have the defined format and file extension will be checked with Q-PLM.

4.2.4 RelationshipNameProperty

The relationship names are defined under the following subnode:

///

Fig. 15: "RelationshipNameProperty" subnodes

The values of these nodes are the symbolic names which are registered in ENOVIA V6. For more

information, refer to chapter 6.1 "Admin Type".

Table 3: RelationshipNameProperty default values

Name Default Value

CADSubComponent relationship_CADSubComponent

PartSpecification relationship_PartSpecification

ActiveVersion relationship_ActiveVersion

VersionOf relationship_VersionOf

PartType type_Part

MATRIXONE NODE


19

4.2.5 AttributeNameProperty

The attribute names are defined under the following subnode:

///

Fig. 16: AttributeNameProperty subnodes (Xerlin editor)

The value of these nodes is the symbolic names which are registered in ENOVIA V6. For more

information refer to chapter 6.1 "Admin Type".

Table 4: AttributeNameProperty default values

Name Default Value

IsVersionObject attribute_IsVersionObject

MoveFilesToVersion attribute_MoveFilesToVersion

FileMessageDigest attribute_IEF-FileMessageDigest

QPLMResult attribute_TCAQPLMResult

QPLMAssessment attribute_TCAQCAssessment

4.3 Attribute Settings

4.3.1 PDM/PLM attribute value settings

In general, the attribute values are set by the subnodes of

////

MATRIXONE NODE


20

For some defined behaviors of the PDM/PLM system the quality attributes can be overwritten by

some special settings.

Specific values for the Q-PLM attributes can be set for different states of the Q-PLM process or in

case of failure.

NOTE: Date, Time

Timestamp, date and time values van not be set to empty value.

NOTE: Customized attributes

In case if the attributes are customized like different naming removed of additional

Q-PLM attributes. These settings must be adjusted.

4.3.2 AttributeDefReset

Attribute values for reset. These values are set if Q-PLM attribute reset is called; for example by

Checkin trigger for standard save of CATIA components. They are defined under the following

subnode:

///

Fig. 1: AttributeDefReset subnodes

Table 5: AttributeDefReset default values

MATRIXONE NODE


21

Name Default Value

TCAQCAssessment NOT CHECKED

TCAQPLMResult 1000

TCAQCProfile

TCAQCActAction

TCAQCCheckUser

TCAQPLMComputerName

TCAQPLMAdminRelease FALSE

4.3.3 AttributeDefProgress

The attribute values for in progress. These values are set for special Q-PLM executions that might

take a long time; like batch checks. They are defined under the following subnode:

///

Fig. 2: AttributeDefProgress subnodes (Xerlin editor)

Table 6: AttributeDefProgress default values

Name Default Value

TCAQCAssessment In Progress

MATRIXONE NODE


22

TCAQPLMResult 100

TCAQCProfile

TCAQCActAction

TCAQCCheckUser

TCAQPLMComputerName


4.3.4 AttributeDefFailure

Attribute values for general failures like Q-Checker cannot be executed or the Q-Checker execution is

interrupted by a serious failure. They are defined under the following subnode:

///

Fig. 3: "AttributeDefFailure" subnodes

Table 7: "AttributeDefFailure" default values

Name Default Value

TCAQCAssessment Execution Failed

TCAQPLMResult -1000

TCAQCProfile

MATRIXONE NODE


23

TCAQCActAction

TCAQCCheckUser

TCAQPLMComputerName


4.3.5 AttributeDefTimeOut

Attribute values for time out. These values are set for time-outs caused by ENOVIA V6 background

jobs with Q-PLM processes. They are defined under the following subnode:

///

Fig. 4: "AttributeDefTimeOut" subnodes

Table 8: "AttributeDefTimeOut" default values:

Name Default Value

TCAQCAssessment Time Out

TCAQPLMResult -1000

TCAQCProfile

TCAQCActAction

TCAQCCheckUser

MATRIXONE NODE


24

TCAQPLMComputerName


4.4 Report Settings

4.4.1 ReportFromat

ENOVIA V6 formats which are defined for report attachment are defined under the following

subnode:

///

Fig. 5: "ReportFormat" node with "Format" subnodes

Table 9: "Format" values

Value Description

QQC-HTML Q-Checker HTML Report

Default by standard installation.

QC-XML Q-Checker XML Report

Not defined and configured by standard installation.

QC-TXT Q-Checker Text Report


QC-Report Q-Checker Report which can be shown with Q-Checker External Report Viewer.


QC-DB Q-Checker DB Report which is use for Q-Monitor coupling.


MATRIXONE NODE


25

4.4.2 ReportError

Error reports page can be attached for general failures like Q-Checker cannot be executed or the

Q-Checker execution is interrupted by a serious failure. They are defined under the following

subnode:

///

Fig. 6: ReportError subnodes

Table 10: ReportError subnode for error reporting

Name Default Value Description

Filetype QC-HTML This filetype is the EONVIA V6 format for the report.

Report format like described in chapter above.

Replace yes Overwrite existing reports of a versioned component. This

doesn’t have an effect if a new versioned component is

created e.g. with checkin operation.

yes: Existing report will be overwritten

no: Existing report will NOT be overwritten it will be

attached in addition.

4.4.3 Attaching Q-Checker Report

The different Q-Checker report files can be attached to PDM/PLM system. They are defined as

subnodes of the following node:

////

Only the EV6CT5 specific settings of these nodes are described in this chapter. Refer to the

corresponding chapter 5.3 "Actions" for further information.

By default the HTML Report is defined by the subnode

MATRIXONE NODE


26

/////

Fig. 7: subnodes

Table 11: Default values for subnode


name Q-Checker HTML Report Generic name for these types of reports

filetype QC-HTML This filetype is the ENOVIA V6 format for the report.

Report format like described in chapter above.

This format must match to the node report node.

Refer to table below.

replace yes Overwrite existing reports of a versioned component. This

has no effect if a new versioned component is created, for

example with the checkin operation.

yes: Existing report will be overwritten

no: Existing report will NOT be overwritten. It will be

attached in addition.

Table 12: Subnodes of and their corresponding filetype

Node Filetype

HTMLReport QC-HTML

XMLReport QC-XML

TXTReport QC-TXT

MATRIXONE NODE


27

Node Filetype

QCReport QC-Report

DBReport QC-DB

4.5 Check behavior

4.5.1 ManualMx_Check, …

The check attributes are defining the workflow stage for which the different actions can be

performed or not. The first section of the node name is corresponds to the default name of the

related node. They are defined under the following nodes:

///

Fig. 8: "ManualMx_Check" subnodes

The name property of the node is the name of the lifecycle stage.

The value property of the node is a Boolean. It identifies if the action is allowed for this

lifecycle stage or not.

Table 13: Default values

Lifecycle stage ManualMx_Check DBTriggerMx_

Check

CheckInMx_Check MaturityChange

Mx_Check

Preliminary yes yes yes yes

MATRIXONE NODE


28

Lifecycle stage ManualMx_Check DBTriggerMx_

Check

CheckInMx_Check MaturityChange

Mx_Check

Review yes yes yes yes

Approved no no no yes

Release no no no yes

For example, the manual check is not allowed for the life cycle stage "Release".

Fig. 9: CATPart with State "Release"

If the check is not allowed for the lifecycle stage the following message will appear:

MATRIXONE NODE


29

Fig. 10: Check not allowed for the lifecycle stage

4.5.2 CheckInTrigger

The subnode CheckInTrigger defines the properties for Check-In trigger. With the enabled Check In

trigger, the Q-PLM check process will be invoked for the components which are checked in by

ENOVIA V6.

If the Check In trigger is not activated, the ENOVIA V6 Q-PLM result attributes will be reset and in

case of PDM Save the ENOVIA V6 Q-PLM result attributes will be updated with the Q-Checker results.

If the Check In trigger is activated these 2 options must not be used.

CAUTION: Either the Q-PLM check with Check-In Trigger or PDM Save should be configured.

We do strongly advice NOT configuring both together.

The Check-In trigger settings are defined as subnodes of the following node:

///

MATRIXONE NODE


30

Fig. 11: "CheckInTrigger" subnodes

Table 14: "CheckInTrigger" settings


IsActive no Enables / disables the Check In trigger

yes: Q-PLM execution for Check In trigger is

activated.

no: Q-PLM execution for Check In trigger is

disabled.

4.5.3 MXBackGroundJob

The "MXBackGroundJob" sub node defines settings for ENOVIA V6 Background Jobs. For some

checking processes, we advise using the ENOVIA V6 Background Jobs for queuing the check

operations in order that the can processed sequently.

Fig. 12: Q-PLM Background Jobs

MATRIXONE NODE


31

The ENOVIA V6 Background Jobs settings are defined as subnodes of the following node:

///

Fig. 13: MXBackGroundJob subnodes

Table 15: General Background Job settings


MXBatchJobProgram TCAQPLM_Batch JPO program which should be launched for

the ENOVIA V6 Background Jobs.

MXBatchJobMethodName execQPLMBatch Method name of JPO program which

should be executed.

BackGroundJobRole role_GlobalUser Symbolic name of the role which should be

used for the ENOVIA V6 Background Jobs.

JobType type_Job Symbolic name of type "Job"

ProgramNameAttribute attribute_ProgramName Symbolic name of attribute "Program

Arguments"

QPLMJobAdminAttribute attribute_TCAQPLMJobAdmin Symbolic name of attribute

"TCAPLMJobAdmin"

CompletionStatusAttrib

ute

attribute_CompletionStatu

s

Symbolic name of attribute "Completion

Status"

JobTimeOut 7200000 Time out for the job in milliseconds

MATRIXONE NODE


32

MaxJobs 2 Maximum numbers of Jobs which can be

executed at the same time

CheckInMx

ManualMx

yes

yes

Name of the action which should be

enabled for using ENOVIA V6 Background

Jobs

4.5.4 AddJobWhereQuery

Q-PLM BatchJob executes an ENOVIA V6 query finding the models for Q-Checker check run. The

default where query consist out of the defined class id, states from the xml configuration (refer to

4.5.1 " ManualMx_Check, …") and the modification time frame from the command line

input.

For the ENOVIA V6 BatchJob the Where Query can be enhanced with the following node:

///

Fig. 1: AddJobWhereQuery node

The additional Where Query can be defined with following attribute nodes:

Attribute Mandatory Description

Separator YES Logic operation like:

and, or, … bracket etc.

No default

MATRIXONE NODE


33

Name NO Name of the object. In general this is the attribute respectively the

database object.

Example: attribute[TCAQCAssessment]

Default: empty

Operator NO Operator like:

~~, …

Default: empty

Object NO Object / value

Example: 'In Order'

Default: empty

If more a more complex query is needed, the can be defined one after the other combined the

"Separator" node.

Example: Only models should be checked which have the assessment "IO" and belonging to the

Q-Checker Profile contains the string "thing".

The configuration for this additional query is:

4.5.5 AdminRelease

The sub nodes under the node define the settings for Maturity

Change with admin release option. If this option is enabled and the value of the attribute

matches to the value that is defined in this XLM sub node, it is possible to promote the

object with an NOT valid data quality. It is highly recommended that a restricted group of

people like design manager or project manager can modify this attribute.

MATRIXONE NODE


34

Settings of the nodes

Name value

enable Enables / disable Admin Release

Yes: enabled

No: disabled

AttributeName Attribute name of the attribute which controles the Admin

Relase

Default: TCAQPLMAdminRelease

AttributeValue Attribute value of the attribute which enables the maturity

change for NONE proper data quality

TRUE

4.6 PDM Save Settings

4.6.1 PDMSave

These sub nodes containing all necessary settings for PDM Save.

Attribute Description

PDMSaveCmd Script for ENOVIA V6 PDM Save operation.

Default file:

${QPLM_ISTALL_DIR}\bin\EV6_Client\EV6CT5\QPLMPDMSaveCmd.bat

This file might be customized, please refer to the related chapter of

Q-PLM_EV6CT5_Customization_5.x.pdf

MATRIXONE NODE


35

MxCheckInCmd Command header of the checkin command which should be performed

V6CATIACheckinActiveHdr: Web Client with dialog

V6CATIACheckinNoOptionActiveHdr: Web Client without dialog (Quick checkin)

ENODC5Save: Immersive Client with dialog

ENODC5QuickSave: Immersive Client without dialog (Quick checkin)

MXResponseXML Full qualified file name of response xml.

Default full qualified file name of response xml:

%CATTemp%\MxCATIAV5Integration\Response.xml

actServer URL of ENOVIA application server. Example:

http://EV6Server:8080/enovia

actLoginname ENOVIA V6 login name for PDM Save operation.

Default: User Agent

actPassword ENOVIA V6 password for login.

DefaultWorkinDir Obsolete

QPLMCheckStampCmd Obsolete

4.6.2 PDMSaveCheckStamp

Obsolete

4.7 Copy CATIA files out of ENOVIA V6

For checking the components, the CATIA models must be copied out to a local file system from

where they can be loaded by Q-Checker.

The copy-out settings are under the following subnode:

///

MATRIXONE NODE


36

4.7.1 nodes

For the copy out directories any combination of "Discrete" and "Global" nodes can be used. System

environment variables can be used with UNIX and WINDOWS syntax.

INFO:

The system environment variables are taken from and resolved on the system where the

PLM Integration is executed. If other modules are executed on other systems this full re-

solved path is passed to these modules. For this path the general roles of the shared file

system has to be considered

Table 16: copydir nodes

Subnode name Description Details

copydir Defines the general copy out

destination

Parameter name="copydir"

Default value: TmpDir

copydir_v4 Defines the copy out destination for

CATIA V4 models

Parameter

name="copydir_v4"

Default: Node is not set

copydir_v5 Defines the copy out destination for

CATIA V5 models

Parameter

name="copydir_v5"

Default: Node is not set

Order of determining the copy directory:

copydir_v4

copydir_v5

copydir TmpDir Not defined

Dir not found

Not defined

Dir not found

MATRIXONE NODE


37

4.7.2 Further CopyOut settings

Subnode name Purpose Details

overwrite Defines if the root part / product / drawing /

model should be overwritten on the destination

file system. The root is the one that is selected in

ENOVIA V6 for performing the Q-CHECKER

operation.

XML subnode:

Possible values: YES | NO

Default value: NO

If it is set to NO and the model

already exists on the file system the

application is terminated. The models

will not be checked by Q-Checker.

drawinglinks Copy out linked CATIA files that are referenced by

CATDrawings.

XML subnode:


Default value: NO

productlinks Copy out linked CATIA files that are referenced by

CATProducts

XML subnode:


Default value: NO

overwritelink Defines if files that are referenced by

CATDrawings or CATProducts are to be

overwritten (according to drawinglinks and

productlinks).

XML subnode:


Default value: NO

If the value for the attribute is set to

NO and the model already exists on

the file system, the file is not

overwritten and will be used.

MATRIXONE NODE


38

Subnode name Purpose Details

copyoutlevel Defines the level of parts and subassemblies

which should be copied out (if productlinks,

drawinglinks are enabled).

XML subnode:

Possible values: 0 – n

0: all parts and subassemblies are

copied out, regardless the level

1: all parts and subassemblies directly

below the assembly root, no parts

which are in subassemblies are

copied out

n: defined level of parts and

subassemblies are copied out

Default value: 0

4.8 Action settings

4.8.1 ActionExtentions

The action extension settings are under the following subnode:

///

Fig. 14: Action settings, ActionExtension

From the different Actions depending to the operation type, are called.

MATRIXONE NODE


39

Fig. 15: Action settings, Default EV6CT5 actions

Table 17: Default Action

Default Action Description

ManualMx ENOVIA V6 interface

EDMSaveMx PDM Save

CheckInMx check in operation

MaturityChangeMx maturity change

DBTriggerMx Batch job

The default name of the different nodes can be enlarged with a special action extension.

These can be done by defining a value for the specific type. The types are based on ENOVIA V6

formats which are defined in the subnodes "CheckFormat", refer to chapter

4.2.2 " CheckFormat".

Table 18: Default action extensions

Action extension Description

prt CATIA V5 part

asm CATIA V5 product

drw CATIA V5 drawing

Example of customized ActionExtension for CATIA Products

The ActionExtension is defined with "_Prod".

MATRIXONE NODE


40

Fig. 16: ActionsExtenstions subnode for products enhanced with "_Prod"

The Action names are enhanced with "_Prod".

Fig. 17: subnode for products enhanced with "_Prod"

The result is that for all assemblies the Actions with the name "_Prod" are used. For the types with

are not configured the standard Actions are used.

4.9 PLM/PDM attribute conversion and mapping

4.9.1 LookupAttrReplExclude

Attributes which are defined by ENOVIA V6 Lookup Tables have integer values instead the string

values which are defined in the Lookup Tables. Q-PLM is replacing all integer values by the

corresponding string values for Q-PLM configuration issues. This replacement is only Q-PLM internal

and does not affect ENOVIA V6 in general. Due to some configuration or processing reason it might

be necessary to bypass this replacement. This can be done by customizing the following node:

MATRIXONE NODE


41

//

Add a sub nodes for each attribute which should be bypassed.

The XML attribute name identifies whether is a document or project attribute:

name="Doc" Document attribute

name="Prj" Project attribute

The XML attribute value defines the name of the document or project attribute for which the

replacement should be bypassed.

Example:

The value of project attribute TDM_SF_SECURE_LVL should not be replaced.

Value of TDM_SF_SECURE_LVL:

With replacement: NotLimited

Without replacement: 0

Configuration for bypassing the replacement:

Fig. 18: Xerlin subnode of "LookupAttrReplExclude"

4.9.2 TypeConvert

The sub nodes of TypeConvert defines which attributes should be converted into a other format

than string for Q-PLM internal use.

Customize the subnodes of:

///

MATRIXONE NODE


42

For each attribute which should be converted an node must be created. The name

of the node is the name of the attribute and the value is the format type. The following format types

are possible:

Value Description

datetime formats which combines date and time in one attribute

date Date formats (until Q-PLM 3.3.1 combined date and time format, in later Q PLM releases

date format only)

time time formats

int integer

Fig. 19: Xerlin subnodes of "TypeConvert"

4.10 Distributed Systems

4.10.1 DspServiceStart

The sub nodes of DspServiceStart are defining which Action is supposed to be executed on a

“Satellite Computer”.

Customize the subnodes of:

///

For each Action, which should be executed on the distributed system, an node must

be created. The name of the node is the name of the Action and the value can be set to yes / no:

MATRIXONE NODE


43

Fig. 20: Xerlin sub nodes of "DspServiceStart"

When the Action is configured for the Distributed System, the node is used for the

definition of the Dispatcher execution, refer to related chapter below.

4.10.2 LocationEPRMap

The sub nodes of LocationEPRMap are defining the EPR’s for “Satellite Computers” on which the

Q-PLM Dispatcher run should be executed.

Customize the sub nodes of:

///

For each STORE a sub node of LocationEPRMap can be created. The name of the node is the

name of the STORE and the value must be the EPR of the Transcat Web Service.

Due to the STORE of the CATIA file the Q-PLM Dispatcher execution will be routed to the Transcat

Web Server which EPR is defined. If the STORE cannot be evaluated or if it is not defined in a sub

node, then the EPR of the “Default” node is used.

The ERP must be the end point reference to the Transcat Base Service. Example:

Http://computerq:8080/axis2/services/TCAQSRBase

ATTENTION

Transcat Web Service must be installed on each satellite computer

MATRIXONE NODE


44

Fig. 21: Xerlin sub nodes of "LocationEPRMap"

4.11 Dispatcher Start

Q-PLM Dispatcher is the kernel module of Q-PLM which is based on Java. This is called from the PDM

integration modules.

The Q-PLM Dispatcher modules are blue in the picture below, the ENOVIA modules are yellow.

Figure 17: Q-PLM Modules

For more detailed information, please refer to the module description of the installation guide.

There are two possibilities for starting the Q-PLM Dispatcher module:

a) Java command line execution with node

b) Execution via web services with node

4.11.1

The node defines the Java command line execution of Q-PLM Dispatcher. It can be

executed locally or remote via TCP/IP Socket connection.

The settings for the remote connection are properties of the node.

MATRIXONE NODE


45

Figure 18: XML node

node properties:

Name Value Description

remote true / false Enables remote execution with TCP/IP Socket connection.

Default: false

unix true / false In case of remote connection:

Identifies if the target computer is a UNIX machine.

Default: false

servername String In case of remote connection:

Name / IP of the remote computer.

portnumber Number In case of remote connection:

TCP/IP port for socket connection

maxretry Number In case of remote connection:

Maximum numbers of retry in case of connection failures.

retrydelaysec Number In case of remote connection:

Delay between retry in seconds.

Table 19: node properties

MATRIXONE NODE


46

NOTE: Remote Connection

For remote connection, the TCP/IP Server must be configured and running on the target

machine. The desired program which should be launched must be available and

executable on the target computer.

The sub nodes of node are defining the Q-PLM Dispatcher execution command on the

target system. It is the Java start command. For detailed information about java program execution,

refer to java documentation or type java –help in a command prompt.

java

-classpath %QPLMPATH%\bin\Q-PLM_DSP.jar

Argument Description/Parameters Examples

java Name of the Java executable. If the Java

directory is not in the system path

environment variable, the full qualified

path (including file name) must be used.

Java environment variables. Below are

some of the important one are

described, for more variables refer to

Java documentation.

Enable/disable trace output files

-DCTRACEON true/false

-DCTRACEON=true

Enable/disable java AWT execution

without GUI.

-Djava.awt.headless

true/false

-Djava.awt.headless=true

Heap space settings; These are java

version and platform dependent.

Initial java heap space:

-Xms

Maximum java heap space:

-Xmx

Set initial heap size as 512 MB

-Xms512m

Set maximum heap size as 4 GB

-Xmx4g

MATRIXONE NODE


47

%QPLMPATH%/bin/

Q-PLM_DSP.jar

Full qualified path of the Q-PLM

installation incl. name of the current

Q-PLM jar file for the current version.

This filename can be different in other

Q-PLM releases.

For version 5.3.0:

c:\Q-Checker\qplm\

Q-PLM_DSP.5.3.0.jar

Name of the Java main class.

The name of the Java main class depends

on the PDM system.

Q-PLM PDM:

qplm/QPLM_PDM_TB

Q-PLM SMARTEAM:

qplm/QPLM_PDM_ST

Q-PLM EV6CT5 (ENOVIA V6 + CATIA V5):

qplm/QPLM_PDM_M1

Q-PLM EV6CT6 (ENOVIA V6 + CATIA V6):

qplm/QPLM_PDM_V6

Table 20: node java call of Q-PLM Dispatcher

Possible sub nodes of node:

Global

Discrete

Default command and configuration for Q-PLM EV6CT5:

java -DTCTRACEON=true -classpath c:\Q-Checker\qplm\bin\Q-PLM_DSP.5.3.0.jar;

%CLASSPATH% qplm.QPLM_PDM_M1

For the example above the sub nodes are configured as follows:

node Value description

Global JavaExe Java start call via Java.exe

Discrete -DTCTRACEON=true Q-PLM trace is enabled

Discrete -classpath

Global DspJar Full qualified path of Q-PLM jar file

Discrete qplm.QPLM_PDM_M1 Q-PLM main class for EV6CT5.

Table 21: sub nodes example

4.11.2

The node defines the remote execution via web services of Q-PLM Dispatcher.

MATRIXONE NODE


48

NOTE: Web Service

Q-PLM Web Services must be configured and running on the target machine. The

desired program which should be launched must be available and executable on the

target computer.

The settings for the remote connection are properties of the node.

Figure 19: XML node

node properties:

Name Value Description

unix false In case of remote connection:

Identifies if the target computer is a UNIX machine.

progstartmode javacall /

javamain /

batch /

waitfor

Type of program execution

filetransmode XML / MTOM /

FTP / SFS

Type of file transfer mode

Table 22: node properties

Possible sub nodes of node:

Global

Discrete

RemoteProperty

ReomteOSVariable

RemoteJavaVariable

MATRIXONE NODE


49

The sub nodes are configured as follows for the default command of Q-PLM EV6CT5 with distributed

systems:

node Value description

Discrete qplm.QPLM_PDM_M1 Q-PLM class for EV6CT5.

Discrete “

RemoteProperty DspXmlFile Get the name of Dsp.xml file from the properties file of the

web service from the remote system.

Discrete “ “

RemoteProperty storePath Get the path for file storage from the properties file of the

web service from the remote system.

Discrete “

Table 23: sub nodes example

NODES


50

5 nodes

This is the main node for process description (Q-Checker processing).

Figure 20: element in Xerlin editor

5.1 NativeLibs

Use the sub nodes of to configure the license behavior and system native libraries for

license. These nodes are needed if the license settings cannot be configured by system or Java

settings / variables. They are only needed for Q-PLM modules which are based on Java.

For Q-PLM modules which are based on CAA (for example PDM Save), these nodes are not needed

and the license settings must be configured inside the related CATIA Environment file, please refer to

the related documentation.

5.1.1 License type

The license type can be set with the attribute licmode.

Figure 21: element with attribute "licmode" in Xerlin

NODES


51

Possible values:

Value Description

(Empty) System license setting are used. If no license mode is set via system or java

variable, DSLS is used.

DSLS DSLS license

If this attribute is set, it is overwriting the license settings. Refer to picture below:

Figure 22: Overwriting license settings

5.1.2 node

With the node, system native libraries which should be loaded can be configured for the

different operating systems. These nodes are only needed if the libraries cannot be loaded by java,

because the path for loading native libraries is not configured by system or java settings /

environment.

The attribute "name" defines the operating system for which the sub nodes are configured.

Figure 23: element with attribute "name" in Xerlin

NODES


52

Possible values of the name attribute:

Value Description

intel_a Windows 32 bit

win_b64 Windows 64 bit

aix_a AIX 32 bit

aix_a64 AIX 64 bit

hpux_a HP-UX

linux_32 LINUX 32 bit

linux_64 LINUX 64 bit

macos_32 MAC 32 bit

macos_64 MAC 64 bit

Not for all of the operating systems above the native libraries might be available with the installation

package. In general, only the needed once are delivered.

5.1.2.1 nodes

These nodes are defining the full qualified name (full path + file name + extension) of the system

native library which should be loaded.

Figure 24: element for Windows 64 bit in Xerlin

System native library which is needed for the license handling:

TCAJLMLibMng.dll

In some cases, the system doesn’t load the dependent libraries. Therefore, it is necessary to add all

needed libraries in the order of loading to the node.

NODES


53

Figure 25: all elements for Windows 64 bit with DSLSV5 in Xerlin

5.2 nodes

With the nodes it can be configured which Q-Checker version is to be started with

which CATIA version and with which settings. It is possible to define several nodes for

different combinations of Q-Checker and CATIA versions. For the standard installation the default

node is to be configured.

For most of these nodes, different sub node types and multiple sub nodes can be used. This is

depending on the node. For more information refer to the detailed Q-PLM_Dsp.xml documentation.

It is possible to define different nodes and employ them depending on the lifecycle

operation or PDM/PLM document/project attributes.

5.2.1 CATIA Q-Checker default sub node

The default nodes for the different CATIA versions are:

Node Description

DEFAULTV4 Default ProfileData for CATIA V4 settings



Example of a node:

///

Table 24: nodes

Node Description

CATEnvDir Directory for the CATIA environment

NODES


54

CATEnv CATIA environment file

QCheckerStart Command for Q-Checker start

QCBatchStart Command for program after Q-Checker execution was

performed, this is used for PDM update

ENVIRONMENT Q-Checker environment

PROFILE Q-Checker profile

QCTmpDir Directory for temporary files

ResultJudge/OKAssessments OK assessments definition, see section below

ResultJudge/OKReturnCodes OK return code definition, see section below

ResultJudge/ResultFileData Q-Checker output file result processing

Figure 26: element with name "DEFAULTV6" in Xerlin

5.2.2 Result judging and validation

The evaluation if the results of the operation are OK or not can be done in two different nodes:

or .

5.2.2.1 / node

The sub nodes of the / node specify which assessments should be

considered to be a successful Q-Checker check result. The assessments, which are not defined in this

node, will be considered NOT OK.

NODES


55

Customize in relation to the Q-Checker environment which is used with this

node. For this create or change sub nodes of .

Figure 27: node in Xerlin

5.2.2.2 / node

The sub nodes of / specify which Q-Checker return codes are to be

considered successful results. The assessments which are not defined in this node will be considered

NOT OK.

Customize the in relation to the Q-Checker return codes which should be

acceptable. For this create new sub nodes of or modify the existing ones.


NODES


56

5.2.2.3 / node

The node of / and its sub nodes specify which conditions are to be considered

with results. The conditions which are not defined in this node will be considered NOT OK.

The / defines the source attribute for the comparison.

Table 25: node attributes

Attributes Value Description

name Attribute

name

Name of the attribute for validation. This must match to an

attribute name of the type which is defined with the

"source" attribute.

type STR | INT Type of the attribute, string or integer

source ReportAttr |

SystemAttr |

DocAttr |

…

Source of the attribute for validation. The attribute which

can be used can be from different sources. This can be for

example an attribute of the Q-Checker result file or one

document attribute of the PDM system.

Example: MODEL_ASSESSMENT attribute of the Q-Checker Report


The sub node of // specifies the values for the comparison. The

values of the attribute which is defined in the / node will be compared to the

values which are defined in the // sub nodes .

Table 26: node attributes

Attributes Value Description

name Attribute

name

Name of the attribute for validation. This must match to an

attribute name of the type which is defined with the "source"

attribute.

retvalue integer Value which should be returned if the comparison matches. In

general this should be 0

NODES


57

cond EQ | NE | GT

| LT | …

Condition which should be used for the comparison like equal,

not equal, greater, less, …

source Discrete |

ReportAttr |

SystemAttr |

DocAttr |

…

Source of the attribute for validation. The attribute which can

be used can be from different sources. This can be for

example an attribute of the Q-Checker result file or one

document attribute of the PDM system.

Example, MODEL_ASSESSMENT attribute of the Q-Checker Report should be equal to OK. In this case

the value 0 should be returned which means that this condition will pass the check.


5.2.2.4 / and / node

The sub node node defines which Q-Checker output file is to be used for the result

processing.

Select in the desired profile the following node:

////

//


NODES


58

The following settings are available:

DBReport

QCReport

QcExSeal

none

With Q-CHECKER version less than V1.14.1, the DBReport setting must be used. In this case a special

license is required. In addition, the writing of this output file must be enabled by a Q-Checker setting.

For Q-CHECKER version V1.14.1 or higher we advise to use the QCReport setting.

Interpreting external seal file the QcExSeal setting must be used.

Out of this report files, the report attributes are taken for the further processing. The Q-Checker

assessment is taken out of these files. In addition they can be used by a node for some

Q-PLM_Dsp.xml nodes. For example, in order to set PDM/PLM system attributes to the values of

report attributes.

Figure 32: Using report attributes of result files in Xerlin

For the different report files, the following report attributes are available.

Table 27: Report attributes of result files

ReportAttr DBReport QCReport QCExtSeal

CHECK_ID Yes No Yes

MODEL_DIRECTORY Yes Yes Yes

MODEL_NAME Yes Yes Yes

MODEL_CAD_VERSION Yes Yes Yes

NODES


59

ReportAttr DBReport QCReport QCExtSeal

MODEL_USER Yes No Yes

MODEL_DIMENSION Yes No Yes

MODEL_SIZE Yes Yes Yes

CHECK_SEAL Yes Yes Yes

RETURN_CODE Yes Yes Yes

MODEL_ASSESSMENT Yes Yes Yes

TOTAL_WEIGHT_SUM Yes No Yes

CHECKING_DATE Yes Yes Yes

CHECKING_TIME Yes Yes Yes

PROFILE_NAME Yes Yes Yes

CHECK_USER Yes Yes Yes

CHECK_GROUP Yes Yes Yes

CHECKING_TOOL Yes Yes Yes

HEALING_STATUS Yes Yes Yes

Additional customer

defined collumns

e.g.:

CHECKING_MODE

CUSTOMER_NUMBER

Yes No No

5.3 Actions

5.3.1 General

The different actions are sub nodes of:

NODES


60

//

For different PDM/PLM systems standard actions are defined.

For certain PDM/PLM systems additional actions can be defined. This depends to the Q-PLM API for

the different systems. E.g. Q-PLM launched by a DB trigger.

This action names can be modified by node definition.

5.3.2 Attributes for ProfileData and Q-Checker Profile

The node contains several attributes for defining which and which Q-Checker

profile are to be used.

Table 28: Attributes for and Q-Checker profiles

Attribute name Values Description

profdatadef string Default ProfileData. It is used for all references

of a node.

profdatattr string PLM attribute which contains the Q-CHECKER

profile name.

profdataloc none | document |

project

Defines where the PLM attribute (for

profdatattr) is located. If it set to "none"

no PLM attribute will be used.

getattrprof true | false The *Inf.xml can contain the information about

the used Q-CHECKER profile:

/

This attribute triggers if it should be used or

not.

getmodelprof true | false The CATIA model can contain the information

about the last Q-CHECKER profile. This attribute

triggers if it should be used or not.

The Q-Checker profile is calculated in several steps. If a Q-Checker profile is found in the first step,

this profile will used. If not found, a next step will be executed to search the profile. Order of the

Q-Checker profile calculation:

1. Get profile with profdatattr and profdataloc

2. Get profile getattrprof from *Inf.xml, only if profdataloc="none"

NODES


61

3. Get profile from model (getmodelprof="true")

4. Get profile from profdatadef

NOTE: If a Q-Checker profile is found, it will be used in every case, regardless if it is valid or not.

An invalid profile will cause a Q-Checker error.

5.3.3 Condition Attribute

The "condition" attribute of the node defines the constraint of the Q-Checker check run.

This is dependent to other Q-PLM settings as well as the integration and check process. The following

values have to be set for the described constraint:

Table 29: Condition Attribute

Value Constraint

check Q-Checker run for single model or external seal check.

One separate Q-Checker Batch run for each model. For every model a new

CATIA / Q-Checker, if necessary VPM session, will be started.

multi Q-Checker run for multiple models.

One Q-Checker Batch run for multiple models. For models which are reflecting

to the same ProfileData one CATIA / Q-Checker, if necessary VPM session, will

be started.

checked Q-Checker run was executed before Q-PLM call.

This has to be set in case of Q-Checker PDM Save. In this case Q-Checker was

launched in an interactive CATIA session. After the interactive Q-Checker run

Q-PLM is launched.

nocheck No Q-Checker run

This has to be set if only the PDM/PLM attributes should be checked without

launching Q-Checker.

NODES


62

5.3.4 Vault Attribute

The "vault" attribute of the node triggers the destination of the models files for PDM/PLM

systems which have a checkout on the local file system.

5.3.5 Attaching Q-CHECKER Report

The different Q-Checker report files can be attached to PDM/PLM system. For this, several report

nodes can be defined as sub nodes of the following node:

////

Possible sub nodes :

HTMLReport

XMLReport

TXTReport

QCReport

DBReport

These nodes have several sub nodes . The name and value of the nodes are

dependent to the PDM/PLM System.

These nodes have the attribute "keeporiginal". Q-PLM is renaming the Q-Checker report files. If this

attribute is true, the file with the original name will be not deleted.

5.3.6 Defining Result Attributes

The names and values of the PDM/PLM system attributes which should be filled with the Q-Checker

results and additional information have to be defined in the following node:

////

For each attribute, a sub node has to be defined. These sub nodes have the name of the

PDM/PLM system attribute. This attributes have to match to the once which are defined as Q-PLM

attributes in PDM/PLM, refer to the PDM/PLM system dependent Q-PLM documentation.

5.3.6.1 Standard attribute definition

The following example shows the assignment of Q-Checker model assessment to the PDM document

attribute E_TCAQCAssessment.

Example E_TCAQCAssessment:

NODES


63

Figure 33: node with name "E_TCAQCAssessment" in Xerlin

5.3.6.2 Date / time attribute definition

Date and time attributes can be handled in a special way. For these kinds of attributes the format of

the values from the sub nodes are important. Because the input can be in different

formats depending to the operation system, the parsed files, etc. and the offset to GMT might affect

the value. In this case they are internally converted to the W3C standard RFC 3339 format (YYYY-

MM-DDThh:mm:ss.sTZD, e.g. 2011-01-19T16:34:34.0+01:00). This kind of definition has to be used if

Date / TimeStamp attributes should be set.

The format of the values from the sub nodes is defined in the sourceformat

attribute of node. The following formatter elements can be used:

Table 30: Date / time formatter elements

Formatter Description Type Example

G Era designator Text AD

y Year Year 1996; 96

M Month in year Month July; Jul; 07

w Week in year Number 27

W Week in month Number 2

D Day in year Number 189

d Day in month Number 10

NODES


64

Formatter Description Type Example

F Day of week in month Number 2

E Day in week Text Tuesday; Tue

a Am/pm marker Text PM

H Hour in day (0-23) Number 0

k Hour in day (1-24) Number 24

K Hour in am/pm (0-11) Number 0

h Hour in am/pm (1-12) Number 12

m Minute in hour Number 30

s Second in minute Number 55

S Millisecond Number 978

z Time zone General time zone Pacific Standard Time;

Z Time zone RFC 822 time zone -0800

’anyString’ Fixed string values Text ’T’

Example, E_TCAQCCheckTimeStamp:

Combination of Q-Checker check date and time including time zone.

sourceformat: yyyy-MM-dd’T’HH:mm:ssZ

sub nodes

Table 31: E_TCAQCAssessment sub nodes example

Type Value Description Example

ReportAttr CHECKING_DATE Check date from Q-Checker

report

2011-01-19

Discrete T Fixed value ‘T’ T

NODES


65

Type Value Description Example

ReportAttr CHECKING_TIME Check time from Q-Checker

report

15:34:34

InternalAttr ActReportGMTOffset GMT offset from Q-Checker

report

GMT+2

Figure 34: node, example defining E_TCAQCCheckTimeStamp

5.3.7 Defining Q-CHECKER Report File Names

The names of Q-Checker report files can be defined with the Q-Checker settings. These settings are

defined as sub nodes of the following node:

////

For a detailed description of the available sub nodes, refer to the Q-PLM_Dsp.xml documentation

and the Q-Checker documentation.

For detailed description about the Q-Checker result file naming, refer to the Q-Checker

documentation.

NOTE: We recommend to set the names of the Q-Checker report files to the name of the CATIA

document.

Setting the names of the Q-Checker report files to the name of the CATIA document (this is the

default setting):

NODES


66

Do the following steps:

(1) Choose or add the sub node:

(2) Create a new or select the existing sub node .

(3) Set the value of this node to YES.

Figure 35: with attribute Discrete="YES"

5.3.8 Enable Q-CHECKER model save

Depending to the Q-Checker profile, the CATIA model can be changed (add internal check seal,

healing). For saving these changes the save of the model must be enabled. These settings are defined

as sub nodes of the following node:

////

For a detailed description of the available sub nodes refer to the Q-PLM_Dsp.xml documentation and

the Q-Checker documentation.

For enable the save of the CATIA models do the following steps:

(1) Change or add the sub nodes:

(2) Create a new or select the existing sub node for both nodes

(3) Set the value of this node to YES.

NODES


67

Figure 36: node with attribute Discrete="YES" and node with attribute Discrete="YES"

5.3.9 Show Message Boxes

The node has an attribute for showing message boxes.

Message box attribute as an example of the Action "Manual" node:

////

This attribute is for the message box behavior of the successive processes. It has no effect for the

Q-PLM modules which are directly integrated into the PDM/PLM system. If the message boxes for

the specific PDM integration module should be suppressed refer to the description of the

node.

ENOVIA V6 GENERAL


68

6 ENOVIA V6 General

6.1 Admin Type

With ENOVIA V6 most of the ENOIA types are registered and a Symbolic Name is assigned to the type

via this registration.

NOTE: All ENOVIA V6 types which are used by Q-PLM must be registered. Q-PLM has to be

configured with the Symbolic Names of these types

The Admin Types can be viewed and modified with MQL or with the ENOVIA V6 Web Interface.

View and modify admin types with ENOVIA V6 we interface

(1) Choose Tools > Property Registration > Admin Type.

Fig. 22: EV6 Web Client, Tools > Property Registration > Admin Type ...

(2) Get Registration:

ENOVIA V6 GENERAL


69

Fig. 23: ENOVIA V6 Admin Type for Part Specification

q-plm dispatcher configuration (q-plm dsp.xml) configuration...

Documents