Appendix B: CSV Reporting

Save PDF

Last UpdatedFeb 15, 2026
8 minute read

The extracted data and the way they are transformed can be inspected at any point during the processing by creating a CSV report from the selected data. The selection of data to be included in CSV reporting is defined by the Transform and Loader configuration extensions. CSV files may include attributes or associations, which are selected in columns keyword in the configuration file. Each transformation configuration extension represents a step in the transformation process, so you should position this CSV reporting configuration at the appropriate transformation step to access the state of the data due to all previous transformation steps. A CSV report of the final transformed data that is converted to EIWM format can also be generated in the loader configuration.

Note: If there are more than one million rows to be written then a warning is logged and the CSV output is segmented into multiple files, with an underscore plus index number added to the extra file names to keep them unique, for example: <filename>_1.csv, <filename>_2.csv, and so on.

Reporting during transformation configured in Transform configuration file

This feature generates the CSV report during transformation and customizes the type of the information written to the CSV file. Generate multiple reports by using different suffixes and output paths for CSV files.

Example 1: CSV Reporting section with basic attributes, from Transform configuration file

<csvReport

suffix="_AfterTransformation"

addHeaderRow="true"

columns="ClassID, ObjectID, ClassName, Name, #Association:Referenced"

</extension>

Example 2: CSV Reporting section with tracking attributes, from Transform configuration file:

<extension name="CSVReporting">

<csvReport

suffix="_AfterTransformation"

addHeaderRow="true"

columns="#InternalId#, ClassName">

<column value="#Tracking:

DateTime

ModuleName

EventType

ChangedMember

PrevAttributeName

AttributeName

PrevAttributeValue

AttributeValue

PrevAssociationType

AssociationType

ChangedMember

PrevTargetInternalId

TargetInternalId

#Filter: EventType: AttributeChanged"

/>

</csvReport>

</extension>

Notes:

The optional 'annotations' feature described in provides additional information which also can be reported. In the above example, after keyword #Tracking: there are listed tracking attributes that store data about creation, modification and deletion operations and can be inspected via CSV reporting as any other information.
Multiple attributes and keywords are separated by commas, but multiple parameters for a # keyword are part of the keyword definition and so are separated by spaces or end of line characters, see Example 2 above.
Limitation: Tracking attributes are not generated for expand and interpolate transformation used under ObjectID node.
Reporting after transformation configured from GUI

This CSV report is generated when CSV value is selected in Data Output Type combo list in Load>CSV panel. This report reflects the extracted data state after all transformations. Report file with .CSV extension is generated in the location set in Output Path field.

GUI Settings in the Load > CSV panel:

Settings

The following list details about the CSV Report features for the Transform and the Load configurations:

