Latest revision as of 01:32, 3 June 2026

Visão Geral do Fluxo de Dados

Veja como os dados trafegam através do MIF em ambas as direções:

Fluxo de Saída (Maximo --> Sistema Externo)

1) Business Event – Um registro é criado, atualizado ou excluído no Maximo.

2) Publish Channel – Avalia se esse evento deve disparar uma mensagem de saída.

3) Object Structure – Organiza os dados na estrutura XML definida.

4) Processing Rules – Aplica mapeamentos de campos, transformações ou condições.

5) Outbound Queue – Coloca a mensagem na tabela MAXIFACEOUTQUEUE para processamento assíncrono.

6) Endpoint – Encaminha a mensagem para o sistema externo (HTTP, JMS, arquivo, etc.).

Fluxo de Entrada (Sistema Externo --> Maximo)

1) External System – Envia dados para um endpoint do Maximo (HTTP, JMS, arquivo ou tabela de interface).

2) Inbound Queue – A mensagem chega à MAXIFACEINQUEUE para processamento.

3) Enterprise Service – Identifica o serviço correto e a ação de processamento correspondente.

4) [XSL Transformation (se configurado)]

5) Object Structure – Mapeia os dados recebidos para os objetos de negócio (MBO) do Maximo.

6) Inbound Processing Rules – Aplica mapeamentos de campos, valores padrão e transformações.

7) Business Processing – O Maximo cria, atualiza ou exclui o registro de destino.

Essa arquitetura bidirecional tornou o MIF extremamente versátil. O mesmo framework era capaz de lidar tanto com importações simples de arquivos texto quanto com sincronizações bidirecionais complexas, em tempo real, com sistemas ERP.

Detalhes

Object Structure

<MXWO>
 <WORKORDER>
   <WONUM>WO-12345</WONUM>
   <DESCRIPTION>Pump motor replacement</DESCRIPTION>
   <STATUS>WAPPR</STATUS>
    ...
   <WPMATERIAL>
     <ITEMNUM>PUMP-100</ITEMNUM>
     ...
   </WPMATERIAL>
   ...
   <WOACTIVITY>
     <TASKID>10</TASKID>
     ...
   </WOACTIVITY>
   <WOACTIVITY>
     <TASKID>20</TASKID>
     ...
   </WOACTIVITY>
 </WORKORDER>
</MXWO>

Na prática, as Object Structures fornecidas nativamente pelo Maximo raramente atendem exatamente às necessidades da sua integração. Normalmente, você criará Object Structures personalizadas contendo apenas os campos necessários para cada integração.

Por que personalizar? menos campos resultam em mensagens menores e processamento mais rápido. Permite excluir campos sensíveis (dados de custos, informações pessoais etc.) dos sistemas externos.

Operações: O que acontece com os dados

Quando um Enterprise Service recebe uma mensagem, o MIF precisa determinar qual ação executar sobre os dados. As operações mais comuns são:

Create — Cria um novo registro. Falha se o registro já existir. Ideal para cargas iniciais de dados.
Update — Atualiza um registro existente. Falha se o registro não for encontrado. Utilizado para alterações de status ou atualização de campos.
Delete — Remove ou marca um registro para exclusão. Utilizado para sincronizar a desativação de registros.
CreateOrUpdate — Cria o registro se ele não existir ou atualiza se já existir. É a operação mais utilizada em integrações.
Sync — Realiza uma sincronização completa, tratando criação, atualização ou outras ações conforme o estado dos dados. Indicada para cenários de sincronização bidirecional.

Invocation Channel vs. Enterprise Service

A escolha entre um Invocation Channel e um Enterprise Service normalmente depende da necessidade de resposta imediata ou processamento assíncrono.

