Customization Examples

Advanced Customization > Windchill ESI Customization > Windchill ESI Customization—Oracle Applications > Middleware Customization Examples: > Example 3: How to configure for different BOM usage or BOM type for a given assembly > Customization Examples

The examples in this section focus only on what needs to happen in ESI services in order for newly added attributes to appear in the ESI RPC response. They do not cover any changes that may be needed in the middleware business logic or configuration settings that may be needed in SAP. See relevant sections in this guide for information on how the middleware business logic may be customized or the target SAP system may be configured, to account for additional attributes that may get sent with the ESI response.

Publish a part with an additional attribute

The additional attribute could be a modeled or a soft attribute, or it could be an IBA. Let the attribute be named standardPrice. Perform the following steps in order that this attribute gets sent with the ESI response:

i. Add standardPrice to WTPart either as a soft attribute using the Type and Attribute Management UI, or as an IBA. Alternatively, it could be added as a soft attribute on a soft type extension of WTPart, or as a modeled attribute (in which case, the Windchill ESI preference “Part Class” should be edited so that it points to the fully qualified name of the WTPart extension class).

ii. Create a copy of the ESI response meta information file and modify its contents as outlined below:

<esi:Map id="ESINewPart">
<esi:attributeMapping sourceAttribute="obid">ObjectID</esi:attributeMapping>
…
<esi:attributeMapping sourceAttribute="iterationInfo.identifier.iterationId">Iteration</esi:attributeMapping>
<esi:attributeMapping sourceAttribute="PreviousVersion">PreviousVersion</esi:attributeMapping>
<esi:attributeMapping sourceAttribute="standardPrice">StandardPrice</esi:attributeMapping>
</esi:Map>

<esi:MapInformation id="ESIPartInfo">
<esi:typedef>wt.part.WTPart</esi:typedef>
<esi:elementMetaName>Part</esi:elementMetaName>
<esi:keyAttribute>ObjectID</esi:keyAttribute>
<esi:mapRef>ESINewPart</esi:mapRef>
</esi:MapInformation>

As can be seen from the portions shown highlighted above, the Map and the MapInformation elements (that have “ESIPart” and “ESIPartInfo” as values for their id attribute) require changes. The Map element has its id attribute set to a modified value, and has a new attributeMapping element added for the attribute standardPrice. Also, the mapRef element of the relevant MapInformation element has its value set to the modified value of the id attribute of the Map element.

Any change to the Map element must be accompanied by a change to the value of its id attribute. Also, if adding a new attribute (such as standardPrice) results in a new extension of WTPart, the fully qualified name of that type should be provided as value for the typedef element of the MapInformation element. See section Modify the ESI Response Meta Information File for more information on how to modify the ESI response meta information file.

iii. Using the Manage Distribution UI (that appears under Site->Utilities or Organization->Utilities), bring up the Edit Distribution Target UI for the distribution target to which to publish the part. Set the ESI Response Meta Information File Path field to point to the file that was modified in step (ii). Save the distribution target by clicking OK. Associate the edited target to the part being published, if it is not already associated.

Publishing the part now (with the attribute standardPrice set to the required value) should cause the newly added attribute, viz., StandardPrice to be sent with the ESI response for the distribution target that was edited in step (iii). If the part were published for the first time, a child XML element <StandardPrice> will appear within the <Part> element in the <AddedParts> section of the response. Clearly, the above described use case simply calls for modifying the response meta information file, and in that sense does not require any customization.

• The position of the <StandardPrice> element within the <Part> element in the response would depend on where in the Map element (of the response meta information file) the new entry is added. For example, if it is added as the last entry in the Map element as illustrated in the above example, <StandardPrice> would appear as the last child element within the <Part> element in the response.

• When publishing a soft type (or a modeled) extension of a WTPart, the ESI response meta information file would require changes (as described in step ii above) only if there is a need to publish a different set of attributes for the extension as compared to the WTPart object. See section Points to note while modifying the ESI response information file for more information.

Publish a part with extra information