columns = "<keywords, names...>": (Mandatory) Sets number of columns, each separated by a comma.
- #Attribute: <name> - (Optional) Sets the name of the attribute to select the attribute values that will be shown in the CSV column for all extracted data entities. Name of the attribute can also be written without #Attribute. #Attribute is added to maintain consistency with other keywords. Besides standard objects' attributes, you collect internal globally unique identifier (GUID) of the objects by writing as name:
- #InternalID# and internal source ID reflecting ID of the object in source data format by writing as name: #SourceID#.
- GUID and SourceID cannot be changed but may be helpful in tracking the history of the objects.
- • #Attributes – (Optional) adds all attributes of the listed objects to the CSV report.
- #ObjectType# - Specifies the internal type of the object, for example: EngineeringObject, GraphicalObject2D.
- #SourceDataName# - Specifies the name of source data like input file.
- These attributes cannot be changed but may be helpful in tracking the history of the objects or filtering the CSV report by Object Type.
- #Association: <type> - Checks if specified association type is available in objects. CSV cells indicate AVAILABLE status if the corresponding object contains selected association type.
- #Associations - Checks if associations are available in objects. All types of associations are present in the extracted data and each CSV column represents one type of association. CSV cells indicate AVAILABLE status if the corresponding object contains association type defined in the CSV column.
- #Association:<type> and #TargetAttribute:<name> - Used together to first set the name of the association and then the name of the attribute whose value should be shown in the CSV column.
- Note: An association may point to many referenced objects and in this case values of attributes of all these objects are added to the cell in the CSV column, each separated by a comma.
- #Unit - Used only with one of the three keywords: #Attribute: <name>, #Attributes or #TargetAttribute:<name>. If attribute contains unit, it is added to the value after putting a single space.
- #Tracking: <tracking attributes names> - This keyword can be used with the list of Tracking attributes' names separated by a blank character (for example, space, tabulation or a new line), where each blank character represents data in a specific column. All recorded changes (Tracking entries) of extracted data are listed in a chronological order in the CSV cell (see Example 2 of CSV Document).
- #Tracking: <tracking attributes names> #Filter: <tracking attribute name> : <RegEx expression> - The #Filter: keyword includes only those changes in the CSV report where selected tracking attribute name matches the RegEx.
column = "<keywords, names...>": Separates long and complex descriptions of columns and defines each description in an XML element (see Example 2). The separate "column" element adds more clarity when the column contains a #Filter with a regular expression.

Note: Columns and column can be used interchangeably or both at the same time.

The following list details about the settings applicable for the CSV Reporting configuration:

suffix = "<file name suffix>: (Optional) Defines a suffix to add to the CSV file name. It is used only in Transform configuration. It is ignored when outputFilePath is set.
outputFolder = "<output folder path>": (Optional) Stores the CSV files in the location indicated by this setting. Otherwise, files are passed to the output folder set in Load settings. It is used only in Transform configuration. It is ignored when outputFilePath is set.
addHeaderRow = "<true/false>" (in Generate Headers in CSV checkbox): (Optional) Sets to "True" to write the names of the attributes or associations to the first row of the CSV file. This setting is enabled by default.
append = "<true/valse>": (Optional) Adds current CSV data to file set by ouputFilePath. When option addHeaderRow is enabled, then file to append must contain columns with the same names in the header row. If addHeaderRow is disabled, then number of the columns in the file must be the same as in the data to append.

In append mode, user cannot provide generic types of columns like #Attributes or #Associations because they may deliver different list of attributes and associations between files. In append mode, list of columns for all processed files is constant.
outputFilePath = "<output file path>": This attribute must be set when append mode is enabled. It can be provided absolute or path relative to Transform configuration location. When outputFilePath is set then attributes: outputFolder and suffix are ignored. This setting can be also used with disabled append mode.

Tracking attributes names which can be used with keyword #Tracking:

Tracking Attribute	Description
DateTime	Date and time of the change
ModuleName	Name of the component which introduces change
EventType	Type of the introduced change
ChangedMember	Affected type of the data: attribute's name, value, unit; or association's type or referenced object
PrevAttributeName	Name of the attribute before the change
AttributeName	Name of the attribute after the change
PrevAttributeValue	Value of the attribute before change
AttributeValue	Name of the attribute after the change
PrevAssociationType	Type of the association before the change
AssociationType	Type of the association after the change
PrevTargetInternalId	Internal ID of the associated object before replacing to new one
TargetInternalId	Internal ID of new associated object

List of the EventType types which can appear in CSV in the EventType column:

ObjectModified, ObjectAdded and ObjectRemoved
AssociationAdded, AssociationChanged, AssociationReplaced, AssociationRemoved, AssociationMoved and AssociationsCleared
AttributeAdded, AttributeChanged, AttributeReplaced, AttributeRemoved, AttributeMoved and AttributesCleared

Example 1 of CSV document viewed in Excel

Example 2 of CSV document with history of changes viewed in Excel

Note: If you want to open CSV reporting in a spreadsheet form, you must extend rows and columns of cells to see complete content.

