Non-Conformance Report

A Task Results report is generated by Check Rules task(s) run in a Session, which is then available to view and to download as JSON. When added to a Session, the Non-Conformance Report Data Store will generate features from all the task results report that precede it. These can subsequently be exported to a data format supported by 1Integrate (see Supported Data Stores).

Note: This combines the results of all task results and will not contain any amendments created from any Actions that precede it. So fixed objects that occur after the Rule has been run, will still have objects created for them in the Non-conformance Data Store.

Both non-spatial and spatial non-conformances are included, and all contain:

The ID of the failing feature (if the data store can determine which attribute is the ID).
Details of the rule that failed.
The feature class.
The geometry or attribute names.
All reported attribute values encoded in JSON.

Using the Non-conformance report Data Store

Add a new Data Store and configure a Non-Conformance Report Data Store for the Read and Commit Details. This creates internal classes to store the non-conformances which can be written out via a Copy-To task in the session.
(Optional) You can also configure Copy To Details to another format.
Build a Session that features at least one Open Data task and one Check Rules task.
Add another Open Data task and configure it as the Non-Conformance Report Data Store created in step 1.

Note: If you do not add an Open Data task before the Optional Copy To task then the session will throw unhandled exception errors containing messages such as “NOSUCHCLASS: No class of this name has been defined in the Schema".
(Optional) Create a Copy To task and pick the Data Store defined in step 1 to export the features to the defined output format.

Note: This should only be placed once and will only apply to Rules that have failed before the Non-Conformance Report Data Store's Open Data Task in the Session.

A simple Session including a Non-Conformance Report being loaded and copied to

Non-conformance Attributes

The following attributes can be reported on when performing a non-conformance report.

Note: Each attribute name will be preceded by the "sys_" or "sys:" depending on the data store e.g. "sys_attributes" or "sys:feature_id".

Attribute	Description
attributes	A comma separated list of attributes and their values; the failing attribute(s), a geometry (minimum bounding rectangle) and any attributes selected for reporting.
attribute_names	A comma separated list of the attribute(s) that fail a Rule when the non-conformance is from a non-spatial check.
error_message (error non-conformances only)	A description of the error that occurred.
feature_class	The `feature_class` of the non-conforming root feature.
feature_id	The ID of the non-conforming root feature, if the Data Store can specify which attribute is the unique id. Not all Data Stores are able to specify which attribute represents a unique ID. Note: Setting a unique key will ensure the feature_id is populated. You can set a unique key on the Data Store by right-clicking on an attribute and selecting “Set Unique Key.
gothic_id	An internal system ID for the feature, unique within the Session.
rule_auto_description	A description of the Rule against which the feature did not conform.
rule_name	The name provided for the Rule.
rule_path	The location of the Rule in the folder structure.
geometry (spatial non-conformances only)	A point or multi-point geometry pinpointing the location of the spatial non-conformance. Geometry is calculated from the inferred hotspot which is either: The problem location (e.g. if a rule is checking for overlaps then this reports the point location of each overlap) A point within the geometry if no specific hotspot was inferred.