One may sometimes want to send extra information in the <Part> element in the ESI response, that does not reside on the WTPart object as an attribute – for e.g., a child XML element called <IsAssembly> that tells whether or not the given part is an assembly. The following steps need to be performed in order that this child element appears in the ESI response:

i. Create a copy of the ESI response meta information file and modify its contents as outlined below:

<esi:Map id="ESINewPart">
<esi:attributeMapping sourceAttribute="obid">ObjectID</esi:attributeMapping>
…
<esi:attributeMapping sourceAttribute="isAssembly">IsAssembly</esi:attributeMapping>
</esi:Map>
<esi:MapInformation id="ESIPartInfo">
<esi:typedef>wt.part.WTPart</esi:typedef>
<esi:elementMetaName>Part</esi:elementMetaName>
<esi:keyAttribute>ObjectID</esi:keyAttribute>
<esi:mapRef>ESINewPart</esi:mapRef>
</esi:MapInformation>

See section Modify the ESI Response Meta Information File for more information on how to modify the contents of the ESI response meta information file.

ii. Create an extension of the class com.ptc.windchill.esi.esipart.ESIWTPartRenderer and override the adjustPartElement() method as follows:

protected Element adjustPartElement( Element element, String group, WTPart part, Eff[] effs, Collection targets )
throws ESIRendererException { boolean isAssem;
try {
isAssem = new BOMUtility().isBom(part);
}
catch(WTException wte) {
ESILogger.debug("Exception while invoking isBom() for part: " + part.getNumber());
throw new ESIRendererException(wte);
}

Att att = element.getAtt(“IsAssembly”);

if(att != null && (att.getValue() == null || att.getValue().toString().trim().equals(“”)))
{
att.setValue(String.valueOf(isAssem));
}

return element;
}

iii. Using the Manage Distribution UI (that appears under Site->Utilities or Organization->Utilities), bring up the Edit Distribution Target UI for the distribution target to which to publish the part. Set the ESI Response Meta Information File Path field to point to the file that was modified in step (i). Save the distribution target by clicking OK. Associate the edited target to the part being published, if it is not already associated.

iv. Open the file <Windchill>\codebase\com\ptc\windchill\esi\conf\esi.service.properties.xconf and look for the following entry:

Edit the above entry so that the serviceClass attribute has the fully qualified name of the extension of ESIWTPartRenderer (that was created in step (ii)) as its value. See section 3.7.4.1 for more information.

v. Run the command “xconfmanager –p” from the Windchill shell so that the change made in step (iv) is propagated appropriately. Re-start the MethodServer.

Publishing the part now would result in the <IsAssembly> element getting sent with the ESI response. Observe that this use case calls for customizing the part renderer, since it requires sending information that does not reside as an attribute on a WTPart object, meaning it cannot be fetched using the Query-Objects webject.

Publish an assembly with an added attribute on the header part

This example would require following the same set of steps as those described in section 10.1.2.1, except that the Map and MapInformation elements of the response meta information file referenced in step (ii) would be for a BOM header. In other words, the Map element having the value “BOMHeader” for its id attribute would carry a new attributeMapping element; also, the id attribute of the Map element would carry a modified value (such as “NewBOMHeader”) and the mapRef element of the relevant MapInformation element would carry this modified value. Also, when publishing the assembly for the first time, a new child XML element (corresponding to the added attribute) would appear in the <BOMHeader> element in the <AddedBOMs> section of the response.

Publish an assembly with extra information

Again, this example would require following the same set of steps as those described in section 10.1.2.2, except that the Map and MapInformation elements of the response meta information file referenced in step (i) would be the ones with values “BOMHeader” and “BOMHeaderInfo” respectively. Also, the Java class to be extended would be com.ptc.windchill.esi.bom.ESIBOMHeaderRenderer and the method to override would be the following:

protected Element adjustElement( Element element, String group, WTPart part, Eff[] effs, Collection targets) throws ESIRendererException

Also, the ESI service property entry to edit would be:

