El Primer Desarrollo en PI (Parte 1)

Antes de partir describiendo los pasos de este ejercicio voy a empezar explicando el objetivo.

La idea es transformar la estructura de un Archivo XML a otra estructura diferente (ver Cuadros 1 y 2). Aunque este cambio de estructura pareciera un poco irrelevante lo que intentamos es explorar los elementos básicos que se necesitan utilizar para implementar una transformación básica en PI.

Para empezar quisiera sugerir que vayan repasando sus nociones elementales de XML, básicamente estructura y terminos, lo que si les sugeriría para posteriores artículos es que vayan repasando mas sobre XML que como verán mas adelante es la estructura base en PI. Adicionalmente quisiera disculparme por los terminos en Inglés que vayan encontrar, lamentablemente solo dispongo de una versión en Inglés de PI y pienso que no es adecuado hacer traduccion de algunos de sus componentes ya que podria generar más confusión que ayuda.

I. Pasos previos...

Primero asegurarse que contamos con las herramientas necesarias para hacer un desarrollo en PI, por lo cual verificar que se cuenta con lo siguiente:

• Acceso a PI dentro del SAP GUI (Consulte con el equipo de seguridad y el el equipo de "basis" para que le den el acceso adecuado)


• Derechos necesarios para ejecutar la transacción: SXMB_IFR y a todos sus componentes.


• Tener instalado en su Computadora Personal el ambito de ejecucion de Java oesa el Java Runtime Environment (JRE) versión 1.4.2_XX
  

II. Plan de implementación...

Luego de que nos hayamos asegurado de que tenemos a los accesos y herramientas debemos asegurarnos de contar con la siguiente información:

1. Estructuras de origen y destino que vamos utilizar, es lo equivalente a la definición de la estructura de una tabla (nombre de campos, tipos, valores por defecto, restricciones) quizás un poco más flexible considerando que son estructuras XML y que estas pueden aceptar varios niveles de anidamiento y ocurrencia.


2. Determinar las reglas que se van a utilizar para convertir la estructura de origen a la estructura de destino, para nuestro caso esto será casi intuitivo, pero para ejemplos posteriores veremos situaciones más complicadas.


3. Determinar el medio por del cual se va obtener y dejar la información que se va procesar en PI. Para nuestro caso en particular nos referimos al folder y nombre del archivo de origen y el nombre o nombres de los archivos de destino. En ciertos casos en particular vamos a necesitar de reglas para obtener y dejar el mensaje esto más adelante será explicado.
   

Para nuestro caso en particular esta es la información requerida:

1. Estructuras de origen y destino
   


• Origen

<origen> <nombre>Alejandra</nombre> </origen>

Cuadro 1



• Destino

<destino> <mensaje>Hola Alejandra</mensaje> </destino>

Cuadro 2



2. Regla
   

Se tomara el valor "Hola " y se concatenara con el valor del elemento <nombre> de la estructura origen y se grabara en el Elemento <mensaje> del destino.


3. Archivo de Origen/Destino
   

Se denominara "ArchivoDeOrigen.xml" se ubicara en el directorio "\\servidor\origen"


Se denominara "ArchivoDeDestino.xml" que se ubicara en el directorio "\\servidor\destino"

III. Empezando…

Comenzare por un resumen de las tareas y posteriormente explicare con más detalle cada punto, estos temas van a ser complementados en posteriores artículos con informacion adicional que les ayudara a consolidar sus conocimientos, se que posteriormente a estos pasos te estaras preguntando el por que, eso paulatinamente lo iremos cubriendo con nuevos articulos:

SLD


1. Crear el Software Component Version en el System Landscape Directory (SLD)
   

Integration Repository


2. Importar el Software Component Version en el Integration Reposity (IR)
   
3. Crear los Namespaces
   
4. Crear los Data Types de las estructuras de Origen y de Destino
   
5. Crear los Message Types
   
6. Crear los Message Interfaces
   
7. Crear el Message Mapping
   
8. Crear la Interface Mapping
   

Integration Directory


9. Crear Scenario
   
10. Crear el Party de Origen y el Party de Destino
    
11. Crear el Service de Origen y El Service de destino
    
12. Crear el Communication Channel de origen y el Communication Channel de destino
    
13. Crear el Sender Agreement y Receiver Agreement
    
14. Crear el Receiver Determination y Interface Determination
    

Message Monitoring y Runtime Workbench


15. Verificar que se hayan ejecutado correctamente los pasos del Pipeline
    
16. Verificar que la información ha pasado correctamente por los adaptadores.
    

Estos son los pasos basicos luego de que te hayas asegurado de que ellos hayan sido ejecutados correctamente estarás listo a desarrollar nuevos ejercicios de transformación en el proxímo capitulo empezaremos a dar mas detalles.

