SAP PI para principiantes

Objetivo

El objetivo de este tutorial es hacerle comprender: ¿qué es la integración de procesos SAP? No entraremos en lo esencial del tema, sino que discutiremos sobre la arquitectura y las diferentes características de SAP PI. Cubriremos solo las características básicas y evitaremos discutir todas las características en este tutorial.

A continuación, hay un conjunto de estudios de casos que le darán una idea sobre la utilización de SAP PI a nivel de la industria. Una vez que se familiarice con el tema, debe tratar de resolverlos. Los casos de prueba están preparados de una manera que lo llevará al tema de simple a más complejos con cada lección y le dará una idea general del tema.

¿Qué es SAP ERP?

Para cualquier empresa, grande o pequeña, estas son las funcionalidades comerciales estándar que debe llevar a cabo, es decir, Gestión de Materiales, Ventas y Distribución, Finanzas, Recursos Humanos, etc. Hay mucho software en el mercado que es utilizado por la industria. Notará el más simple: el cajero que genera facturas de venta si visita una tienda pequeña a una red de computadoras en una gran tienda minorista, hotel, etc. que opera en un ERP.

La planificación de recursos empresariales, es decir, el ERP, es un enfoque eficaz que la mayoría de las empresas implementan para mejorar su productividad y rendimiento. SAP ERP es la Planificación de Recursos Empresariales de SAP AG, una solución de software integrada que incorpora las funciones empresariales clave de la organización. Las funcionalidades básicas, es decir, HR, MM, SD, FICO, etc., se denominan módulos de negocio en SAP. SAP los construye como productos y los vende en el mercado. Hay dos módulos más que no admiten funciones empresariales directamente, pero se utilizan para la presentación y la integración. El primero se llama EP (Portal Empresarial) y el segundo se llama PI (Integración de procesos). Todos los módulos de negocio se desarrollan en ABAP, mientras que EP y PI se desarrollan principalmente en Java. Estos módulos no son ejecutables, pero deben implementarse en un Servidor de aplicaciones, es decir, un Servidor de Aplicaciones Web ABAP para módulos ABAP y Servidores de aplicaciones Web Java para módulos Java.

Hay algunos puntos que deberíamos saber antes de entrar en el tema.

• SAP significa Sistemas, Aplicaciones y Productos en Procesamiento de Datos.

• SAP AG es una corporación de software multinacional alemana que fabrica software empresarial para gestionar las operaciones comerciales y las relaciones con los clientes. SAP ERP es la Planificación de Recursos Empresariales de la corporación, una solución de software integrada que incorpora las funciones empresariales clave de la organización.

• SAP NetWeaver Process Integration (SAP PI) es un software de integración de aplicaciones empresariales de SAP (EAI), un componente del grupo de productos NetWeaver utilizado para facilitar el intercambio de información entre el software y los sistemas internos de una empresa y los de partes externas.

Sistema heredado

Al implementar el ERP de SAP en un establecimiento comercial grande, se observa que no todas las secciones se pueden incluir en el ERP de SAP. Muchas de las secciones de negocios pueden tener sus propias herramientas propietarias que son altamente complejas y pueden no ser posibles de reemplazar. Corren en paralelo al Sistema SAP. Se llaman los Sistemas Heredados. Entonces se hace necesario integrar entre los Sistemas SAP y dicho Sistema preexistente no SAP. Aquí es donde el SAP PI entra en juego.

Por qué necesitamos SAP PI Aparte de los Sistemas Heredados, en un establecimiento comercial grande, SAP ERP no consiste en un solo sistema, sino en varios sistemas integrados, como CRM, SRM y FICO, etc. Para manejar estas complejidades, SAP introdujo la Integración de procesos una plataforma para proporcionar un único punto de integración para todos los sistemas sin tocar la compleja red existente de sistemas heredados. Este es un poderoso middleware de SAP para proporcionar una integración integral perfecta entre aplicaciones SAP y no SAP dentro y fuera de los límites corporativos. SAP PI admite intercambios B2B y A2A, admite el intercambio de mensajes síncronos y asíncronos e incluye un motor integrado para diseñar y ejecutar Procesos de integración.

Arquitectura de SAP PI

