Points to note while modifying the ESI response information file
Keep the following in mind while modifying the contents of the response meta information file:
1. Do not modify the file directly from the default location; always create a copy of the file and modify it. Updating the installation to a subsequent maintenance release could wipe out your changes, if you modified the file directly. Also, you may want to create modified versions of the response meta information file and associate them to distribution targets, when there is a need for those targets to receive custom data
2. When modifying a Map element, ensure that its id attribute has a unique value; in other words, the value should not be used by any other Map element in the same or any other active version of the file. If this condition is not met, an error will be thrown when attempting to save a distribution target that references the modified file.
3. When creating a Map element with a new id attribute, create a MapInformation element as well whose mapReference element’s content equals the value of the id attribute. Alternatively, the mapRef element of an existing MapInformation element can bemodified as appropriate.
4. Do not modify the id attribute of a Map element unless its contents are changed.
5. When creating a new (or modifying an existing) MapInformation element, ensure that its id attribute has a unique value within the file. It is recommended that this value is unique across different versions of the file, although not essential.
6. When creating a MapInformation element with a new id attribute, ensure that a GroupInformation element exists in the file whose mapInformationRef element’s content equals the value of the id attribute.
7. It is an error to change the value of the logicalName element of any GroupInformation element. Values of physicalName elements may be modified, but this will almostalways require modifying the file
<Windchill>/tasks/com/ptc/windchill/esi/lite/GetPostResultInfoForTarget.xsl as appropriate.
8. When there is a need to publish ERP Material (or plant specific) attributes for a part,
a. add the relevant attributeMapping entries to the Map element for parts
b. set the XML attribute erpMaterialAttribute (or plantSpecificAttribute ) to true as appropriate.
9. In order for changes to the response meta information file that is already referenced by a target to take effect,
a. re-start the MethodServer or
b. toggle the Status attribute of the referencing target from Active to Inactive, save and reset the attribute once again toActive.
10. When publishing a soft type (or a modeled) extension of an object, the response meta information file would require changes only if there is a need to publish a different set of attributes for the extension as compared to the object that was extended. In other words, the default version of the file itself will suffice, as long as the extension has the same set of attributes as the parent object.
11. When adding a <GroupInformation> element that represents a custom group, remember to set its attribute "isUnchanged" if appropriate, as shown below:
<esi:GroupInformation isUnchanged="true" >
<esi:logicalName>MyUnchangedType</esi:logicalName >
...
</esi:GroupInformation>
In the above example, the custom group named "MyUnchangedType" is meant to hold unchanged data in the ESI response, thereby requiring the attribute "isUnchanged" to be set to "true".
Contents of the response meta information file impact the ESI response message onlywhen generating the message in XML format (i.e., when the distribution target attribute ESI Response Output Format is set to ESI XML ). In other words, the file has no role to play whatsoever, when generating the ESI response in PLM format.
Was this helpful?