Procedure support objects

Procedure configurations rely on many supporting objects which must exist to ensure procedure configuration validity. The importer will attempt to create support objects that do not exist, use existing support objects, and optionally edit existing support objects based on the information provided in the lightweight objects representing the support objects.

The following are supporting objects which are embedded in procedures:

• Assets
• Asset Status Lists
• Response Lists
• Default Notes
• Data Filters
• Severities
• Units of Measure

System-wide unique objects

Assets, Asset Status Lists, Response Lists, Default Notes, Data Filters, Severities, and Units of Measure are unique in a system.  

The import process finds a match based on the following:

• Locate the required object by using the unique property of the object. For example, Assets are located by name, type, and the organization.
• When the importing application is non-builder and a matching support object belonging to another application is found in the database:
  • The importer identifies the support object as a “found equivalent” because the external Ids do not match
  • The importer will transfer ownership to the current importing application if the support object is updated
• When the importing application is Procedure Builder and a matching support object belonging to another application is found in the database, the support object is not updated.

Note: An organizational hierarchy consist of the following units in it: the Organization, Plants, and all the bases of the Plants. For more information on understanding the organization hierarchy, see the AVEVA Mobile Operator Help in the web app.

Based on import options selected, appropriate changes are made.

Assets

Assets are unique in an organizational hierarchy based on the name and type. A match for an asset being imported is found in the database if:

• Asset name and type are the same
• If externally owned and application id + application item id matches one in database

Special ownership rules apply to the following properties of an asset.

• Display Name
• Asset Type
• EPC Code

These properties of an asset may require editing by Procedure Builder even if the asset is owned by an external application. The system checks, whether the value for the properties are specified by an external application.

If the external application has specified a value for these properties, then the application owns the property, and the values cannot be edited by the Procedure Builder.

If the external application has not specified a value for these properties, then the Procedure Builder can edit and supply a value to that property.

However, at any time, if the asset is imported by the external application and a value to these properties are supplied in the application, then the value provided by Property Builder will be overwritten and the Procedure Builder will no longer be able to edit the property.

AssetTypes

AssetTypes are unique in an organizational hierarchy based on the Asset Type name. A match for an asset type being imported is found in the database if:

• Asset type name is the same
• If externally owned and application id + application item id matches with the application and application item IDs in the database

Rules applicable when an asset type is being inserted are described in the "Global Application Id vs. LightWeightObject Application Id" topic in the Key Concepts section.

Status Lists

Status lists are unique per application. For external applications the import logic is driven by "Application Item Id" (unique Id provided from external system) only.

For Builder-owned status lists, the importer attempts to look for a match based on the following criteria:

• Name of Status List matches within an organization hierarchy
• Parent hierarchy matches
• Status items required by importer matches

If the name and hierarchy match, but the items required do not exist, the importer will add the Status List required with a suffix making its name unique.

Response List

Response lists are unique per application. For external applications, the import logic is driven by "Application Item Id" (unique Id provided from external system) only.

For Builder-owned Response lists, the importer attempts to look for a match based on the following criteria:

• Name of Response list matches within an organization hierarchy
• Parent hierarchy matches
• Response items required by importer matches

If the name and hierarchy match, but the items required do not exist, the importer will add the status list required with a suffix making its name unique.

Roles

Roles associated with a procedure may be created during import, if the “createroles” option is selected.

If the “createroles” option is not selected, the importer will remove any role either:

• Associated with the procedure that does not exist in the database or
• Exists in the database but is not linked to the parent Plant of the base referenced by the Procedure.

Base

The Base associated with the Procedure must exist in the database being imported to. The Import API will not create new bases.

Sequencing

Calculations

Preserving the validity of complex calculations that refer to other objects in the database, during import from one database to another, is not supported in this release. The Ids of objects embedded in calculations are not valid when moved to a different database.

If a procedure contains complex calculations, it will need to be imported by setting the “Save with validation errors” option to "true," and manually modifying / validating the Procedure in Procedure Builder after import.