In this blog series I’ve been thinking about the most common questions I get when integrating IBM Maximo Asset Management into an enterprise resource planning (ERP) system.

As I mentioned in my previous blog posts, I split this process into three steps:

1. The what: What are the data sets that need to be shared?
2. The when: When is this needed?
3. The how: How are we going to perform the integration?

In Parts 1 and 2 I discussed the what and when components, and in this blog post I am going to cover the how.

At this point you have identified the data sets and frequency of each of the integration points required. Now we need to think about how we are going to perform the integration actions.

As I mentioned earlier I am not going to cover the technical aspects of the integration in great detail and will focus more on the design process. Therefore when we get to the how, the first question you need to ask is whether the integration action needs to be automated or manual.

Automation or not?

There are a number of data sets that may require sharing across the systems but only contain a small amount of data and hardly ever change, such as the IBM Maximo organizations and sites. These data sets may not warrant automation, and a manual process to keep these aligned may suffice.

If the data set is high volume and changes are frequent, then regardless of whether real-time or batch integration was defined an automated integration is the most likely outcome. Examples of these are shown in this table:

For automated integration there are number of methods and tools you can use, but pretty much all of them will use the IBM Maximo Integration Framework (MIF).

Preconfigured adapters for integration between IBM Maximo and some enterprise resource planning (ERP) systems such as SAP or Oracle are available from IBM and may be used if your design consists of reasonably standard processes, and IBM Maximo and your ERP system have remained  as close to the standard configuration as possible without the need for any complex customisation.

On the other hand, if you have heavily customised environments or have complex supporting processes that do not fit the way these adapters work, then a custom solution is usually the selected approach.

Do I need an ESB?

You may be considering using an enterprise service bus (ESB) to manage the messaging between the systems within your environment. This has been the case in virtually all integration solutions I have been involved in over the last few years.

An interesting article I read recently by Kai Wahner made the following statement:

“Numerous products from different vendors include the name "Enterprise Service Bus." Unfortunately, there is no standard definition of this term. The products therefore offer many different features. The term ESB should always be clearly defined before it is used. In the following, an ESB is defined as a software product which assists the developer in application integration and therefore provides the necessary infrastructure to implement routing, translation, and other integration facilities.”

You can read the full article here, where Kai also discusses some of the ESB solutions that are available.

On the integration solutions I have been involved in, we have also taken the approach that the source system will always send complete data sets to the ESB.  Then, as part of the processing rules, the target systems will be presented with only the data attributes they require to enable those systems to deliver the functions they are performing.

This method allows the supply of data to multiple target systems if required but using a single integration point from the source system. An example of this would be where your ERP is the master source of the company’s data.

IBM Maximo would be one of the target systems for this data, but your client may also have a 'requirement for another system that also utilises companies data. Each of these systems may require different data from the company record, but you only need the source ERP system to send this data set once to the ESB, and then you let it manage the push to each of the target systems.

The Maximo Integration Framework can perform integrations using the following transfer methods: web services, HTTP, XML and file transfer among others. So you need to identify the most appropriate method to send the messages to either the ESB or directly to the other system you are integrating with if not using an ESB solution.

Configuration

Now that you have the what, the when and the how you should be in a position to start the configuration of each of the products. For example, in the Maximo Integration Framework you will need to create the following:

• External system
• Endpoints
• Publish channels
• Enterprise services
• Web services

 For more detailed technical information in relation to the configuration of the IBM Maximo Integration Framework please use this link.

Error Handling

Now we’ll talk about probably one of the most important components for your solution to ensure reliability. Error handling should be considered in its own right for each of the integration points you are developing and should have documented processes as well as the actual code that will make up the error handling solution.

In the scenario I mentioned earlier, when you have an ESB there are at least three potential failure points:

1. IBM Maximo
2. ESB
3. ERP system

Each of these possible points of failure may have both inbound and outbound messaging being performed, and therefore you have six failure points to consider against each integration point.

You will need to ensure that each of the possible failures have been identified and that the systems have the code in place to catch and act upon any errors received.

In the case of IBM Maximo this part should be relatively straightforward, because the integration framework uses the Maximo business objects and therefore performs the same validation as it would if records were being entered manually by the user.

The other components in your solution would also need to have the same level of validation included.

Now when an error is captured you need to look at the process for notification and resolution and should result in an error-handling process document.

Well, that is as far as I intended to take this blog series. However, if there is any additional details you think I should have considered please let me know, and I look forward to you sharing your own experiences. How do they differ from the examples I have covered here?

I hope you will follow me on Twitter @stevealee0, and good luck if you are about to embark on an integration project. Thank you for taking the time to read this blog series on integrating Maximo into your ERP.