Comparison of Maximo Integration Types

If you’ve worked with IBM Maximo for a while, you are aware that it includes robust, flexible integration capabilities via the Maximo Integration Framework, or MIF. The MIF provides support for many different communication types, including:

• File transfer
• Interface tables (database tables)
• HTTP via MIF
• REST API
• Web services

At times, the selected integration method is determined by what the connected system can support. In other cases, multiple options are available, and it’s wise to consider the pros and cons of each when designing a new integration.

File-Based Transfer

File-based communication has been around for a while, and is as simple as it sounds: one system writes a file, the other receives and processes the file. While this is occasionally the only option supported by legacy systems, data and error management capabilities are limited and often require external scripting.

Fortunately, it’s easy to set up a publish channel in Maximo using a file-based end point. Once that’s in place, it’s just a matter of tuning the publish channel rules to only output a file when desired. In addition, you’ll want to enable the event listener for the publish channel. With the file output, you’ll now need to devise a file management scheme to process the files and remove them from the output folder.

Inbound files may be read using one of Maximo’s file consumer cron tasks: FLATFILECONSUMER for flat files, such as CSV, and XMLFILECONSUMER for XML-formatted content.

Interface Tables

Interface tables provide another option that is often supported by legacy systems. Interface table integration involves creating tables in the Maximo database to manage inbound and outbound messages.

For outbound messages: Maximo writes the information from the business object to the outbound table. It is the responsibility of the target system to read the data from this table and mark it as consumed. Various options are available, but careful design is required.

For inbound messages: The target system writes to Maximo’s inbound interface table. Maximo’s integration framework can be set up to automatically process the data once it has been written to the table. From there, you will need to address your error resolution strategy.

HTTP via Integration Framework

HTTP-based integrations are where Maximo shines. Using the integration framework, you can set up both inbound enterprise services and outbound publish channels that use HTTP to communicate. With HTTP integration, you can send either XML or JSON messages.

Additionally, using the integration framework and setting up an external system gives you the option to use either sequential or continuous queues. The sequential queue forces messages to be processed in the order they were received, which means that if there is an error, that entire queue comes to a grinding halt until the error is resolved. When using a continuous queue, errors are moved to a separate error handling queue, allowing subsequent messages to be processed.

You will need to define an HTTP end point for the publish channels, and you will also need to make sure that Maximo is able to communicate with that end point. This means any firewalls need to allow traffic between the two systems. Both sides will need to accept SSL certificates from each other if SSL is configured, and on the Maximo end that means importing the certificate into WebSphere.

If you’ve gone through the effort to set this up, you also have access to track every single integration message, inbound and outbound. This allows you to reference those messages when managing errors.

HTTP via REST

For rapid processing of inbound messages, REST is the way to go. REST integration allows external systems to send XML or JSON messages to Maximo and create, update, or delete records. REST is automatically enabled for all Maximo MBOs, so sending a REST message is just a matter of knowing the URL. The REST end point can and should be secured to require authentication. Messages to the REST end point are processed as they are received, but the largest drawback is that there is no message tracking.

Web Services

Web services provide a framework for an external system to communicate with Maximo via messages and queries. Maximo provides automatic schema generation for web services, so consuming them is relatively easy from the point of the external system. Please note that creating a web service requires a restart of the Maximo application server.

As stated before, web services provide a framework for querying or messaging. If you have an open-ended integration, rather than a specific set of actions that must always be taken, web services are useful. Perhaps you need to query work orders for any CM created within the last week, or perhaps you need to query the inventory table for all transactions of a specific item. In these scenarios, web services are handy because they do not force a structured integration messaging protocol.

Likewise, web services can also be configured to add, update, or delete data. And they are configurable just like the HTTP end points previously discussed. They’re a great tool to have in your arsenal, but may be overkill for what you need.

Maximo can also be set up to consume web services provided by other systems. This integration is configured in the Interactions application.

Options

While not an exhaustive list, the above options are the most common ways of using the Maximo Integration Framework. Given the wide range of options and highly-configurable utilities, we have yet to find a systems integration that Maximo can’t handle, but we’d welcome the challenge.