Object Parameters Available for the CSV Report

The data available to select as columns in the CSV Report are as follows:

ObjectID
ClassID
ClassName
#Attributes (selects all attributes)
#Associations (selects all associations)
#InternalID#
#SourceID#
#ObjectType#
any attribute and property name defined for the entities, defined in property sets.

When a relationship is used, the property names from each relationship get concatenated, for example, HasAssociations:Materials:Name.

Notes:

Objects containing an attribute "#EXCLUDE_FROM_CSV#" will not be included in the output .csv file. For more information, see

quot; >

</Attribute>

...

</Object>

This mapping entry indicates that for all the objects matching the condition, if the Tag attribute in the source system is present, then a new attribute named Identifier is added.

The attribute mapping entry to create a new attribute taking multiple attributes with their corresponding patterns to match a specific format is shown below:

</Attributes>

...

</Object>
You may use a lookup to obtain the attribute value. You may use transforms to modify the attribute value from the source system.

Transforms may be combined with a lookup, in which case the transform is applied to the source value and the resulting value is passed to lookup:

<Attribute name="Tag" pattern="^[A-Za-z]+

quot; >

</Transforms>

</Lookup>

</Value>

</Attribute>

</Attributes>

...

</Object>

Update:

The simplest form of an Attribute mapping entry is to update an existing attribute:

<Attribute name="Tag" pattern="^[A-Za-z]+

quot; >

</Attribute>

</Attributes>

...

</Object>

This mapping entry indicates that for all the objects matching the condition, the Tag attribute in the source system, if present and matching the pattern then, the attribute value of Tag is fixed to abcdef123.

<Object>
...

</Attribute>

</Attributes>

...

</Object>

This mapping entry indicates that for all the objects matching the condition, the Tag attribute in the source system, if present, then the attribute value of Tag is prefixed with the text ID#.

Attributes from associated objects can also be used, as shown below:

<IncludeAssociatedObjectAttributes type = "^FillsVoids

quot; refID = "[Tag] " >

<Attribute name = "Name" pattern = "^element1

quot; />

</Conditions>

</IncludeAssociatedObjectAttributes>

<Attribute name="Tag" pattern="^[A-Za-z]+

quot; >

</Attribute>

</Attributes>

...

</Object>

In the above case, the value of the Tag attribute along with the value of Tag of the first associated object matching the condition is used to derive the attribute value. You must use the prefix "associated:" to resolve the value from its associated objects.

...

<IncludeAssociatedObjectAttributes type ="^FillsVoids

quot; refID = "[associated:Tag]" >

<Attribute name = "Name" pattern = "^element1

quot; />

</Conditions>

</IncludeAssociatedObjectAttributes>

</Attribute>

</Attributes>

...

</Object>

When there is more than one associated object with a Tag attribute and you need to include all of them, all these values can be aggregated into a single symbol-separated list value. In the above case, the value of the attribute Tag present in all associated objects matching the condition is used to derive the attribute Identifier value. All the values are joined using the separator string ";" defined by appendSeparator. You must use the prefix "associated:" to resolve the value from its associated objects.

The following example supports the case when there are associated object attributes more than one descendant level below the main object.

...

<Attribute name = "ClassName" pattern = "^DOOR

quot; />

</Conditions>

<IncludeAssociatedObjectAttributes type = "^Materials

quot; refID = "[associated{descendantLevel=2}:Name] ">

<Attribute name = "ClassName" pattern = "^MATERIAL

quot; />

</Conditions>

</IncludeAssociatedObjectAttributes>

</Attribute>

</Attributes>

...

</Object>

In the above case, the material values are in Material objects located two levels down in the object hierarchy: DOOR is associated (via the inverse relationship RELASSOCIATESMATERIAL) with MATERIALLIST, which is directly associated with two MATERIAL objects. You must therefore use the prefix "associated{descendantLevel=<level>}:" to resolve the value from its associated objects that are specified to a certain level in the object hierarchy. All of these values are joined using the separator string ";" defined by appendSeparator.

