Manifest References
- Last UpdatedNov 17, 2025
- 3 minute read
The following table lists the supported manifest attribute placeholders:
|
File Object Attribute Placeholder |
Value |
|---|---|
|
#TYPE# |
Fixed value "manifest". |
|
#MANIFEST# |
Fixed value "AC3D". |
|
#CURRENT_USER# |
User name of the person who is currently logged on to the Windows operating system during execution. |
|
#GRAPHICS_FORMAT# |
Fixed value "tessellated". |
|
#INPUT_LOCATION# |
Full path of the input .DWG/.DXF file. |
|
#INPUT_FOLDER# |
Parent directory of the input .DWG/.DXF file. |
|
#MODEL_NAME# |
Derived from the input .DWG/.DXF filename excluding its extension. |
|
#DEFINED_SEGMENTS# |
FALSE
|
|
#KEEP_FOLDER_TREE# |
TRUE, if input folder hierarchy is preserved in output generation. |
|
#TARGET_LOCATION# |
Output folder path. |
|
#SEGMENT_NAME# |
Segment name of the graphics drawing. |
|
#UNITS# |
Source drawing units. |
Note: Do not change the following attributes:
-
#INPUT_FOLDER#
-
#TYPE#
-
#MANIFEST#
-
#CURRENT_USER#
-
#GRAPHICS_FORMAT#
-
#INPUT_LOCATION#
-
#INPUT_FOLDER#
-
#KEEP_FOLDER_TREE#
The following mapping entry indicates how to use any of the Manifest attribute values. For example, to add a new attribute named IDENTIFIER with the value of the manifest "#MODEL_NAME#" attribute, into all the objects that match the condition where the Tag attribute is present. As attribute "#MODEL_NAME#" belongs to the associated document object you must use the prefix "associated:" to resolve the value from its associated objects.
<Object>
<IncludeAssociatedObjectAttributes type="^is referenced in$" refID="associated">
<Conditions>
<Attribute name = "#TYPE#" pattern = "^manifest$" />
</Conditions>
</IncludeAssociatedObjectAttributes>
<ObjectID value="[Id]" />
<Attributes>
<Attribute name="Tag" pattern="^[A-Za-z]+$" >
<Name value="IDENTIFIER" />
<Value value="[associated:#MODEL_NAME#] [Tag]" />
</Attribute>
</Attributes>
</Object>
User-Defined Manifest Attributes
You can define your own list of custom attributes, which can be used during transformation as other pre-defined manifest attributes. The following is the way to add these user-defined manifest attributes to the configuration file.
<ManifestAttributes>
<Attribute name="USER_ATTRIBUTE1" value="VALUE1" />
<Attribute name="#USER_ATTRIBUTE2#" value="VALUE2" />
</ManifestAttributes>
These user-defined manifest attributes can then be referenced during transformation to resolve other values.
<Object>
<IncludeAssociatedObjectAttributes type="^is referenced in$" refID="associated">
<Conditions>
<Attribute name = "#TYPE#" pattern = "^manifest$" />
</Conditions>
</IncludeAssociatedObjectAttributes>
</Attributes>
<Attribute name="Tag" pattern="^[A-Za-z]+$" >
<Name value="IDENTIFIER" />
<Value value="[associated:USER_ATTRIBUTE1] [Tag]" />
</Attribute>
<Attribute>
<Name value="User Attribute" />
<Value value="[associated:#USER_ATTRIBUTE2#]" />
</Attribute>
</Attributes>
</Object>
The above mapping entry indicates that for all the objects matching the condition, if the Tag attribute is present in this object, then a new attribute named IDENTIFIER is added. The attribute value is taken from the value of the user-defined manifest attribute "USER_ATTRIBUTE1", appended with the Tag attribute value. It also creates a new attribute named "User Attribute" whose value is taken from the value of the user-defined manifest attribute "#USER_ATTRIBUTE2#".
Review from here: https://dev.azure.com/AVEVA-VSTS/Interoperability/_workitems/edit/4110096/
You can also include user defined manifest attributes in conditions to be used for filtering by using the <Conditions> attribute "manifestMatch". Consider the below example:
<Object>
<Conditions>
<Attribute name="USER_DEFINED_ATTR" manifestMatch=" USER_ATTRIBUTE1" />
</Conditions>
<Attributes>
<Attribute>
<Name value="User Attribute" />
<Value value="[USER_ATTRIBUTE1]" />
</Attribute>
</Attributes>
</Object>
In this example, the manifestMatch parameter is used to select only objects that both have an attribute named "USER_DEFINED_ATTR" and this attribute value matches the value of the manifest object’s attribute named "USER_ATTRIBUTE1". The <Attributes> node will then update or create an attribute named "User Attribute" with the value of the manifest attribute "USER_ATTRIBUTE1". Note that when the manifestMatch parameter is used, the Gateway automatically makes the manifest object’s attributes available when assigning values, so that <IncludeAssociatedObjectAttributes> of the "is referenced in" association is not needed nor do you need to refer to manifest attributes with "associated:" prefix.
End review here
Note: Manifest attributes can also be defined on the command line. For more information, see Running the Gateway from the Command Line.
The document object's class is read from an attribute named ClassID.
By default, its value is 3D Model derived from the #MODEL_NAME# value, but it can be changed in base mapping configuration by identifying the document object in a Conditions statement and updating the "ClassID" attribute value:
<Object>
<Conditions>
<Attribute name="#type#" pattern="manifest" />
</Conditions>
<Attributes>
<Attribute name="ClassID">
<Value value= "Test class"/>
</Attribute>
</Attributes>
</Object>
Note: You must not remove either the Manifest object or any of its attributes as these attributes such as #MODEL_NAME#, #TARGET_LOCATION# are needed for loader functions. You can control whether the Manifest object is included in the EIWM as the Document object via the createDocumentObject option. For more information, see Load Settings.
The following example shows how to remove the attributes from other objects without affecting the Manifest object.
<ObjectMappings regExTimeoutSecs="10">
<Object>
<Conditions>
<Attribute name="#TYPE#" pattern="manifest$" />
</Conditions>
<TemplateID id ="default" />
</Object>
<Object>
<TemplateID id ="default" />
<ObjectID value="[TAG]"/>
<ClassID value ="[Classification]" />
<Attributes>
<Attribute name="*" >
<Remove />
</Attribute>
</Attributes>
</Object>
</ObjectMappings>