Edit the above entry so that the serviceClass attribute has the fully qualified name of the extension of ESIBOMHeaderRenderer. Propagate this property the usual way and re-start the MethodServer.

Publishing the assembly now would result in the required extra information getting sent with the ESI response. This would appear as a newly added child XML element in the <BOMHeader> element of the ESI response.

Publish an assembly with an added attribute on WTPartUsageLink

This example considers publishing a soft attribute that is added to the WTPartUsageLink object that links the assembly part to a certain part master. Let the soft attribute be named color. Perform the following steps in order that this attribute gets sent with the ESI response:

i. Add color as a soft attribute on WTPartUsageLink, using the Type and Attribute Management UI the usual way.

ii. Create a copy of the ESI response meta information file and modify its contents as outlined below:

<esi:Map id="NewBOMComponent">
<esi:attributeMapping sourceAttribute="PartMasterID">ObjectID</esi:attributeMapping>
…
<esi:attributeMapping sourceAttribute="PartUsageLink.ComponentId">ComponentId</esi:attributeMapping>
<esi:attributeMapping sourceAttribute="xxxx">IsChildPhantom</esi:attributeMapping>
<esi:attributeMapping sourceAttribute="color">Color</esi:attributeMapping>
</esi:Map>

<esi:MapInformation id="BOMComponentInfo">
<esi:typedef>wt.part.WTPartUsageLink</esi:typedef>
...
<esi:mapRef>NewBOMComponent</esi:mapRef>
</esi:MapInformation>

As can be seen from the portions shown highlighted above, the Map and the MapInformation elements (that have “BOMComponent” and “BOMComponentInfo” as values for their id attribute) require changes. The Map element has its id attribute set to a modified value, and has a new attributeMapping element added for the attribute color. Also, the mapRef element of the relevant MapInformation element has its value set to the modified value of the id attribute of the Map element.

iii Using the Manage Distribution UI (that appears under Site->Utilities or Organization->Utilities), bring up the Edit Distribution Target UI for the distribution target to which to publish the assembly. Set the ESI Response Meta Information File Path field to point to the file that was modified in step (ii). Save the distribution target by clicking OK. Associate the edited target to the assembly (and its component parts) being published, if it is not already associated.

Publishing the assembly now (with the attribute color set to the required value on each of its components) should cause the newly added attribute, viz., Color to be sent with the ESI response. If the assembly were published for the first time, a child XML element <Color> will appear within the <BOMComponent> element in the <AddedBOMComponents> section of the response. Clearly, the above described use case simply calls for modifying the response meta information file, and in that sense does not require any customization.

The position of the <Color> element within the <BOMComponent> element in the ESI response would depend on where in the Map element of the response meta information file the new entry is added.

8.8.3.6 Publish an assembly with added information on the component part

It may sometimes be necessary to send some extra information in the <BOMComponent> element in the ESI response - for e.g., a child element <IsEndItem> that tells whether or not the given component part is an end item. This may be achieved by performing the following steps:

i. Create a copy of the response meta information file and modify its contents as outlined below:

<esi:Map id="NewBOMComponent">
<esi:attributeMapping sourceAttribute="PartMasterID">ObjectID</esi:attributeMapping>
…
<esi:attributeMapping sourceAttribute="PartUsageLink.ComponentId">ComponentId</esi:attributeMapping>
<esi:attributeMapping sourceAttribute="xxxx">IsChildPhantom</esi:attributeMapping>
<esi:attributeMapping sourceAttribute="isEndItem">IsEndItem</esi:attributeMapping>
</esi:Map>

<esi:MapInformation id="BOMComponentInfo">
<esi:typedef>wt.part.WTPartUsageLink</esi:typedef>
...
<esi:mapRef>NewBOMComponent</esi:mapRef>
</esi:MapInformation>

ii. Create an extension of the class ESIBOMComponentRenderer and override the method adjustElement(Element, String, PartUsageInfo, Collection) as follows:

protected Element adjustElement(Element elem, String group, PartUsageInfo pui, Collection targets )