Remove:

The simplest form of an attribute mapping entry to remove an existing attribute is shown below:

The following mapping entry removes the attribute Tag from an object, if the attribute Tag is present in the source system.

<Object>
...

</Attribute>

</Attributes>

...

</Object>

The following mapping entry removes the attribute Tag from an object, if the attribute Tag is present in the source system and also matches the pattern.

<Object>
...

<Attribute name="Tag" pattern="^[A-Za-z0-9]+

quot; >

</Attribute>

</Attributes>

...

</Object>

The following mapping entry removes all the attributes matching the pattern from an object.

<Object>
...

<Attribute name="*" pattern="^[A-Za-z0-9]+

quot; >

</Attribute>

The following mapping entry removes all the attributes present in an object.

<Object>
...

</Attribute>

...

</Object>

keepUnmappedAttributes

This setting determines whether attributes that are not matched are included in the output EIWM file.

If this setting is true, then all the attributes are included in the output EIWM file.

If this setting is false, then only those attributes that have a matching mapping entry are included in the output EIWM file.

</Attribute>

</Attributes>

...

</Object>

Notes:

The keepUnmappedAttributes setting is optional. By default, the keepUnmappedAttributes attribute value is true if the setting is not provided.
The following attributes are included in the EIWM file regardless of their mapping or of the value of keepUnmappedAttributes attribute being set to false:
- GlobalID
- Name
- ObjectID
- ObjectName
- ClassID
- Context
- RevisionID
- TemplateID
- IncidentalClassification

When only the path is set in the Input Locator field, then all the DWG/DXF files present in the top folder and sub-folders will be processed. If any DWG/DXF files contain internal references (XREF) to other DWG/DXF files, then they will automatically be included in the processing of the main DWG/DXF file. Therefore, if referenced files are placed in the same folder or sub-folders of the folder path selected for processing, then they may be processed more than once, for example, as a referenced file and as an individual file. This can be prevented by either ensuring all referenced files are not located in the input root folder or its sub-folders or by processing each specific DWG/DXF file representing the model as a single file in the input locator rather than setting it to the folder pathname.

DWG objects are read with all their internal information. This information is attached directly to these objects as attributes:

Attribute name for AutoCAD handle: "handle"

Attribute name for AutoCAD parent handle: "parent handle"

Attribute name for AutoCAD layer: "layer"

Attribute name for AutoCAD block name: "block name"

Attribute name for AutoCAD object's type: "autocad type"

Attribute name for main and each referenced ("XRefs") AutoCAD models: "#MODEL_NAME#"

Attribute name for AutoCAD layout name: "#LAYOUT_NAME"

When multiple layouts of the drawing are processed, then the #MODEL_NAME# attribute is a concatenation of the filename and the layout name separated by an underscore character.

Each of these attributes can be used for tagging or classification of objects.

When objects are extracted from reference files, the value of the #MODEL_NAME# parameter is set to the name of the reference file. If relevant, this name can then be used to define the object’s ID.

...
<Conditions>
<Attribute name="#MODEL_NAME#" />
</Conditions>
<ObjectID value = "[#MODEL_NAME#]"/>
<ClassID value = "Equipment"/>
<ContextID value="Avngate|XREF" />
...

</Object>

The "MODEL_NAME" attribute is used to set the tag (ObjectID) for all objects according to their source DWG file name. Additionally, the ContextID attribute is set with a nested name "XREF" to ensure uniqueness and it differentiates the main model’s object tag from its child objects’ tags.

DWG objects may have additionally associated two types of attributes:

block attributes which can be attached only to objects of type "block reference".
attributes represented by extended object data (XData) which can be attached to any kind of objects.

After reading this data from DWG, both groups of attributes are instantiated as two separate objects with attributes and are attached to main DWG object. DWG object refers to these objects by association of type: "has dataset".