El SAP PI consiste en una estructura de concentrador y radios; los radios se conectan con sistemas externos mientras que el concentrador intercambia mensajes entre ellos. El sistema de origen se conoce como el sistema emisor y el sistema de destino se conoce como el sistema receptor. El PI no es un solo componente, sino más bien una colección de componentes que trabajan juntos de manera flexible para implementar escenarios de integración. La arquitectura incluye componentes que se utilizarán en tiempo de diseño, en tiempo de configuración y en tiempo de ejecución.

Podemos dividir el SAP PI en varias áreas

1. Integration Server
2. Integration Builder
3. Paisaje del sistema
4. Configuración y supervisión

Integration Server es el motor de procesamiento central del SAP PI. Todos los mensajes se procesan aquí de forma coherente. Consta de tres motores separados

1. Motor de integración
2. Motor Adaptador
3. Motor de procesos de negocio

El motor de integración se puede considerar el eje y el motor Adaptador el radio. En cuanto al Motor de Procesos de Negocio, lo explicaré más adelante.

Integration Builder es un framework cliente-servidor para acceder y editar objetos de integración y consta de dos herramientas relacionadas:

1. Repositorio de servicios empresariales: para diseñar y desarrollar objetos que se utilizarán en escenarios
2. Directorio de integración – para configurar los objetos ESR para desarrollar escenarios

Dos juntos, creamos procesos de integración que comúnmente se denominan escenarios.

El entorno del sistema es un repositorio central de información sobre software y sistemas en el centro de datos y simplifica la administración del entorno del sistema.

En Configuración y Monitoreo podemos monitorear los mensajes y adaptadores.

Pila única y pila doble

Cuando PI se lanzó por primera vez, no todos los componentes se construyeron en la misma plataforma. El Motor de integración y el Motor de Procesos de negocio se construyeron en ABAP, mientras que el Motor Adaptador, el Integration Builder, SL, CM y el tiempo de ejecución de Mapeo se construyeron en Java. Por lo tanto, PI necesita tanto el entorno Java como el ABAP para ejecutarse y se conoce como pila dual.

Pila ABAP	Pila de Java
Motor de integración Motor de procesos de negocio Generador de integración	Repositorio de servicios empresariales Directorio de integración Banco de trabajo de tiempo de ejecución Directorio de paisaje del sistema Motor adaptador Tiempo de ejecución de asignación

Pero en la versión posterior, todos los componentes están construidos en Java. Algunos de los componentes de doble pila se dispensan o se modifican para que funcionen en la pila Java. Por lo tanto, PI solo necesita el entorno Java para ejecutarse y se conoce como pila única.

Hay pros y contras entre las dos pilas, pero no se tratan en este tutorial.

La Integración Del Motor

El Motor de Integración es responsable de los servicios de Servidor de integración central, es decir, de los pasos de tubería: enrutamiento y asignación. Si la estructura del mensaje de origen es diferente de la estructura del mensaje de destino, entonces el motor de integración llama al tiempo de ejecución de la asignación, donde la estructura de origen se convierte en la estructura de destino. El tiempo de ejecución de la asignación se basa en la pila Java. El motor de integración también puede utilizar un programa ABAP para la conversión, que se basa en la pila ABAP.

Un mensaje puede ser de dos tipos

1. Síncrono-tiene la parte solicitud-respuesta
2. Asíncrono-tiene la parte solicitud o respuesta solo

En PI, el mensaje está representado por una interfaz.

Interfaz -> estructura del mensaje en formato XML + dirección

En función de los criterios anteriores, hay tres tipos de interfaces

1. Interfaz de salida – conéctese al sistema emisor
2. Interfaz de entrada – conéctese al sistema receptor
3. Interfaz abstracta – conéctese al BPE

Cuando configuramos la lógica de integración (escenario) en SAP PI según los requisitos de nuestro negocio, es el motor de integración el que ejecuta esa configuración de manera gradual. Canalización es el término utilizado para referirse a todos los pasos que se realizan durante el procesamiento de un mensaje XML. Los pasos de la tubería consisten en lo siguiente:

1. Identificación del receptor: determina el sistema que participa en el intercambio del mensaje.
2. Determinación de interfaz: determine qué interfaz debe recibir el mensaje.
3. División de mensajes: si se encuentra más de un receptor, PI creará una instancia de mensaje nuevo para cada receptor.
4. Mapeo de mensajes: mapeo para transformar el mensaje de origen en el formato de mensaje de destino.
5. Enrutamiento técnico: enlaza un destino y un protocolo específicos al mensaje.
6. Adaptador de llamada: envía el mensaje transformado al adaptador o a un proxy.

