Modeling Using Modeler

A model in RapidCMDB is a high level representation of one or more physical devices and/or logical data coming from different sources. The properties that made up a model depends on the developer's perspective and needs.

The preparation steps before starting to work on a model are to :

• identify the properties
• identify the sources of data
• define proper RapidCMDB connections and datasources for each physical data source. Currently, supported connections can be database, html, a third party application, Smarts, or Netcool whereas datasources are those which use these connections. You can define Connections and Datasources from RapidCMDB application homepage (http://host:port/RapidSuite/admin.gsp)
• identify the relations to other models
  

There are two ways to create and manage models; from RapidCMDB home page or via groovy scripts. Please refer to tutorials for specific examples of creating models differently. Tutorials 1 and 2 explain two scenarios in which scripts are used to the models whereas Tutorial 3 shows the steps to create a model from RapidCMDB home page. You can download the scripts for Tutorial 1 and 2.

Defining Model 

Each model is given a name which starts with a capital letter. A model can also extend another model. When extended, the parent model's properties, datasources, relations, and operations are available to the child model. Please check the list of [invalid names].

Defining Properties

Properties are the model's attributes that will be populated either manually or through connector scripts and manipulated using consuming scripts. A model's properties can come from different data sources and may have different names in the original data sources. Those properties which are not kept in RCMDB are called "federated". Federated properties are kept in the original datasource and retrieved when needed.

While defining properties, you have to specify:

• its name and type: Note that a property name always starts with a small letter. Please check the list of [invalid names].
• which datasource this property is coming from: RCMDB is the default RapidCMDB datasource. It is provided with the application. However, you need to explicitly define other external data sources beforehand as explained above. A property's datasource can also be dynamically determined. If this is the case, there needs to be at least one property that keeps the particular model instance's datasource and this property is selected as dynamic datasource.
• whether it can be blank: Note that a property identified as a key in the datasource can NOT be blank.
• whether it has a default value: Default value is used when this property is not given any value when an instance of this model is created.
• whether it is lazy: Only a federated property can be defined as lazy. Being lazy means the value of this property is retrieved from the original datasource every time it's referred. This is a costly operation. Therefore, if the property is rather static in nature, its lazy attribute can be set to false. This way, its value is retrieved only once and the first time its datasource is accessed.
• its name in datasource: This attribute is defined when the property is federated and its name in RCMDB differs from its original datasource.

Defining Relations

Relations, as the name implies, relate the model to other model classes. These relations can be of type 1-to-1, 1-to-many, and many-to-many. When a relation is defined at one model, reverse relation information should also be provided.

Defining Datasources

Each model can only have one master datasource, most of the time, it will be RCMDB. For each datasource, you need to specify the model property and its respective counterpart in the datasource as key.

Generating Model 

Once all of the above steps are executed, you need to generate the model. This can be done either from Model creation UI by pressing "Generate" button, or from the groovy script. This step creates the proper configuration in RCMDB, however, in order for the model to be loaded in the application and its controller and view files to be generated, you need to reload the application.

You can reload the application from the url: http://host:port/RapidSuite/application/reload

Generating a model will automatically generates the other models to which this model is related either through relations or as a child. In other words, if model Router extends from Device and relates to Event through 1 to many relation, and assuming all the above steps are taken care of for all models, when Router is generated, both Device and Event models will also be generated. It is perfectly fine to explicitly generate all models one by one and reloading the application only once at the very end. 

Implementing Operations

During model generation, basic CRUD operations are automatically generated. You can learn more about these basic operations [here].

If model requires additional operations, they have to be manually implemented in a separate groovy script. Static operations are supported. After the model generation, another file named <ModelName>Operations.groovy is saved under RS_HOME/RapidCMDB/operations folder. This file can be edited to have the additional operations required for the model. For example, a sample operation for a Ticket model could be:

def assign(username){
	owner = username;
	writeToJournal("Ticket is assigned to $owner");
}

All operations must be implemented in operations files, not directly in model files, as there is no access to relations from code within model file.

Note that if there is a modification to the operations file, the model has to be reloaded.

The list of operations implemented in the operations file can be displayed in the model definition UI. In order to accomplish this, user should mark the operation with CmdbOperation annotation.
ex:

class Book
{
     @CmdbOperation(
             description = "This operation is used to borrow the book from library"
     )
     def borrow()
      {
      }
}

This marked operation will be listed in the model definition UI for Book, under the Operation List section.

Reloading Model Operations

Operations of a modeled class must be reloaded when the operations are modified. There are several ways to reload the changes in an operation file:

• From RapidCMDB home page/model page:
  • Go to model's view (http://host:port/RapidSuite/model and click on the id of the model to be reloaded)
  • Click on Reload button in the Model's show view
• From Web UI: http://host:port/RapidSuite/model/reloadOperations*<model id>*
• From script: <ModelName>.reloadOperations()

Model Generation Mechanics - Advanced Topic

Directories 

"data" directory will be created under both RapidCMDB and RapidCMDBModeler upon service startup. These are the persistent repositories for these applications. Currently an empty "operations" directory is created under RapidCMDB.

RapidCMDB Modeler

When the modeled classes are defined in RapidCMDB Modeler along with Datasource names and relations between modeled classes, the modeling meta data is captured in the UI and it is saved in the Compass repository. This information will be converted to a transient XML string in memory and will be passed to Model generator to generate a subset of modeling artifacts. Currently, only the domain classes are generated under RCMDB/generatedModels/grails-app/domain folder. Views, Controllers, and Operation template files are not created at this step.

The purpose of the "generatedModels" directory is to insulate currently running application from potential generation errors. When RapidCMDB is reloaded, the latest artifacts will be validated and will be deployed only if they are valid.

RapidCMDB

Currently, when the application is reloaded

• more files are generated, not in generatedModels dir but in the deployment area (views, controllers and operation templates).
• domain classes are copied from generatedModels dir to the deployment area.