O JAVA presente no universo ERP – Parte II de II

No artigo anterior tratamos de enfatizar um breve conceito sobre o SAP NetWeaver da SAP, para mostrar algumas oportunidades deste sistema ERP, e servir de base para nossa colocação neste segundo artigo.

por Eduardo Fabricio da Cruz

III. Conceituando o SAP NetWeaver Exchange Infrastructure (XI)

No artigo anterior tratamos de enfatizar um breve conceito sobre o SAP NetWeaver da SAP, para mostrar algumas oportunidades deste sistema ERP, e servir de base para nossa colocação neste segundo artigo.

Dentro desta plataforma existe toda uma gama de oportunidades e componentes que poderiam ser explorados e expostos aqui como Portais, Business Intelligence, Java... e também o Exchange Infrastructure, ou simplesmente XI, que será o alvo nessa abordagem.

Vamos entender um pouco da arquitetura do XI, iniciando pelo movimento da SAP de incluir dentro da suas soluções o Java como base para suas novas aplicações. Particularmente, entendo que esta deve ter sido uma manobra complexa para a SAP, isto porque no momento que você tem uma tecnologia proprietária para desenvolvimento e sustentação da solução, o ABAP, com diversos profissionais preparados e treinados no mundo, tendo toda uma infra-estrutura criadas pelos clientes, abrir mão desta tecnologia seja parcial ou total, para uma tecnologia não proprietária, significa no mínimo abrir mão do domínio do conhecimento, e a pulverização do mesmo, que por outro lado ganha em recursos, visto que a massa profissional de Java é muito superior aos profissionais de tecnologia ABAP.

É bom esclarecer que o ABAP ainda está longe de desaparecer do mundo ERP da SAP, e é parte integral da solução SAP NetWeaver Exchange Infrastructure, e hoje co-existe com o Java num mesmo servidor. O XI trata de tirar as vantagens de ambos os componentes, para materializar nossa conceituação, podemos fazer uma analogia do XI com o BizTalk da Microsoft, que também tem o conceito de integração de sistemas, e entendemos que serve como exemplo para ilustrar o tipo de solução que vamos dissertar.

O XI foi desenvolvido sobre o principio dos conceitos de integração do NetWeaver, e é responsável justamente pela integração de sistemas homogêneos e/ou heterogêneos, estamos falando de integração de bancos de dados com o SAP, de integração do chão de fábrica (MES, PIMS, LIMS, PLCs, etc) com o SAP, da integração de um sistema legado com um sistema proprietário da empresa... Opsss!!! Neste último exemplo falamos de algo não relacionado com o SAP, isto porque o XI simula uma "ponte", ele trata de unir 2 pontos (sistemas) independe da infra-estrutura que suporta esse ambiente, e isto inclui o controle de workflow entre BPM (Businness Process Management) de diferentes sistemas. É claro que o objetivo maior é e sempre será a integração com o SAP, mas não devemos restringir nossa visão a este ambiente.

Então basicamente para facilitar o entendimento, vamos restringir a 2 grandes áreas de configuração desta ferramenta, uma responsável pela conectividade e outra responsável pela lógica do processo de integração. O componente responsável pela conectividade, é chamado de Adapter, cada um deles são desenvolvidos especificamente para o fim de integrar com uma plataforma, assim que temos adapters para protocolos SOAP, Banco de Dados, Mail, Businness Conector, sistemas de chão de fábrica e tantos outros.

V. Finalmente a Engenharia de Software

Quando analisamos os objetos responsáveis pela lógica de integração do XI, nos deslumbramos com a semelhança entre o conceito de orientação a mensagem da SAP, com o conceito de Orientação de Objeto da Engenharia de software, guardado as devidas proporções, OO é um conceito muito rico em detalhes, e inclui vários conceitos como polimorfismo que não se aplica no XI, por exemplo.

O modelo do XI é baseado na troca de mensagens entre o sistema origem e destino, mas para chegar a este ponto primeiro é necessário definir uma estrutura, data type no XI, este objeto se assemelha com a classe de OO, onde deve ser definir os atributos, métodos e encapsulamento, a única diferença é a não presença do método, isto se justifica facilmente visto que o XI foi desenhado para ser um sistema somente de interface (ponte) como mencionamos ao inicio, seu único método seria a execução quando o objeto é solicitado.

