Tag iBM i

Padrões e Melhores Práticas para Integração ERP

Glenn Johnson – Senior Vice President – Magic Software Americas

Integração ERP pode ser definida como o processo de projetar, testar e implementar processos de negócios automatizados, orquestrando as conexões entre os sub-processos de um sistema de planejamento de recursos empresariais e os sub-processos de outros aplicativos de software corporativo, aplicações web, ferramentas de conteúdo, sistemas de e-mail/comunicação, mídias sociais e workflow humano.

Quando alguém aplica os princípios de integração ERP para um sistema ERP específico, isso pode se tornar conhecido como Integração SAP, Integração JD Edwards, Integração Peoplesoft, Integração Oracle eBusiness Suite (EBS), Integração Lawson, Integração Dynamics, Integração Sage, etc.

Melhores Práticas e Padrões de Integração durante a Implementação de Sistemas ERP

Plataforma agnóstica. Os sistemas ERP estão ligados a uma plataforma de aplicações ou ambiente específicos, tais como J2EE ou. NET e você também os executa em um sistema operacional específico. Sua integração de aplicações empresariais (EAI) e solução de gerenciamento de processos de negócios (BPM) deve ser capaz de trabalhar com todos os principais ambientes de computação e sistemas operacionais, incluindo Windows, Linux, UNIX e IBM i. Uma boa solução de integração ERP vai mesmo ser capaz de suportar os padrões de integração IBM i e padrões de integração de mainframe para aquelas organizações que executam aplicações nestes ambientes.

Modelagem e execução integradas. Muito freqüentemente, os analistas de negócio são forçados a modelar processos de negócios de alto nível usando uma ferramenta e executá-los usando soluções completamente diferentes, incluindo programação manual, pacotes de componentes java, ou soluções de EAI e BPM mal concebidas. Os gerentes de TI precisam ser muito cuidadosos aqui. Só porque a mesma marca, tais como IBM WebSphere ou Oracle Fusion Middleware, é aplicada a uma variedade de produtos diferentes utilizados para modelagem e integração pelos fornecedores, não significa que eles sejam integrados e projetados para trabalhar juntos. Ambas as marcas são conhecidas por ter usado uma estratégia de aquisições ao invés de uma estratégia de desenvolvimento unificado para ganhar mercado. Como resultado, suas ofertas para integração de aplicação e gerenciamento de processos de negócios são desconexas, confusas, sobrepostas e frustrantes para serem entendidas – e mais ainda para serem utilizadas.

Decisores de negócios devem ser extremamente cuidadosos com as recomendações que amarram sua integração ERP com estas soluções de integração desarticuladas e fraturadas de grandes marcas. Elas exigem numerosas compras de licenças de software e um exército de desenvolvedores e implementadores para realizar a integração. Não caia na “armadilha do mel”, método de vendas que convence que você precisa de apenas uma das muitas ferramentas de software avulsas oferecidas por estas marcas e, em seguida, prossegue com uma estratégia para vender mais e mais  produtos diferentes e desconexos que são agrupados sob a mesma marca, a fim de tentar forjar uma solução de trabalho.

Monitoramento e Design paralelos. Quando o monitor de integração utiliza a mesma interface visual que o estúdio de design de integração, fica muito mais fácil para seus gestores de TI monitorarem a execução de seus processos de negócios. Monitoramento e design paralelos significam que o fluxograma que você criou para seu projeto de integração é o mesmo que você utiliza para controlar sua execução. No estúdio de design você pode se aprofundar em qualquer componente para ver a sua configuração. No ambiente de monitoramento você pode se aprofundar em qualquer componente no fluxograma para acompanhar a sua execução.

