Using Instantiable Models

Instantiable model allows to define new business objects from scratch and permits system operators or lower-level administrators to create instances of those business objects on demand and manage them.

Similarly to all other Iotellect Server objects (such as queries), instances of instantiable models are stored in container contexts. However, containers of queries and other standard objects are in most cases located in two parts of server context tree:

• In contexts of users, if users own those objects (example: alerts)

• In the root context, if those objects are global (example: timezones)

Unlike "classic" containers, model instance containers can be attached to any part of the server context tree except for another container. This is controlled by the Validity Expression and Validity Update Rules of an instantiable model (see resource validity). The Validity Expression is evaluated for each context in the server context tree, and if it results in True, a container for the model's instances is attached to this context.

Thus, to emulate the behavior of "classic" objects, an instantiable model's Validity Expression should be configured as follows:

• {.:#type} == "root" for attaching a single instance container to the root context (global instances)

• {.:#type} == "user" for attaching an instance container to each user context (per-user instances)

A model instance container is represented by icon, while individual instances use icon.

Instantiable model instances can be managed just like any other system resource, such as alerts or reports.

Model instance containers support all typical resource container actions such as Create From Template, Replicate To Children, Import, Export, Edit Context Permissions, Monitor Related Events, Search/Filter, and various Group Actions.

Model instances support all typical resource actions including Delete, Make Copy, Replicate, Edit Context Permissions, Monitor Related Events, and View Status.

Contexts of instantiable model instances offer the Move to Container action, allowing an instance to be moved into another instance container of this model.

There are several properties of an instantiable model that control basic characteristics of model instances container contexts and model instance contexts:

• Container Type

• Container Type Description

• Container Name

• Object Type

• Object Type Description

• Object Naming Expression

The first three of them control model instance container contexts:

• Container Type is an identifier that can be later used to find or distinguish model instance containers within the server context tree. Set it to something like a camel-cased name of your object in plural, i.e., "oilDerricks". See context types for more information.

• Container Type Description is just a human-readable version of the above, i.e. "Oil Derricks".

• Container Name is a context name that will be used for model container contexts. It should satisfy context naming conventions. The name is required to refer to the containers from other parts of the system. Set it to "oilDerricks" (same as Container Type), and if you've attached your model containers to user contexts (see above), the full path of a container will be users.john.oilDerricks.

The second three properties control model instance contexts:

• Object Type is, similarly to Container Type, an identifier that can be later used to find or distinguish model instances within the server context tree. Set it camel-cased name of your object, i.e. "oilDerrick". See context types for more information.

• Object Type Description is a human-readable version of Object Type, i.e., "Oil Derrick".

• Object Naming Expression is an expression that is used to evaluate human-readable descriptions of model instances.

Was this page helpful?

Tell us more

Send

Thank you!