Using Conditions in Publish Rules

Administration spécialisée > Prise en charge de la visualisation et de la publication > WVS Publish Rules > Using Conditions in Publish Rules

Configuring Additional File Types

WVS provides support for the generation of additional file types during publishing. The publish rules XML definition allows for configuring additional file types. This section describes the publish rules that support the additional file types functionality.

For information on how to display the list of available file types on the Representations/Annotations table, see Exposing the Representations and Annotations.

Additional File Types Elements

To configure the generation of additional file types during publishing, use the following elements in the Publish Rules XML:

file and additional-Files

Refer to the sample PublishRules-AdditionalFiles.xml file in the <Windchill>/codebase/com/ptc/wvs/server/xml directory, for simple examples of these publish rules XML elements.

File — Each additional file type that can be generated is represented by a <file> element, for example:

Where:

• display-label is the label exposed in the UI, for instance Additional Files in the second step of the New Representation wizard.

• type is the additional file type that the worker is asked to export.

• output-prefix and output-suffix add a prefix or a suffix to the additional file name in the generation of additional files during publishing. output-suffix is optional.

• default—Defines whether this is a default file type for publishing. For create-representation publish requests using the Windchill New Representation wizard, this attribute identifies the additional file types to preselect for output. For check in and the other publishing request types, it identifies those additional file types to publish.

◦ default=true—Pre-selected in the New Representation wizard, but automatically output by the other publishing request types.

◦ default=false—Not pre-selected in the New Representation wizard and not automatically output by the other publishing request types.

Each <file> element can also have visible and locked elements within its definition that interact with the default element for create-representation publish requests, for instance when using the Windchill New Representation wizard.

• visible determines whether an additional file type is displayed in the Additional Files list.

• locked defines whether the user can select the output of an additional file type or not. Setting locked=true removes the check box from the Additional Files list, preventing the default setting in the <file> element from being changed. If set to locked=false, the check boxes are displayed.

The settings of these two elements, together with default provide different outputs and displays, as shown in the examples below.

• The file is displayed in the Additional Files list and is published. There is no check box next to the file name, so the user cannot alter the settings.

default="true" locked="true" visible="true"

• The file is published, the file name is not displayed, and therefore not selectable by the user. (Locked is inconsequential as the user can’t change the setting of something that he can’t see.)

default="true" locked="true" visible="false"

default="true" locked="false" visible="false"

• The file is displayed in the Additional Files list. The user can select or clear the check box next to the file name to publish the file or not.

default="true" locked="false" visible="true"

• The file is not published and not displayed. The user cannot take any action.

default="false" locked="true visible="false"

Each <file> element can also have a number of <option> elements within its definition. These <option> elements are used to pass additional application export settings to the worker, for example:

