Import – Export of the object Collection

Universal functionality for export / import collection of objects

• Export protection for data security
• Export-Import management objects
  • frmEIManager
  • frmEIObjEnv
  • persistentObject
• Exported data structure
• Export / Import relations between objects
• File (no)export
• Example of usage

Frameworks support export and import of a collection of objects. Functionality shall also be supported by object itself – they shall manage its own export / import functionality

When object supports its import / export, it can be used anywhere – for any arbitrary collection of objects.

Export / Import functionality has strong support in the persistentObject, general ancestor of all persistent objects supported by the framework.

Objects are exported without client identification (clientID) – objects that are exported from on client could be imported to any AyMINE environment an to any client (even in the same environment).

Export protection for data security

Generally, data export might support violate data security. Therefore, system implements several steps how to protect data:

• Functionality is implemented only for collections of objects where it is necessary.
• Encrypted data are never exported
• Documents linked with objects are not exported
• User that starts export shall have reading right to each exported objects. It also blocks administrators or system administrators to make an export – they simply have no rights to the objects
• Export is recorded to the object update so that data export is not a hidden operation. It can be always found what object were exported.

Export-Import management objects

The following model explains objects and methods related with export and import

frmEIManager

The is a facade that encapsulates all export-import functionality. It is the only entry point to the functionality. All other methods are called within the process.

Object has entry methods static. However, it creates its own instance during export and import. Instance of this object is stored in the output file.

frmEIObjEnv

Envelope for exported / imported object is created for each object. So, during process there is single envelope for single independently exported object.

Envelope internally control process of export / import and control managerial data about single object necessary during the process. Envelopes provides some functionality for processes.

Envelope has an array attribute:

   /** Object with additional data tahb object should store */
   public array $transData;

The array is intended for any kind of additional data exported by objecta. Automatically managed export stores the object data (alle fields) but not other than that. See export example for usage

persistentObject

Persistent object is not an object designed for import / export. Contrariwise, it is a general abstract ancestor for all exported/imported objects. It contains both processing methods an supporting methods for processes.

The object itself manages its own save to the export as well as import. It never manages the process.

Exported data structure

Collection of objects is exported to the proprietary data format (extension aydat). The structure is not intended to any other purpose than import to the same or another instance of AyMINE.

AyDAT file format:

• file could be encrypted with symmetric AES encryption (optional, not all exported files are encrypted)
• gziped document compresses data
• Exported as a collection of objects in the internal PHP serialisation format (not json). Import is supported only with appropriate objects installed. Format does not support using data without object definition but it is not an intention of use
• Each object decide internally what part of its description is exported and what not.

Export / Import relations between objects

System supports using object GUID identifiers so that each objects have its own world-wide unique identification. When relations between objects are exported, they are exported with information about the local ID and GUID of the related object. Both values are used during import, however local ID are used only to located the linked object in the collection of exported object. GUID can also identify object in the target database. (It support updating of existing object by imported collection).

File (no)export

Export procedure does not explicitelly manage files linked and stored in the AyMINE. The export-import technology support storing blob data and so object might export/import files as well.

However, framework and particularly sysFile object does not implement export since method is not intended for data export. When functinality intention change, the logic does not make any obstacle to that.

Example of usage

Method is used to export the methodology. It exports single root – methodology – with all objects included in the methodology.