Invocation Channel
- Comunicação síncrona (requisição/resposta).
- O sistema chamador aguarda a resposta imediatamente.
- Erros são retornados instantaneamente ao chamador.
- Menor capacidade de processamento, pois as requisições são tratadas individualmente.
- Maior dependência entre os sistemas, que precisam estar disponíveis ao mesmo tempo.
- Indicado quando a resposta é necessária imediatamente.

Enterprise Service
- Comunicação assíncrona (fila de mensagens).
- O processamento ocorre posteriormente, sem aguardar resposta imediata.
- Erros podem ser reenviados ou reprocessados por meio das filas.
- Maior capacidade de processamento devido ao uso de filas e processamento em lote.
- Menor acoplamento entre os sistemas, já que as filas absorvem indisponibilidades temporárias.
- Indicado quando o processamento pode ocorrer posteriormente.

O que são Interface Tables?

As Interface Tables são tabelas de estágio (staging tables) no banco de dados do Maximo que atuam como intermediárias entre o Maximo e sistemas externos. Elas permitem que dados sejam carregados ou extraídos do Maximo de forma desacoplada, sem a necessidade de integração direta via APIs, serviços ou filas de mensagens. Os registros são inseridos nas tabelas de interface e posteriormente processados pelo MIF (Maximo Integration Framework), que realiza as validações e atualizações necessárias nos objetos de negócio do Maximo.

INBOUND (External System --> Maximo):

 [External System]
       |
       | (writes records via SQL INSERT)
       v
 [Interface Table: e.g., MXWO_IFACE]
       |
       | (IFACETABLECONSUMER CRON task picks up records)
       v
 [MIF Enterprise Service processes record]
       |
       v
 [Maximo business object created/updated]

OUTBOUND (Maximo --> External System):

 [Maximo business event triggers Publish Channel]
       |
       v
 [MIF writes to Interface Table: e.g., MXPO_IFACE]
       |
       | (External system reads via SQL SELECT)
       v
 [External System processes record]

Filas JMS e Processamento de Mensagens

O MIF oferece suporte a filas JMS (Java Message Service).

JMS na Arquitetura do MIF

As filas JMS fornecem um mecanismo de entrega assíncrona de mensagens, desacoplando o sistema remetente do sistema destinatário.

Isso permite que as mensagens sejam armazenadas e processadas mesmo quando um dos sistemas estiver temporariamente indisponível.

No MIF, o JMS é utilizado principalmente de duas formas:

Filas Internas — as filas de processamento do próprio MIF, como MAXINQUEUE e MAXOUTQUEUE, podem utilizar JMS como mecanismo de transporte e gerenciamento de mensagens.
Filas Externas — integração com plataformas de mensageria corporativa, como IBM MQ, ActiveMQ e outras soluções compatíveis com JMS.

O MIF suporta dois modelos de processamento para filas JMS:

MDB (Message-Driven Bean): Processa mensagens imediatamente após o recebimento.

JMSCRONQUEUE: Consulta a fila em intervalos configurados (Processa mensagens em lote).

Resumo: use MDB para processamento imediato e JMSCRONQUEUE quando a prioridade for controle e escalabilidade.

Tipos de Endpoint no MIF

O MIF suporta diversos tipos de endpoint para atender diferentes cenários de integração:

HTTP/HTTPS
- Utilizado para APIs, serviços REST e integrações com sistemas em nuvem.
- Comunicação síncrona baseada em requisições web.

JMS
- Utilizado para integração com filas de mensagens, como IBM MQ.
- Fornece comunicação assíncrona e alta confiabilidade.

Interface Table (IFACETABLE)
- Utilizado para integrações baseadas em banco de dados.
- Processamento realizado por tarefas CRON.
- Comum em sistemas legados e cargas em lote.

Flat File (FLATFILE)
- Exporta ou importa arquivos XML, CSV ou texto.
- Adequado para integrações baseadas em troca de arquivos e SFTP.

Web Service (SOAP)
- Utilizado para integração com serviços SOAP.
- Muito comum em integrações com SAP e Oracle.

Ver também