Each object read from DWG has set Handle attribute; so objects created for keeping the additional attributes have always set Handle attributes with values, respectively: "block dataset of <internal object handle>" or "XData dataset of <internal object handle>".

To export them to EIWM XML these objects representing groups of attributes (datasets) must be tagged by setting "ObjectID" attribute value and classified by setting "ClassID" attribute.

The following example first creates two new attributes: "ObjectID" and "ClassID" for both dataset objects and as a result they will appear in AIM. Last section of the mapping creates "ObjectID" and "ClassID" for each main DWG object which has associated dataset object.

...

</Conditions>

...

</Object>

...

</Conditions>

...

</Object>

...

<IncludeAssociatedObjectAttributestype="has dataset" refID = "[associated:Tag]" " [associated:Type]" />

</Conditions>

</IncludeAssociatedObjectAttributes>

...

</Object>

In these cases "ClassID" attribute is created with constant values "Equipment".

"ObjectID" attribute is created with the value taken from attribute Handle.

Main DWG object has "ObjectID" and "ClassID" attributes created with values taken from one of the associated dataset which contains attributes names "Tag" and "Type".

Excluding Objects from Output Files

Add the following special attributes to specific objects to exclude them from the various output files:

#EXCLUDE_FROM_EIWM# - excludes the objects from the EIWM file (but not associations to those objects from other objects).
#EXCLUDE_FROM_CSV# - excludes the objects from CSV files, both CSV reports and CSV load files.
#EXCLUDE_DOCUMENT_ASSOCIATIONS# - excludes the references to Document objects (usually represented by 'is referenced in' associations) in the EIWM file.
#EXCLUDE_FROM_SVG# - excludes the object's hotspot (vnet:id) tagging information from the SVG file, if produced.

It's possible to create multiple EXCLUDE attributes of different types on the same object to exclude it from the relevant multiple output files. If you do not want the EXCLUDE attribute for one type of output file appearing as an attribute in another type of output file, then set the attribute's system parameter to "true".

For example, the following configuration will exclude from a CSV file all objects that do not have a Class ID defined and the #EXCLUDE_FROM_CSV# attribute will not be included in the EIWM file:

" data-html="true" data-placement="auto" data-toggle="popover" data-viewport=".center_block" id="d1e40757" title="Attribute Mapping">Attribute Mapping.

If an object has two attributes with the same name and the user configures the attribute by name (any casing), both values are combined into one cell, separated by a semicolon (;).

If the user configures #Attributes, then each attribute is written to a separate column, using its own attribute name.

For example, suppose the EIWM has two attributes with the same name but different case, "Type" and "type":

Then the CSV report, being case-insensitive, will concatenate the two attribute values.

If the CSV Report configuration was:

Then the "#Attributes" parameter will export all the attributes (for example, ObjectID, Type and type) and the other parameters "Type, type, TYPE" would all be interpreted as case-insensitive hence identical, so the CSV output file would be structured as:

ObjectID	Type	type	Type	type	TYPE
Pipe_101	a	b	a;b	a;b	a;b

Note: Objects containing an attribute "#EXCLUDE_FROM_CSV#" will not be included in the output .csv file. For more information, see Attribute Mapping.

Example 3: CSV Reporting the Base Mapping patterns used for defining ObjectID’s

<column value="#Tracking: AttributeName

BMExpression

BMChanges

#Filter: AttributeName: ObjectID " />

</csvReport>

</extension>

Note: "BMExpression" and "BMChanges" contain the patterns used in the conditions and definition of the ObjectID. These tracking attributes are available to the CSV report when the BaseMapping annotation level is set to "ObjectIdTracking", see Appendix C: Tracking Changes in Data.

AVEVA™ Gateway for 2D Data

Appendix B: CSV Reporting

Table of Contents

Appendix B: CSV Reporting

Related Links