There can be any number of <option> elements, but the actual “name” and “value” of the option must be something that is recognized by the worker. The file type options that are supported by the worker are documented for each adapter in the Creo View MCAD Adapter Installation and Configuration Guide (Guide d'installation et de configuration des adaptateurs Creo View MCAD).

Additional Files — Each <file> element is contained within a list of additional file types to be exported, and defined using the <additional-files> element as shown below.

<additional-files name="iges_files">
<file display-label="iges 2D" type="iges" default="true" outputPrefix="2d">
<option name="output_2d" value="true" />
</file>
<file display-label="iges 3D" type="iges" default="false" outputPrefix="3d">
<option name="output_2d" value="false" />
</file>
</additional-files>

The “name” attribute is used to reference this additional file types definition in other elements (see the <publish> element below). There can be any number of <file> elements contained within the list of <additional-files>.

<additional-files> elements can be used in two ways:

• Under the root <rules> element—Applies to all <authoring-application> elements.

• Under one specific <authoring-application> element—Applies to the <authoring-application> rules for that specific Authoring Application only.

Reference from within a <publish> element— To reference an additional-files definition, add the additional-files attribute to the <publish> element, specifying its name as shown below.

This attribute can also be used in combination with the param-set and output attributes.

Since param-set, output, and additional-files are all part of a specific <publish> element, they are closely aligned. However, the param-set and output attributes are used for post-publishing activity (e.g., Arbortext), and additional-files is used during the actual publish (mainly CAD publishing and Multi-fidelity publishing) so the two cannot be used together that often. The output attribute cannot be combined with the additional-files attribute. Also note the introduction of the display-label attribute to the publish element. The display-label attribute’s value is displayed in the Creo View Output Options list in the New Representation wizard during a create-representation publishing request.

If there is only one <publish on=”create-representation"> element, only that option is displayed; but if there are more than one <publish on=create-representation> elements, each one is a separate output option, and an additional option called All is displayed at the top. If you choose the option All, a separate job is created for each <publish on=create-representation> element; if you pick anything but All, only the selected <publish on=”create-representation"> element (and corresponding additional-files) is honored.

If you specify a display-label then that is the default for the representation description. If you do not want to have a description set on the representation, set.

display-label=””

When no display-label is specified for a <publish on=create-representation> element, a concatenation of param-set, additional-files, and evaluate-rules-on-republish attributes is used as the display name. The example below includes two <publish on=”create-representation"> elements, one with a display label and one without.

Condition Elements

The newer <condition> elements enable users to set up rules that look for more attributes on an EPMDocument, such as the lifecycle state (for instance, In Work, Released), the CAD type (for instance, Part, Assembly), and the container. This includes the introduction of a number of logical operators, such as AND, OR, and NOT

Attribute — The basic attribute element looks like this:

Thename attribute of this element is the attribute to be checked on the EPMDocument being evaluated. One way to find all of the available attributes is to open a representation in Creo View and look at the properties. You see a series of epmdoc_* properties which are all available to the publish rules. In addition, any properties of the related WTPart are also available. These are also visible in Creo View and appear in the part_* format.

The value attribute in this example is the value to be compared against. If the value on the EPMDocument equals the value (case sensitive) on this Element, then this attribute is considered to be true.

Instead of using value, a user could use the regex XML attribute to use regular expressions, as in the following example:

In this case, the attribute would be considered true as long as the regular expression pattern returns a match for this EPMDocument.

Another use of the attribute element is to check if an attribute exists on the object, but it does not matter what the value is. This does not use either name or regex and looks like this:

Instance-of—The <instance-of> element is used like the <attribute> element, but is used to see if the object being evaluated is of the type specified. It looks like this:

<instance-of type=”wt.epm.EPMDocument” />

This evaluates in the publish rules to be true if the object is an EPMDocument. Alternatively, you could use:

<instance-of type="wt.doc.WTDocument" />

which would evaluate in the publish rules to be true if the object is a WTDocument.

structure — The <structure> element looks like this:

<structure> is similar to the existing <structure-type type=”epm”> element, and behaves in the same way. See “Compatibility of the Publish Rules Elements” below for more information on this new element.

Logical Operators — You can use the attribute, instance-of, and structure elements by themselves, but they become more powerful when they are combined using logical operators. The new supported operators are and, or and not. For example:

In this example, the object being evaluated must be both an assembly and in a released state for the statement to be true. Using or works in a very similar way:

In this example, the object is either Released or In Work. There can also be more than two sub-elements for <and> and <or>; but both need to have at least two. For example:

<not> works in a similar way, but can have only one sub-element. The example below indicates that the object being evaluated is not Released:

To add to the capacity of these statements, you can use the logical operators nested within each other to create complex evaluations. The following example indicates that this is an Assembly that is either In Work or Released:

The next example indicates that the object is either an In Work Drawing or a Released Assembly

The nesting can go as many levels deep as you want.

Condition Wrapper — All of the above elements must be wrapped in a <condition> element, as shown here:

The “name” attribute is what is used by the<if> element (see below) to reference this condition. The <condition> elements can be under the root <rules> element, which implies they can be used for all <authoring-application> elements, or they can be under one specific <authoring-application> which means it can only be used in that context. The “name” attribute must be unique throughout the entire publish rules document. Here is another example using the logical operators:

if condition— To use a defined <condition> element to control publishing, use the <if> element like this:

Where a condition with name Released Assembly is defined in the rules (as above).

Compatibility of the Publish Rules Elements

You cannot use any of the newer <condition>/<if> or the <additional-files> elements with the older conditional elements (<epm-number>, <epm-iba>, <epm-type>, and <structure-type>) that you used for the previous condition evaluation. Publish rules files created using these older conditional elements continue to work as previously, but if you choose to use one of the newer elements, the “older” elements can no longer be used.

Migration — The following are some examples of how to move from the older conditional elements in a publish rules file to the newer ones:

Older:

<epm-number number="01-12345.PRT">
<publish on="checkin" />
</epm-number>

Newer:

Older:

<epm-iba iba="MyIBA" value="true">
<publish on="checkin" />
</epm-iba>

Newer:

Older:

<epm-iba iba="MyIBA">
<publish on="checkin" />
</epm-iba>

Newer:

Older:

<epm-type type="EPMDocument">
<publish on="checkin" />
</epm-iba>

Newer:

Older:

<structure-type type="epm">
<publish on="checkin" />
</epm-iba>

Newer:

Republishing

In order to handle republishing, a file is stored on the representation during the original publish that is referenced during a republish. This file is called publish_params.xml and has a content-role-type of PUBLISH_PARAMS. During a republish, either from the Representation/Annotation table or a scheduled republish, this file is used to make sure the same options are applied during the republish as during the original publish. This affects the additional files concept in that it ensures that the same additional files are created during a republish as the original publish. The details of the additional file types previously published based on the user selection of additional files (in case of manual representation creation) is stored in the publish_params.xml file.

It is necessary to keep a record of the files that are selected during a manual publish. For example, if a new additional file is added to the publish rules, and it is default, that additional file will be created on a republish. If a file is removed, then the additional file is not created. However, if the “default” attribute in the publish_params.xml file changes, it is necessary to recreate what was created initially. The lists of selections must never change during subsequent republishes because they must always represent the original publish.

publish_params.xmlfile format — The following is an example of a republishing publish_params.xml file:

<result>
<publish on="create-representation" output="PDF"
param-set="Share with Arbortext"
additional-files=”standard_cad_xport_files”
evaluate-rules-on-republish="true" version="1.2">

<post-publish name="name">
GDD_of_01-2_VALVE_TIMING_SPROCKET.PRT<post-publish>
<post-publish name="delegate">
com.ptc.wvs.server.publish.EPMPostPublishDelegate</post-publish>
<post-publish name="published-content-link">create</post-publish>
<post-publish name="type">DynamicDocument</post-publish>

<file displayName="iges 2D" type="iges"
default="true" outputPrefix="2d">
<option name="output_2d" value="true" />
</file>
<file displayName="iges 3D" type="iges"
default="false" outputPrefix="3d">
<option name="output_2d" value="false" />
</file>
<file displayName="step file" type="step"
default="true" outputPrefix="step" />
</publish>

<user-selections>
<selected>
<file displayName="iges 2D" type="iges"
default="true" outputPrefix="2d">
<option name="output_2d" value="true" />
</file>
<file displayName="iges 3D" type="iges"
default="false" outputPrefix="3d">
<option name="output_2d" value="false" />
</file>
</selected>
<unselected>
<file displayName="step file" type="step"
default="true" outputPrefix="step" />
</unselected>
</user-selections>
</result>

In the above example:

• The root node is now <result>. Previously, it was just the <publish> section. This is to accommodate <user-selections> as well as <publish>.

• Under <publish> there is a new list of <file> elements that represent all the additional files in the selected list in the publish rules file. This list corresponds to the new “additional-files” attribute on the <publish> element.

• The <user-selections> element is added to store the list of what file the user actually selected. Under this element are two lists, <selected> and <unselected>.

• The evaluate-rules-on-republish attribute on the <publish> tag is added to indicate if the publish rules file must be re-evaluated on a republish instead of looking at this file. If the evaluate-rules-on-republish attribute is set to true, then the publish_params.xml file is not used on a republish; instead, the publish rules are evaluated. If the evaluate-rules-on-republish attribute is set to false, then this file is used on a republish. The evaluate-rules-on-republish attribute can also be an attribute on the rules element. At the rules level, the attribute is used as the default value for any publish elements that do not specify the evaluate-rules-on-republish attribute.

Out-of-the-box, the evaluate-rules-on-republish attribute defaults to false during publishing if not set in the Publish Rules. The Publish Rules, as evaluated during the initial publishing request, are saved with the Representation in the publish_params.xml file. If publish_params.xml does not already include evaluate-rules-on-republish="true", the rules is not be re-evaluated when republishing an existing Representation, either on state change or manually.

At Windchill 10.2 M010, two groups of properties have been added to wvs.properties to provide greater configuration control of the evaluation of Publish Rules during republishing:

• publish.evaluaterulesonrepublish.default — provides mechanisms for defining the default when evaluate-rules-on-republish is not present.

• publish.evaluaterulesonrepublish.override — provides mechanisms for overriding evaluate-rules-on-republish when it is present.

These two new groups of properties are described below.

The following properties control whether to have Publish Rules re-evaluated for an existing representation that is submitted for republishing when the evaluate-rules-on-republish flag was not specified in the Publish Rules file at the time the representation was created. Valid values for these properties are either true or false. When neither property is present, the default value is false. The authoring application-specific property always takes precedence over the property for all authoring applications.

Property	Description
publish.evaluaterulesonrepublish.default	Default value: False Specifies the default behavior of evaluate-rules-on-republish during republishing for all authoring applications that are included in the publish.usesPublishRules property.
publish.evaluaterulesonrepublish.default.<AUTHORING_APP>	Default value: False Specifies the default behavior of evaluate-rules-on-republish during republishing for a specific authoring application that is included in the publish.usesPublishRules property.

When a representation is submitted for republishing, the following properties control whether or how to override the evaluate-rules-on-republish flag that was specified in the Publish Rules file at the time the representation was created. If the evaluate-rules-on-republish flag was not specified in the Publish Rules file at the time the representation was created, these properties have no impact. Instead, the default value specified by the publish.evaluaterulesonrepublish.default property is used.

The authoring application-specific property always takes precedence over the property for all authoring applications. Valid values are either true or false. The value true means always evaluate rules on republish, and the value false means never evaluate rules on republish, regardless of what the evaluate-rules-on-republish flag was originally set to on the representation. When neither property is present, the default is null, which means do not overwrite the evaluate-rules-on-republish value that was originally specified.

Property	Description
publish.evaluaterulesonrepublish.override	Default value: False Overwrites the evaluate-rules-on-republish behavior during republishing for all authoring applications that are included in the publish.usesPublishRules property.
publish.evaluaterulesonrepublish.override.<AUTHORING_APP>	Default value: False Overwrites the evaluate-rules-on-republish behavior during republishing for a specific authoring application that is included in the publish.usesPublishRules property.

Est-ce que cela a été utile ?