Motor adaptador

Debe haber notado anteriormente que el motor de integración solo maneja mensajes en el protocolo XML-SOAP. Pero qué pasa si tenemos un sistema de negocios emisor y receptor donde los datos no están en el mismo formato. Utilizamos los diversos adaptadores en el Motor de adaptadores para convertir mensajes basados en XML y HTTP al protocolo y formato específicos requeridos por estos sistemas, y viceversa.

Como hemos discutido anteriormente, SAP PI es una estructura de concentrador y radios donde el motor Adaptador se puede considerar como radios. Utilizamos el Motor Adaptador para conectar el Motor de Integración (Hub) a los sistemas externos. El Marco del Adaptador es la base del Motor del adaptador. El marco del adaptador se basa en el motor SAP J2EE (como parte del Servidor de Aplicaciones Web SAP) y la Arquitectura de conectores J2EE (JCA). El marco de trabajo del adaptador proporciona interfaces para la configuración, administración y supervisión de adaptadores.

En un sistema de pila dual, la mayoría de los adaptadores se basaban en la pila Java, salvo dos adaptadores que se basaban en la pila ABAP.

Pila de Java	Adaptador RFC, Adaptador de conector SAP Business, adaptador de archivo / FTP, adaptador JDBC, adaptador JMS, adaptador SOAP, Adaptador Marketplace, Adaptador de correo, adaptador RNIF, adaptador CIDX
Pila ABAP	Adaptador IDOC y adaptador HTTP

Cuando SAP PI pasó de la pila dual a la pila única, estos dos adaptadores se convirtieron en parte de la pila Java. El motor de adaptador modificado se conoce como Motor de adaptador Avanzado y los dos adaptadores se llaman adaptador IDOC_AAE y adaptador HTTP_AAE respectivamente.

Motor de procesos de negocio

El Motor de procesos de negocio es responsable de ejecutar y mantener los procesos de integración.

BPM significa Gestión de Procesos de Negocio de componentes cruzados o ccBPM y también se llama Proceso de integración. Un proceso de integración es un proceso ejecutable entre sistemas para procesar mensajes. En un proceso de integración se definen todos los pasos del proceso que se van a ejecutar y los parámetros relevantes para el control del proceso. La Gestión de Procesos de Negocio proporciona la infraestructura de Intercambio de SAP con las siguientes funciones:

1. Procesamiento de mensajes de estado completo: El estado de un proceso de integración se conserva en el servidor de integración.
2. También puede usar correlaciones para establecer relaciones semánticas entre mensajes.
3. Implementa procesos de integración cuando desea definir, controlar y supervisar procesos de integración complejos que se extienden a través de los límites de la empresa y de las aplicaciones, es decir, recopilar/Fusionar, Dividir, multidifusión

En tiempo de ejecución, el Motor de procesos de negocio ejecuta los procesos de integración. El proceso de integración puede enviar y recibir mensajes utilizando únicamente interfaces abstractas.

Construir un escenario en SAP PI

Comenzamos desde la página de inicio si tenemos que construir un escenario en PI.

La página de inicio se verá similar a la que se muestra a continuación:

Figura 6 – Página de inicio para SAP PI Pila Java

La página de inicio tiene hipervínculos a las siguientes 4 áreas de trabajo

1. Repositorio de servicios empresariales (ESR)
2. Directorio de integración (ID)
3. Paisaje del sistema (SL)
4. Configuración y supervisión (CM)

Cada hipervínculo abrirá una aplicación. Estos cuatro son aplicaciones Java. ESR e ID son aplicaciones oscilantes. Se inician desde el navegador basado en JNLP. Así que por primera vez toma más tiempo, ya que descarga todo el archivo de la biblioteca. Pero a partir de la segunda vez, el lanzamiento tarda menos tiempo. SL y CM son aplicaciones web puras y se ejecutan en el navegador.

Repositorio de servicios empresariales

Aquí diseñamos y creamos objetos que se utilizarán en la creación de un escenario de integración. El flujo de datos en PI será similar al que se muestra a continuación:

Encontramos la opción de diseñar los siguientes objetos de interfaz

