Arquitectura SAP PI/XI

A primera vista, el trabajo que desempeña SAP Process Integration (SAP PI) parece muy simple: El intercambio de información de una aplicación a otra a través de mensajes. Sin embargo, SAP PI es quizás una de las partes mas ampliamente utilizada dentro de la plataforma SAP NetWeaver.
El objetivo real de SAP Process Integration (SAP PI) es proveer una plataforma que permita a diferentes interfaces comunicarse entre ellas usando una tecnología uniforme. Para lograrlo SAP PI/XI proporciona un conjunto de herramientas que pueden ser usadas para definir formatos de mensajes, transformaciones de un formato A a un formato B, definir procesos, y permitir a estos procesos interactuar con el mundo exterior a través de mensajes.

Figura 1 - Arquitectura SAP PI

• System Lanscape Directory (SLD). Es simplemente un directorio de información técnica acerca de los programas y computadoras que están conectados a través de SAP Process Integration. La información que se incluye en el SLD va desde hostnames y otros atributos técnicos, así como información sobre los componentes de software que están instalados en el servidor.
• Integration Builder. Es un completo entorno de desarrollo usado en tiempo de diseño para definir mensajes y procesos, mapeos de un formato a otro, configurar la forma en que serán usados con otros sistemas y almacenar todo tipo de información relacionada al intercambio de mensajes.
• Integration Repository (IR). Es en este componente donde SAP PI mantiene la metadata que describe los tipos de datos, mensajes, procesos y los mapeos y conexiones entre ellos. El objetivo del Integration Repository es crear un punto de acceso centralizado a los objetos que podamos crear para un determinado escenario de integración, pudiendo así reutilizar algunos de los objetos que hayamos definido.
• Integration Directory (ID). En este componente, los tipos de mensajes y procesos descritos en el Integration Repository son conectados al mundo real. Cuando un mensaje viene desde un partner y luego es enviado a un sistema interno, la metadata que describe todas estas conexiones es almacenada en el Integration Directory. En resumén, el Integration Directory describe con qué sistemas te comunicas, cómo te comunicas con ellos, y las reglas de comunicación establecidas.
• Integration Server. Es el motor responsable del ruteo de los mensajes. El Integration Server no tiene estrictamente componentes, es más parecido a un pipeline donde ocurren una serie de tareas, tales como: ruteo lógico, ruteo físico(o técnico), mapping y la llamada a los adaptadores.
• Central Monitoring. Este componente se encarga del monitoreo y evaluación de que los mensajes estén fluyendo satisfactoriamente entre sistemas. Este punto de acceso centralizado proporciona una visión del escenario de integración completo, presentando las restricciones y todo lo que necesites para seguir el flujo de un mensaje hacia un sistema determinado.