Customization Points
Extendable classes
If classes used by the Windchill ESI renderers described in the Publishing BOMs section of this document are extended, the extensions must be defined in certain Windchill ESI preferences or in the ESI service properties file as may be appropriate.
Following are classes that are typically defined in Windchill ESI preferences:
BOMOrgFilter
Preference name: Distribution Target Filter
Default value: com.ptc.windchill.esi.bom.BOMOrgFilter
* 
See the example in Publishing BOMs section for a typical use of this preference.
TreeNavigator
Preference name: Tree Navigator
Default value: com.ptc.windchill.esi.treenavigation.TreeNavigatorImpl
Following are renderer classes that are typically defined in the ESI service properties file:
ESIBOMRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <Option> element:
cardinality="duplicate"
requestor="wt.part.WTPart"
selector="BOM"
serviceClass="com.ptc.windchill.esi.bom.ESIBOMRenderer"
ESIBOMHeaderRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <Option> element:
cardinality="duplicate"
requestor="wt.part.WTPart"
selector="BOMHEADER"
serviceClass="com.ptc.windchill.esi.bom.ESIBOMHeaderRenderer"
ESIBOMComponentRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <Option>element: cardinality="duplicate"
cardinality="duplicate"
requestor="wt.part.WTPart"
selector="BOMCOMPONENT"
serviceClass="com.ptc.windchill.esi.bom.ESIBOMComponentRenderer"
ESISubstituteRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <Option> element:
cardinality="duplicate"
requestor="wt.part.WTPart"
selector="SUBSTITUTE"
serviceClass="com.ptc.windchill.esi.bom.ESISubstituteRenderer"
ESIReferenceDesignatorRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <Option> lement:
cardinality="duplicate"
requestor="wt.part.WTPart"
selector="REFERENCEDESIGNATOR"
serviceClass="com.ptc.windchill.esi.bom.ESIReferenceDesignatorRenderer
The following TreeNavigationRequestBuilder class is defined in the ESI service properties file as well:
BOMTreeNavigationReqBuilder
Service Property name: com.ptc.windchill.esi.treenavigation.TreeNavigationRequestBuilder
Default values of attributes of the <Option> element:
cardinality="duplicate"
requestor="null"
selector=" WCTYPE|wt.part.WTPart"
serviceClass="com.ptc.windchill.esi.bom.BOMTreeNavigationReqBuilder"
All of the above classes are designed to permit extensions by customizers.
BusinessRuleSetRelationshipDelegate delegate: ESIPartRelationshipDelegate class is defined in the ESI service properties file:
ESIPartRelationshipDelegate
Service Property name: com.ptc.core.businessRules.relationship.BusinessRuleSetRelationshipDelegate
Default values of attributes of the <Option> element:
cardinality="singleton"
requestor="null"
selector= "ESIPartRelationshipDelegate"
serviceClass="com.ptc.windchill.esi.businessRules.relationship.ESIPartRela tionshipDelegate"
This class can be extended to collect other associated objects with part to apply business rules. This business rule evaluation decides publication of the given assembly node as a production BOM. Similarly the class can be extended to filter out objects that the default logic has collected before applying business rule.
BOM difference logic can be customized by changing the default logic. Refer to the section Modify BOM Difference APIs for more details.
Example: A typical use of the preference Distribution Target Filter
It may sometimes be necessary to implement a business process that allows sending a "work in process" BOM to ERP early during the design process. A typical use of this may be that it provides for early procurement of tools for parts that may have long lead times. As the design evolves, there may be parts that are listed on the Windchill assembly, but which are not ready to be sent to the ERP system yet. In other words, there is a need to filter out such parts from the BOM, when they are exported to ERP. This may typically be achieved using the said preference by following the steps outlined below:
1. Create a new Java class say, com.ptc.windchill.esi.bom.BOMUsageLinkFilter that extends the class com.ptc.windchill.esi.bom.BOMOrgFilter. Provide an overridden version of the method public Enumeration filterOutput(WTPart, Enumeration) in this new class to filter out component parts from the BOM, based on a certain condition. For example, the value of a certain attribute on the WTPartUsageLink object may be used to indicate that the given component needs to be filtered out from the BOM.
2. Compile BOMUsageLinkFilter.java to create its class file in the <Windchill>\codebase\com\ptc\windchill\esi\bom directory.
3. Set the value of the Windchill ESI preference named Distribution Target Filter to com.ptc.windchill.esi.bom.BOMUsageLinkFilter.
Publishing a BOM would now cause the required filtering of components from the BOM to occur.
An example implementation of the method filterOutput() in class BOMUsageLinkFilter is shown below:
package com.ptc.windchill.esi.bom;


