El Bruno

Buenas,

quien más, quien menos; si alguna vez estuviste trabajando en alguna empresa mediana o grande te habrás topado con un SAP. SAP es ese monstruo alemán que nació en el 1972 (tiene 4 años más que yo), que hoy tiene más de 40000 empleados en sus filas y es uno de los sistemas de gestión por referencia para las grandes organizaciones.

Internamente SAP en casi todas sus versiones siempre ha sido un producto muy cuidado y extremadamente práctico. Por ejemplo la versión actual SAP R/3 es una aplicación que se puede desplegar y escalar de forma masiva respetando el concepto sobre el que habló Rodrigo ayer de hacer las cosas simples:

una aplicación con 3 capas: capa de presentación, de aplicación y de base de datos.

Ojo, que internamente dentro de SAP podemos encontrarnos miles de módulos y de aplicaciones (SAP Business Warehouse, Internet Transaction Server, Sales Force Automation, etc.), pero cuando conoces un poco como funciona y como se escala, la verdad que es un ejemplo a seguir en lo que respecta al diseño de aplicaciones empresariales.

Sin embargo, la cosa deja de ser tan bonita cuando desde el mundo Microsoft empezamos a ver las opciones de desarrollo que nos brinda SAP: ABAP y Java. El 1ro, ABAP, nació como el lenguaje de reporting de SAP pero con el paso del tiempo se convirtió en un 4GL (dios que miedo!!!) que se mete en las tripas de SAP y permite adaptarlo a casi cualquier necesidad. Por otra parte, con la incorporación de SAP NetWeaver, Java pasó a ser parte de los lenguajes con los que se podía “programar” SAP.

¿Y qué pasa con Microsoft? – 1. DCOM

Pues que toca sufrir y mucho en algunas ocasiones. Si bien es posible instalar SAP sobre SQL Server, jamás se recomienda atacar la base de datos de SAP directamente especialmente si quieres mantener tu cordura mental. Lo mejor en todos los casos es utilizar alguno de los mecanimos de integración especialmente diseñados para estos escenarios.

Inicialmente la única opción de integración era utilizar C y la biblioteca librfc32.dll, sin embargo esta opción tenía muchos problemas sobre los que realmente no puedo hablar al respecto porque no los conozco.

En 1997 cómo había mucha gente joven dispuesta a perder tiempo y neuronas SAP lanza su DCOM Component Connector. Este conector se basaba en DCOM y permitía interactuar con los objetos de SAP y al ser un estándar Microsoft, se podía utilizar el mismo desde Visual Basic, C++, Visual Fox, J++, etc. Sin embargo, DCOM era una tecnología que si bien tenía algunas ventajas como por ejemplo separar físicamente los componentes en diferentes entornos (podías conectar desde el mundo Windows a un SAP en un mundo Unix), era un sufrimiento para los desarrolladores ya que COM era su base y … busca en la wikipedia DLL Hell y verás de lo que hablo. Pero bueno, era una opción y una muy buena para integrar aplicaciones con SAP.

SAP .Net Connector

Con la llegada del .Net Framework (año 2000) SAP decidió crear un conector para .Net. Lo bueno de esto es que por un lado era posible aprovechar toda la potencia de .Net como plataforma de desarrollo, pero lo malo es que el SAP .Net Connector llegó en el año 2004. Es decir, tuvimos 4 años la esperanza de hacer las cosas más fáciles, pero mientras a apechugar con lo que tengamos a mano. Pero una vez lo tuvimos en nuestras manos, pudimos ver que era realmente grandioso:

• 100% integrado en el entorno de Visual Studio
• capacidad para integrarnos con RFCs, BAPIs e IDocs
• capacidad para publicación e integración a través de webservices

Por ejemplo, internamente lo que hacía este conector era crear un proxy en .Net para las entidades de SAP con las que “trabajábamos en local”. Esto era grandioso. En 2005 se lanzó una actualización de este componente con mejoras como el soporte para Remoting, y soporte para Visual Studio 2003.

SAP NetWeaver

SAP NetWeaver es una de las plataformas de integración de SAP (XI es otra), pero lo interesante de SAP NetWeaver es que ofrece mucha de la funcionalidad propia de los fomularios de SAP a través de WebServices. Y al ser un estándar, esta opción es una de las más utilizadas actualmente.

