¿Qué es una interfaz SAP IDoc para datos de producción SCADA?

Volver al glosario

Tipos de IDoc y mapeo de segmento a tag

Un IDoc es un contenedor con una estructura definida: un registro de control que dice qué tipo de documento es y a dónde va, uno o más segmentos de datos que contienen los campos reales, y registros de estatus que rastrean lo que le sucedió. El tipo de documento es el tipo de IDoc, también llamado tipo básico, y existen distintos tipos de IDoc para distintos mensajes de negocio, así que contabilizar una confirmación de producción usa un tipo de IDoc diseñado para llevar datos de confirmación en vez de uno genérico. Elegir el tipo de IDoc correcto es el primer paso, porque determina la estructura de segmentos disponible y la lógica de procesamiento de SAP que correrá cuando el IDoc se contabilice, lo que a su vez determina cuáles registros de negocio se actualizan.

Dentro del tipo de IDoc elegido, los segmentos de datos son donde van los valores SCADA, y el mapeo es el trabajo de decidir cuál valor de tag llena cuál campo en cuál segmento. Una cantidad de producción de un tag se mapea al campo de cantidad del segmento apropiado, junto con las unidades, la referencia a lo que se está confirmando, y cualquier fecha o identificador que SAP necesite para saber a cuál orden u objeto aplica la confirmación. Este mapeo de segmento a campo tiene que ser exacto, porque SAP valida el IDoc contra sus expectativas al contabilizar, y un valor en el campo equivocado, un campo requerido faltante, o unidades erróneas hacen que la contabilización falle en lugar de contabilizar incorrectamente, lo que al menos es una falla limpia.

El mapeo también tiene que puentear identidades, porque SAP no sabe de los tags SCADA. La confirmación tiene que referenciar los propios objetos de SAP, como la orden o el material y la planta, así que la integración se apoya en el mismo tipo de referencia cruzada entre tags y datos maestros de SAP que cualquier contabilización de campo a ERP necesita. Un total de producción de un tag no significa nada para SAP hasta que se expresa como una confirmación contra un objeto SAP específico, así que parte de construir el IDoc es resolver el tag en los identificadores SAP que los segmentos requieren, usando un mapeo mantenido entre los dos mundos.

RFC, ALE y middleware PI/PO

Los IDocs no flotan hacia SAP por su cuenta; viajan sobre las tecnologías de integración de SAP. ALE, application link enabling, es el marco que SAP usa para distribuir IDocs entre sistemas, definiendo los sistemas lógicos, los perfiles de socio, y los tipos de mensaje que gobiernan qué documentos fluyen a dónde. RFC, remote function call, es el protocolo subyacente que en realidad lleva el IDoc a SAP, invocando la función que lo recibe y lo procesa. Configurar la interfaz significa configurar estas piezas: perfiles de socio que le dicen a SAP cómo manejar los IDocs del sistema emisor, puertos que definen la conexión técnica, y el tipo de mensaje y el código de proceso que enrutan el IDoc entrante hacia la lógica de contabilización correcta.

En muchos paisajes el lado SCADA no habla con SAP directamente sino a través de middleware, históricamente SAP PI y luego PO, que se sienta entre los sistemas y maneja la traducción y el enrutamiento. El middleware recibe los datos de campo en la forma que produzca la integración SCADA, los mapea a la estructura del IDoc, y los entrega a SAP por la maquinaria de RFC y ALE, y hace lo inverso para los mensajes que fluyen hacia afuera. Esta capa de middleware es valiosa porque aísla a SAP de las particularidades de los sistemas de campo, así que un cambio del lado SCADA se absorbe remapeando en el middleware en lugar de tocar SAP, y múltiples orígenes pueden normalizarse en IDocs consistentes antes de que lleguen a SAP.

Ya sea que el camino pase por middleware o de forma más directa, la plomería tiene que configurarse coherentemente en ambos extremos, porque un desajuste en cualquier parte rompe el flujo. El sistema emisor y SAP tienen que ponerse de acuerdo en el perfil de socio, el tipo de mensaje, y la conexión, y el middleware, si está presente, tiene que configurarse para producir IDocs que coincidan con lo que el perfil de socio de SAP espera. Por eso levantar una interfaz de IDoc es tanto un ejercicio de configuración a través de las capas de RFC, ALE, y middleware como un ejercicio de mapeo, y por eso la interfaz suele construirse y probarse con cuidado antes de que fluyan datos de producción reales por ella.

Estatus 51 y manejo de errores en operaciones de campo

Los IDocs cargan su propia historia en registros de estatus, y esos estatus son cómo se sabe si una contabilización tuvo éxito. Un IDoc que se contabiliza limpio alcanza un estatus de éxito, mientras que uno que SAP no pudo contabilizar aterriza en un estatus de error, y el estatus 51 es el bien conocido que significa que el documento de aplicación no se contabilizó porque una validación de negocio falló. Un IDoc en estatus 51 no ha desaparecido ni se ha contabilizado; está sentado en SAP con un mensaje de error que explica por qué, como un campo requerido faltante, una referencia inválida, una cantidad que SAP no acepta, o una orden que no está en un estado que permita la confirmación. El mensaje en el IDoc fallido es el punto de partida para averiguar qué salió mal.

Manejar estos errores es una responsabilidad operativa real, no un caso excepcional, porque los datos de campo son desordenados y algunos IDocs fallarán. El flujo de trabajo es monitorear los IDocs en estatus de error, leer el mensaje de error para entender la causa, corregir el problema subyacente, y luego reprocesar el IDoc para que se contabilice. A veces la corrección está en los datos, como una referencia equivocada que necesita que se corrija el mapeo, y a veces está en SAP, como una orden que necesita estar en el estado correcto antes de que la confirmación pueda contabilizarse. Como un IDoc atorado significa un evento de producción que no se ha registrado en SAP, alguien tiene que estar vigilando estos y limpiándolos, o el ERP se desincroniza en silencio de lo que la planta realmente produjo.

Aquí es donde la calidad de los datos de campo que alimentan la interfaz rinde frutos, y donde una capa de monitoreo ayuda a mantener baja la tasa de errores. Cuando los datos SCADA que llegan a la integración son limpios, están identificados de forma consistente, y están correctamente mapeados a objetos SAP, menos IDocs fallan la validación en primer lugar, y los que fallan son más fáciles de diagnosticar. Una plataforma como Merobix que recolecta y normaliza datos de producción SCADA con tags consistentes y estampas de tiempo confiables da al armado del IDoc una entrada de confianza, así que los totales de producción que llegan a SAP están bien formados y son rastreables, lo que reduce el flujo de IDocs en estatus 51 que operaciones de otro modo tendría que perseguir y reprocesar.

Preguntas frecuentes