1. Interfaz de Servicio, Tipo de Mensaje, Tipo de datos
2. Mapeo de objetos-Mapeo de Operaciones y Mapeo de mensajes
3. Procesos de integración

PI utiliza el repositorio de integración para diseñar la estructura de mensajes para los sistemas emisor y receptor y desarrollar un mensaje de interfaz utilizando las estructuras de mensajes correspondientes que actúan como un punto de interacción con el mundo exterior. El tipo de datos y el tipo de mensaje se utilizan para simplificar y modular el diseño de una interfaz compleja.

permite la transformación de la estructura de origen a la estructura de destino cuando las dos estructuras son diferentes. Pero si la estructura de origen y de destino son las mismas, la asignación de la operación puede eliminarse. Al igual que la interfaz de servicio, la asignación de mensajes se utiliza para simplificar y modular el diseño de una asignación de operaciones complejas. La asignación de mensajes se puede implementar de 4 maneras

1. Asignación gráfica
2. Asignación Java
3. Asignación XSLT
4. Asignación ABAP

La asignación gráfica es la más utilizada, ya que permite al desarrollador asignar atributos de ambas estructuras gráficamente para pasar datos mediante interfaces de servicio. Para los otros tres, tenemos que desarrollar el mapeo escribiendo código. Si se trata de un servidor de una sola pila, la asignación ABAP no estará disponible.

Hay otras áreas también, pero no están cubiertas en este tutorial.

Directorio de integración

Aquí hacemos los pasos de tubería configurando los objetos ESR creados anteriormente. El motor de integración ejecuta estos pasos durante el tiempo de ejecución.

Antes de iniciar la configuración necesitamos crear / importar los siguientes objetos en el directorio.

1. Servicio – Sistema Empresarial/ Servicio Empresarial / Proceso de Integración
2. Canal de comunicación

Un servicio le permite dirigirse a un remitente o receptor de mensajes. Dependiendo de cómo desee usar el servicio, puede seleccionar uno de los siguientes tipos de servicio.

1. Sistema empresarial: Si desea dirigirse a un sistema empresarial en particular como remitente o receptor de mensajes, elija este tipo de servicio. Un sistema empresarial es un sistema de aplicación real en un entorno de sistemas.
2. Servicio empresarial: Si desea dirigirse a una entidad empresarial abstracta como remitente o receptor de mensajes, elija este tipo de servicio. Un servicio comercial no está definido en el entorno del sistema.
3. Servicio de proceso de integración: Si desea abordar un proceso de integración como remitente o receptor de mensajes, elija este tipo de servicio. En tiempo de ejecución, estos procesos de integración son controlados por mensajes y pueden enviar mensajes por sí mismos.

El canal de comunicación determina el procesamiento de entrada y salida de mensajes. Los mensajes se convierten del formato nativo al formato de mensaje específico soap-xml y viceversa a través del adaptador. Generalmente hay dos tipos de canal de comunicación en un escenario

1. Canal de comunicación del remitente
2. Canal de comunicación del receptor

Debe asignar un canal de comunicación a un servicio. Dependiendo de si el servicio se dirige como emisor o receptor de mensajes, el canal de comunicación asignado tiene la función de emisor o canal receptor, y debe configurarse en consecuencia. No se puede asignar un canal de comunicación a un servicio de proceso de integración.

Los pasos de la tubería se crean creando la siguiente configuración de 4 en el directorio

Encontramos las siguientes opciones:

1. Acuerdo del remitente
2. Determinación del receptor
3. Determinación de la interfaz
4. Acuerdo del receptor

El acuerdo del remitente define cómo se debe transformar el mensaje de un remitente para que el Servidor de integración pueda procesarlo. Consiste en el siguiente

1. Componente de remitente
2. Interfaz de remitente
3. Canal de comunicación de remitente

El acuerdo de remitente es similar a la clave primaria en la tabla. No pueden existir los dos acuerdos de remitente similares en un mismo entorno.

El acuerdo de receptor define cómo se va a transformar el mensaje para que pueda ser procesado por un receptor. Consiste en

1. Componente del remitente
2. Componente del receptor
3. Interfaz del receptor
4. Canal de comunicación del receptor

Se utiliza una determinación del receptor para especificar a qué receptores se va a enviar un mensaje. Tiene la opción de definir las condiciones para reenviar el mensaje a los receptores. Consiste en