¿Para qué el SLD? (parte 1)

SAP System Landscape Directory (SLD), definido en el post de Arquitectura de SAP PI, actúa como proveedor central de información de las aplicaciones.

Tiene dos tipos de información (ver Grafico1):

- Información del componente.

- Descripción del Landscape

Información del componente: es donde se registra toda la información de productos y componentes de SAP con sus versiones, también incluye a los productos de terceros o externos de SAP, conocidos como “Third Party”.

Cuando se van a diseñar los objetos, la información del componente se extrae del SLD para definir los escenarios de negocio. (Esto sucede en el Integration Repository para crear los namespaces, data types, message interfaces, message mappings, interface mappings, etc).

Descripción del Landscape (entorno de desarrollo): este contiene todos los sistemas instalados en un entorno de sistema (system landscape). Cuando se configura un proceso de colaboración de negocio, la descripción del landscape es necesaria para determinar la información del sistema de los socios (Partners) que están involucrados.

Grafico 1: Información del componente y Descripción del Landscape en el SLD

El primer paso en el SLD es configurar los componentes (Productos y Software Component Versions) para tener la información y se pueda realizar la interacción de las aplicaciones.

- Producto (product): la versión de un producto es la unidad técnica que puede ser entregado al cliente. Cada producto contiene uno o más versiones de componentes de software. (SWCV).

- Componente de software (Software Component): la versión de un componente de software es la unidad más pequeña que pueden ser entregados como un producto. Cada componente de software contiene varios nombres (namespaces) y estos corresponden al los objetos de diseño.

El gráfico 2 ilustra cómo los productos y los SWCV están relacionados.

Grafico 2: Relacion de Productos y SWCV

Vamos a crear dos productos y dos SWCV para un escenario, uno para enviar y otro para la recepción de solicitudes (se usa PI 7.1). Los detalles son los que se indican a continuación:

Para la aplicación que envía Product Vendor: SAPDemo Name: Client_Sender Version: 1.0 Software Component Version Vendor: SAPDemo Name: CLIENT_SENDER Version: 1.0

Para la aplicación que recibe Product Vendor: SAPDemo Name: Client_Receiver Version: 1.0 Software Component Version Vendor: SAPDemo Name: CLIENT_RECEIVER Version: 1.0

- Abrir el Integration Builder (Exchange Infrastructure -> Start Integration Builder).
- Entrar al System Landscape Directory link. Dar click en ‘Product’ en el Software Catalog

- Veras los productos y sus componentes de software. Click en New. You will follow steps to create the product and the SWCV. First select a new product and version.


- Ingresar el nombre del producto, vendedor y versión correspondiente a la aplicación que envía. Luego el software unit que pondremos el mismo nombre del producto.


- Finalmente ponemos los datos del Software Component Version and click Finish

Repetir los pasos para la aplicación que recibe.

Dependiendo de la version de PI los pasos pueden ser diferentes, en versiones anteriores se crean por separado. Por ahora solo configuraremos la información del componente. Luego veremos para el System Landscape. Espero sus comentarios, dudas o preguntas.

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.

Tipos de Adaptadores

En el siguiente artículo se enumera y describe brevemente los diferentes tipos de comunicacion que podriamos usar con PI. El objetivo de esto es dar a conocer cuales son los adaptadores que se pueden utilizar. En otros artículos podrémos ver, con casos simples, el uso de estos adaptadores en los canales de comunicación.

File/FTP: El adaptador de tipo File/FTP nos va a permitir intercambiar información con el Integration Server utilizando archivos de texto o un servidor FTP. El contenido del archivo puede ser enviado, inalterado, al Integration Server. Si la data contiene valores separados por coma (CVS), entonces primero puede ser convertido a un formato XML simple. Este XML puede entonces ser enviado al Integration Server.En cambio, el contenido del archivo proveniente del Integration Server o del PCK puede ser puesto, inalterado, en un archivo o convertido de XML a un formato CSV.Archivos de texto que serán procesados por el Integration Server o el PCK deben estar en el código de pagina UTF-8. El adaptador File/FTP puede usar cualquier código de pagina que este instalado en el entorno JAVA para propósitos de conversión (por ejemplo, para convertir caracteres extraños).

AS2: Este adaptador utiliza el protocolo AS2 basado en HTTP y SMIME. A través de este adaptador se pueden incluir archivos en el envío de los mensajes, se puede transmitir de manera segura (HTTPS) inclusive se puede encriptar el contenido del mensaje. Bajo los estándares de comunicación se puede solicitar una confirmación MDN (Message Disposition Notifications).

BC: El adaptador SAP Conector de Negocios (SAP Business Connector Adapter-BC Adapter) soporta el protocolo B2B del SAP Business Connector, el cual esta basado en HTTP. El adaptador BC permite reemplazar un conector de negocio por SAP XI o PCK en escenarios donde diversos SAP BCs son usados. Esto asegura la entrega de mensajes via SAP XI.

