Llamada de función remota (RFC) en SAP Tutorial ABAP

¿Qué es RFC en SAP?

RFC son las siglas de Llamada a función remotaEs el mecanismo que permite que las aplicaciones empresariales se comuniquen e intercambien información —en formatos predefinidos— con otros sistemas. RFC es la forma más común de comunicación. SAP El sistema se comunica con otro, y también es el puente que conecta. SAP sistemas a no-SAP aplicaciones.

RFC ofrece dos interfaces:

1. Una interfaz de llamada para programas ABAP.
2. Una interfaz de llamada para no-SAP

Cualquier programa ABAP puede invocar una función remota utilizando el FUNCIÓN DE LLAMADA…DESTINO declaración. La DESTINATION parámetro le dice al SAP sistema en el que la función llamada se ejecuta en un sistema diferente al de la función que la llama.

Sintaxis

CALL FUNCTION 'remotefunction'
  DESTINATION dest
  EXPORTING  f1 = ...
  IMPORTING  f2 = ...
  TABLES     t1 = ...
  EXCEPTIONS ...

Los destinos lógicos se definen mediante transacción. SM59 y almacenado en la tabla RFCDES.

Funciones de la interfaz RFC

El entorno de ejecución de RFC es responsable de tres cosas en cada llamada:

• Convertir todos los datos de los parámetros al formato esperado por el sistema remoto.
• Llamar a las rutinas de comunicación necesarias para hablar con el sistema remoto.
• Manejo de errores de comunicación y cómo se los comunica a la persona que llama a través de la EXCEPTIONS parámetro de CALL FUNCTION.

RFC es el SAP Protocolo que maneja la comunicación entre sistemas y simplifica la programación relacionada. Es el proceso de llamar a un módulo de función que reside en una máquina diferente a la del programa que realiza la llamada. Técnicamente, los RFC se pueden usar para llamar a un módulo de función en el mismo máquina, pero se utilizan con mayor frecuencia cuando los programas que llaman y los llamados se ejecutan en máquinas separadas. El sistema de interfaz RFC se utiliza para establecer conexiones RFC entre diferentes SAP sistemas, Así como entre SAP y externo (no-SAP) sistemas.

Detalles imprescindibles sobre RFC

• SAP utiliza el CPIC Protocolo (Interfaz de Programación Común para la Comunicación) para transferir datos entre sistemas. CPIC es SAPRFC es una interfaz de comunicaciones construida sobre CPI-C, pero con más funciones y una interfaz más amigable para los programadores de aplicaciones.
• Las funciones de la biblioteca RFC admiten la Lenguaje de programación C y Visual Basic en Windows plataformas.
• Las conexiones RFC funcionan en todo el sistema. Una conexión RFC definida en el cliente 000 también puede utilizarse desde el cliente 100 sin ningún problema.
• RFC es el protocolo para llamar a subrutinas especializadas (módulos de función) a través de la red. Los módulos de función son comparables a las funciones de C o los procedimientos de Pascal: exponen una interfaz definida a través de la cual se intercambian datos, tablas y códigos de retorno. Los módulos de función se gestionan dentro de la SAP el sistema en una biblioteca dedicada, el Generador de funciones.
• El Generador de funciones (transacción SE37) proporciona a los programadores de aplicaciones un entorno para escribir, documentar y las pruebas módulos de función que pueden ser llamados tanto localmente como de forma remota. El sistema genera automáticamente el código adicional (el Fragmento de RFC) necesario para llamadas remotas.
• Las conexiones RFC se mantienen mediante transacciones. SM59. SAP también envía un SDK de RFC (Kit de desarrollo de software) que utiliza extensas bibliotecas C para que los programas externos puedan conectarse al SAP .
• La única diferencia entre una llamada remota a otro servidor y una llamada local es la DESTINATION parámetro, que especifica el servidor de destino en el que debe ejecutarse el programa.

Ventajas de RFC

RFC reduce el esfuerzo de programación al eliminar la necesidad de reimplementar módulos y métodos en el extremo remoto. La capa RFC se encarga de:

• Convertir los datos a un formato que el sistema remoto (destino) pueda comprender.
• Se ejecutan las rutinas necesarias para establecer la comunicación con el sistema remoto.
• Manejo de errores que surgen durante la comunicación.
• Proporcionar una semántica transaccional fiable cuando se utilizan variantes transaccionales o en cola.

Tipos de RFC

