La jornada comenzó con el modelo de programación clásico. Disfruté de la programación libre. Pero con el tiempo, las tendencias comerciales comenzaron a cambiar y el mercado evolucionó significativamente con aplicaciones en la nube y móviles en la infraestructura digital. Y ahora, cuando la práctica mejor reconocida para la programación es el Modelo de Programación ABAP para SAP Fiori, miro hacia atrás y veo una evolución en varias áreas en SAP. Y continuará, ya que el modelo de programación futuro ya está listo, llamado el modelo de programación ABAP RESTful. Desde el punto de vista de un viajero de SAP, llegaron muchas herramientas, se desarrollaron varias técnicas y surgieron nuevos conceptos en el contexto de la interfaz, infraestructura e integración en SAP. Hay varios blogs sobre cada uno de estos temas, pero todos están segregados y escritos desde un punto de vista puramente técnico. La idea de esta publicación de blog es proporcionar una visión desde el punto de vista de un viajero de SAP para que sea fácil de entender incluso para principiantes. Por lo tanto, sin dar mucha información técnica, permítanme compartir un vistazo a los conceptos en secuencia.
Evolución de técnicas, conceptos y herramientas
La vista pictórica anterior no representa ningún índice de prioridad para el uso de las técnicas, es solo una representación de la llegada de diferentes técnicas en una secuencia aproximada de cronología.
1. Interfaz de Archivos
: Las interfaces basadas en el intercambio de archivos son una de las técnicas más antiguas para proporcionar datos al sistema de terceros desde SAP. Ya sea empujando el archivo de texto o Excel a un directorio específico o extrayéndolo del servidor de aplicaciones; de ambas maneras funciona. Sin necesidad de una codificación o configuración compleja, utilizando FTP/SFTP el archivo se puede transferir desde SAP a cualquier sistema de terceros. Con la llegada de PI (integración de procesos), el archivo extraído de SAP se envía primero a PI donde se realiza el mapeo y la conversión según los requisitos planteados por el sistema de terceros y luego es posible enviar el archivo en el formato deseado, JSON, XML, etc.
PI como middleware
La mayor ventaja de introducir NetWeaver PI como middleware para la transferencia de datos es que cualquier formato o tipo de archivo de datos solicitado por el socio comercial es posible de cumplir, lo que no es tan flexible para el sistema ERP hacerlo.
Algunos tcodes, declaraciones, Módulos de Función y Métodos importantes utilizados con frecuencia en este contexto son:
AL11 (tcode), GUI_UPLOAD, GUI_DOWNLOAD, OPEN DATASET, CLOSE DATASET, CL_GUI_FRONTEND_SERVICES=>
GUI_DOWNLOAD,
CL_GUI_FRONTEND_SERVICES=>FILE_OPEN_DIALOG, CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD y CL_GUI_FRONTEND_SERVICES=>DIRECTORY_EXIST
2. RFC
:
Otro enfoque bajo el modelo clásico es una llamada de función remota. La interfaz RFC se utiliza para establecer la comunicación entre SAP y no SAP, también entre dos sistemas SAP. Se ejecuta en el concepto de Cliente y Servidor. El cliente busca una función a realizar y realiza una llamada al servidor RFC. La función se ejecuta en el sistema remoto en el lado del servidor y puede ser sincrónica.
Bajo el concepto de interfaz RFC, SAP introdujo BAPI (Interfaz de Programación de Aplicaciones Comerciales). La idea era exponer los objetos comerciales (BO) a los sistemas externos. Entonces, un sistema basado en Java puede acceder a la instancia del objeto comercial expuesto (Cliente, Pedidos, Empleado, etc.) a través de métodos exclusivos proporcionados por el BO. Se crea una conexión RFC en SM59 para establecer la conexión entre dos sistemas SAP.
Interfaz RFC
Algunos códigos de transacción BAPI, SWO1, SE37, SM59 y tabla SWOTLV son comunes de usar para las Interfaces RFC.
SAP distingue entre cuatro tipos diferentes de RFC:
· Sincrónico (sRFC)
· Asincrónico (aRFC)
· Transaccional (tRFC)
·