Interfaces are a common cause of record refresh errors and the design of the interface is important.

If an interface generates a number of transactions for the same record (e.g. a workorder) in a very short period of time then it is possible that one of the transactions could suffer from the record refresh error.

Figure 1 Why multiple MIF transactions on a continuous queue can lead to record refresh errors

How to check if this is happening on your system

The diagram above shows how three separate transactions can collide and lead to the error.

However system administrators often “receive” a new interface as part of a new release and may not understand / be told that multiple messages could be received simultaneously or in a very short time period.

Maximo can be configured to help system administrators if the messages are being received on a continuous queue***. The configuration instructs Maximo to search the message for a particular XML attribute and record its value e.g. workorder number. This is then stored with the message so that the value can be seen in the Message Tracking application.

System administrators can then instantly see that a number of messages were received at the same time for the same record.

Details about how to configure this can be seen in my “Making Maximo integrations easier to support” webcast on the IBM Middleware User Community site. If you are impatient then jump straight to 24:06 for 8 slides that provide advice around Message Tracking and how to configure this.

 It is free to create an account and there are a number of interesting presentations on there. Vetasi customers can raise a helpdesk call and get these slides and some additional information.

*** This configuration is recommended for all Object Structure/Publish Channels/Enterprise Services that use queues regardless of the queue type.

What is the cost of this error?

The cost can be significant for new system administrators.

New system administrators often aren’t aware of the importance of the Message Tracking application so they don’t monitor/reprocess these messages in a timely manner.

If these messages aren’t processed promptly then other people may manually perform the changes which can lead to other transactions failing… This can lead to problems with financial systems e.g. unable to bill for workorders because the associated material usage records can’t be processed.

Interfaces that send multiple records at the same time also increase the load on the JVM/DB. This cost may be small for an individual message but it can grow substantially when there are lots of messages being submitted every minute.

Vetasi advice

Minimising the risk

There are several things that can be done to minimise the risk of this error:

• Build the interface so that transactions are implemented in a single transaction – this is the solution I recommended
• If the interface is using continuous queues then Configure the MDB retry delay so that there is a delay between retries when a message fails. If it fails with a record refresh error then the delay gives the other transaction a chance to complete.

Things to ask/confirm when a new interface is being designed

• Is there a situation where multiple incoming messages could be received at the same time?
• If so then how has the solution been designed to avoid this e.g. increase in retries & delay? - It is important to set a delay to give the other transactions a chance to complete
• Is it possible to group all of the incoming transactions together and pass them to Maximo as a single transaction?
• Confirm that all the messages are being stored so they can be viewed in the Message Tracking application – it is frustrating to explain that you can’t investigate a message related problem because there is no evidence to look at
• Confirm that the searchID is being set so you can easily find the messages and see if there is a timing issue. Ensure that the searchID is set to something useful e.g. PO number for PO/Receipt and Invoice.

Vetasi offer consultancy to:

• Investigate interface problems
• Design and build interfaces

This blog series

This article is one of a series of articles to help system administrators understand the Maximo logs and the underlying architecture.

If you like this article then please share or like it so other people can benefit from it.