Nenhuma Programação Manual. Há uma série de soluções de integração de aplicativos que destacam o fato de serem livres de código, ou que nenhuma programação manual é necessária. Isto só será útil se a solução o levar longe o suficiente na direção de seu objetivo final. Uma viagem gratuita de táxi que te deixa a vinte milhas de seu destino não tem nenhum valor. Uma solução de EAI que é livre de código, mas não pode adaptar-se à variedade de tecnologias em uso hoje, é igualmente de efeito muito limitado. Alguns vendedores podem mostrar uma demo estratégica de integração entre o JD Edwards EnterpriseOne e Salesforce.com, por exemplo. Mas eles realmente possuem os adaptadores de baixo nível necessários para integrar o JD Edwards World? Podem se integrar com aplicações legadas? Filas de mensagens? Fontes de texto não estruturadas? Eles podem funcionar com arrays multi-dimensionais? Será que eles possuem uma gama completa de operações lógicas incluídas em seus editores de expressão?

Equilíbrio entre Adaptadores de Alta Granularidade e Baixa Granularidade. É impossível para qualquer solução de integração de ERP ter adaptadores pré-construídos para todos os outros aplicativos que você pode possivelmente querer integrar. É por isso que é muito importante que a solução de integração ERP escolhida tenha os adaptadores tecnológicos necessários para realizar o trabalho. Isso significa muito mais do que ter suporte para bancos de dados e web services. Verifique atentamente para ver se a solução escolhida tem suporte para protocolos de comunicação, sistemas de arquivo, codificação / decodificação, redes e outras tecnologias de alta granularidade de baixo nível que te permitirão colocar em prática a integração necessária, sem recorrer à programação de interfaces para essas tecnologias. Qualquer analista de negócio que tenha experimentado a satisfação de realmente configurar uma solução de integração e não programá-la, entenderá este ponto muito claramente.

Aplicações compostas. Estas são as aplicações que são montadas utilizando tanto componentes de múltiplas aplicações existentes e adição de funcionalidades desenvolvidas especificamente, quanto serviços, tais como leitura de pedido do cliente, validação do status do cliente, cálculo do desconto ao cliente, ou aplicação de desconto ao pedido. Os componentes de uma aplicação composta são criados independentemente uns dos outros, sem o conhecimento ou análise dos diferentes modelos de informação que estão sendo usados. Na verdade, eles são independentes de plataforma, o que significa que o componente  que fornece algum serviço pode residir em qualquer plataforma capaz de fornecer tal serviço. Quando a integração ERP permite que o sistema ERP forneça serviços como parte de uma aplicação composta, você valoriza muito mais o seu investimento no ERP e começa a ver a recompensa prometida por fornecedores de ERP no início.

Arquitetura Fracamente Acoplada. Seu padrão de integração ERP deve incorporar arquitetura de baixo acoplamento com forte integração com o sistema ERP em si. Arquiteturas fortemente acopladas dependem umas das outras. Assim, alterações em qualquer componente podem (o que freqüentemente acontece) exigir mudanças em muitos outros componentes. Arquiteturas fracamente acopladas, em contrapartida, mantêm independentes os componentes que podem operar de forma independente. Uma arquitetura de baixo acoplamento permite substituir ou modificar componentes sem ter que fazer mudanças que refletem para os outros componentes. Desenvolvedores podem exigir a tecnologia correta para o trabalho sem ter que se preocupar com dependências técnicas. Na integração com ERP, você vai querer ter a certeza de que manterá os fontes do ERP e os destinos de terceiros separadamente (e vice-versa).

Componentes Stateless (sem estado). Os sistemas de ERP normalmente são capazes de múltiplas transações simultâneas. Isto é essencial para a escalabilidade da arquitetura. Quando um componente permite que mais de uma instância do componente esteja em uso simultaneamente e com estados separados, então ele é considerado um componente stateless. Isto tem a vantagem da escalabilidade e é vital para uma implementação robusta de arquitetura orientada a serviços e integração escalável de ERP.

