Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

Mobile Operator Extensibility SDK On-Premises

Import design

The importer engine typically follows the following processing logic:

  1. Performs initial validation on light weight objects that need to be imported.
  2. Builds light weight object hierarchy. Any object whose parent cannot be traversed to the root is moved to an orphan list and not processed any further.
  3. For each light weight object, the importer looks for a match in the database. The method it uses to find a match can vary depending on the type of object. See the Procedure Support Objects section for details.
  4. If it finds a match in the database, it will update the object if edits are allowed (Procedure Builder, as a global application, cannot modify externally owned objects).
  5. If no match is found, importer will insert the object. If the "Application Id" of the object is Procedure Builder, the newly created object will also belong to Builder; otherwise, the "Global Application Id" will supersede the "Application Id" specified in the light weight object.
  6. The feedback object encapsulates the decision taken by the importer with regards to a particular light weight object. The importer ties a feedback object to each light weight object as it finishes processing them.
  7. The importer maintains a list of all the errors encountered during processing and exposes this information to the caller.

Error Reporting

The importer engine maintains a collection of errors while processing the light weight objects. Some errors force the import process to halt, whereas some simply force certain objects in the list to be skipped. The error information typically encapsulates an error code, an error message and the light weight object involved with the error.

During the import process, the importer can encounter different types of errors as described below:

  1. Errors in the content of the light weight object, e.g. incorrect parent information
  2. Errors encountered when processing the light weight objects, e.g. a failure to import support objects
  3. Validation Errors. Each type of object must adhere to certain business rules, and the importer always validates these objects against them before persisting in the database. If one object fails validation, the import is aborted. If the error code indicates that validation errors were encountered, the validation errors can be retrieved from the "validationinfo" property in the light weight object.

Feedback Mechanism

On successfully processing a light weight object , the importer associates a feedback object to it. The feedback object encapsulates the action the importer performed on the object. For example -   whether it’s an insert, update etc

TitleResults for “How to create a CRG?”Also Available in