SAP Admite cuatro variantes de RFC. Cada una ofrece un equilibrio diferente entre latencia, fiabilidad y garantías de ordenación.

1. SyncRFC crono (sRFC)

SyncUna llamada RFC requiere que tanto el cliente como el servidor estén disponibles en el momento de la llamada. Es el tipo más común y se utiliza cuando quien realiza la llamada necesita el resultado inmediatamente después de la ejecución.

sRFC es un protocolo de comunicación entre sistemas donde se esperan confirmaciones. Los recursos del sistema de origen esperan en el sistema de destino y garantizan que el mensaje llegue con una confirmación (ACK). Los datos intercambiados son consistentes y fiables.

El inconveniente es que, si el sistema de destino no está disponible, los recursos del sistema de origen esperan hasta que vuelva a estarlo, lo que puede provocar que los procesos del sistema de origen entren en modo de suspensión/RFC/CPIC en el sistema de destino y bloqueen los recursos.

Usado para:

• Comunicación en tiempo real entre sistemas.
• Comunicación entre el SAP Servidor de aplicaciones web y el SAP GUI

2. RFC asíncrono (aRFC)

La RFC asíncrona es una comunicación entre sistemas donde no se requiere confirmación, comparable a la caídaping una postal en el correo. No es necesario que ambos sistemas estén disponibles en el momento de la ejecución, y el resultado no se devuelve inmediatamente al sistema que realizó la llamada.

El recurso del sistema de origen no espera al sistema de destino; entrega los datos y continúa. Esto hace que aRFC sea rápido, pero no totalmente fiable: se pueden perder datos si el sistema de destino no está disponible.

Usado para:

• Comunicación entre sistemas del tipo "dispara y olvida".
• Procesamiento paralelo entre sistemas.

3. RFC transaccional (tRFC)

RFC transaccional es una forma especial de RFC asíncrono. Garantiza un manejo transaccional de los pasos de procesamiento que, de otro modo, serían autónomos.

tRFC ejecuta el módulo de función llamado en el servidor RFC exactamente una vez, incluso si los datos se envían varias veces debido a problemas de red. El sistema remoto no necesita estar disponible en el momento en que el cliente RFC ejecuta la llamada. El componente tRFC almacena la función llamada y sus datos en el SAP base de datos bajo un único ID de transacción (TID). Si el sistema de destino no está disponible, los datos se escriben en tablas RFC (visibles en la transacción SM58) y posteriormente recogido por el informe del planificador RSARFCSE, que se ejecuta cada 60 segundos.

Usado para:

• Ampliación de RFC asíncrono con entrega como máximo una vez.
• Comunicación fiable entre sistemas donde la ejecución precisa es fundamental.

4. RFC en cola (qRFC)

RFC en cola extiende tRFC al garantizar que los pasos individuales se procesen en la secuencia especificada por la aplicación que realiza la llamada. Para asegurar que múltiples LUW (Unidades Lógicas de Trabajo/transacciones) se procesen en el orden previsto, tRFC se puede serializar mediante colas de entrada y salida, de ahí el nombre de "RFC en cola".

Usado para:

• Ampliación de RFC transaccional con ordenación estricta.
• Escenarios en los que es obligatoria una secuencia de procesamiento definida.
• Casos en los que varias transacciones deben procesarse en un orden predefinido.

Comparación de tipos RFC

Tipo	¿La persona que llama está esperando?	¿De confianza?	¿Ordenado?	Mejores para
sRFC	Sí:	Sí:	No disponible (llamada única)	Consultas en tiempo real
aRFC	No	No	No	Dispara y olvida, trabajo paralelo
tRFC	No	Sí (exactamente una vez)	No	Actualizaciones asíncronas fiables
qRFC	No	Sí (exactamente una vez)	Sí:	Actualizaciones estrictamente ordenadas

Tipos de conexiones RFC

El SM59 admite varios tipos de conexión. Los tres que encontrará con mayor frecuencia se resumen a continuación.

Tipo 3 — ABAP a ABAP

Las entradas de tipo 3 especifican la conexión entre sistemas ABAPEl nombre de host o la dirección IP son obligatorios; la información de inicio de sesión puede proporcionarse opcionalmente. El tipo 3 se aplica tanto a las RFC entre sistemas ABAP como a las llamadas externas a sistemas ABAP.

Tipo I — Par de la misma base de datos