Componentes Dinâmicos. Embora seja vantajoso ter componentes stateless em termos de dados de cada instância de execução, também é vantajoso ser capaz de configurar componentes de forma flexível para seu ambiente. Suponha que você está configurando a integração do Microsoft Dynamics CRM com o Oracle JD Edwards EnterpriseOne. Um sistema que utiliza componentes dinâmicos permitirá que você atualize a configuração do componente de forma a refletir quaisquer campos ou tabelas personalizados em uso nos ambientes de destino. O projeto de integração ERP é bastante simplificado quando os componentes utilizados podem ser passados em um pacote XML que configura a instância de execução. Um sistema de ERP que combina componentes sem estado e dinâmicos terá grandes vantagens, tanto no projeto concepção e execução.

Web Services. A Integração de ERP que utiliza Web Services pode vir a ter programação incrivelmente intensiva. Web Services programados manualmente também são difíceis de manter. Com Web Services nós estamos falando sobre o uso de protocolos padrão (como o WSDL, SOAP e UDDI) para “envolver”  serviços SOA, de forma que possam ser compartilhados com outras aplicações através da Internet. Este termo é freqüentemente usado como sinônimo de “SOA”, apesar de Web Services ser na realidade um mecanismo que permite SOA. Mas apenas porque estas tecnologias estão sendo utilizadas, isso não significa que você deve recorrer à programação delas. Uma boa solução de integração evitará completamente a necessidade de programar conexões para o seu sistema de ERP e outras aplicações, sistemas de comunicação e Web Services em seu ambiente.

Enterprise Service Bus. Um enterprise service bus é um mecanismo de mensageria distribuído baseado em XML, orientado a eventos – é um tipo de implementação de arquitetura orientada a serviços. É mais adequado para ambientes com servidor Wintel do que para ambientes de computação de médio porte, embora um sistema de médio porte possa certamente funcionar como um nó em uma implantação de enterprise service bus.

Sem um planejamento cuidadoso e a seleção de uma solução ágil de integração de processos de negócios orientada a eventos, a Integração ERP será cara, demorada e instável. Embora muitas empresas procurem evitar riscos, comprometendo-se com soluções de grandes marcas para integração, em vez disso eles estão expondo-se a maiores riscos e apenas evitando a culpa. É o fracasso destas grandes soluções para integração que inspirou a Magic Software a trazer a solução de integração iBOLT. Os wizards amigáveis ao usuário do iBOLT, as opções de arrastar e soltar, e as tabelas permitem criar conexões diretas com as aplicações corporativas implantadas em qualquer tecnologia de hardware, sistema operacional ou banco de dados. O resultado é uma arquitetura flexível e escalável que te permitirá fazer novas conexões, implementar mudanças e se adaptar rapidamente à necessidade sempre presente de mudanças em seu negócio.

Desenvolvimento de integração com JD Edwards requer a ferramenta correta para o trabalho

Glenn Johnson – Senior Vice President – Magic Software Americas

Imagine que a você tenha sido atribuída a tarefa de gerenciar o desenvolvimento de uma interface JD Edwards para a sua empresa, e agora? Você chama a Oracle, um integrador de sistemas, ou faz você mesmo?

Desenvolver interfaces JD Edwards exige consciência dos padrões de integração disponíveis para a versão do JDE e versões das ferramentas a serem integradas. A versão utilizada suporta objetos de negócios? Os processos necessários estão disponíveis? Quais módulos precisam ser interligados?

Vamos assumir por um momento que você tem uma versão antiga do JD Edwards World, sem suporte para objetos de negócios (vamos chegar ao outro caso mais tarde). Você tem opções além de escrever programas de RPG? Sim. Com o iBOLT Special Edition para JD Edwards (JDE Connect) você pode desencadear e orquestrar processos de negócios que abrangem aplicações, sistemas, pessoas e websites utilizando para a integração, uma abordagem arrastar e soltar, e configurar. Em outras palavras, um analista de negócios ou arquiteto pode executar o trabalho, sem recorrer à programação do código linha por linha. Quando os objetos de negócios são uma parte dos objetivos da integração, então o iBOLT pode fazer interface diretamente para as funções de negócios do Enterprise One (E1), por exemplo, independente de que módulo ou módulos são o alvo.