1. Componente del remitente
2. Interfaz del remitente
3. Componente del receptor

La determinación del receptor es de dos tipos: Estándar o Extendida, dependiendo de si desea especificar el Receptor de forma manual o dinámica mediante una asignación en tiempo de ejecución.

Se utiliza una determinación de interfaz para especificar a qué interfaz de entrada de un receptor se debe reenviar el mensaje. También puede especificar qué asignación de interfaz desde el Repositorio de Integración se utilizará para procesar el mensaje, p. ej. si la interfaz emisor y receptor no tienen el mismo formato, entonces hay una asignación operativa para cambiar el formato. Se define una determinación de interfaz para un remitente, una interfaz de salida y un receptor. Consiste en

1. Componente de remitente
2. Interfaz de remitente
3. Componente de receptor
4. Interfaz de receptor

La determinación de la interfaz es de dos tipos: Estándar o mejorada, dependiendo de si desea especificar la interfaz de receptor manualmente o mediante división de mensajes basada en asignación.

Determinación del receptor y Determinación de la interfaz: los dos juntos se conocen comúnmente como enrutamiento lógico. Acuerdo de Remitente y Acuerdo de Destinatario: los dos juntos se conocen comúnmente como el Acuerdo de Colaboración.

Paisaje del sistema

El SAP System Landscape Directory (SLD) es el proveedor de información central en un paisaje del sistema. En la página web encontrará los siguientes enlaces:

1. Sistema técnico: Los sistemas técnicos son sistemas de aplicación que se instalan en el entorno de su sistema.
2. Sistema de negocio-Los sistemas de negocio son sistemas lógicos, que funcionan como remitentes o receptores dentro de PI. Business Systems tiene una dependencia individual con el sistema técnico asociado.
3. Productos y componentes: Esta es información sobre todos los productos y componentes SAP disponibles, incluidas sus versiones. Si hay productos de terceros en el entorno del sistema, también están registrados aquí.

El SLD se verá similar al que se muestra a continuación:

Figura 11-Paisaje del sistema

Los productos y componentes se denominan comúnmente Información de componentes

El Sistema Técnico y el Sistema Comercial se denominan comúnmente Descripción del paisaje.

Un sistema empresarial se puede configurar como un servidor de integración o un sistema de aplicación.

1. Servidor de integración: El servidor de integración solo ejecuta la lógica de integración configurada en el Integration Builder. También se pueden identificar como Pasos de Tubería. Recibe mensajes XML, determina el receptor, ejecuta las asignaciones y enruta el mensaje XML a los sistemas receptores correspondientes. Por lo tanto, el Motor de Integración configurado se identifica como Motor de Integración Configurado centralmente.
2. Sistema de aplicaciones: El sistema de aplicaciones no ejecutará la lógica de integración. A su vez, llama al servidor de integración para ejecutar la lógica de integración si es necesario. Actúa como emisor o receptor de mensajes XML. Por lo tanto, el sistema de aplicaciones con un Motor de integración local requiere que el servidor de integración ejecute la lógica de integración.

Solo se puede configurar un cliente del sistema SAP como Servidor de integración.

La siguiente información se extrae del SLD en el ESR y DIR

1. La información del componente se utiliza en el ESR para definir el Producto y el Sistema Empresarial SWCV
2. Se utiliza en el Directorio para definir el emisor y el receptor de mensajes

Configuración y supervisión

Es el punto de entrada central para fines de supervisión. Esto le brinda la opción de navegar a las funciones de monitoreo del Motor de Integración, así como la integración con el Sistema de Administración de Centros de Computación (CCMS) y la Infraestructura de Monitoreo de Procesos (PMI) de SAP.

La configuración y el monitoreo se verán similares a los que se muestran a continuación:

Figura 13-Configuración y supervisión

Con la Configuración y supervisión se admiten las siguientes funciones de supervisión:

