I would expect system administrators using queue based interfaces to be checking the message tracking application every day for ERROR messages.
Message Tracking becomes a lot more useful when the XPATH for the searchIDs has been setup for the relevant Enterprise Service/Publish Channels.
If you aren't sure how to define XPATH for the searchID then have a look at my webex on how to make Maximo Integrations easier to support.
https://www.imwuc.org/p/do/sd/sid=3049
I'm going to be raising an RFE soon that will help make these searchIDs much easier to define and remove some of the reasons given for not defining them when the interface is built.
I advise my customers to modify the Message Tracking ist screen so that it shows the initialdatetime ( MAXINTMSGTRK.INITIALDATETIME) and the searchID (MAXINTMSGTRK.SEARCHFIELDDATA)
Once those configurations are working properly then it is possible to quickly trace all the transactions for a particular record e.g. a workorder. You can then very quickly see what has been going on.
If the interfaces put or read data from external databases then I find that a clever BIRT report is really useful because it can summarise all the transactions and the related status values in one place and save a lot of time. If joint data sets are used then you can have the values from both systems in the same row and you can then compare the data.
I build these reports for my customers as consultancy and they can normally be built quite quickly if you understand the table relationships and the relevant columns.
One of the other posters referred to technote 1445791 and deleting messages.
You need to be careful to only delete messages where the transaction is completely closed e.g. a PO has been invoiced etc. You can safely delete the messages before then but you lose all track of the flow of transactions e.g. what data was sent to/from the other system. This information can be really useful if you have to understand what has happened with the record.
#Maximo#AssetandFacilitiesManagement