Classes

Classes are designed to store large number of similar objects in a relational or graph database. Each class instance is represented by a single relational database table record or a dedicated node in a graph database. Classes have user-defined fields that are directly mapped to columns of a relational database table that contains instances of a specific class. In a graph database, field values are stored as node properties.

Classes may have one-to-one, one-to-many and many-to-many relations between each other. Those relations help to establish smart navigation between class instances. Class instance relations are mapped to foreign keys or lookup tables in a relational database and edges of a graph database.

Dashboards are aware of classes, allowing to render and modify fields of individual instances as well as display tabular instance lists with on-the-fly sorting, searching and filtering.

Classes instances may have configurable states and lifecycles, as well as configurable per-instance permissions.

Here are some use cases for classes:

  • In a CRM system, typical classes are Contact, Account, Lead and Opportunity

  • In an asset inventory system these could be Asset, Asset Type, Person and Location

  • A Service Desk system may feature classes like Agent, Incident, Service and Service Level Agreement (SLA)

  • A Data Center Information Management system typically deals with Racks, Servers, Cables and similar industry-specific classes

Class instances are normally stored in Iotellect Server database, but only relational and graph databases can be used for storing them. It's also possible to retrieve class-like data from external systems via the Relational database device driver or Graph database device driver.

Classes are cannot rely on NoSQL or Key-Value storage due to their data structure.

Administering Classes

Two contexts are used to administer classes: The first is the general Classes context, which serves as a container. The second is the Class context, which stores the information about a single class type (and all its instances).

Every user has their own set of Classes.

Global Settings

Global settings are used to set up Classes plugin:

Property

Description

Default Storage Context

Context that points to the underlying storage facility for classes.

Managing Class Instances

Class instances are normally managed via dashboards. Regular (Absolute and Relative) dashboards may act as a "gateway to class world" by containing lists of class instances formatted, filtered and sorted according to pre-defined rules. Clicking on an instance in any of those class lists normally brings system operators to a Class Instance dashboard that displays state and fields of selected instance as well as lists of other classes' instances linked to it via various relations. See dashboard types for more information.

Managing Database Schema

Creation, updating and removal of database tables that contain class instances is fully automatic. Once a new class is created, a new database table is created for its instances. Table name matches class name. The table is updated every time class fields of life cycles are modified. Finally, the table is dropped if the class itself is deleted.

Also, each many-to-many relation is mapped to a dedicated database table. This table is automatically created, managed and destroyed as well.

Building a Class-Based Operator Interface

Classes are very powerful objects that help building full-scale applications based on Iotellect. Here is a list of basic steps that are normally required for building such an application:

  • Design the complete class structure of your application

  • Create your classes and define their fields. Class fields may include links to other classes ( fields that use Foreign Class Instance editor ), attached files ( Data-type fields that use File, Image or Sound editors), and any other typical fields such as Integer, String, Date, Data Table, etc.

  • Set up relations between classes by either creating fields that use Foreign Class Instance editor to configure one-to-many links or adding many-to-many relations

  • Set up class instance life cycles

  • Set up views for your classes to enable re-using instance field sets, filtering rules and sorting rules within various dashboards

  • On one of the main dashboards of your operator UI, add several elements of Class Instance List type to enable navigation into the world of your classes

  • Design a dedicated class instance dashboard for each of your classes. Click on a class instance within any instance list will lead an operator to a class instance dashboard valid for the clicked class.

  • On your class instance dashboards:

  • Add Class Instance Fields elements to display attributes of a class instance.

  • Add Class Instance List elements to display a list of other class'es instances that are related to the current instance. Set up Relation field in Class Instance List parameters to filter out related instances only.

  • Add Event Log elements to show class instance creation/change/removal events as well as class instance comments (Class Instance Commented events). See Class context for details on those events.

  • Add Data Table elements that will show allowed state transitions for your classes. See life cycles article for more information.

  • Add any other dashboard elements (widgets, data tables, etc.)

Once top-level dashboards and class instance dashboards are configured, your operators may start operating the application and managing your classes.

Class Inheritance and Subclasses

Each Class context provides a Subclass container. You can create a Class context within a Subclass container. By default, your created Class context within your Subclass container has the same Fields, Many to Many Relations, and Lifecycles variables as its parent context. Therefore, you can use parent Class as a template to create Classes with similar structures.

Class Inheritance could be useful in many ways. For example, you can use it while creating CMDB objects. This provides you with Configuration Item with the following parameters: Name, Location, and Status. You can create a child IP device context and add more fields to its properties, for instance: IP address, Subnet Mask, Manufacturer. Therefore, you can create IP device contexts with a set of parameters: Name, Location, Status, IP address, Subnet Mask, Manufacturer.

At the level of the database, subclasses and base classes have the following properties:

  • When a new subclass is created, Iotellect creates a corresponding table in the database, which contains only the fields specific to the subclass. Inherited fields are not replicated in the subclass table.

  • The system creates hidden fields in the subclass and base class which serves as a private key to allow the display of subclass instances with both subclass and inherited fields. Similarly, modifying a subclass can result in update and insert operations being performed on both the table associated with the subclass and the table associated with the base class.

  • Base classes are able to display instances of subclasses, albeit only displaying the fields which are associated with the base class

  • Modifications made to an instance from a subclass view will be reflected in the base class, and vice versa.

When using a Class Field List component on a Class Instance Dashboards to display instances of a subclass, it is important to correctly configure the dashboard bindings to ensure that displayed instances are updated dynamically. This can be accomplished with the following binding:

  • Target: form/<name of class field list component>:storageContext

  • Expression: 

    catch(
    	cell(
    		cell(
    			callFunction( // Open the class instance from the parent dashboard storage location to ensure dynamic update
     				"{path.to.parent.class}" // Indicate the context path of the highest-level PARENT CLASS of any class instance that can be displayed by the component 
     				, "storageOpen" 
     				, null
     				, "{view}"
     				, null
     				, "{storageTable}"
     				, null
     				, callFunction( // create filter to get the instance indicated by the dashboard property URL query term instance_id
     					"{path.to.parent.class}"  // Indicate the context path of the highest-level PARENT CLASS of any class instance that can be displayed by the component
     					, "prepareFilter"
     					, 0
     					, 0
     					, "instance_id"
     					, "EQUALS"
     					, {env/instanceId} 
     					, null
     					)
     				, null
     				, true
     				, null
     				, null
     			),
     		"data"
     		), 
     	"class"
     	), 
     ""
    )

  • Activator: form/:shown@

  • On Event: True

Was this page helpful?