1. Monitoreo de componentes-monitoreo de los diferentes componentes de SAP PI (partes Java y ABAP).
2. Monitoreo de mensajes: seguimiento del estado del procesamiento de mensajes dentro de un componente SAP PI y en la detección y el análisis de errores.
3. Monitoreo de extremo a extremo: monitoreo del ciclo de vida de un mensaje desde el punto de vista de SAP PI.
4. Monitoreo de rendimiento: se puede acceder a estadísticas sobre diferentes aspectos de rendimiento de SAP PI a través de RWB. Aquí, puede seleccionar y agregar datos de rendimiento, por ejemplo, por componente, rango de tiempo o atributos de mensaje.
5. Administración de índices: al administrar y supervisar la indexación de mensajes por componente SAP PI, habilita una búsqueda de mensajes basada en índices que puede usar en la supervisión de mensajes. Este tipo de búsqueda de mensajes ofrece criterios de selección mejorados, incluidos atributos de mensaje específicos del adaptador y términos o frases de la carga útil del mensaje.
6. Configuración de alertas: mediante el marco de Alertas, se puede proporcionar monitoreo central en PI con todos los errores reportados durante el procesamiento de mensajes en ABAP y Java. Esto permite una reacción mejorada a tales errores tanto en el tiempo de ejecución de ABAP como en el Motor Adaptador basado en Java. Con este fin, el Marco de Alerta está provisto de reglas basadas en ciertos eventos y en la información del encabezado del protocolo de mensajes PI. Estas reglas determinan si las alertas se envían o no. Si se envía una alerta, se puede utilizar para el análisis de errores.
7. Bandeja de entrada de alertas: la bandeja de entrada de alertas es específica para el usuario y muestra todas las alertas para cada servidor de alertas que se ha generado en función de la configuración de alertas.
8. Monitoreo de caché: el monitoreo de caché muestra los objetos que se encuentran actualmente en la caché de tiempo de ejecución. Se supervisan diferentes objetos de caché en función de la instancia de caché en cuestión.

Comunicación síncrona vs. asíncrona

Un proceso se puede definir como síncrono o asíncrono.

• Un proceso síncrono es invocado por una operación de solicitud / respuesta, y el resultado del proceso se devuelve al llamante inmediatamente a través de esta operación.
• Un proceso asíncrono es invocado por una operación unidireccional y el resultado y cualquier fallo son devueltos invocando otras operaciones unidireccionales. El resultado se devuelve a la persona que llama a través de una operación de devolución de llamada.

En el mundo informático, no hay comunicación asíncrona. Toda la comunicación entre dos sistemas es siempre a través de llamada de método (operación de solicitud/respuesta). Entonces, ¿cómo lo hacemos asíncrono? La respuesta radica en la introducción de un tercer sistema entre la función llamada y la función que llama.

Supongamos que hay dos sistemas a y B. Toda la comunicación entre A y B es a través de una llamada de método y, por lo tanto, son sincrónicas. Introducimos un tercer sistema entre A y B y lo llamamos el sistema Intermedio-I. La comunicación entre A e I es a través de la llamada al método y, de manera similar, entre I y B es también a través de la llamada al método. Pero la comunicación entre A y B se puede llamar asíncrona, ya que A no tiene que esperar la respuesta de B.

Esta es la base de la comunicación asíncrona y ¿qué es este sistema intermedio? Esa es la cola. A se llama remitente y B se llama receptor. El mensaje de A se agrega primero a la Cola y luego se extrae de nuevo de la Cola y se envía a B. La respuesta de B llega a A de manera similar. En ciertas situaciones, el requisito comercial requiere que los mensajes se entreguen a B en el mismo orden en que se activan desde A. En tal caso, seguimos una política de primero en entrar y primero en salir. Si no hay tales requisitos, los mensajes se envían desde la cola a B en cualquier orden.

Con la comunicación asíncrona, logramos una entrega garantizada, es decir, el sistema B no está disponible cuando el sistema A envía el mensaje. El mensaje se añade a la cola y permanece allí mientras B no esté disponible. Una vez que B está disponible, el mensaje se extrae de la cola y se envía a B.

Para que podamos clasificar nuestra comunicación de mensajes de tres maneras:

1. Síncrono
2. Asíncrono con orden no mantenida
3. Asíncrono con orden mantenida

En PI, los identificamos como: Síncrono – BE (Mejor Esfuerzo), Asíncrono con orden no mantenida – EO (Exactamente Una vez), Asíncrono con orden mantenida – EOIO (Exactamente Una Vez en Orden).

Reconocimiento

El reconocimiento es la raíz de la comunicación asíncrona. ¿Por qué?