Lo interesante de esta opción es que en equipos complejos, puedes trabajar codo a codo con gente del mundo SAP (ABAP o Java) que creen y publiquen servicios específicos para ser utilizados desde el mundo .Net. Esto permite que todas aquellas personalizaciones que se apliquen a un SAP para un determinado negocio puedan ser utilizadas desde el mundo .Net sin problemas. De todas mis experiencias, éstas han sido las más fructíferas.

Otras opciones

Para finalizar y para no hacer un libro de un post, simplemente comentar que existen otras herramientas muy interesantes a tener en cuenta. Un ejemplo de ello puede ser Duet; Duet es un proyecto desarrollado en conjunto por Microsoft y SAP que tiene como objetivo lograr que los productos de Office puedan ser utilizados como Front-End para los procesos en SAP. Esto brinda una gran ventaja sobre la interfaz clásica de SAP ya que la suite de productos Office es la más popular del mercado. Además aprovechando las posibilidades de integración de Office con otros productos como Sharepoint o la capacidad de extensión a través de VSTO, se pueden lograr experiencias de usuario realmente productivas trabajando con Office + SAP.

Y si lo tuyo es la integración pura y dura, seguramente tu herramienta sea Biztalk. Como no podía ser de otra manera, existe una opción muy robusta para este caso, aunque lamentablemente o afortunadamente yo no tengo mucha experiencia para hablar sobre la misma:

• BizTalk Adapter Pack
  http://www.microsoft.com/biztalk/en/us/adapter-pack.aspx
  Donde se incluyen una serie de adaptadores basados en WCF y entre ellos uno para mySAP, entre ellos el SAP Adapter.
  
• SAP Adapter para Microsoft Biztalk 2004 o Microsoft Biztalk 2006
  http://msdn.microsoft.com/en-us/library/aa561012.aspx
  

Pues bien, mi idea era dar un poco una idea general sobre las diferentes capacidades y además creo que logré un objetivo personal: un post de integración a muy alto nivel sin un solo diagrama :D

Update: gracias al gran Andrés (thanks amigo !!)

Ey Bruno!

Gran articulo (as usual).

Dado que en mi cliente (que ya sabes cual es y por el cual puede que después de tanto tiempo en él acabe haciendo mutar mí apellido jajaja) estamos trabajando desde hace tiempo (y últimamente con más empuje) en las diferentes opciones de integración con SAP, pongo aquí una pequeña y humilde aportación:

- Respecto a la opción Netweaver: Gracias a él se pueden exponer como web services SOAP “estándar” Funtion Modules/BAPIs de SAP, pero no solo los que se creen custom. En principio cualquier modulo (incluso los estándar de SAP) se pueden exponer como un web service normal y corriente. Solo hay que activar la opción “Remote Enbaled module” que aparece en esta imagen (img8.imageshack.us/.../remoteenabledbapi.jpg) dentro de las propiedades del Funtion Module/BAPI en SAP. Una vez hecho esto, el WAS expone un explorador de web services (img8.imageshack.us/.../webservicebrowser.jpg) a través del cual podemos acceder a todos los Function Modules/BAPIs que dicho entorno SAP tenga configurados como “Remote Enabled” y generar el WSDL correspondiente (voila! Web reference de toda la vida en nuestro proyecto .NET). La URL del Web Service browser tiene esta estructura: http://<host_name>:<port_number>/sap/bc/bsp/sap/WebServiceBrowser/search.html?sap-client=<relevant_client>

- El Biztalk Adapter Pack: Aparte de poderse usar en integraciones  en las que “cuadre” BizTalk, este pack (cuyo  adaptador SAP reemplaza al antiguo SAP Connector) se puede usar también desde cualquier aplicación .NET. Es decir, se puede usar ese mismo Adaptador desde tu propia aplicación .NET sin necesidad de involucrar BizTalk, pudiendo llamar a SAP desde cualquier aplicación .NET, e incluso pudiendo hacer que SAP sea el que llame a un servicio WCF que contenga un endpoint de tipo SAPBinding expuesto en tu aplicación .NET (una aplicación .NET actuando como servidor RFC!). Las diferentes opciones de uso del Adaptador desde una aplicación .NET están documentadas aquí (technet.microsoft.com/.../cc185470.aspx). OJO, según informaciones que hemos recibido, el antiguo SAP Connector dejara de recibir soporte oficial de SAP en breve, por lo que es recomendable modificar las aplicaciones existentes que lo usen y empezar a usar el adaptador del Biztalk Adapter Pack.

Saludos @ Home

El Bruno