CIDX: El adaptador CIDX soporta Chem eStandards, un estándar publicado por Chemical Industry Data Exchange usado para un mejor comercio por Internet en la industria Química. El adaptador CIDX esta basado en el Chem eStandards Envelope and Security Specifications, el cual hace referencia a una extensión de RosettaNet Implementation Framework (RNIF) versión 1.1, con ciertas variaciones de este framework. El adaptador CIDX es usado para enviar mensajes entre el Integration Server y un sistema que cumpla con los estándares CIDX, transformando los mensajes del formato XI hacia el formato CIDX. Para mas información sobre CIDX visita la pagina web http://www.cidx.org/

HTTP: El adaptador HTTP (sencillo) brinda a aplicaciones la opción de comunicarse con el Integration Engine y de intercambiar data de negocio usando una conexión HTTP sencilla. Dependiendo del sistema receptor, mensajes de salida podrían ser mejorados con cierta información.El adaptador HTTP sencillo es parte del Integration Engine y es usado por sistemas externos para conectarse al Integration Engine usando interfaces HTTP nativas (sin envoltura SOAP)

IDoc: El adaptador IDoc (IDoc Adapter), nos va a permitir procesar IDocs (Intermediate Documents) usando el “Integration Engine”. Son soportados los IDocs de los sistemas SAP desde la versión 3.1x en adelante. Un adaptador de tipo IDoc es usado por los sistemas SAP para conectars a una configuración central del “Integration Engine” usando IDocs. Un sistema que tenga un Integration Engine de este tipo es considerado un Integration Server. Sistemas externos tambien pueden hacer uso del adaptador IDoc para conectarse a un Integration Server.

JDBC: El adaptador JDBC te permite conectar una base de datos con el Integration Engine o el PCK. El adaptador convierte el contenido de base de datos a mensajes de tipo XML y viceversa. El contenido de base de datos puede ser leído con cualquier sentencia SQL. Un formato especial de XML es definido para el contenido que proviene del Integration Server o del PCK. Este formato habilita sentencias SQL INSERT, UPDATE, SELECT, DELETE, o stored procedures para que sean procesados. Un mensaje es siempre procesado exactamente en una transacción de base de datos.

JMS: El adaptador JMS (Java Message Service) te permite conectar systemas de mensaje al Integration Engine o al PCK. El adaptador soporta las especificaciones JMS 1.02b y 1.1 (Para más información SAP Note 856346).Una consideración importante para poder usar el adaptador JMS es instalar los driver necesarios. Las librerías JAVA necesarias son específicas por fabricante o terceros. Se debe desplegar las librerías JAVA en el servidor J2EE para que el adaptador JMS pueda acceder las clases JAVA requeridas en tiempo de ejecución.

Mail: El adaptador de tipo Mail permite conectar servidores de correo con el Integration Server o el PCK. El adaptador de correo receptor convierte mensajes XI a e-mails y usa el Simple Mail Transfer Protocol (SMTP) o el Internet Message Access Protocol (IMAP) para transferirlos al servidor de correos. El adaptador de correo emisor usa el Internet Message Access Protocol o el Post Office Protocol Version 3 (POP3) para collectar los mensajes y convertirlos en mensajes XI.Si un servidor de correos se comunica con el adaptador de correos, se puede configurar la seguridad para encriptar/desencriptar y firmar/verificar los mensajes. Aquí, la seguridad de los mensajes esta basado en el estándar de internet S/MIME (Secure Multipurpose Internet Mail Extension).

Marketplace: Se usa el adaptador de tipo Marketplace para conectar el Integration Server al Marketplace. Permite el intercambio de mensajes convirtiendo el mensaje del formato XI al formato MarketSet Markup Language (MML) y viceversa.Como prerrequisito, se tiene que especificar el DDID (Document Destination ID) para el party y service.

RFC: Un adaptador tipo RFC te permite usar las funciones del Integration Engine o del PCK en los existentes escenarios de SAP. Es usado por sistemas SAP para conectarse al Integration Engine o al PCK usando interfaces RFC. Soporta sistemas SAP desde la versión 3.1xEl adaptador de tipo RFC es suministrado por el Adapter Engine y el PCK. El receiver adapter soporta acknowledgments de sistema pero no acknowledgments de tipo aplicación.Los adaptadores RFC soportan Secure Network Communications (SNC).

RNI: El adaptador RNIF soporta la comunicación de datos estándar - RosettaNet Implementation Framework (RNIF) definido por RosettaNet. Este estándar define el protocolo RNIF en sus versiones 1.1 y 2.0. Los adaptadores RNIF 1.1 y 2.0 estan basados en estos protocolos.

