Few years ago, I had written a blog on errors encountered while applying the configuration changes to one or many database objects in Maximo. One of my acquaintances had asked me to write a blog on the intricacies of configdb. Let us first understand why do we need to configure the database.
When we make some change to an object, say adding a new attribute or changing the length of an attribute, creating or modifying indexes, etc. or, may be we are adding a new object altogether in Database Configurations application, and when we click on the Save button, the changes are stored in temporary database configuration objects (secondary tables) and these changes do not take effect until you apply the configuration changes. It is important to back up your data before configuring the database. However, if we want to add a new relationship to an object or we want to modify a few relationships, once we save the record in Database Configurations application, they can be used and we do not need to apply the configuration changes. A relationship is a link between two MBOs, which is created by specifying a SQL Join statement.
There are three ways to configure the database: command-line mode, a full live configuration, or a partial live configuration with administration mode turned on. If you want to use the command-line mode, you must shut down the application server. It is easier to restore data from this configuration mode as there are no updates while the database is being configured. While restarting the application server, you need to ensure that you do not encounter internal 500 error. I had also written a blog on internal 500 error. You can refer to that if you like.
Full live configuration has least impact on users as active transactions are not interrupted or lost as administration mode need not be turned on in this case and this can be used only for non-structural changes to Maximo objects. Partial live configuration requires administration mode to be turned on which blocks users from the system applications, disables event listeners, suspends cron tasks, and does not allow remote connectivity. We should know when to use what configuration mode. For this, we need to understand the difference between a structural and a non-structural change. Before that let us also find out what are MBOs and its attributes.
Maximo Business Objects and Attributes
A business object is an object that has attributes and values, operations, and relationship to other business objects. The business object contains the business data and models the business behavior around it. The Maximo Business Object (MBO) defines a set of fields and business rules and updates one or more Maximo database tables. These can be of two types - Mbo and MboSet. MboSet is a collection of Mbo objects, which has methods to manipulate, iterate and query through the data. This can be considered as a database table. Mbo represents a record in a table which implies that each MBO represents a single database record from a single database table.
Information about a business object, which is referred to as metadata, is stored in the database in database tables. The metadata that is associated with the business objects is used to manage the database objects. This metadata for a business object may include the following:
- Definition of the Business Object - Name of the object, database entity, whether the object is persistent or non-persistent, the underlying java class
- Attributes - Name, data type, length or size, field validation class
- Associated Relationships - associations between tables that are created using join statements to retrieve data.
The Attributes of business objects contain the data that is associated with a business object. When you create an object, you must specify the attributes that are assigned to the object. These attributes can either be persistent or non-persistent. A persistent attribute represents a database table column or a database view column. A non-persistent attribute exists in memory only, because the data that is associated with the attribute is not stored in the database. The additional metadata that is associated with business object attributes, can include a domain, a custom class, a default value, and to specify whether the attribute is required, etc.
Structural Vs Non-Structural Database Change
The changes made in the Database Configurations application has the ability to change not only the data schema but also the data dictionary tables which store information about the tables, fields, and views used by Maximo. You can check the list of data dictionary tables here.
There is also a set of shadow data dictionary tables which are known as the CFG tables, which store the necessary changes made in the Database Configurations application until you are ready to apply those changes to the database. So, the changes which are made in the Database Configuration application are actually written into the CFG tables and after the DBConfig process is successful, the changes are written into the data dictionary tables which may alter the schema of the database or reconfigure particular attributes.
A non-structural change to Maximo object does not disrupt the live business object definition. For example, if we change the field validation class for an attribute or we add a domain to an attribute and perform a live update to apply the changes, the business objects that are already instantiated are not re-validated. Modifications to indexes do not use the CFG tables but use two other Maximo objects, MAXSYSINDEXES and MAXSYSKEYS. These changes are also considered as non-structural and hence, do not required admin mode to be turned on before configuring the database.
A change which may alter the data schema, like the ALTER, CREATE, DROP statements in SQL, is termed as as Structural change, like, creating or deleting a Maximo object, changing the data type or length of an attribute, etc. A structural change may alter the transaction table. For certain structural changes, Maximo will automatically rename the original table with an XX prefix during the configuration process and these tables will serve as backed up data. This would be for major modifications, like data type changes which cannot be made on a table with data in it. The configuration process reconstructs the table schema and restores the data from the backup. These backup tables will be retained so as to be used in case you need to do a roll back of the configuration process, and they can be deleted periodically by an administrator. Turning admin mode on allows the structural changes to be applied to the database without stopping the application server.
Changes to the structure should only be done through the Database Configuration application and not directly through the database. This will ensure that all Maximo rules are observed. After doing the changes in the database configuration, the system will then take care to do the changes to the underlying database, if any are needed.
Using Database Configuration Application - WHY?
An object is a self-contained software entity that consists of both data and functions to manipulate data. User-defined objects are always created in the Database Configuration application. All changes should be performed from here, as this will ensure the integrity and upgrade-ability of your configuration.
When adding a new MBO, there are several settings which one should configure. Just to mention a few, you can set a “Custom class” which will tell Maximo which Java class has the logic to be used with this MBO. You can also set the MBO to be a View or enable Auditing for this MBO. So, it is not as simple as creating a new table in the database using CREATE TABLE statement.
When we are creating a new object in Maximo database, it is not as simple as creating a new table in the database using CREATE TABLE statement in the native database. The changes should be saved in the Data Dictionary tables else we cannot use it from Maximo instance. The object details will be saved in MAXOBJECT table which may be based on MAXTABLE or MAXVIEW. Details of the attributes of this object will be saved into MAXATTRIBUTE table, details of indexes will be saved in MAXSYSINDEXES and MAXSYSKEYS tables, and details of relationships will be saved in MAXRELATIONSHIP table, details of the columns for the view will be saved in MAXVIEWCOLUMN, and MAXSEQUENCE table will store all the sequences used in the system.
When we create the new object in Database Configurations application and save the record, details are saved in the shadow tables, MAXOBJECTCFG, MAXATTRIBUTECFG, MAXTABLECFG, MAXVIEWCFG, etc. During the partial live configuration process, the system runs the CREATE TABLE statement in the native database and also inserts the changes into the data dictionary tables as mentioned above. Once the configuration process is successful we will be able to access this object in the Maximo instance.
We can create a native view directly in Maximo database using CREATE VIEW statement, then we can come into Database Configurations application and click on New Object icon, provide the same name of the view created above in the Object field, "Imported?" and "View?" checkboxes will get automatically checked, and "View Select", "View From", and "View Where" fields will be populated with the appropriate portions of the SQL statement. When you save these changes in the Database Confugurations, the details are written to MAXOBJECTCFG, MAXATTRIBUTECFG, MAXVIEWCFG tables and after the configuration changes are applied with admin mode turned on, these changes are written into MAXOBJECT, MAXVIEW, MAXATTRIBUTE, etc. tables and you can access the view in Maximo UI. You can refer the youtube video for the same.
No comments:
Post a Comment