Import collection of objects

Universal import of the object collection including relationships

• The import cycle logic
• Import variants
  • Import to the multi-client system
• Single object import
  • Object import method return states

The major import process describes the interaction diagram:

Imports runs in several steps:

• All objects shall set its state if could be imported or not
• Import is called repeatedly until all object import is in the final state. Maximal number of cycles is deterministic – it is never called more than how many objects is in the collection

The import cycle logic

Each object might have relation to some other master objects that should be loaded before the master. However, they never could be in cycle. Each pass of the import cycle should at least single object complete its loading and it could enable loading of another object(s).

If any object changes its state of loading, the import completes.

Import variants

Import support several types of import

• Fake import just check the process but does not import anything. It informs user what data will be imported but does not import them
• Complete import Imports all objects and created new instances for each objects. Import never use GUID of the objects and newly created objects doesn't have them
• Merge import Objects that are already in the database are not recreated but updated or skipped (Objects internally managed how they updated the object in database).
• Only new Import only objects that are not yet in the target repository. The method works sucessfully only in case that objects in the source and target space uses the same GUID. Typically when objects are created in the testing repository that is clone of the production repository and moved to the production repository after the testing.

Import to the multi-client system

AyMINE is a multi-client system. Import / Export functions never combine data for several clients.

GUID are client-relative

In a nutshell, when someone exports collection from a repository and import it to another client. The same repository might contain more objects with the same GUID. That's not mistake. System support export-import various data, share them among client's and later updates single collection by a newer collection from source.

Usage example:

• Single client – producer – creates and manage a methodology.
• He exports it and sell to another client – receiver
• A year later producer updates methodology and provides update to the clients
• Client might update their methodology by
  • inserting new objects (e.g. new task patterns) or
  • completely update – change also existing objects.

In both cases GUID values are used to identify source-target object pairs.

Single object import

Activity diagram of a single object import:

Object could be imported only if there already exist all master objects – those that have not-null link from the imported objects. Import method verifies their existence a shall get their new local ID. Method frmEIManager->isObject returns value of object if already imported or information if it will be imported later.

Object import method return states

Method returns import process status. Status for each object is stored in the frmEIObjEnv envelope

• notImported – Object is not imported – field created but import not started. Value is never returned by method. It is initial state
• partlyImported – Part of the object was imported but not everything. Method returns the state to inform about some progress but also requests to be called again
• totalyImported – Everything is imported and there is no reason the call the import method again. When method returns this state it won't be activated more
• importError – Error occurred during the report – Error is stored in the protocol. Method is no more called
• neverImported – Method returns the state when decide that it cannot be imported to the database. It is returned if some import condition permanently disregard import