public class BOMUsageLinkFilter extends BOMOrgFilter
{


public Map<WTPartUsageLink, WTPart>[] filterOutput(WTPart part, Map<WTPartUsageLink, WTPart>[]partDelta) {
Map<WTPartUsageLink, WTPart>[]delta = super.filterOutput(part, partDelta);
// Perform the necessary filtering of components here, adding the remaining
// ones to a result Vector in the process
return delta;
}
Configurable Options
Windchill ESI preferences control several configurable options for Windchill ESI BOM renderer support. The options are:
Define whether ERP Connector should create alternate item groups. Alternate Item Groups are required to provide compatibility with SAP ERP. SAP manages BOM substitutes by assigning an alternate item group number to all BOM components which have substitutes. SAP determines that parts with the same alternate item group number are interchangeable.
Preference name: Enable Alternate Item Group
Default value: Yes
Define whether ERP Connector should throw an exception whenever a product structure is found that has no line number information. Standard Windchill behavior is to allow both product structures with line numbers and product structures without line numbers. Any one product structure must have line numbers on all of its components or no line numbers on any of its components. The standard Windchill behavior is the equivalent of setting the preference to "No". In cases where the target enterprise system cannot handle BOMs without line numbers, the preference should be set to Yes
Preference name: Enforce Line Numbers
Default value: No
Define whether ERP Connector should throw an exception whenever a product structure is found with components having zero quantities. The default behavior is to throw an exception.
Preference name: Require Component Quantity
Default value: Yes
Define whether ERP Connector should throw an exception when no qualifying version is found for a part master, while processing the components within an assembly.
Preference name: Show No Qualifying Version Found Error
Default value: Yes
Define whether Windchill ESI services will examine the GetBOM, GetECN and GetProcessPlan RPC request parameters to determine whether or not line numbers have been requested. If line numbers have not been requested, Windchill ESI services will generate a warning message in the Enterprise Systems Transaction Administration UI for each object that may cause a uniqueness error in SAP. This will happen when a part is listed as a substitute for more than one component on a BOM, or when a part is listed as both a component and a substitute on a BOM.
* 
By GetXXX RPC request parameters is meant the relevant distribution target attributes that provide the response settings.
Preference name: Enforce Line Number Warning for BOM
Default Value: Yes
Define the mappings between Windchill ESI views and distribution targets, via a comma separated list of <view name>:<target number> pairs. For example, a value such as Plant1:001 ,Plant2:002 would map the views Plant1 and Plant2 to the distribution targets with numbers 001 and 002 respectively. Besides driving the validation of distribution target assignments for parts, this preference plays a role in determining the value of the Usage element that is sent with the ESI response for a BOM. See the preference View To BOM Type Mappings for more information.
Preference name: View To Distribution Target Mappings
Default value: The preference is set to a blank value by default.
Defines the mappings between Windchill ESI views and BOM type (or usage) values, via a comma separated list of <view name>:<BOM usage value> pairs. For example, a value such as Design:Engineering,Manufacturing:Production would map the views Design and Manufacturing to the BOM usage values Engineering and Production respectively.
When publishing a BOM to a given distribution target, ESI services first determine the view corresponding to the target from the preference View To Distribution Target Mappings. The preference View To BOM Type Mappings is then looked up for the BOM usage value corresponding to the view fetched from the previous step. It is this value that will be sent with the Usage element for the BOM in the response, thereby overriding any usage that may have been set on the BOM header iteration.
Preference name: View To BOM Type Mappings
Default value: The preference is set to a blank value by default.
Defines whether or not to send part data in the ESI response for an alternate assembly. If set to Yes, ESI services will send part data for an alternate assembly. If set to No, no part data will be sent for such an assembly. This preference can come in handy when parts are to be created in the ERP system only while publishing a regular assembly as opposed to an alternate assembly.
Preference name: Send Part Data For Alternate Assemblies
Default value: Yes
Defines whether to return unchanged objects information in the ESI response. Select Yes to render unchanged objects and No to ignore unchanged objects.
Preference name: Render Unchanged Objects
Default value: Yes
* 
Setting the preference to No would cause only unchanged parts and BOM components to be ignored while generating the ESI response.
Specifies whether or not to send BOM data with the ESI response when publishing alternate parts. When set to Yes, BOM data is sent for alternate parts that are assemblies. When set to "No", only part data is sent for such parts. This preference assumes significance only when the distribution target attribute for publishing alternates has a value Yes
Preference name: Send BOM Data For Alternates
Default value: No
Specifies whether or not to send BOM data with the ESI response when publishing substitute parts. When set to Yes, BOM data is sent for substitute parts that are assemblies. When set to "No", only part data is sent for such parts. This preference assumes significance only when the distribution target attribute for publishing substitutes has a value Yes.
Preference name: Send BOM Data For Substitutes
Default value: No
Define whether ERP Connector should publish the production BOM for a Part node with children or just send a part to the downstream. This allows the user the flexibility of selectively publishing production BOM for certain parts in the given bill of material. This preference should be used in combination with the distribution attribute Always publish Production BOM for a Part when Publishing a BOM. Thus when prefence is set with business rule set then by setting target attribute along with it to ‘Yes/No’ rules can be applied selectively to only one or more set of targets depending on the need. Refer to the Windchill Help Center topic Configuration option to Inhibit Publishing of a Production BOM to know more this feature.
Preference name: Business rule set to inhibit production BOM publishing
Default value: Blank value
Define how publishing incremental information to a distribution target for BOM should be processed. Since Windchill release 10.2 M030 onwards, ERP Connector compares parts with ‘view’, ‘variation1’, ‘variation2’ attributes and version and iteration of the object. Users who do not want to use this new default behavior can revert back to the older behavior by setting the following Windchill property to false. Older implementation will compare parts based on version or iteration and by comparing ‘variation1’, ‘variation2’ attributes only. This property is optional and is not available out of the box in esi.properties file. For more information on calculating the difference, see section Publishing Incremental Information for Equivalent BOMS to a Distribution Target in topic Bills of Material.
Windchill property name: com.ptc.windchill.esi.CalculateDeltaUsingLatestPublishedObject
Default value:true
With the default setting in place, the latest published iteration of an object (rather than the latest as per the version series) is considered for computing the delta for incremental publication. For e.g., if version A.2 of the object is published after version B.1, the former (A.2) will be considered for delta computation.
Steps to change the default behavior
1. Add the following property to site.xconf to propagate the changes to behavior
<Property name="com.ptc.windchill.esi.CalculateDeltaUsingLatestPublishedOb ject" overridable="true" targetFile="codebase/com/ptc/windchill/esi/esi.properties" value="false"/>
2. Propagate changes to esi.properties
3. Restart Windchill services.
There are several configurable attributes on the distribution target that impact the contents of the ESI response message when publishing an assembly.
Refer to the section "Attributes Pertaining to a BOM" under the topic "Distribution Target Attributes" in the Windchill Help Center for more details.
Publishing VariantSpec
Overview
When a variant is created in a part structure, Windchill stores the configSpecs, options, choices and parameter inputs in a variant specification and associates it with the variant. A variant specification is a collection of inputs and selections specified for a configurable structure in preparation for creating a variant. ERP Connector allows publishing of assigned VariantSpec when ESI Options and Variants is installed along with ERP Connector, along with the part information when the BOM is published. The variant specification is published only if the distribution target attribute Publish the Associated Variant Specification when Publishing an Object is set to Yes. The default value of this attribute is No.
When publishing a variant specification, the configuration specifications which are Latest, AsMatured, Baseline, Unit Effectivity, Promotion Request, Date Effectivity and filter information for Option filter and Attribute filter is published as well. Windchill ESI services make use of certain renderers for processing and its related objects, all of which extend the class BasicESIRenderer. These render classes are described in the Variant Spec Classes section of this document.
Publishing ModuleVariantInformationLink
ModuleVariantInformationLink is a version-to-version link from WTPart to the VariantSpec. ERP Connector enables you to publish this link along with the BOM when ESI Options and Variants is installed along with the part and variant spec information. This link and the associated VariantSpec is published only when the distribution target attribute Publish the Associated Variant Specification when Publishing an Object is set to Yes. The default value of this attribute is No.
BasicESIRenderer
This is the abstract class implementing the interface ESIRenderer and is extended by the variant specification and related renderer classes provided by ESI services. See section Classes for more information on BasicESIRenderer.
VariantSpecRenderer
It belongs to the package com.ptc.windchill.esi.ov and is extendable for customization. The class is instantiated when publishing a BOM structure, having an assigned variant specification and a certain distribution target attribute is set.
Refer to the Windchill release specific Java Documentation for more details on available attributes and methods in the class.
* 
The renderer has methods for processing navigation criteria of the variant specification besides the VariantSpec itself.
When the distribution target attribute Publish the Associated Variant Specification when Publishing an Object is set to Yes, ESI services processes the assigned VariantSpec (if any), on publishing a BOM structure.
On publishing a variant specification, its related configuration specifications, Option filter and attribute are also published. The VariantSpecRenderer renderer uses ConfigSpecRenderer and FilterRenderer for this purpose.
ConfigSpecRenderer
It belongs to the package com.ptc.windchill.esi.ov and is extendable by customizers. The class is instantiated by the buildGroups() API which in turns calls the renderConfigSpec() API of class VarinatSpecRenderer for processing all the configSpecs related to a VariantSpec. This class extends from NavigationCriteriaAssociatedObjectRenderer which in turn extends from BasicESIRenderer. It is used to initialize the data required for ConfigSpec renderer and FilterRenderer.
Refer to the Windchill release specific Java Documentation for more details on available attributes and methods in the class.
* 
The renderer processes all the configSpecs which are mentioned in the above sections.
There is an <ESIPartConfigSpec> element in the ESI response for each type of configuration specification that is present in the published VariantSpec. The element contains the attribute Class through which you can identify the type of configuration that is published. Also, the element contains the Product_Configuration_ObjectID attribute that denotes the ConfigSpec is part of which VariantSpec.
FilterRenderer
It belongs to the package com.ptc.windchill.esi.ov and is extendable by customizers. The class is instantiated by the buildGroups() API which in turns call the renderFilters() API of class VarinatSpecRenderer for processing all the Option Filter and Attribute Filter related to a VariantSpec. This class extends from NavigationCriteriaAssociatedObjectRenderer which in turn extends from BasicESIRenderer. It is used to initialize the data required for ConfigSpec renderer and FilterRenderer.
Refer to the Windchill release specific Java Documentation for more details on available attributes and methods in the class.
* 
The renderer processes only the following types of filter- Option Filter and Attribute Filter.
The renderer also has methods to publish the OptionFilter related ConfigSpec.
electedChoicesInfoRenderer
It belongs to the package com.ptc.windchill.esi.ov and is extendable by customizers. The class is instantiated by the buildGroups() API which in turns call the renderOptionsAncChoices() API of class FilterRenderer for processing all the selected choices and options information of the OptionFilter. This class extends form BasicESIRenderer.
Refer to the Windchill release specific Java Documentation for more details on available attributes and methods in the class.
OptionsVariantsHelper
It belongs to the package com.ptc.windhill.esi.ov and is not meant to be extended by customizers. The class provides renderAssocVarinatSPec method which takes in the Part object for which the VariantSppec has to be published, the Authentication String, VdbBuilder instance and Collection of VariantSpec.
Refer to the Windchill release specific Java Documentation for more details on available attributes and methods in the class.
Customization Point
Extendable classes
If there are different type of Variant Spec, filters, or ConfigSpec that are resent OOTB then, you have to create your own renderers for the above objects and register them with the "service.properties" file for the respective selectors. Below are the selectors and the OOTB renderer files which you can use.
VariantSpecRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <Product_Configuration> element:
<Option cardinality="duplicate"
requestor="com.ptc.wpcfg.doc.VariantSpec"
selector="VARIANTSPEC"
serviceClass="com.ptc.windchill.esi.ov.VariantSpecRenderer"/>
ConfigSpecRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <ESIPartConfigSpec> lement:
<Option cardinality="duplicate"
requestor="wt.vc.config.ConfigSpec"
selector="CONFIGSPECRENDERER"
serviceClass="com.ptc.windchill.esi.ov.ConfigSpecRenderer"/>
If a user wants to add a new ConfigSpec which is not provided OOTB, then override renderConfigSpec method. If the newly added configSpec is of the type WTPartConfigSpec then user can just override the adjustConfigSpecElement to add their own logic to display the added configSpec
FilterRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <ESIOptionFilter> element:
<Option cardinality="duplicate"
requestor="wt.filter.NavigationFilter2"
selector="NAVIGATIONFILTER"serviceClass="com.ptc.windchill.esi.ov.FilterRenderer"/>
SelectedChoicesInfoRenderer
Service Property name: com.ptc.windchill.esi.rnd.ESIRenderer
Default values of attributes of the <ESISelectedChoices> element:
<Option cardinality="duplicate"
requestor="com.ptc.windchill.option.model.Option"
selector="SELECTEDCHOICESINFO"
serviceClass="com.ptc.windchill.esi.ov.SelectedChoicesInfoRenderer"/>
Changing the type of the VariantSpec/ Customized logic to render VariantSPec attached to the part:
If you have own logic to render the Variant Spec object then: Override renderAssociatedVariantSpec method in BasicEsiRenderer to write logic to fetch the collection of VariantSpec associated to the part.
This API internally calls renderAssocVariantSpec of BasicEsiRenderer which dynamically invokes the method renderAssocVariantSpec of OptionsVarinatHelper class.
This method is responsible for calling the buildGroup() method of VariantSpecRenderer.
Adding a new Filter
Update ESI ResponseMetaInfo.xml for rendering Additional Filter object.
Add the filter MapInfo in the Group Information of Added_Product_Configuration to render it along with the Variant Spec bucket.
Create a new FilterRenderer (eg. CustomizedFilterRenderer) by extending either of
1. NavigationCriteriaAssociatedObjectRenderer and adding own logic for all the filters to be rendered or by extending
2. FilterRenderer and adding the logic for showing a new Filter in it by overriding the buildGroup() API.
Register the new FilterRenderer in the xconf file against the NAVIGATIONFILTER elector
Adding a new ConfigSpec
Update ESI ResponseMetaInfo.xml for rendering Additional ConfigSpec object.
Add the new configSPec MapInfo in the Group Information of Added_Product_Configuration to render it along with the Variant Spec bucket.
1. NavigationCriteriaAssociatedObjectRenderer and adding own logic for all the configSpecs to be rendered including the OOTB one or by extending
2. ConfigSpecRenderer and adding the logic for showing a new ConfigSpec in it by overriding the renderConfigSpec () API.
If the newly added configSpec is of the type WTPartConfigSpec then user can just override the adjustConfigSpecElement() to add their own logic to display the added configSpec.
Register the new FilterRenderer in the xconf file against the CONFIGSPECRENDERER elector
Was this helpful?