specs/models/M_APP_EXPORT_IMPORT
App Export/Import
Overview
The mechanism to export a zip file of an App and import into another destination.
Import Behavior
| Imported? | Notes | |
|---|---|---|
| Application | ||
| App Name(s) | Yes | |
| Variables | Yes | |
| Logic | Yes | |
| Transitions | See Notes | Transitions that include navigating to a separate application will only import successfully if the apps are imported together as an app group. Otherwise, the reference to the external application will show as “Deleted App”. Transitions internal to the application will import successfully. |
| Completion Data | No | |
| Version History | No | |
| Analytics | Yes | |
| User References | See Notes | App logic to send notifications to users will look for a matching user ID (not the plain text name representation). If the user ID does not exist on the target instance, it will not create the user and instead will be highlighted in red in the app showing as “Select a user” (the message is retained). |
| Approvals | No | |
| Users | ||
| User Table | See Notes | Custom columns in the user table will be imported, but referenced users and table data will not import. |
| Tables | ||
| Table Schema | See Notes | All tables referenced from an application will import via the following rules. Tables are uniquely identified by an underlying table ID. If a table with the same ID does not exist, or if a table with the same ID exists but is owned by a different Workspace than the one being imported to, a new table with a matching table schema (including matching table and column IDs) will be created. If a table with the same ID exists but new columns had been added, columns will be added to the table on the target instance with matching IDs. If a table with the same ID exists and columns were archived, but they exist in the source instance, they will be restored upon import. |
| Table Data | No | Table data can be exported to CSV and reimported to target instance via standard tooling. |
| Table Analytics | Yes | |
| Queries/Aggregations | See Notes | Queries and aggregations will import but will always import as duplicates. |
| Table Record Placeholders | Yes | Save for Analysis is set to True for all table records as default |
| Machines | ||
| Machines | No | Individual machines in the library are not imported. |
| Attributes | See Notes | If an app is imported with a reference to a machine type, any machine attributes added to that machine type will be imported with the application. |
| Types | See Notes | If an app is imported with a reference to a machine type, that machine type will be imported with the application. |
| States | See Notes | If an app is imported with a reference to a machine type, any machine states added to that machine type will be imported with the application. |
| Downtime Reasons | See Notes | If an app is imported with a reference to a machine type, any machine downtime reasons added to that machine type will be imported with the application. |
| Activity History | No | |
| Machine Analytics | See Notes | If an app is imported with a reference to a machine type, any machine analytics included in the application will be imported. |
| Widgets | See Notes | Widget will import but will not be linked to a machine. |
| Connectors | ||
| Connectors / Connector Functions | See Notes | Connectors will import via the following rules. As a note, all connectors will remove authentication details and require re-authentication in the target instance. If a connector with the same ID does not exist, a new connector and function will be imported If the connector with the same ID exists but the function does not exist, the function will be created in the connector with the matching name If the connector with the same ID exists but the function has been deleted, the function will restored in the connector with the matching name. If the connector with the same ID exists and the function with the same ID exists, no changes will be made to the connector function, even if the body in the source instance has changed. |
| Shop Floor | ||
| Devices | No | |
| Stations | No | |
| Edge devices | No | |
| Vision Cameras | See Notes | Vision Camera Configurations (e.g. virtual cameras, obviously physical cameras cannot be export/imported) will be created if a trigger in the app requires the vision camera. Otherwise, the triggers will be improperly imported and be broken. Note: For Vision Camera Widgets using a virtual Vision Camera Configuration we do not create a new configuration upon import, unlike triggers. The import will always create new Vision Camera Configurations and name them after the importing app name, regardless if configurations of the same name exist. |
| Other | ||
| Bots | No | |
| Activity History | No |
Tests
| ID | Name |
|---|---|
| QA-T937 | App Export/Import : 01 - Running the "Import-Export" app after import |
| QA-T938 | App Export/Import : 02 - Widgets are Imported and Function |
| QA-T939 | App Export/Import : 03 - Embedded Widgets are Imported and Function |
Requirements
| ID | Requirement |
|---|---|
| PLAT-8797 (851) | Provide portability of configuration and components with full version, audit trail and history information. Ie. models and components can be exported and imported between environments and instances. |