In IBM Maximo, audit tables can be incredibly useful for tracking changes to records in the system, such as when data is created, modified, or deleted. These audit tables are typically used for tracking changes for security, compliance, or troubleshooting purposes. One application that audit tables have been a life saver is against automation scripts. By using audit tables against automation scripts, administrators can easily see recent changes and revert code when necessary.
Before you can track changes, auditing must be enabled in Maximo. This can be done through the Database Configuration application. Note that this does required a database configuration.
To view the audit changes, there are a few approaches that can be used. In general, you pull and display audit data just like any other Object in Maximo. The easiest way to view the data is via the database. This works great for occasional use by an administrator and is our best bet for automation script data. For other objects, a report, customs tab in a related application, or even a dedicated application would make viewing the data with Maximo easier.
When looking at the data, most columns on the source object will not be audited and therefore will be null in the audit table. There will also be some audit table specific attributes. These attributes record the user, type of update, and timestamp of the change. In the example below, we can see the insert (I) of an automation script, updates (U) over time, and the deletion (D) of the script. The source column was audited in this example so we can also extract the code from each of the changes for further analysis.
select autoscript
,active
,source
,eauditusername
,eaudittype
,eaudittimestamp
from a_autoscript
where autoscript='LABTRANS.APPVALIDATE'
order by eaudittimestamp desc
You can add a custom tab in an existing Maximo application to display the audit history for a particular record. For example, you might want to show a "History" tab for automation script to show the same data that the previous example showed via the database.
Enabling audit tables in Maximo results in additional records being written to the audit tables, which can slightly slow down operations on the audited objects. This is because both the main object and the corresponding audit table must be updated simultaneously. As a result, you may notice delays in the user interface, and over time, the database size will increase. Based on my experience working with numerous Maximo databases, it's common to find that audit tables often have the highest record counts of any tables in the system. Displaying audit data within the UI can further impact performance, particularly when querying large datasets. While this may not be a concern in scenarios like automation scripts, enabling auditing on high-volume objects like work orders could present challenges. To address these performance concerns, I recommend only auditing high-value columns, such as the automation script source column. If you need to audit larger objects or make audit data readily accessible in Maximo, it’s also important to consider adding indexes to support the performance of those interfaces.