Para la comunicación síncrona, el sistema A llama al sistema B y si B no envía la respuesta, el proceso falló. Pero en una comunicación asíncrona, el Sistema A llama al Sistema I y el Sistema I llama al Sistema B. Supongamos que la comunicación entre A e I es exitosa, pero entre I y B, falla. ¿Cómo debería A darse cuenta de que la entrega a B ha fallado? Esto se realiza mediante un acuse de recibo que se envía de vuelta a A por B a través de la misma ruta que el mensaje de A llevado a B. Si el acuse de recibo de B no llega a A, A considerará que el proceso ha fallado y enviará el mensaje de nuevo.

Mientras hablamos de la comunicación asincrónica en PI, hemos usado el término «Exactamente una vez» para EO y EOIO. Exactamente una vez significa que un mensaje entregado una vez no se puede entregar de nuevo. Para lograr esto, hay un acuse de recibo para cada mensaje enviado de A a B. Son los adaptadores los que se encuentran al final de la comunicación. Por lo tanto, los adaptadores deben admitir reconocimiento.

Todos los adaptadores proporcionan reconocimiento del sistema i.e. la entrega de acuse de recibo. Los adaptadores que admiten comunicación síncrona admiten reconocimiento de aplicaciones además del reconocimiento del sistema.

Así que en PI, a continuación se muestra el tipo de reconocimiento

1. Reconocimiento del sistema: reconocimientos del sistema utilizados por el entorno de tiempo de ejecución para confirmar que un mensaje asíncrono ha llegado al receptor.
2. Acuse de recibo de la aplicación: los acuses de recibo de la aplicación se utilizan para confirmar que el mensaje asíncrono se ha procesado correctamente en el receptor.

Llamada de función remota

Mientras trabaja en PI, encontrará el término-RFC. ¿Qué son? Para establecer la comunicación entre dos sistemas SAP, es decir, un R/3 y PI, creamos el Destino RFC. Está configurado por el siguiente

1. Tipo de conexión
2. Dirección IP y Puerto del receptor

El tipo de conexión indica el tipo de conexión del sistema, es decir, R / 3, TCP / IP, Interno, etc.

El Destino RFC que creamos se clasifica de acuerdo con el modo de comunicación requerido, p. ej. si debe admitir comunicación síncrona o asíncrona.

1. para comunicación síncrona-RFC síncrono
2. para comunicación asíncrona con pedido no mantenido-RFC transaccional
3. para comunicación asíncrona con pedido mantenido – RFC en cola

Se identifican por sRFC, tRFC y qRFC.

Estudios de casos-1

Suponga que está en una sala de clase y hay 10 estudiantes en ella. A continuación, el profesor pide a cada alumno que prepare los siguientes datos personales y los guarde en un archivo XML. Los detalles son como sigue:

1. IDENTIFICACIÓN del Estudiante
2. Nombre
3. Móvil
4. Correo electrónico
5. Género

Hay 10 archivos y los archivos se denominan como cv_1,2,3….10. Los archivos se guardan en el directorio de origen. Para fines de prueba, se crean los siguientes directorios:

Directorio fuente: c:\ibm\sap\training\input

Directorio de archivo: c:\ibm\sap\training\archive

Directorio de error: c:\ibm\sap\training \ error

Directorio de destino: c:\ibm\sap\training\target

Se le pide que desarrolle escenarios en SAP PI que leerán los archivos de origen del directorio de origen y los escribirán en el directorio de destino. Una vez que un archivo se lee correctamente desde el directorio de origen, se debe mover al directorio de archivo y si el archivo no se puede leer por algún error, es decir, el formato xml no se mantiene, se debe mover al directorio de errores. Los archivos movidos al directorio de archivo, error o destino deben tener una marca de tiempo anexa al nombre del archivo.

1. es decir nombre de archivo + <marca de tiempo>.

Lección-1

Prepare un escenario para leer un solo archivo, es decir, el archivo cv_1.xml del directorio de origen y escribirlo en el directorio de destino. El nombre del archivo de destino también debe ser cv_1.xml con la marca de tiempo anexa al nombre.

Lección-2

Prepare un escenario para leer todos los archivos del directorio de origen y escribirlos en el directorio de destino. De manera similar, los archivos de destino también deben ser nombrados como cv_1, 2 ..xml con la marca de tiempo anexa a cada uno de ellos.

Lección-3

El instructor les pide a todos que agreguen la siguiente validación a los datos.

