Você está na página 1de 7

O JAVA presente no universo ERP Parte I de II

Neste primeiro artigo, vou pedir licena aos amigos amantes de cdigo fonte para expor e explorar um pouco do mundo dos sistemas integrados ERP...
Publicado em: 14/09/2005 I. Introduo Neste primeiro artigo, vou pedir licena aos amigos amantes de cdigo fonte para expor e explorar um pouco do mundo dos sistemas integrados ERP, entendo que este passo inicial servir com uma pilastra para formar os argumentos de sustentao da base de conhecimento, para posteriormente dissertarmos sobre a tecnologia e a lgica que est por detrs deste mundo, e ademais disto mostrar as oportunidades que hoje so realidades pouco conhecidas por especialistas Java, e que podem ter neste nicho de mercado um oportunidade para alcanar bons rendimentos financeiros, e uma oportunidade singular de desenvolvimento de carreira. A primeira vista pode parecer estranho, este tipo de colocao visto que a maioria absoluta dos artigos no site so de origem .NET, Delphi, Linux, VB, ... mas o objetivo justamente este, tirar a blindagem dos sistemas ERP e mostrar como no caso da SAP, ela vem adotando o padro Java em sua plataforma NetWeaver, o que nos brinda a oportunidade de conhecer um pouco mais desta tecnologia atravs de algo mais tangvel a um nmero maior de pessoas, o Java. II. JAVA em ERP? Muitos enxergam o mundo ERP como uma ilha isolada de tudo, onde as coisas acontecem como num ecossistema independente, onde sua "imaginvel" autosuficincia em relao as demais tecnologias de mercado, transparecem um mundo no alcanvel aos profissionais que no se encontram dentro deste contexto. Realmente isto nunca foi perto de ser uma verdade, os sistemas ERP"s no seriam viveis em grandes corporaes, se eles no fossem conectados aos sistemas legados, sistemas colaborativos de fornecedores e clientes, entre outros. Mas ento porque os sistemas ERP aos olhos de muitos aparecem se encontrar to longe ou distantes de sua realidade? Podemos comear a responder esta questo quando analisarmos sobe o ponto de vista do cliente que compra um ERP. A compra de um ERP uma das decises mais complexa a ser tomada numa empresa, visto que o que se compra num ERP, muito mais que um software, uma parceria de negcio, podemos inclusive usar o termo "casamento", porque algo que deveria perpetuar por muitos anos e ser os alicerces de sustentao tecnolgica da empresa que o adquiriu. No podemos esquecer que estas empresas buscam principalmente atravs do ERP solucionar toda a complexibilidade de integrao das reas de sua companhia, isto

porque a alma do ERP esta baseada na integrao de seus componentes, como vendas, faturamento, compras, produo, manuteno, custos, finanas... enfim, toda a cadeia de logstica, financeira e de recursos humanos; bem verdade que em alguns casos pode ocorrer um engessamento dos processos, ainda que estas ferramentas sejam customizadas e permitam a configurao igual ou bem prximo da sua realidade e necessidades. Quando existem lacunas entre o modelo de negcio da empresa e o ERP, essas precisam ser preenchidas, e estas solues na maioria das vezes so buscadas dentro das ferramentas de desenvolvimento proprietrias do ERP, no caso da SAP, por exemplo, o ABAP, isto porque os altos investimentos num sistema integrado, exigem muitas vezes, na viso dos clientes, que as solues complementares estejam dentro do ERP, como forma de garantir e proteger o investimento realizado em um sistema responsvel pela funo de integrao, e poderamos ir mas alm porque alguns imaginam que o ERP deveria ser a soluo de todos os seus problemas! Essas lacunas mencionadas ao principio, so em fato programas, relatrios e interfaces que sero necessrios desenvolver para fechar os elos com entre o sistema e o negcio. Vamos enfocar o tema interfaces, na sua maioria absoluta so elaboradas ponto a ponto (1:1), onde cada necessidade se traduz num novo desenvolvimento, no difcil entender este conceito quando entramos no tema de integrao de sistemas financeiros, como bancos, neste tipo de comunicao, ainda que o destino da informao seja o mesmo no ERP (tabelas e/ou transaes), poderamos ter necessidades de EDI diferentes para cada Banco, isto porque no podemos restringir o nosso foco unicamente nos distintos lay-out"s utilizados por cada entidade, e ir alm nesta analise, at ao ponto aonde comeamos a enxergar a diversidade de plataformas que convivem neste ambiente, isto , todo um universo de servidores e aplicaes diferenciadas utilizadas pela rede bancria. Est claro que no estamos falando somente de software, mas tambm de hardware, e de uma necessidade de integrao de todos estes componentes. Foi desta necessidade que surgiu a soluo da SAP, chamada Exchange Infrastructure, mais conhecido simplesmente pela sigla XI. O XI tem justamente o objetivo de realizar a integrao de sistemas heterogneos, e um componente do SAP NetWeaver. Neste momento estamos entrando com siglas e nomes que para boa parte das pessoas so novidades, ento tratarei de ter cuidado para que no haja conflito entre os conceitos de cada componente do sistema. Na linha que estamos seguindo at o momento, chegamos a base de sustentao desta soluo, o SAP NetWeaver, e vamos destacar o que est por detrs desta tecnologia, e entender as oportunidades para desenvolvedores Java, e olha que no estamos falando nenhuma novidade, o que estou tratando de mostrar foi apresentado no Javaone 2003 em So Francisco. Nesta ocasio foi apresentado o SAP NetWeaver Developer Studio, que foi concebido baseado na ferramenta na plataforma de desenvolvimento aberto Eclipse. Esta nova soluo permitiu a integrao de 2 mundos, o ERP da SAP e a tecnologia Java, incluindo APIs J2EE 1.3, Java Message Service e Enterprise JavaBeans 2. Com o SAP NetWeaver Developer Studio, criou a possibilidade de desenvolvedores Java desenvolverem e integrarem de forma simples e segura suas aplicaes atravs de

