Before you being working with Maximo, there are a couple of important concepts you need to know. These will affect your design options in creating solutions.
First thing to know is that when programming Maximo is that it is database agnostic. What I mean by this is that Maximo does know what database it is using. What does this mean to you? Well if you are trying to develop something in Maximo and hope to sell it, then you need to make sure that your enhancement is also database agnostic. If you are developing something in-house and will never change database platforms, then this is not that big of a programming concern, but it is a good practice to do it anyway.
Next thing to know is that Maximo is an Object Oriented database. Now you might be wondering how this can be since the physical database is a standard relational database (DB2, Oracle or SQL Server). Maximo does it the same way that the Java tool Hibernate does it, through a set of class files that manage all physical read/writes to the database. As a developer, you just would use the class files for accessing the database. IBM however did not use Hibernate for the Object Oriented interface. Instead, they created their own set of classes call Maximo Business Objects (MBOs) (pronounced M.B.Os or Maybows). Since Maximo is database agnostic, there is no guaranteed way to place business rules and all data integrity requirements in the database. As such, Maximo places almost all of this in the MBOs. In the database, the only data integrity you will find are unique indexes and required fields. None of the tables have primary keys, Foreign Keys or default values. This makes updating/adding data directly to the database tricky at best. It is entirely possible to enter data into the database and have it not show up in the front end because it does not meet Maximo’s data requirements. You are safe to query the database directly but all updated/inserts/deletes should be done in Java using the MBO objects. Another benefit of using the MBOs is that your code then becomes database agnostic too.
In order for Maximo to stay database agnostic and keep the MBOs current on data structure and business rules, IBM has created its own database management tool. (This tool is built into Maximo.) It is called the Database Configuration. Here you can add/edit MBOs (tables), add/edit Attributes (fields) to an MBO, manage indexes and even create relationship to other MBOs. Once you have made your changes, you then perform a Configure Database. This will then updated the underling database with your changes.
At this point, I am going to encourage you to stop thinking in terms of tables and fields and start thinking in terms of MBOs and Attributes. There are some difference between the two. The biggest by far is that you have persistent and non-persistent MBOs and Attributes. Persistent means that it will physically exist in the database while non-persistent means that it is only available in your java code. So you can have an attribute on am MBO that doesn’t really exist in the database. (A non-existent field on a table does not make much sense so think of them as MBOs and Attributes.) In fact you can have an MBO that is non-existent in the database.
Since Maximo places all of the data integrity and business rules in the MBOs, you should always use the MBOs to deal with Maximo data. Now I am not saying there won’t be cases where the MBOs are not practical (one place IBM recognizes is in importing very large amounts of data). But in case you are not completely convinced, let me add a few other “gotchas” if you try using the database for data manipulation.
First thing to know is that when programming Maximo is that it is database agnostic. What I mean by this is that Maximo does know what database it is using. What does this mean to you? Well if you are trying to develop something in Maximo and hope to sell it, then you need to make sure that your enhancement is also database agnostic. If you are developing something in-house and will never change database platforms, then this is not that big of a programming concern, but it is a good practice to do it anyway.
Next thing to know is that Maximo is an Object Oriented database. Now you might be wondering how this can be since the physical database is a standard relational database (DB2, Oracle or SQL Server). Maximo does it the same way that the Java tool Hibernate does it, through a set of class files that manage all physical read/writes to the database. As a developer, you just would use the class files for accessing the database. IBM however did not use Hibernate for the Object Oriented interface. Instead, they created their own set of classes call Maximo Business Objects (MBOs) (pronounced M.B.Os or Maybows). Since Maximo is database agnostic, there is no guaranteed way to place business rules and all data integrity requirements in the database. As such, Maximo places almost all of this in the MBOs. In the database, the only data integrity you will find are unique indexes and required fields. None of the tables have primary keys, Foreign Keys or default values. This makes updating/adding data directly to the database tricky at best. It is entirely possible to enter data into the database and have it not show up in the front end because it does not meet Maximo’s data requirements. You are safe to query the database directly but all updated/inserts/deletes should be done in Java using the MBO objects. Another benefit of using the MBOs is that your code then becomes database agnostic too.
In order for Maximo to stay database agnostic and keep the MBOs current on data structure and business rules, IBM has created its own database management tool. (This tool is built into Maximo.) It is called the Database Configuration. Here you can add/edit MBOs (tables), add/edit Attributes (fields) to an MBO, manage indexes and even create relationship to other MBOs. Once you have made your changes, you then perform a Configure Database. This will then updated the underling database with your changes.
At this point, I am going to encourage you to stop thinking in terms of tables and fields and start thinking in terms of MBOs and Attributes. There are some difference between the two. The biggest by far is that you have persistent and non-persistent MBOs and Attributes. Persistent means that it will physically exist in the database while non-persistent means that it is only available in your java code. So you can have an attribute on am MBO that doesn’t really exist in the database. (A non-existent field on a table does not make much sense so think of them as MBOs and Attributes.) In fact you can have an MBO that is non-existent in the database.
Since Maximo places all of the data integrity and business rules in the MBOs, you should always use the MBOs to deal with Maximo data. Now I am not saying there won’t be cases where the MBOs are not practical (one place IBM recognizes is in importing very large amounts of data). But in case you are not completely convinced, let me add a few other “gotchas” if you try using the database for data manipulation.
- Since Maximo uses it own tool for DDL (managing tables and fields) and there is no way to tell Maximo you have a custom database object (like a trigger), it is possible that doing Configure Database operation will drop your trigger. (This is especially true for interface tables as Maximo only drops and rebuilds them to update their structure).
- Since Maximo uses the MBOs for all data manipulation, any changes you make via a trigger, stored proc, etc will not be known by Maximo and will require a refresh to retrieve.
- Any changes to data change you make via a trigger, stored proc, etc will not trigger escalations, work flows or interfaces within Maximo as they only look at the data in the MBO at the time save() is called.
- Maximo stores all data relationships in the MBOs. You would have to hard code any data relationships and they could then be made invalid by changes made via the Database Configuration screen.
No comments:
Post a Comment