Neste mesmo objeto as semelhanças vai mais a diante, esse data type, pode ser criado a partir de outro data type, e ampliado com outros atributos, exatamente o mesmo conceito de herança do OO, onde se permite definir uma nova classe (subclasse) a partir de uma classe já existente (superclasse). Outro ponto a destacar é que cada atributo pode ser encapsulado dentro um context, de forma que poderemos identificar de maneira simples nossas mensagens através deste context ou information hiding (encapsulamento) para os amigos do OO. Ainda dentro deste contexto de information hiding, nosso data type vai ser encapsulado em um novo objeto chamado Message Interface, onde receberá outros atributos ocultos como: se a mensagem é inbound ou outbound, se é assíncrona ou síncrona, etc... Após esta definição nossa estrutura está apta a ser mapeada e posteriormente executada.

Quando vamos trocas as informações entre sistemas, para cada registro recebido pelo XI ele instancia os dados da nossa estrutura (data type), através do message interface, num processo semelhante ao OO, quando instancia uma classe e cria-se um objeto. Agora a mensagem deve ser comunicar com o sistema destino, aqui sim, temos uma diferença entre XI e OO, no XI durante o tramite de troca de mensagens (mapping objects), ele permite tratar estas informações, isto porque quase sempre os layouts do sistemas origens e destinos são diferentes, assim que é necessário direcionar os atributos de forma correta durante a troca de mensagens. Nos casos mais complexos, poderemos estar utilizando o BPM (Business Process Management) incluso para mudar a relação entre as mensagens de 1:1 para 1:n ou n:1. Também se poderia desenvolver bibliotecas de funções compostas em Java para ser utilizado durante o tratamento das mensagens.

Uma vez finalizada a parte lógica das mensagens, podemos utilizar este modelo, para mais de 1 sistema, isto é, numa integração do sistema bancário por exemplo, poderíamos definir que a origem é a mesma: o ERP da SAP, e o destino são todos os bancos parceiros da empresa, onde definimos o adapter necessário para cada banco, mas utilizando a mesma lógica de troca de mensagens, desta forma os sistemas podem trocar de forma "simples" e transparente informações independente da plataforma onde as informações estejam, podemos imaginar o facilitador que isto pode gerar na utilização de web services ao futuro.

Neste último capítulo, tratamos muito do tema de Engenharia de Software, isto porque no inicio a Engenharia de Software sempre me pareceu mais acadêmico, do que profissional, visto que sempre transpareceu ser mais funcional visto sobre o prisma de um modelo teórico, do que na sua aplicação pratica.

Talvez estes pensamentos tivesse sido contaminado pela falta de casos e estudos documentados no cenário nacional, que demonstre a real aplicação e os benefícios dos conceitos de orientação a objetos, mas isto contrasta com a realidade vivida em outros países, aonde se encontram um grata quantidade de materiais e livros com definições, modelagens, estudos de casos, entre outras informações. E hoje me sinto confortável de verificar os conceitos aplicados em uma ferramenta mundial que deverá crescer muito nos próximos anos.

VI. Web Services, ERP II, OO: é para onde os caminhos apontam

Espero ter conseguido esclarecer o básico dos conceitos do XI, de como se aplica a ferramenta e qual a sua missão a desempenhar no futuro, através do uso do Java. Gostaria de dedicar este artigo ao mestre Dr. Ítalo Vega, que teve a paciência de realizar uma lavagem cerebral nos meus conceitos de programação procedural, e conseguido de forma brilhante conceituar os paradigmas de objetos e demonstrar sua aplicação, não somente se prendendo nos benefícios mas trabalhando também os riscos potenciais.

Para finalizar entendo que existe muitas áreas de oportunidade, o futuro deve apontar para Web Services, por isto vejo com bons olhos ferramentas como o XI, que são baseadas em Java e permitem a integração por HTML, protocolo SOAP, Web Services ... entre outros. Poderíamos falar também da nova onde de ERP"s, que muitos vem chamando de ERP II, que são os sistemas de Business Inteligence conhecidos como CRM, SRM e SCM por exemplo. A tendência da Orientação a Objetos em detrimento ao desenvolvimento procedural... Mas todos estes pontos seriam temas para outros artigos, assim que despido aqui e uma vez mais me coloco a disposição para maiores esclarecimentos, dúvidas, criticas ou qualquer tipo de comunicação, através deste conceituado site ou pelo meu endereço eletrônico pessoal efcruz_br@hotmail.com.