Las entradas de tipo I especifican sistemas ABAP que comparten la misma base de datos que el sistema actual. Estas entradas están predefinidas y no se pueden modificar. Un nombre de entrada típico tiene el siguiente aspecto: ws0015_K18_24:

• ws0015 — nombre del host
• K18 — nombre del sistema (base de datos)
• 24 — Nombre del servicio TCP

Tipo T — Programa externo

Los destinos de tipo T se conectan a programas externos que utilizan la API RFC para recibir RFC. El tipo de activación puede ser Comenzar or Registración deSi se trata de Iniciar, se deben proporcionar el nombre del host y la ruta del programa que se va a iniciar.

Cómo Code un RFC

La construcción de extremo a extremo de un RFC tiene cinco pasos. Los tres primeros son clics mecánicos en SE37 y SM59; los dos últimos se refieren a obtener el contract correcto.

Paso 1: En la pestaña de atributos del módulo de función de la transacción SE37, establezca el tipo de procesamiento en Módulo con capacidad de control remoto para marcar el módulo de función como compatible con RFC.

Paso 2: Escribe el código del módulo de función en el editor de código fuente.

Paso 3: Defina el destino del servidor RFC en el sistema cliente RFC que llama a la función remota; esto se realiza en la transacción. SM59.

Paso 4 — Declaración de parámetros: Todos los campos de parámetros de un módulo de función remoto deben definirse como campos de referencia, es decir, con tipos vinculados a campos del Diccionario ABAP. No se permiten parámetros de valor para módulos de función remotos.

Paso 5 — Excepciones: El sistema plantea FALLO DE COMUNICACIÓN y FALLO DEL SISTEMA internamente en caso de errores a nivel de transporte. Las excepciones a nivel de aplicación pueden generarse dentro de una función remota exactamente igual que en una local.

Depuración de llamadas a funciones remotas

• Es no es posible depurar una llamada a una función remota en un sistema que no es ABAP de la manera clásica: el entorno de ejecución externo es opaco.
• Sin embargo, para las llamadas RFC de ABAP a ABAP, se puede utilizar el depurador ABAP para supervisar la ejecución de la función RFC dentro del sistema remoto.
• En las llamadas remotas, el depurador ABAP (incluida su interfaz de usuario) se ejecuta en el sistema local. Los valores de datos y otra información de tiempo de ejecución para la función remota se transmiten desde el sistema remoto.

Clave SAP Transacciones RFC

El conjunto de herramientas RFC de uso diario se reduce a un puñado de códigos de transacción que todo desarrollador ABAP y administrador Basis debería conocer de memoria.

código T	Propósito
SM59	Mantener los destinos RFC: host, inicio de sesión, tipo, seguridad.
SE37	Generador de funciones: cree o edite módulos de funciones habilitados para control remoto.
SM58	Supervise las RFC transaccionales fallidas y reproceselas.
SMQ1 / SMQ2	Supervise las colas qRFC de salida (SMQ1) y de entrada (SMQ2).
CONFIANZA	Mantenga los certificados SSL utilizados por los destinos RFC protegidos con HTTPS.
ST22	Inspeccione los volcados de memoria cortos causados ​​por llamadas remotas fallidas.

Mejores prácticas para SAP RFC

Una capa RFC bien diseñada permite que las integraciones sean rápidas, observables y fáciles de evolucionar. Vale la pena incorporar los siguientes hábitos en cada proyecto.

• Elige la variante correcta para la contract. Utilice sRFC para búsquedas síncronas, tRFC para actualizaciones asíncronas de ejecución como máximo una vez y qRFC cuando el orden sea importante.
• Reutilizar un destino por sistema de destino. En lugar de distribuir nombres de host en muchos destinos, permite la rotación de credenciales. tracmesa.
• Nunca introduzca credenciales de forma fija. En ABAP. Utilice conexiones de sistema seguras o tickets de inicio de sesión seguros siempre que sea posible.
• Supervise periódicamente los sensores SM58 y SMQ2. Las entradas tRFC bloqueadas retrasan silenciosamente los procesos empresariales hasta que se reprocesan.
• Solo se permiten parámetros de tipo referencia. Los parámetros de valor provocan fallos en los módulos de función habilitados para control remoto.
• Utilice STRUST para gestionar certificados TLS. Para destinos HTTPS, los certificados caducados son una de las principales causas de los misteriosos errores COMMUNICATION_FAILURE.

Preguntas Frecuentes