O primeiro passo é definir a sua topologia para fins de referência e para se certificar que você está usando uma convenção de nomenclatura padrão de notação. O segundo passo é mapear em alto nível o processo de negócio desejado. Chegar ao ponto em que você está pronto para mapear o processo de negócio é uma das maiores fases do seu projeto. Esta é a fase de coleta de requisitos, onde ocorre a análise de negócios em grande parte fora do sistema de integração. Uma boa sessão de “quadro branco” com uma ampla oferta de post-it para notas pode ser uma forma eficaz para descrever o que é e como é o processo de negócios desejado. Exceto que, quando você começa a documentar visualmente esses fluxos de negócios, você pode agora começar a gravá-los digitalmente no Business Process iBOLT Editor.

Tenha em mente que você está procurando identificar os eventos que disparam os fluxos de processos de negócios. Que eventos devem ser utilizados para disparar eventos? Atividade de banco de dados, e-mails pré-formatados, serviços web, exame de diretório para arquivos novos ou modificados, etc? Tenha em mente que um fluxo de negócios pode ter vários gatilhos, incluindo a realização ou uma saída lógica a partir de um fluxo diferente.

Cada fluxo normalmente deve conter as condições de execução, ações permanentes, verificação da validade, condições para a ação, saídas de fluxos de exceções e gerenciamento de status. O iBOLT Special Edition para JD Edwards irá permitir-lhe gerenciar tudo isso a um nível elevado para que o foco esteja na lógica do negócio. Não há programação envolvida. Isto é possível devido ao fato do iBOLT possuir uma biblioteca de componentes pré-construídos que são totalmente configuráveis por um analista de negócios usando uma interface gráfica (Windows). Os componentes disponíveis incluem não apenas os adaptadores para aplicação JD Edwards, mas também incluem uma robusta biblioteca de adaptadores sem a necessidade de investimentos extras. A biblioteca de componentes do iBOLT inclui componentes para .NET, Call COM, COM, Directory Scanner, Domino, uniPaaS (eDeveloper), EJB, e-mail, Encryption, File Archive, File Management, File Splitter, FTP, HL7, HTTP, iBOLT Portal, iSeries Connector, ItemField Connector, Java Component, JD Edwards Connector, JMS, Microsoft Excel, Microsoft Word, MSMQ, Notes DB Connector, Salesforce Connector, SAP Business One, SAP R/3, UPS, W4, Web Services, WebSphere MQ, XSLT e outros. E claro,  trabalha com todos os tipos de bancos de dados e possui uma extensa biblioteca de métodos e wizards, incluindo um poderoso data mapper.

Tenha em mente que o iBOLT Monitor irá monitorar a execução de seus fluxos. Você pode utilizar esta monitoração do status do fluxo para executar outros fluxos e alertas. Os processos estão falhando devido à falta de conectividade? Inicie um fluxo de recuperação. Os volumes de transação estão anormalmente altos ou baixos? Envie um alerta para um usuário-chave ou administrador do sistema.

Com um bom projeto dos fluxos de integração desenhado, a Interface JD Edwards que você desenvolveu está pronta para ser testada. O teste pelo analista de negócios é possível usando o modo de emulação do iBOLT. Depois que você está satisfeito com os testes pelo departamento de TI, fazer testes de aceitação com o usuário é vital. Será que os processos de negócios recém-orquestrados cumprem as metas e objetivos definidos durante a fase de coleta de requisitos de negócio e sua sessão de brainstorm?

Os fundamentos das melhores práticas não mudam muito de um projeto de TI para o outro. Mas as ferramentas disponíveis para integração e desenvolvimento de interface do JD Edwards podem fazer toda a diferença. Independente de saber se você decide entrar em contato com um integrador de sistemas ou fazer você mesmo, os usuários de JD Edwards usuários são aconselhados a investigar o iBOLT Special Edition para JD Edwards. A integração de JDE não tem que envolver um arriscado projeto de programação.

Acesse o Integrate JD Edwards With SharePoint White Paper aqui.

A integração de aplicativos cloud com sistemas legados

David Akka

