How do I determine which integration components to use for my integration scenario?
This is a common question for those who are not familiar with the I-F. Reasons for choosing the use of certain I-F components is often decided based on one or more of the following:
- The integration capabilities of the application being integrated to Maximo
- The integration skills of the developers who will implement the integration
- The need to have the integration processing occur in a synchronous or asynchronous manner
- What level of error management is required and what level is supported by the external application
- Do integration messages need to process based on events (ie. approval of a Work Order)
- Does the integration need to operate in a batch or real-time (near) mode.
- Is the I-F being used to support implementation data loading
- Will the integration be deployed using a common ESB layer within your enterprise
The above list is not intended to be all-inclusive, but it should give you an idea of the types of things to consider when planning integration with Maximo. Keep in mind, large integration deployments could involve many systems and require different integration components to be used for different external applications.
To help answer the stated question above, you need to start by having a general understanding of the capabilities offered by I-F.
The I-F is a framework that supports the sending and receiving of XML messages for querying and updating of the data in the Maximo Business Objects (MBOs). Although the framework is based on data messages in an XML format, there is support for other data formats such as .CSV, Database tables and JSON.
Beyond the format of the data, there is support for sending/receiving data in an asynchronous manner by placing integration messages into JMS queues. This allows the sender (either Maximo or the external application) of the message to drop the message to the queue and not wait until the message is processed by the receiving application. There is also support for synchronous process where one system may query the other system for data and take the response of that request for use in its application processing.
The I-F provides support for a number of common integration protocols that a customer may choose to integrate with. Some of the most common include HTTP Post of XML, SOAP-based web services, JMS queue to queue, Files (XML or .CSV) and interface tables (DB). The choice of which integration protocol is often made based on the capabilities of the external application (ie. external app only supports SOAP messages) or the capabilities of those who will implement the integration (ie developers are strong with PL/SQL and DB access, not familiar with XML).
In addition to the above, other features of the I-F include:
- Support for customizations using processing rules, java classes or XSL
- Event based processing where an event in Maximo will trigger the sending of an integration message to an external application
- Error Management application that allows for an administrator to view messages in error, provide corrections to messages and initiate the reprocessing of messages
- Support for RESTful interactions where external application can retrieve/update Maximo data as REST resources
- Enabling OSLC interactions where resource links can be saved in Maximo and used to view external resource data using the delegated UI of an OSLC Provider application.
Now that we have discussed the general capabilities of the I-F, let's look at the individual components that provide this functionality.
There are 3 main layers of the I-F. The most important is the Object Structure layer. This layer defines the content (Maximo objects and attributes) of the message (XML schema). A number of object structures are provided 'out of box' with the products and there is also an object structure application where new/custom object structures can be created by customers/implementers. Below depicts the MXPO object structure content that supports the creation and updating of a Purchase Order in Maximo.
The object structure identifies the objects (PO, POLINE, POCOST and POTERM) and its attributes that make up the message content (schema). Object structures can be defined for any objects that are registered in the Maximo Data Dictionary (DD), including custom objects. Channels and Services include a reference to an object structure that identifies the content of the message within the channel or service. An object structure can also used for integrating data stand-alone.
The Channel/Service layer is used to process an outbound (Channel) and inbound (Service) message. This layer is primarily used to implement filtering and perform data mapping or business rules that are specific to the integration processing. Like object structures, there are a number of channels and services provided 'out of box' and there are applications provided to create new/update existing channels and services. The last layer supports the sending and receiving of the messages. The End Point definition defines the protocol to be used when sending a message out of Maximo. The external system represents the application being integrated with and identifies the end point and all the channels and services being used with that external application. Depending upon your integration scenario you may need to use/configure all 3 layers or just the object structure layer.
When evaluating I-F components for your integration scenario, it is common to consider outbound integration separate from inbound. Outbound integration is when Maximo is the sender of the message to the external application. Inbound integration is when Maximo is the receiver of the message from the external application.
Outbound Integration Scenario
To support outbound integration scenarios, the I-F provides 2 Channel components, Publish and Invocation. The Publish Channel is the more commonly used channel and it provides the means to send an outbound message based on an event in asynchronous model. The Invocation Channel, supports a synchronous message processing where the response of the request from the external application may be used to update a Maximo object.
The Publish Channel can be initiated from an event (on left in image above), such as an update of an asset, or by an admin user performing a Data Export on the Channel. The XML message is created by the object structure tied to the channel and then the message processes through the channel layers before dropping to the outbound JMS queue. In the case of an event based message, the Maximo user's transaction (the user updating an asset record) will be committed after confirmation that the message was saved to the JMS queue. The Processing layers in the channel are where the implementers could choose to use the processing rules, Java code and/or XSL to modify the message, perform business rules or transaction filtering. Processing of messages out of the queue is done (by default) by the JMS CRON task. Messages retrieved from the queue are processed in a strict FIFO (First In-First Out) order and messages are delivered to the external application as defined by the configured End Point in the External System application.
The Invocation channel can be initiated from an action class (class provided with product). The XML message is created by the object structure tied to the channel and the message processes through the channel layers before invoking the End Point configured on the channel (there is no external system configuration for an invocation channel). The Processing layers in the channel are where the implementers could choose to use java and/or XSL to modify the message, perform business rules or transaction filtering. Since the processing is synchronous, the response of the invoked service is returned to the channel and the implementer can provide code to have the data mapped to a Maximo object structure for updating or could display the data from the response in the Maximo UI if desired.
The most common points (not all) to consider when deciding on which channel to use is:
- If you need event-based message processing: Publish Channel
- if you need an asynchronous processing model: Publish Channel
- if you need a synchronous processing model: Invocation Channel
Inbound Integration Scenario
To support inbound integration scenarios the I-F provides 3 Service components, Object Structure, Enterprise and Standard. The Object Structure and Enterprise Service provide support CRUD (create, replace, update, delete) operations on the MBOs that are defined in the object structure. Standard services are more fine-grained service for specific actions of a MBO such as change status or move asset. Choosing between the use of an object structure service versus an enterprise is dependent upon the integration scenario and integration capabilities of the application calling the service. The table below summarizes the capabilities of each service:
| Feature | Object Structure Service | Enterprise Service | Enterprise Service |
| Processing | Synchronous | Synchronous | Asynchronous |
| Options to invoke | EJB, Web Service, HTTP Post,File (XML or .csv),REST, OSLC | EJB, Web Service, HTTP Post | EJB, Web Service, HTTP Post, JMS, File (XML or .csv), DB Tables |
| Customization | none | Yes | Yes |
| XML format | Requires Maximo XML | Maximo or external XML | Maximo or external XML |
| Configuration | Less: requires object structure configuration | more: requires object structure, enterprise service & external system configuration | more: requires object structure, enterprise service & external system configuration |
So from the table above there are some very clear choices in certain cases. If you want to leverage interface tables then your only option is to use enterprise services in an asynchronous model. If you are integrating using REST or OSLC then your only option is to use object structure services. If you need to leverage customization points during the processing of an inbound message then you need to use an enterprise service (using a sync or async model). If you want your external system to call a web service synchronously and that system will provide Maximo XML, you can use either service type. However, you may choose to use the object structure service simply because it requires less configuration in Maximo.
The object structure service allows synchronous calls to query and/or update Maximo data. When calling, data must be a in Maximo XML format and there are no customization layers to manipulate the message. Object structures are also use for Application-based importing where the data can be in either an XML (Maximo XML) or .CSV format. This loading process is intended to be for relatively small amounts of data (not for loading 1000's of records). See
this link for more information application importing.
The Enterprise Service offers the most capabilities for inbound processing. It support many protocols, offers synchronous and asynchronous processing models and provide implementers multiple choices for customization. Probably the most common use of enterprise services is using either XML over HTTP or as a Web Service (SOAP). In addition, the use of file loading (either .CSV or XML) and integration through interface tables is heavily used as well. In terms of which protocol to use, this is often based on the external systems capability. If your external application can only invoke a SOAP web service then the enterprise service needs to be deployed as a web service.
In terms of whether to use JMS (aync) or not, may depend on whether your external application requires an immediate confirmation that the record in Maximo was created/updated successfully. One key factor here is that if you choose to not use JMS (sync processing), then the external application owns the responsibility of managing errors that may be returned to it from Maximo and it also must manage the errors and subsequent re-processing of the message to Maximo as needed. When posting a message to the Maximo inbound queue (async processing), the external application only gets confirmation that the message made it successfully to the queue. Any problems in processing the message from the queue into Maximo would be managed in Maximo by an administrator using the integration Message Reprocessing application where integration messages that hit errors can be viewed and managed.
The Standard Service is a fine-grained service for operations such as Change Status or Asset Move. These services require method annotations to be done in Application services. At this time there is a small number of services available and the use of these services is relatively small when compare to object structure or enterprise services. Standard Services can be identified using the Web Service Library application. In some cases, such as Change Status, the same functionality is available through the object structure.
to refresh the system properties to include your modification.