uma plataforma de classe mundial ao ERP da SAP. Podemos ainda ir mais longe e deslumbrar oportunidades na rea corporativa, onde empresas interessadas em desenvolver parcerias com a SAP poderiam adaptar suas solues de sucessos, e criar um novo canal de vendas at ento desconhecido, podendo gerar demandas e oportunidades importantes de business. E as solues desenvolvidas internas nas empresas? O proprietrio do ERP tambm ganha algo muito importante, o poder da independncia, porque eles no mais precisam ser escravos da ferramenta de desenvolvimento do ERP, para as necessidades na qual esta ferramenta no se mostrava ser flexvel suficiente ou at mesmo era inapropriada; criando a possibilidade de ser desenvolvidas em Java e utilizar de toda a infra-estrutura proporcionada pelo SAP NetWeaver para garantir a integrao da soluo. Para finalizar este tema, importante ressaltar que todo o suporte ao Java feito atravs do servidor de aplicao virtual da SAP (SAP Web Application Server) que conta ainda com o suporte a web services e outras aplicaes Java. Outra vantagem importante est na rea de conectividade, atravs de adapters que suportam arquitetura de conexo J2EE (Java Connector Arquiteture-JCA), mas este tema trataremos em detalhes no prximo artigo na qual voltaremos o foco ao SAP XI, e vamos entrar tambm em conceitos acadmicos fazendo uma analogia no conceito de "orientao a mensagens" do XI, com o conceito de "orientao a objetos" enfatizado na Engenharia de Software, e finalizar o artigo com uma tendncia e expectativas para os prximos anos. Espero que este primeiro artigo tenha conseguido alcanar meu objetivo inicial de quebrar os paradigmas de sistemas ERP e demonstrar as oportunidades que esto abertas neste segmento com a SAP, e isto no se limita to somente a SAP, quem tiver o interesse pode buscar informaes tambm sobre plugins de EJB3 para Eclipse da Oracle, e pesquisar sempre. Me coloco a disposio para maiores esclarecimentos, dvidas, criticas ou qualquer tipo de comunicao, atravs deste conceituado site ou pelo meu endereo eletrnico pessoal efcruz_br@hotmail.com.

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 colocao neste segundo artigo.
Publicado em: 17/05/2006 Compartilhe "...Orientao a Objetos x Orientao a Mensagens..." 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 colocao 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 tambm 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 solues o Java como base para suas novas aplicaes. Particularmente, entendo que esta deve ter sido uma manobra complexa para a SAP, isto porque no momento que voc tem uma tecnologia proprietria para desenvolvimento e sustentao da soluo, o ABAP, com diversos profissionais preparados e treinados no mundo, tendo toda uma infra-estrutura criadas pelos clientes, abrir mo desta tecnologia seja parcial ou total, para uma tecnologia no proprietria, significa no mnimo abrir mo do domnio do conhecimento, e a pulverizao 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 soluo 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 conceituao, podemos fazer uma analogia do XI com o BizTalk da Microsoft, que tambm tem o conceito de integrao de sistemas, e entendemos que serve como exemplo para ilustrar o tipo de soluo que vamos dissertar. O XI foi desenvolvido sobre o principio dos conceitos de integrao do NetWeaver, e responsvel justamente pela integrao de sistemas homogneos e/ou heterogneos, estamos falando de integrao de bancos de dados com o SAP, de integrao do cho de fbrica (MES, PIMS, LIMS, PLCs, etc) com o SAP, da integrao de um sistema legado com um sistema proprietrio da empresa... Opsss!!! Neste ltimo exemplo falamos de algo