throws ESIRendererException { Att att = elem.getAtt(“IsEndItem”);
if(att != null && (att.getValue() == null || att.getValue().toString().trim().equals(NULL_STRING)))
{
boolean endItem = pui.getPartMaster().isEndItem(); String endItemAsStr = String.valueOf(endItem);

att.setValue(endItemAsStr);
}

return elem;
}

iii. Using the Manage Distribution UI (that appears under Site->Utilities or Organization->Utilities), bring up the Edit Distribution Target UI for the distribution target to which to publish the assembly. Set the ESI Response Meta Information File Path field to point to the file that was modified in step (i). Save the distribution target by clicking OK. Associate the edited target to the assembly (and its component parts) being published, if it is not already associated.

iv. Open the file <Windchill>\codebase\com\ptc\windchill\esi\conf\esi.service.properties.xconf and look for the following entry:

Edit the above entry so that the serviceClass attribute has the fully qualified name of the extension of ESIBOMComponentRenderer (that was created in step (ii)) as its value.

v. Run the command “xconfmanager –p” from the Windchill shell so that the change made in step (iv) is propagated appropriately. Re-start the MethodServer.

Publishing the assembly now would result in the <IsEndItem> element getting sent with the ESI response. Observe that this use case calls for customizing the BOM component renderer, since it requires sending information that does not reside as an attribute on a WTPartUsageLink object, meaning it cannot be fetched using the Query-Objects webject.

8.8.3.7 Publish an assembly with a usage different from what may be set on the assembly part iteration

The usage value that is set on an assembly part iteration using the BOM Transformer can be overridden when publishing the assembly. This requires performing the following steps:

i. Set the Windchill ESI preference View To Distribution Target Mappings to a value that relates a Windchill view to the distribution target that the assembly is being published to. For example, if the assembly was created in the Design view and is to be published to a distribution target having the value 00001 for its Number attribute, the preference may be set to Design:00001.

ii. Set the Windchill ESI preference View To BOM Type Mappings to a value that relates a Windchill view to the required BOM usage value. For example, if the assembly is to be published as an Engineering one, the preference may be set to Design:Engineering.

The said preferences may be set either for Site or for an organization, depending on whether the assembly resides in Site or within an organization.

iii. Associate the distribution target with number 00001 to the assembly in question and release the assembly.

If the attribute Default for Context has a value Yes for the distribution target, the settings described in (i) will ensure that the target is automatically associated to the assembly part.

The above will result in the assembly being sent as an Engineering one, as can be seen from the content of the Usage element in the ESI response for the released assembly. It is important to keep in mind that the value sent thus will override any other BOM Usage value that may have been set on the assembly part iteration using the BOM Transformer.

8.8.3.8 Publish different usages of an assembly to the same plant in Oracle

One may want to publish different usages (say, Engineering and Production) of an assembly to the same plant in Oracle. This will call for performing the following steps:

i. Using the New Distribution Target UI, create an Oracle distribution target, setting its Number attribute to say, 00001 and its Plant attribute to 1100 (where 1100 is a valid plant name in the target Oracle system). Set the other attributes of the distribution target as appropriate.

ii. Create a second Oracle distribution target, setting its Number attribute to say, 00002. Set the other attributes pertaining to the Oracle system (such as Plant, System ID and Client) to exactly the same values as for the target created in step (i).

iii. Set the Windchill ESI preference View To Distribution Target Mappings to Design:00001,Manufacturing:00002.

iv. Set the Windchill ESI preference View To BOM Type Mappings to Design:Engineering,Manufacturing:Production.

v. Associate both the distribution targets 00001 and 00002 to the assembly (and its component parts) and release the assembly.

The above will result in the assembly being sent as an Engineering BOM to the distribution target with number 00001 and as a Production BOM to the distribution target with number 00002. However, since both the targets point to the same plant in Oracle, the middleware business logic will end up publishing both the usages of the assembly to the same plant.

An underlying assumption here is that the assembly and its component parts were created in the Design view in Windchill, so that both the distribution targets (00001 and 00002) may be associated to them.

Was this helpful?