Quem é do mercado SAP já deve ter ouvido falar da Balance Consulting, onde trabalho como consultor. E para quem não é deste mercado, provavelmente nunca ouviu falar de SAP ou então só deve lembrar vagamente de uma palavra ou outra sobre o assunto.
Apresentações primeiro: a SAP é a Microsoft do mundo corporativo, talvez um monopólio com um mind-share ainda maior. Pense na Fortune 500: a maioria (se não todos) com certeza usam produtos SAP. Não estamos falando aqui de websites ou intranets, estamos falando dos processos dessas mega-corporações. O carro-chefe, o SAP R/3 (hoje, rebatizado de ECC, ou Enterprise Core Components) é um Enterprise Resource Planning (ERP), feito para suportar indústrias globalizadas, com filiais espalhadas pelo mundo, tudo interligado. Módulos financeiros, contábeis, produção, vendas, manufatura. O R/3 suporta em verticais tão variadas quanto Aerospace and Defense, Chemicals, Retail, etc. Já vi vários javeiros falando em “Enterprise” applications. Vocês não sabem o que é “enterprise” até conhecer instalações SAP. Talvez ele só não seja mais importante do que os mainframes rodando Cobol que muitas empresas (como bancos) ainda conservam.
Pois bem, no mundo da plataforma baixa, diversas dessas empresas implementam partes desses grandes processos como aplicativos web. Claro, Java ganhou destaque. Na solução SAP NetWeaver, o SAP R/3 vem pré-instalado com um servidor SAP J2EE. Além disso eles oferecem também o SAP NetWeaver Developer Studio, que é um Eclipse cheio de plugins deles. E também tem o SAP Enterprise Portal, com seu formato proprietário de portlets, chamado iViews.
Enfim, soluções completas de ponta a ponta para trazer a Web para o mundo corporativo. Porém, em vez de abraçar as iniciativas open source que já são consagradas como JSF, JDO ou coisa parecida, a SAP resolveu que só ela tem a solução ideal. Para a camada de persistência eles adaptaram os conceitos do ABAP/4 (a linguagem 4GL oficial da SAP) na forma do OpenSQL. Para a camada MVC eles criaram o Web Dynpro, e assim por diante. Até o servidor J2EE funciona de forma diferente da maioria dos servidores.
No fim, como desenvolvedor experiente nessa área, me parece que eles conseguiram complicar o jogo mais do que precisava. Isso sem contar que know-how SAP é reservado para aqueles que fazem parte do jogo (o mercado é controlado e particionado entre os parceiros pela própria), assim como eu, por exemplo, que sou Enteprise Portal Certified. Acreditem, vocês não conhecem uma panela até entrar em uma.
Enfim, venho acompanhando essa evolução para o mundo Java desde 2002. Depois de tanto tempo, a SAP conseguiu ganhar muita credibilidade, muito graças ao seu líder tecnológico, Shai Agassi. Vem sendo muito elogiada, mas na prática não tem sido muito adotada. Pelo menos no Brasil, temos dezenas de clientes que consomem SAP há anos, mas poucos embarcaram de vez na solução NetWeaver.
Pouco a pouco a própria SAP vem demonstrando estar aberta a alternativas. Primeiro foi a parceria com a Microsoft para fazer sites ASP.NET que se integram ao Enterprise Portal usando a infraestrutura de iViews. Foi o lançamendo do PDK for .NET (Portal Development Kit). Agora temos também algumas iniciativas individuais aparecendo no site oficial de desenvolvedores da SAP, o SDN (SAP Developer Network).
Claro, a idéia é pegar o segundo maior mercado de desenvolvedores depois do Java. Portanto começaram com PHP. Mas pouco a pouco o Python também ganhou suporte e, agora, finalmente já conseguimos ver traços de apoio ao Ruby on Rails. O projeto open source RadRails, que são plugins para Eclipse para auxiliar no desenvolvimento de Rails também anuncia na sua homepage o suporte a SAP.
Venho lidando com integração de soluções híbridas com SAP há muitos anos. Incluindo produtos como Business Connector, Tibco, Webmethods, agora XI. Fora desenvolvimento customizado com plataformas como J2EE, ASP.NET, ASP, Visual Basic, Web Services, etc. Como programo em ABAP/4 também conheço muito da sua infraestrutura de integração.
Para possibilitar a conexão de aplicativos externos aos recursos do R/3, a SAP disponibiliza bibliotecas binárias com todos os seus produtos (incluindo o RFCSDK) que tem todo o suporte a conversar no protocolo SAP RFC (Remote Function Call).
Dentro do R/3, programamos “módulos de função” (encapsulados ou não na forma de BAPIs ou Business APIs) que suportam acesso remoto. Grosseiramento comparável a EJBs que acessamos via RMI. Essa biblioteca nativa já ganhou diversos wrappers, incluindo o famoso Jco ou Java Connector, .NET Connector, SOAP Connector e assim por diante. No mundo das linguagens dinâmicas, alguns esforços individuais geraram wrappers para Perl, PHP, Python e, agora, Ruby. Toda nova instalação de R/3, o SAP R/3 4.7 Enterprise ou o mais recente ECC 5 já vem out-of-the-box preparado para disponibilizar Web Services de todas as suas APIs.
No caso de Ruby on Rails, Piers Harding, um experiente consultor SAP e programador é um dos principais mantenedores de tecnologia para integração de aplicativos Rails com R/3. Não deixem de ler seu blog e artigos a respeito. Sua biblioteca saprfc e SAP4Rails funciona muito bem. Já analisei seu código e notei pequenos bugs que pretendo ajudar a corrigir, mas mesmo assim é um trabalho notável. Ele acabou de lançar a versão 0.16 na forma de gems. Ainda preciso testar essa versão.
Na prática, o que faltava ao Rails para ser “Enterprise-ready” é a capacidade de se comunicar com o SAP R/3. Qualquer plataforma que não seja integrada ao SAP não pode se entitular “enterprise”, esta é a prática do mercado pois o Core Business da empresa está em seus processos.