Adding New Modeled Class

All modeled classes will be defined in Models section of ModelConfiguration.xml file. If there are relations for that modeled class to be defined, then Relations section should also be updated. For a new modeled class, following needs to be defined:

• Name: model name

  The model name should start with a capital letter.

• Parent: optional attribute for parent model name. If users set the Parent property of a model, this model's properties, datasources, operations, and relations will be inherited from the new model.
• StorageType: optional attribute that defines where the model data is to be stored, if needed. Refer to RapidCMDB Persistence Operations document for more information on how to set this attribute.
• IndexName: optional attribute that specify how the index data is to be kept. Refer to Persistent Index Data Management document for more information on how to set this attribute.
• its properties and their external datasources if there are any. Refer to Adding New Properties.
• its relations to other modeled classes if there are any. Refer to Adding New Relations.

In order to make the modifications effective, first generate the model and then reload the application.

Extending A Modeled Class

Adding New Properties

Each property for a modeled class is to be defined in the Property subsection within the appropriate Model/Properties section of a modeled class to which the property belongs. Property section supports the following attributes :

• Name: property name

  The first two characters of the property name must be small case letters.

• Default: optional attribute to set the default value for the property if the user does not provide one when creating the model instance
• Type: Supported property types are date, boolean, number (corresponds to Java long),  float (corresponds to Java double), and string.
• IsKey:  is a special, optional attribute which marks a property as key for that model in local repository.
• Datasource, DatasourceProperty and NameInDatasource: There are two categories of properties:

1. Local properties: They are stored and indexed by RapidInsight. These properties do not need to have Datasource, DatasourceProperty and NameInDatasource fields.
2. Federated properties: These properties should provide one of Datasource or DatasourceProperty attributes and optionally NameInDatasource property. If NameInDatasource property is not specified, it will be the same as the name of the property.

In Datasources section of Model, datasources which will be used in federation are defined. Each datasource has a Name and a set of Key nested tags which specify the key properties for that datasource to retrieve the federated property value. 

<RsModel>
    <Models>
        <Model Name="RsEvent" StorageType="FileAndMemory">
            <Properties>
                <Property Name='name' Type='string' IsKey="true"/>
                <Property Name='creationClassName' Type='string' DatasourceProperty="sam1" NameInDatasource="CreationClassName"/>
                <Property Name='severity' Type='number' Datasource="sam1" NameInDatasource="Severity"/>
            </Properties>

            <Datasources>
                <Datasource Name="sam1">
                    <Keys>
                        <Key Name="name" NameInDatasource="Name"></Key>
                    </Keys>
                </Datasource>
            </Datasources>
        </Model>
    </Models>
</RsModel>

In order to make the modifications effective, first generate the model and then reload the application.

Adding New Relations

Relations between Models will be defined in the Relations tag. Each Relation tag should provide the following attributes:

• From: One side of the relation (model name)
• To: Other side of the relation (model name)
• Name: Relation name at the "From" side
• ReverseName: Relation name at the "To" side
• Type: Supported relation types are one-to-one, one-to-many and many-to-many.

<RsModel>
        <Model Name="RsSmartsObject">
            <Properties>
                <Property Name='name' Type='string' IsKey="true"/>
            </Properties>
        </Model>

        <Model Name="RsEvent" StorageType="FileAndMemory">
            <Properties>
                <Property Name='name' Type='string' IsKey="true"/>
                <Property Name='creationClassName' Type='string' />
                <Property Name='severity' Type='number' Datasource="sam1" NameInDatasource="Severity"/>
            </Properties>

            <Datasources>
                <Datasource Name="sam1">
                    <Keys>
                        <Key Name="name" NameInDatasource="Name"></Key>
                    </Keys>
                </Datasource>
            </Datasources>
        </Model>
    </Models>

    <Relations>
        <Relation From ="RsSmartsObject" To="RsEvent" Name="events" ReverseName="device" Type="OneToMany" ></Relation>
    </Relations>
</RsModel>

In order to make the modifications effective, first generate the model and then reload the application.

Removing Properties, Relations, or Modeled Classes

Removing is as easy as deleting the related lines that define property/relation/model from the ModelConfiguration.xml file.

When a model is deleted, make sure that the relations that are defined for the model are also removed.

In order to make the modifications effective, first generate the model and then reload the application.

Activating Modeling Changes

Generating Models

After making the necessary changes to the ModelConfiguration.xml,  new modeled classes must be generated.

Go to the Scripts tab in the admin UI and run modelCreator script.

After the script is executed successfully, new domain classes will have been generated in the temporary location: RS_HOME/RapidSuite/generatedModels/grails-app/domain.

Application has to be reloaded to finalize the deployment.

Reloading Application

In order to generate rest of the modeling artifacts (views, controllers, and model operations) the whole application must be reloaded. These artifacts are groovy files generated in their respective directories inside RS_HOME/RapidSuite/grails-app folder, except model operations, which are saved under RS_HOME/RapidSuite/operations folder.

Reload tab in the admin UI allows you to reload parts of the application or the whole application depending on the change

Making changes to the ModelConfiguration.xml requires reload of the whole application.

Select Reload App in the admin UI. After the reload is completed, review the modified domain classes, views, controllers, and operations.

A web UI is generated for each modeled class to allow you a quick way to list, add, update, and delete instances of your modeled class. If the name of your modeled class is RsSmartsObject, simply go to the following url: http://localhost:12222/RapidSuite/rsSmartsObject (replacing the host and port if necessary)

Application reload will:

• attempt to compile generated groovy classes to validate modeling changes
• if compile is successful, these files will be copied into the deployment area and the application will be restarted.

It will take a while to generate and deploy new modeling artifacts. Please be patient while the application comes back up.

Model Operations

Implementing Model Operations

During model generation, some operations including 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/RapidSuite/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 operation file has to be reloaded. Refer to Reload Model Operations section.

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

There are several ways to reload the changes in an operation file:

• In Admin Web UI:
  • Go to admin page:http://host:port/RapidSuite/admin.gsp
  • Go to Reload tab
  • Select the model name from the Reload Operations list box
  • Click on Reload button
• In RapidInsight UI:
  • Go to model's view: http://host:port/RapidSuite/<modelName>
  • Click on Reload Operations button in the Model's list view
• From script: <ModelName>.reloadOperations()

Views and Controllers

Views and controllers are used to manage the Web UI for modeled classes. By implementing the methods in controllers, you can define the operations on a modeled class that can be called from Web UI. The default methods generated with modeled class are list, show, add, update, and delete. More methods can be implemented in the model's controller file depending on your needs.

Using views, it is possible to set which properties to be displayed and how, in certain UI pages for the model. The default views are generated for list, create, edit, show, and addTo for relation. You can modify existing views as well as define new ones for those methods you implement in the model's controller.

The views are located in RS_HOME/RapidSuite/grails-app/views folder under individual folders with model names whereas all model controller files are in RS_HOME/RapidSuite/grails-app/controllers folder.

When you modify the views or controllers, you need to reload them for the changes to be effective.