1. El número de teléfono móvil debe tener 10 dígitos numéricos: si el número de teléfono móvil no es de 10 dígitos, reemplácelo con ‘error’
2. El correo electrónico debe tener un carácter ‘@’ y uno ‘.’carácter-si el correo electrónico no tiene el’ @ ‘o’.’carácter, luego reemplácelo por ‘error’

Antes de ejecutar el escenario, en algunos de los archivos de origen, modifique el móvil y el correo electrónico para que estén en error según la lógica indicada anteriormente.

Lección-4

Prepare un escenario para leer todos los archivos fuente y clasificarlos según su género. Los archivos para los hombres se escribirán en un directorio y para las mujeres en otro directorio. Se crean dos directorios para el propósito anterior:

Directorio de destino para hombres: c:\ibm\sap\training\target\men

Directorio de destino para mujeres: c:\ibm \ sap \ training \ target \ women

Supongamos que hay 6 hombres y 4 mujeres en la clase, entonces si todos los archivos de origen se leen correctamente, el directorio de destino para hombres debe tener 6 archivos y el directorio de destino para mujeres debe tener 4 archivos.

Estudios de casos-2

El instructor les pide a todos que preparen un solo archivo con los datos personales de cada estudiante en segmentos separados.

Lección-5

Escriba un escenario que lea este archivo y produzca 10 archivos de destino donde cada archivo debe corresponder a los datos personales de cada empleado. Los archivos de destino deben llamarse cv_< emp_ID> _ < marca de tiempo>

Lección-6

Modifique el escenario anterior para que produzca 2 archivos de destino en lugar de 10, donde un archivo de destino para hombres y otro archivo de destino para mujeres. El archivo de destino para hombres debe tener 6 segmentos para 6 hombres y el archivo de destino para mujeres debe tener 4 segmentos para 4 mujeres.

Los archivos de destino deben nombrarse como

Para hombres – men_<marca de tiempo>

Para Damas-mujeres_<marca de tiempo>

Estudio de caso -3

Igual que el estudio de caso – 1, el instructor pide a cada estudiante que prepare sus datos personales y guardarlos en un archivo XML. Habrá 10 archivos. Los archivos se guardan en el directorio de origen.

Lección-7

Prepare un escenario para leer todos los archivos de origen del directorio de origen y crear un solo archivo en el directorio de destino. El nombre del archivo de destino será la salida.xml con la marca de tiempo anexa al nombre del archivo. El archivo de destino tendrá todos los detalles de cada archivo de origen como sub-segmento.

Lección-8

Preparar un escenario para leer los archivos fuente desde el directorio de origen y crear dos archivos en el directorio de destino – uno para hombres y otro para las damas. Para 6 hombres, el archivo de hombres debe tener seis segmentos con los detalles de cada hombre y para 4 mujeres, de manera similar, debe haber 4 segmentos con los detalles de cada dama.

Estudio de caso-4

El instructor ahora pide a cada uno de los estudiantes que prepare otro conjunto de detalles que consistirá en sus siguientes detalles académicos:

1. ID de estudiante
2. Nombre de la escuela
3. Nombre de la universidad
4. Nombre del departamento
5. Año de admisión

Habrá 10 archivos y los archivos se nombrarán como ad_1, 2, 3….10. Los archivos se guardan en el directorio de origen. Por lo tanto, cada estudiante tendrá ahora un par de archivos, uno para los detalles personales y otro para los detalles académicos. Dos archivos están relacionados con la identificación del estudiante. El directorio de entrada consta ahora de 10 archivos personales y 10 archivos académicos.

Lección-9

Se le pide que desarrolle un escenario que recogerá los archivos fuente y los procesará en pareja. El escenario generará 10 archivos de destino. Cada archivo objetivo consistirá en los detalles personales y académicos de un estudiante en segmentos separados. Los archivos de destino se llamarán res_1, 2, 10.

Los archivos de destino se verán como:

Lección – 10

A continuación, se le pedirá que cambie el ID de estudiante en algunos de los archivos para que no tengan archivos académicos o personales coincidentes y viceversa. El escenario debe ejecutarse y si encuentra algún archivo que no tenga un archivo correspondiente coincidente, el proceso debe terminar después de un período de tiempo, es decir, 2 minutos, y esos archivos se moverán al directorio de errores y no habrá archivos de destino correspondientes para ellos.