Transformation Filter
Filters are the artefacts provided to remove XML files from downgrade delivery zip which are not applicable for a given target release. Transformation filters can be name-based, XPath-based or a Java-based type.
It is assumed that application developers who perform these configurations have expertise in JAVA, XML and XSL.
Name based Filter
Apply this filter to remove an element from a new downgrade delivery zip file. For instance, a new object type is introduced in a recent Windchill release but this object is not supported with any previous releases of Windchill.
When specifying filters that are based on tag names, add the suffix _filter.propertiesto the tag name.
Add elements to be removed in comma separated values.
A sample of filter.properties file with tag-based filter configuration:
tagsToFilter=WTChangeOrder2,WTChangeActivity2,LWWfProcess,LWWfAssignmentEventAudit,LWWfAssignedActivity,LWWorkItem contentInclusionCriteria=+;-WCTYPE|wt.doc.WTDocument
where contentInclusionCriteria lists the object types that are to be excluded or included in a synchronized delivery. These exclusions or inclusions are cumulatively evaluated from left to right.
• + : Includes all object types by default.
• -WCTYPE|wt.doc.WTDocument: Exclude WTDocument objects.
The filter.properties file is located at <Windchill_codebase>/registry/transformationEngine/filter/<releaseId>/.
XPath based Filter
This filter configuration is based on XPath. Apply this filter when an object-specific XML is to be removed for a given attribute for a given value. For example, a new soft type is introduced in the current release and all the XML files related to that soft type must be removed in the downgraded deliveries.
When specifying an XPath filter, add the suffix _xpath_filter.xml to the name.
The xpath_filter.xml file is located at <Windchill_codebase>/registry/transformationEngine/filter/<releaseId>/.
Java based Filter
Use this filter configuration when you want to perform persistence query to remove additional objects based on the filtering result of the Name-based filter and XPath-based filter. An example of applying this filter, if a soft type is invalid then there are chances that all the required dependent objects which have an impact on integrity of the data is filtered.
These filters are used to filter XML files from the downgrade delivery package. If an attribute is not supported for downgrade in an XML file, consider using XSL transformation scripts to set filter configuration.
In a synchronized delivery, the contents of the objects are excluded. This is done to reduce the size of the synchronized zip delivery. If objects are filtered during downgrade, their content is included in synchronized delivery. To include the contents of the objects other than the filtered objects, configure the contentInclusionCriteria property in filter.properties.
For example, to exclude the contents of type WTDocument define filter.properties as contentInclusionCriteria=+;-WCTYPE|wt.doc.WTDocument. For more details refer to the section “Name based Filter”.
Element Handlers
Element handlers are the transformation invokers based on the Java transformation API. These element handlers can be configured for a given element tag. Transformation happens in the following three phases for each element:
1. Pre-Process phase, sets the operations required for preparing XML files for transformation. This is required for use cases which cannot be handled through XSL. Object owners can decide the pre-process method to provide their pre-processing logic. Framework calls the pre-process of the registered element handlers for attributes.
2. Transform phase, transforms an XML file to target XML file based on the configuration set in XSL.
3. Post-Process phase, involves the transformed XML documents and validation activities for element transformation processing. Object owners can decide on the post-process method to provide their post-processing logic. The framework calls the post-process of the registered element handlers for attributes.
Content Transformation
Contents are copied during the downgrade process by default. To update the content in the downgrade process, perform the following:
1. Create an element handler by extending from XSLTransformElementHandler. Overrode the method is ContentTransformationRequired to return true.
2. If the metadata transformation is not required, then override the transform method and return the collection as is. This improves performance by not invoking the XSLT processor just for copying.
3. Implement a task by extending ContentTransformer.
4. Implement methods as required. The call method in ContentTransformer should be able to perform the following:
a. Download the content to a temporary location.
b. Downgrade the content as required.
c. Return the inputstream of the downgraded content.