no 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 integrao com o SAP, mas no devemos restringir nossa viso a este ambiente.

Ento basicamente para facilitar o entendimento, vamos restringir a 2 grandes reas de configurao desta ferramenta, uma responsvel pela conectividade e outra responsvel pela lgica do processo de integrao. O componente responsvel pela conectividade, chamado de Adapter, cada um deles so 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 cho de fbrica e tantos outros. V. Finalmente a Engenharia de Software Quando analisamos os objetos responsveis pela lgica de integrao do XI, nos deslumbramos com a semelhana entre o conceito de orientao a mensagem da SAP, com o conceito de Orientao de Objeto da Engenharia de software, guardado as devidas propores, OO um conceito muito rico em detalhes, e inclui vrios conceitos como polimorfismo que no 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 necessrio definir uma estrutura, data type no XI, este objeto se assemelha com a classe de OO, onde deve ser definir os atributos, mtodos e encapsulamento, a nica diferena a no presena do mtodo, isto se justifica facilmente visto que o XI foi desenhado para ser um sistema somente de interface (ponte) como mencionamos ao inicio, seu nico mtodo seria a execuo quando o objeto solicitado. Neste mesmo objeto as semelhanas 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 herana 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 atravs 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 assncrona ou

sncrona, etc... Aps esta definio nossa estrutura est apta a ser mapeada e posteriormente executada. Quando vamos trocas as informaes entre sistemas, para cada registro recebido pelo XI ele instancia os dados da nossa estrutura (data type), atravs 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 diferena entre XI e OO, no XI durante o tramite de troca de mensagens (mapping objects), ele permite tratar estas informaes, isto porque quase sempre os layouts do sistemas origens e destinos so diferentes, assim que necessrio 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 relao entre as mensagens de 1:1 para 1:n ou n:1. Tambm se poderia desenvolver bibliotecas de funes compostas em Java para ser utilizado durante o tratamento das mensagens. Uma vez finalizada a parte lgica das mensagens, podemos utilizar este modelo, para mais de 1 sistema, isto , numa integrao do sistema bancrio por exemplo, poderamos definir que a origem a mesma: o ERP da SAP, e o destino so todos os bancos parceiros da empresa, onde definimos o adapter necessrio para cada banco, mas utilizando a mesma lgica de troca de mensagens, desta forma os sistemas podem trocar de forma "simples" e transparente informaes independente da plataforma onde as informaes estejam, podemos imaginar o facilitador que isto pode gerar na utilizao de web services ao futuro. Neste ltimo captulo, tratamos muito do tema de Engenharia de Software, isto porque no inicio a Engenharia de Software sempre me pareceu mais acadmico, do que profissional, visto que sempre transpareceu ser mais funcional visto sobre o prisma de um modelo terico, do que na sua aplicao pratica. Talvez estes pensamentos tivesse sido contaminado pela falta de casos e estudos documentados no cenrio nacional, que demonstre a real aplicao e os benefcios dos conceitos de orientao a objetos, mas isto contrasta com a realidade vivida em outros pases, aonde se encontram um grata quantidade de materiais e livros com definies, modelagens, estudos de casos, entre outras informaes. E hoje me sinto confortvel de verificar os conceitos aplicados em uma ferramenta mundial que dever crescer muito nos prximos anos. VI. Web Services, ERP II, OO: para onde os caminhos apontam Espero ter conseguido esclarecer o bsico dos conceitos do XI, de como se aplica a ferramenta e qual a sua misso a desempenhar no futuro, atravs do uso do Java. Gostaria de dedicar este artigo ao mestre Dr. talo Vega, que teve a pacincia de realizar uma lavagem cerebral nos meus conceitos de programao procedural, e conseguido de forma brilhante conceituar os paradigmas de objetos e demonstrar sua aplicao, no somente se prendendo nos benefcios mas trabalhando tambm 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 so baseadas em Java e permitem a integrao por HTML, protocolo SOAP, Web Services ... entre outros. Poderamos falar tambm da nova onde de ERP"s, que muitos vem chamando de ERP II,

que so os sistemas de Business Inteligence conhecidos como CRM, SRM e SCM por exemplo. A tendncia da Orientao 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 disposio para maiores esclarecimentos, dvidas, criticas ou qualquer tipo de comunicao, atravs deste conceituado site ou pelo meu endereo eletrnico pessoal efcruz_br@hotmail.com.