SOAP: El adaptador SOAP permite intercambiar mensajes SOAP entre clientes remotos o servidores de servicios web y el Integration Server o PCK. En el adaptador SOAP se puede configurar seguridad para ser usada para firmar/verificar el cuerpo del mensaje SOAP. Adicionalmente, se puede especificar el estándar a ser usado para firmar/verificar el mensaje SOAP.

XI: Este tipo de adaptador (Adaptador XI) nos va a permitir una comunicacion con Proxy. Un adaptador de tipo XI se utiliza para intercambiar mensajes con el “Integration Engine”. Ambos protocolos de mensaje “XI 3.0” y “XI 2.0” son soportados. También puede ser usado para intercambiar mensajes entre PI y el “PCK” (Partner Connectivity Kit). Se le puede aplicar seguridad para “firmar” los mensajes (al enviar) y revisar la firma (al recibirlos). Se puede encriptar y desencriptar el contenido del mensaje.

¿Qué es SAP XI?

Es la plataforma de integración que provee SAP en su Solución SAP Netweaver. El nombre de XI se debe a la palabra inglesa “Exchange Infraestructure” (Infraestructura de intercambio). Actualmente el nombre sufrió una modificación y se denomina Process Integration(SAP PI).

Imagen: Componentes/Productos de SAP Netweaver
Fuente: help.sap.com

Funcionalidad
A continuación, un diagrama de cómo trabaja básicamente SAP XI

Imagen: Escenaro básico en SAP XI
Fuente: SAPXIPERU

Problema: El sistema A utiliza su interfase A (formato del mensaje) para enviar un mensaje a sistema B, sin embargo este espera que el mensaje llegue en el formato B.

Solución: PI tiene registrado el formato A, el formato B, y las reglas de cómo de transformarse de A a B. Cuando llega el mensaje A, XI transforma a un mensaje B e inmediatamente lo envía al sistema B.

Comentarios: El escenario simple que tenemos arriba puede llegar a ser más complejo cuando:

1. El sistema A necesita una confirmación que el mensaje fue transformado correctamente o que el mensaje fue recibido correctamente por el sistema B. (reconocimiento - acknowledgment)
2. Se requiere tener el registro de todos los mensajes.(monitoreo - monitoring)
3. Se requiere guardar centralizadamente el mensaje A y el mensaje B (rastreo- Tracking).
4. El mensaje A quiere enviar el mensaje, además del sistema B, al sistema C condicionalmente.(Lógica de envió – logical routing, ramificación de mensajes – message branching).

Todos estos escenarios enumerados, y otros más, son soportados por SAP XI.

El entorno es capaz de recibir el mensaje en cualquier formato y transformarlo a cualquier otro. Por mencionar unos ejemplos: XML -> TEXTO, ANSI x12 -> XML, HTML – TEXTO, EDIFACT – ANSI X12, PDF -> XML, EXCEL – TEXTO, entre otros.

Es importante recalcar que existen empresas que proveen conversores para estándares utilizados en el mercado, por ejemplo conversores para ANSIX12 y EDIFACT. Aquí tenemos a iWay y Seeburger.

XI, puede recibir y enviar el mensaje usando una variedad de protocolos de comunicación: HTTP, HTTPS, FTP, IDOC, RFC, JMS, FILE, JDBC. Así mismo existen empresas que permiten ampliar esta funcionalidad a: AS1, AS2, SPLIT997, OFTP. (Algunos de los muchos que tenemos en el mercado).


Integración A2A y B2B
SAP XI permite integrar las aplicaciones de una misma empresa (A2A), así mismo posibilita hacer la integración con las aplicaciones de otras empresas (como proveedores, clientes (B2B)).

A2A: Una aplicación de ventas al por menor envía un reporte de consolidación diariamente a una aplicación de finanzas.

B2B: Enviamos a un cliente un factura por concepto del servicio que le hemos prestado.

Los escenarios de integración pueden ser entre:
Sistema SAP – Sistema SAP
Sistema SAP – Sistema No SAP (Viceversa)
Sistema No SAP – Sistema No SAP


Comentarios finales
Con SAP XI, podemos dar fin a la complejidad de las conexiones directas entre sistemas, teniendo así, un entorno centralizado de comunicación. Olvidando el tener que entrar a diferentes sistemas y herramientas para poder monitorear los mensajes. Ahora lo tenemos todo en un solo lugar.

SAP XI, tiene la flexibilidad de poder ampliar su funcionalidad usando la tecnología abierta “Java” a través de librerías, módulos y adaptadores desarrollados a medida.

XI, permite implementar escenarios de tipo BPM, mediante los cuales, los procesos entre aplicaciones se definen de forma centralizada, con una herramienta única.