Maximo Integration Framework_Architecture1.0

8/10/2019 Maximo Integration Framework_Architecture1.0

1/17

Maximo Integration Framework-

Architecture


2/17

December 17, 2009

Agenda Maximo Integration Framework : Basics

Maximo Integration Framework : Integration Types

Maximo Integration Framework : Operations

Maximo Integration Framework : Transaction Processing

Maximo Integration Framework : JMS Queues

Maximo Integration Framework : Inbound Integration Process Flow

Maximo Integration Framework : Outbound Integration Process Flow

Maximo Integration Framework : Components


3/17

December 17, 2009

MIF : Basics

The Integration Framework is an integral part of Tivoli Process Automation Platform (TPAP)

Allows the synchronization and integration of data between an External System and applications thatuse these Base Services.

There are 57 integration objects (Object Structures) provided with the product that can be used by

configuring the Integration Framework.

Follows the Service Oriented Architecture (SOA) directive and implements Web Services.

The External System can be another system (such as Oracle Financials), or it can be the same

application, such as Maximo Asset Management or CCMDB.

It is any system that can accept transactions. The External System (the location to which thetransaction is sent) is known as an End Point.


4/17

December 17, 2009

MIF :Integration Types

Integration types define how the integration is performed.

Data Integrat io n: The data for two applications is synchronized. Whenever something happens inthe application, the external system will have the same data. The reverse is also true. This type of

integration is transactional and usually asynchronous.

OMP Integrat ion: Operational Management Product (OMP) integration allows communication

with an OMP.

Appl ic at ion Integration: This represents real-time, synchronous communication between the

application and the external system to retrieve information from each other or perform actions


5/17

December 17, 2009

MIF :Transaction Processing (Contd..)

To process the integration types, the Integration Framework can integrate an application with an

external system using :

Asynchronousprocess ing:This is not a real-time connection and the two systems

communicate through a queue.

Synchronousprocess ing:This is a real-time connection between the two systems. Whenever a

transaction is sent from the application, it is immediately received by the external system. If a

transaction is sent from the external system, it will be immediately received by the application.


6/17

December 17, 2009

MIF :JMS Queues

Use Java Message Service (JMS) queues to exchange data with an external system.

When an enterprise service message is received, it writes the message to a JMS queue. Messagesremain in an inbound queue until they are successfully processed into the system or deleted from the

queue.

When the system sends publish channel messages, the message is written to a JMS queue. The

message is then sent to an external system. Messages remain in an outbound queue until they are

successfully processed or deleted from the queue.

There are three default message queues:

One outbound sequential queue

Two inbound queues, one sequential and one continuous


7/17

December 17, 2009

MIF :JMS Queues

Queues


8/17

December 17, 2009

MIF :JMS Sequential Queues

When a message results in an error, the system generates an error file and does not process

subsequent messages in the queue until the error is cleared.

The sequential queue is for transactions that are sequence dependent, such as purchase orders,

receipts, and invoices.

Sequential transactions are processed one by one. If the first one fails, the queue comes to a halt.

For example, a receipt cannot be processed before the purchase order is processed. Another

example is exchange rates. This type of transaction should go through a sequential queue;

otherwise the data would be inconsistent.

The sequential queue is driven by a cron task.


9/17

December 17, 2009

MIF :JMS Continuous Queues

Messages are processed in a multi-threaded mode, which produces better system performance.

When message processing results in an error, the system generates an error file, then continuesprocessing subsequent messages in the queue.

Other transactions do not depend upon each other.

If one fails, the next one can still be processed. These transactions can go to the continuous

queue.

The continuous queues are JMS queues and processed with a message-driven bean.

The WebSphere Application Server (WAS) has a second queue that can be configured to process

the transactions that fail in the continuous queue. When a transaction in the continuous queuefails, it is placed in the error queue to allow the continuous queue to continue processing other

records.


10/17

December 17, 2009

MIF :Operations

The operations identify the purpose of an integration transaction.

Two types of operations identify Outboun d Transact ions: Publ ishis for asynchronous transactions generated by a publish channel.

Invokeis for synchronous transactions that use invocation capabilities.

Five types of operations identify Inbound Transact ions:

Syncoperation allows data synchronization. It updates the record if it exists. Otherwise, a new

record is created.

Createoperation to create a new record.

Updateoperation indicates that the record is going to be updated. An error is produced if record

does not exist.

Deleteoperation indicates that an existing record needs to be deleted. An error is generated if

the record does not exist.

Queryoperation is used for query and response. The query returns a response with all the data

defined in the response object.


11/17

December 17, 2009

MIF :Operations (Contd..)


12/17

December 17, 2009

MIF :Inbound Integration Process Flow (Contd..)

Asynchronous Inbound Process Flow


13/17

December 17, 2009

MIF :Inbound Integration Process Flow (Contd..)

Synchronous Inbound Process Flow


14/17

December 17, 2009

MIF :Outbound Integration Process Flow

There are two types of outbound transactions: asynchronous and synchronous.

The two ways of generatingAsynchronou s Transact ions

are event-based or export-based. Event-basedmeans that when something happens on the application side, such as the approval

of a work order, a transaction is sent out.

Export-basedallows any publish channel to be exported manually at any time.

There are two ways of sending a transaction Synchronously:

Invocat ion channel:lets the application call an inbound facility on any external system and can

use any of the end points supported by the Integration Framework.

In tegrat ion mod ule:is used by the OMP integrations.


15/17

December 17, 2009

MIF :Outbound Integration Process Flow (Contd..)

Outbound Asynchronous Process Flow


16/17

December 17, 2009

MIF :Outbound Integration Process Flow (Contd..)

Outbound Asynchronous/Synchronous Flow


17/17

December 17, 2009TCS Internal 17

Maximo Integration Framework : Components

Object Structure

Enterprise Service

Publish Channel

Invocation Channel

External System

End Points

Web Services

Logical Management Operations

Integration Module

Launch in Context

Documents

Maximo Integration Framework_Architecture1.0