Operating Modes

Adaplets can operate in the read-only, read/write, extend, or migrate mode. The mode is set in the mapping file. For more information, see Mapping File Syntax.

The operating mode is generally determined when shared libraries are designed and written. For example, read-only drivers need to implement only a small number of functions, while those designed to update the legacy system require more custom code. However, a read-only driver, when set to operate in extend or migrate mode, will use 3DSpace to perform tasks that the adaplet is unable to execute. Over time the operating mode of an adaplet can be changed.

Adaplet modes can be classified as either basic, (readonly and readwrite) or advanced (extend and migrate).

In a basic mode adaplet, all data resides in the foreign database. An advanced mode adaplet keeps part of the data in the foreign system, but part of the data (the 3DSpace portion) is in a set of 3DSpace database tables very similar to those used in a native 3DSpace vault. In an advanced mode adaplet, both portions of the data must be present at all times. Deleting a record from the foreign system without deleting it from 3DSpace will cause errors.

Not all adaplets will support all operating modes. For example, some interfaces may only implement the functions required for certain transactions, or only those that are required for read only operations. These types of interfaces would fail when attempts are made to perform operations that they were not designed to handle.

Operating ModeDescription
Readonly modeAll 3DSpace dialogs are available when in readonly mode. Objects can be navigated, and the user can view detail tables, states, basics, attributes, formats, files, history, and revisions, as if they were native 3DSpace objects. This mode is used to publish legacy data, and might be suitable for use with the internet. When using adaplets in readonly mode, however, dialogs must be dismissed without making changes, or errors will occur.
Readwrite modeReadwrite mode is used when another database will be used side-by-side with 3DSpace. The data will be accessed via both databases, and so changes made with 3DSpace must also be available to the other application. When data is edited from 3DSpace with a driver in readwrite mode, the changes are written to the other database’s tables. Therefore, updates are allowed only to the extent that they are supported in the legacy system. Some functions (those that are not handled by the other database, such as promote or demote) are not allowed. Objects in a foreign vault that is using a readwrite adaplet can not be attached to workflows or IconMail, or saved as part of a set.
Extend modeExtend mode is an extension of the basic readwrite mode in that it lets 3DSpace handle functions that are not supported by the adaplet. Updates handled by 3DSpace are written to the foreign vault’s 3DSpace/Oracle tables, and this information would not be available to the other database. These kinds of updates would be for things the other data source doesn’t know about, such as a change policy event. The sample adaplet works in this mode by default.

An interface designed to work in this mode must implement every function in the API. This allows a common view of common data to be maintained between 3DSpace and the legacy system, but 3DSpace may also have additional information such as lifecycle and history.

If objects must be removed, they should be deleted from 3DSpace to ensure that 3DSpace extensions (such as lifecycle and history) are also discarded. Object deletions from the legacy system may cause inconsistent behavior.

Migrate modeChanges made are written to 3DSpace only. The legacy system is readonly. This mode is used for situations that require legacy system replacement, where the legacy system is on-line but not in use. The 3DSpace and legacy system views of the data will differ over time.

A readonly adaplet (that is one whose interface implements only the readonly functions) may be used in this mode to give the appearance of full read/write/extend. 3DSpace will perform the functions that the adaplet is not designed to handle. These updates are written to 3DSpace tables.

When using migrate mode, keep these design limitations in mind:

  • Objects cannot be deleted in this mode since the legacy system is readonly.
  • When operating in migrate mode you might need to set the following in the initialization file (enovia.ini (previously matrix.ini or ematrix.ini) for the Studio Modeling Platform or 3DSpace Server):

    MX_CHECK_DUPLICATE_NAMES=false

    This setting allows duplicate names only in different vaults. This is necessary for the change vault operation. Since the legacy system is not updated when in migrate mode, the object cannot be deleted from the original vault, and so, without allowing duplicate names it cannot be added to the new vault.

  • Relationship cardinality and revision rules may be broken if connections are made between native and foreign objects, and the relationship data is obtained from the other database. This is essentially the same scenario as above; the legacy system may not be updated so relationship ends may not be changed. Cardinality, allowed types, and other rules of relationships are enforced by 3DSpace and not the adaplet.