David Akka – CEO – Magic Software UK  

Em um artigo recente e muito bem escrito, intitulado “Cloud Computing: o que os CIOs precisam saber sobre Integração”, Kim Nash – CIO.com editor sênior – entrevistou CIO’s e CTO’s que estavam dispostos a compartilhar a sua experiência de computação em nuvem. Um dos problemas comuns que todos eles descreveram foi a questão da integração dos sistemas legados com aplicações em nuvem. Lorraine Lawson refere-se a esta questão como o calcanhar de Aquiles do Cloud Computing em Os únicos e não-tão-únicos desafios da Integração. A pergunta é: por que um dos passos fundamentais para funcionar eficazmente na nuvem é tão difícil? Existe uma maneira de tirar essa dor? A resposta  é sim, pura e simplesmente, e chama-se iBOLT.

Se tomarmos o exemplo do artigo de Nash, podemos ver qual é o problema. Nash entrevistou Stuart Appley, CIO na Shorestin Properties. Eles usaram “uma versão hospedada de um sistema chave de gestão, da Yardi Systems, sendo que o  Yardi é executado em um servidor IBM (IBM) AS/400. Quando ele quis versões em nuvem de outras aplicações para troca de dados com o software Yardi, nenhum fornecedor dos aplicativos nem a Yardi tinha um utilitário escrito especificamente para ligar seus sistemas. A equipe da Appley tinha que escrever interfaces em RPG, a linguagem de programação que a IBM usa no AS/400. Isto pode parecer uma solução simples para um problema pequeno, mas aqueles que tentarem saberão que escrever uma interface entre duas aplicações não é rápido nem simples e o que será, se você tem dezenas de aplicações?

A manutenção e modernização de sistemas legados tornaram-se um dos obstáculos mais visíveis enfrentados pelos departamentos de TI de muitas organizações. Um sistema que tornou-se legado pode ser simplesmente definido como qualquer sistema que seja difícil e caro de manter.

Há todo um espectro de razões pelas quais isso poderia ser o caso, mas, essencialmente, é porque:
(A) Está sendo executado em uma plataforma cara (e muitas vezes obsoleta);
(B) É escrito em uma linguagem obsoleta;
(C) Não há mais ninguém na equipe que o compreenda.  

 Estas questões compartilham o mesmo resultado: um sistema legado não tem a agilidade que a maioria das empresas precisa para apoiar as mudanças nos seus processos, além de que está custando muito mais para manter.

 

 Motivadores de negócios para a modernização:  

• A rápida evolução das necessidades do consumidor e dos modelos de negócios
• Tarefas manuais caras e demoradas devido à sub-processos semi manuais – o processo global não é racionalizado.
• Incapacidade para adicionar interações ricas (baseadas na web) e módulos móveis para aplicações legadas.
• Os usuários não estão satisfeitos
• Novos padrões/regulamentos/notificações não podem ser implementados/suportados em tempo.
• Integração manual de processos
• Fusão e Aquisição – necessidade de integrar processos de negócios
• Definição e monitoramento de workflow/processo
• Alto custo de manutenção de sistemas legados reduzindo o orçamento disponível

 

Motivadores de Tecnologia:  

• Permitir o uso de Web Services
• Reutilização do código existente combinado com novos serviços/códigos
• Sincronização de dados entre legado e novas aplicações/processos
• Migração, substituição ou cenários mistos de plataforma e/ou banco de dados
• Conectividade de aplicações legadas e outras aplicações diretamente ou através de sistemas de mensagens (JMS, MS MQ e Websphere MQ); substituindo interfaces proprietárias com plataforma de integração escalável
• Construção de uma arquitetura SOA, incluindo aplicações legadas
• Manipulação de transações para processos que integram aplicações legadas

 

Opções com Legados

Tradicionalmente, há poucas opções quando uma organização procura lidar com um desafio do sistema legado. Geralmente, uma organização pode:

Substituí-lo: Criar um novo sistema que substitui a funcionalidade completa do sistema antigo. Este é a opção mais difícil, mais dispendiosa e arriscada, mas é a única que oferece uma solução de longo prazo e, possivelmente, fornece um sistema que seja ágil o suficiente para responder às novas necessidades do negócio. Questões a considerar incluem:
• Alto custo inicial de desenvolvimento;
• Risco muito elevado;
• Dificuldade para adquirir o comportamento do sistema legado;
• Risco de criação de um sistema legado de segunda geração;
• Possibilidade de criação de um novo sistema, mais ágil.

Envolvê-lo: Trata-se de envolver a aplicação do legado existente em interfaces mais modernas e atraentes. Essas interfaces permitem o uso de abordagem mais flexível de arquitetura orientada a serviços. Isso realmente não ajuda a tornar o sistema mais flexível e mais fácil de manter. Mas, contudo, permite maior acesso ao sistema legado por outros sistemas. Esta abordagem pode permitir que o sistema legado seja modularizado e, assim, parte dele pode ser substituído em uma base fragmentada. As considerações incluem:
• Custo inicial de pequeno porte;
• Baixo risco;
• Ainda é necessário manter os sistemas legados;
• Não há aumento de agilidade no sistema legado.

Viver com ele: Tendo em conta as possíveis repercussões das alternativas, esta é uma opção popular que não surpreende. Além do risco envolvido ser quase zero,  infelizmente isso não oferece nenhuma esperança para o alívio do problema do legado e fornece apenas estagnação. Com esta opção, as principais características são:
• Não há custo inicial;
• Não há redução no custo de manutenção ou na capacidade de aumentar as eficiências da operação;
• Não há aumento na agilidade.

 

Nesta situação, como o iBOLT tornaria a integração mais fácil?

Com o iBOLT você teria que usar simplesmente uma única ferramenta para se conectar às suas aplicações legadas, então Appley e seus colegas poderiam utilizar um conector do iBOLT for System i/AS400 para integrar rapidamente o AS400 e o sistema Yardi sem necessidade de qualquer codificação local. O iBOLT é uma plataforma de integração livre de código. Abaixo está uma imagem do iBOLT que mostra apenas uma coleção de componentes que servem a diferentes tecnologias.

Por exemplo, usando uma ferramenta para conectar de/para sua aplicações legadas para permitir compartilhamento de dados e processos com outras aplicações. Ou um produto que tem um suporte embutido para diferentes ambientes e plataformas e pode fornecer a ponte entre eles.

Aqui está um exemplo de como acessar os serviços do sistema System i – com recuperação de listas de objetos, valores do sistema, entradas do arquivo de spool, e arquivos do diretório IFS.    

iBOLT acessando System i

  

– Integração / Exposição dos elementos do System i – que podem chamar processos externos em qualquer outra plataforma de programas OS/400 RPG/CL/Cobol via API requisitada pelo iBOLT
– Função embutida de abrir o arquivo de consulta – que permite a seleção e classificação de registros no System i
– Runtime de gerenciamento de ambiente – com  acompanhamento do projeto em tempo real e o iBOLT pode ser usado para permitir que sistemas legados facilmente se conectem e consumam serviços recém-criados da web. O iBOLT trata automaticamente cada chamada e resposta de webservice de cada mensagem de acordo com o protocolo padrão SOAP e HTTP. Você pode efetivamente integrar aplicações legadas e aplicações baseadas na nuvem, incluindo as locais e as remotas.    

O que é mais prova de um bom futuro, do que você poder se concentrar no desenvolvimento de processos de negócio independente da tecnologia utilizada.Você, portanto, mantém todo o controle dos processos de negócios da sua empresa melhor do que qualquer fornecedor conseguiria.    

Para obter uma representação visual do iBOLT em ação, dê uma olhada no vídeo abaixo sobre o iBOLT e a integração SAP, mas lembre-se que poderia ser qualquer coisa, desde algo escrito em casa , até algo escrito em RPG.    

[youtube=http://www.youtube.com/watch?v=VvThGAqQRUo]