<p>
O interesse em realizar a integração mainframe com JD Edwards, SAP, Salesforce.com, Microsoft SharePoint, Lotus Notes e outros softwares C/S e Web ou soluções Software-as-a-Service (SaaS) continua em alta demanda.
</p>
<p>
Embarcar em um projeto de integração mainframe requer uma cuidadosa avaliação das opções de integração disponíveis. Para a maioria das organizações de TI que rodam aplicações mainframe, é desejável manter a lógica de negócios atual e o poder de processamento do mainframe tanto quanto possível. No entanto, na maioria dos cenários, a integração para SaaS e ambientes não-mainframe requer um servidor de integração que fique fora do mainframe, bem como um padrão de integração disponível no mainframe.
</p>
<p>
Uma série de padrões de integração mainframe está disponível para ajudá-lo a conseguir a integração de aplicações em toda a empresa.
</p>
<p>
Os desafios a serem considerados na integração mainframe incluem diferenças fundamentais entre os sistemas, tais como padrões texto EBCDIC versus ASCII.<br />
<br />
Encontrar informações metadados sobre as estruturas do arquivo também é fundamentalmente diferente entre mainframe e outros sistemas. No mainframe, a maioria da programação é realizada em COBOL e os dados são definidos e contidos internamente no COBOL-Copybook. Freqüentemente, o copybook é a única fonte de metadados também. Além disso, deve ser levado em consideração se o processamento no mainframe ocorre em processos online, processos batch ou alguma combinação. A questão não é se você pode integrar, mas como o processo de negócio deve ser desenhado para lidar com dados síncronos em tempo real, semi-síncronos em tempo quase real e assíncronos em ambientes batch. O processamento de eventos nem sempre é fácil e exige uma análise cuidadosa quando o objetivo é atingir uma arquitetura dirigida a eventos ou, pelo menos, processos dirigidos a eventos ou triggers.
</p>
<p>
Padrões de Integração Mainframe que podem ser utilizados com iBOLT.
</p>
<p>
Adaptadores de banco de dados mainframe. Um adaptador de banco de dados conecta-se diretamente ao banco de dados mainframe e procura mudanças na base de dados ou responde às triggers do banco de dados. Esses adaptadores podem normalmente ler, escrever, apagar e atualizar os dados na base de dados do mainframe, assim como fornecer os dados do mainframe através de certos protocolos.
</p>
<p>
Adaptadores de banco de dados são soluções muito poderosas e de “low-level”, mas têm a desvantagem de exigir que o arquiteto de integração tenha profundo conhecimento das estruturas de dados utilizadas e os processos da aplicação.
</p>
<p>
Enquanto a leitura de um banco de dados é menos problemática, gravar diretamente em um banco de dados é problemático e poderia mesmo anular as obrigações de suporte do fornecedor da solução.
</p>
<p>
Adaptadores mainframe ODBC.Outra abordagem é o uso de um driver ODBC, tais como um nativo para o servidor SNA ou um dos diversos disponíveis a partir de fornecedores de softwares de terceiros. O driver ODBC tem a vantagem de ser mais amplamente acessível por software de terceiros, mas no final tem as mesmas limitações fundamentais ou riscos associados com adaptadores de base de dados ou acesso direto.
</p>
<p>
FTP. File Transfer Protocol (FTP) utiliza o TCP / IP e fornece uma maneira de transmitir arquivos entre os diversos sistemas, incluindo mainframes, sistemas Linux, IBM i, sistemas UNIX e servidores Windows. Em mainframes IBM, o sistema operacional z/OS inclui capacidades tanto para pegar e colocar comandos para transferir arquivos. Existem sérias limitações para a integração baseada em FTP, no entanto: 1) A quantidade de análise necessária para a obtenção de dados relevantes é normalmente extensa. 2) Riscos de segurança não são superficiais e requerem atenção meticulosa. 3) FTP é ineficiente dos recursos por exigir uma conexão de dados separada para cada arquivo transferido. 4) Análise de diretórios FTP também é complexa. 5) Pelo alto volume de requisitos integração, a gestão de todos os arquivos FTP pode se tornar problemática.
</p>
<p>
APIs proprietárias. APIs proprietárias podem, a princípio, parecer atraentes baseada na especificidade da sua integração para uma aplicação específica. Isso também pode ser um ponto fraco, porém, devido ao alto investimento em icenciamento e trabalho para fazer estas APIs funcionarem e por elas terem essencialmente uma única finalidade. Se mais tarde você descobrir que precisa de um outro ponto de integração, você está de volta ao ponto inicial para pesquisar o padrão de integração correto. Uma abordagem melhor parece implicar em uma solução generalizada de integração em ambos os lados do mainframe e o lado não-mainframe do cenário de integração.
</p>
<p>
Emulação 3270. Outra opção para integração mainframe é a emulação 3270. Adaptadores disponíveis irão publicar um Webservice seguro que permite a comunicação bidirecional com sistemas e aplicações mainframe via interface do usuário stream conhecido como 3270. As vantagens desta abordagem são a quantidade relativamente pequena de trabalho de integração necessário para o lado mainframe. Um usuário experiente pode em poucas horas ser treinado no emulador para encontrar o fluxo correto para revelar os dados ou conduzir às transações e outros I/O necessários. Todavia, as possibilidades de integração serão limitadas aos fornecidos pela aplicação para o usuário. Se há uma necessidade de ir além destes limites, então este pode não ser o melhor padrão de integração. Além disso, o risco de uma concepção inadequada de integração deve ser cuidadosamente considerado. Até mesmo usuários experientes podem desconhecer completamente as ramificações de uma interação particular.
</p>
<p>
Messaging Queues (MQ). Com JMS ou WebSphere MQ no mainframe, um protocolo de mensagens que pode ser observado e inclui capacidades de transferir mensagens e aumenta significativametne a capacidade de integração do sistema. Em muitos aspectos, messaging é a melhor porta para integração. Mas não deve ser confundida com a solução total, mesmo com MQ, você tem apenas parte da solução. E, nem todos os sistemas são preparados para lidar com MQ. Por esta razão, outros protocolos como o CICS podem ser preferíveis não apenas por sua maior presença, mas também devido à forte base de conhecimento em mainframe da comunidade de TI que o utiliza.
</p>
<p>
CICS. Sistema de Controle de Informações do Cliente (CICS) é um server de transações mainframe concebido principalmente para uma interação rápida, alto volume de processamento online e pode também realizar processos background. Com um adaptador CICS, um motor de integração como o iBOLT Integration Suite pode ser criado para aparecer como outro servidor CICS para um sistema mainframe. O suporte CICS para a operação multi-região (MRO), prevê um simples e seguro ponto de entrada para o ambiente da aplicação mainframe sem a necessidade de muito esforço de programação. Algumas soluções de integração CICS utilizam a interface Weservices CICS no mainframe para o mundo exterior. Um padrão ideal CICS utiliza o adaptador para conectar a um broker de integração, eliminando assim a necessidade de desenvolvimento de múltiplas interfaces e simplificando a integração com os sistemas fora do mainframe.
</p>
<p>
Para gerenciar a integração em sistemas fora do mainframe, o iBOLT Integration Suite está disponível e inclui editor de topologia, editor de processos de negócios, editor de fluxos, e monitor.
</p>
<p>
Senior Vice President – Magic Software Americas
</p>
