8.Capítulo 8 - Ejemplos de Escenarios en SAP PI. Diseño y Configuración

8/17/2019 8.Capítulo 8 - Ejemplos de Escenarios en SAP PI. Diseño y Configuración

1/40


2/40

Introducción a la plataforma SAP NetWeaver. Estudio de SAP Process Integration

Proyecto fin de carrera Alberto Naranjo Moruno2


3/40

Cap.8. Ejemplos de escenarios en SAP PI. Diseño y configuración


8.1. ESCENARIO 1. SAP PI leerá un fichero de un directorio lo procesará yrealizará una llamada RFC a un sistema SAP R3 pasándole como parámetroslos valores extraídos del fichero. SAP PI deberá pasar el fichero procesadocorrectamente a un directorio de backup eliminándolo del directorio origen.Gráficamente:

Figura 8.1. Ejemplo gráfico del escenario 1.

Comenzamos con el diseño de los objetos necesarios en el IntegrationRepository. El primer elemento básico a definir es el data type; en nuestro caso

solo deberemos definir el tipo de datos para la lectura del fichero ya que laestructura de datos del lado de SAP está marcada en la RFC que deberemosimportar a SAP PI. Así pues definimos el Data Type para el fichero:

Figura 8.2. Data Type de lectura del fichero.

Como se puede ver la estructura del data type que usaremos para leer elfichero tiene un nivel RECORD (ocurrencia 1) que será el nombre del recordsetutilizado para el content conversion en la configuración del adaptador tipofichero (en el caso de que tengamos conversión del contenido; en este ejemplono usaremos conversión); este nivel debe existir siempre. De él cuelgan lasPOSICIONES (ocurrencia 1…unbounded) que contendrán cada una de laslíneas del fichero. Por debajo tendremos cada uno de los campos quecontendrán la información de cada línea del fichero.

FTP RFCSAPFILE PI


4/40


5/40



la RFC, mandante, usuario y password. Así tendremos en el repositorionuestra interfaz RFC.

Figura 8.5. RFC importada de un sistema SAP.

Con todas las interfaces diseñadas procedemos a definir el mapeo decampos de la estructura fuente (message interface de fichero) a la estructura

destino (RFC), realizando las conversiones que nos exigan.

Figura 8.6. Mapeo de la estructura fichero a la RFC.

Como último objeto a definir en el Repositorio está el Interface Mappingdonde como se sabe indicamos las interfaces fuente y destino y el programa demapeo que acabamos de crear.


6/40



Figura 8.7. Interface Mapping de fichero a RFC.

Con todos los objetos diseñados realizaremos la configuración delescenario en el Integration Directory. Para empezar asignaremos al escenario

que creemos los sistemas o servicios correspondientes, en nuestro ejemplodeberemos tener por un lado el habilitador del fichero con nombreSERVICIO_PFC (Business System) y por otro el sistema SAP en el que seejecuta la RFC con nombre ECDCLNT600 (Business System). En cada uno deellos se creará un canal de comunicaciones.

En el lado el fichero crearemos un canal de comunicaciones Sender tipofichero (File) en el que no usaremos conversión del contenido de los ficherosleídos (con máscara tdpur*.*) y en el que se ejecutará un script de comandosantes del procesado del mensaje.


7/40



Figura 8.8. Canal de comunicaciones fichero sender. Pestaña ‘Source’.

Figura 8.9. Canal de comunicaciones fichero sender. Pestaña ‘Processing ’.

Figura 8.10. Canal de comunicaciones fichero sender. Pestaña ‘ Advanced ’.

En el otro servicio crearemos un canal de comunicaciones Receiver detipo RFC en el que básicamente se especificará el tipo de servidor RFC(normalmente sistema SAP), los datos de la máquina y parámetros de logon.


8/40



Figura 8.11. Canal de comunicaciones RFC receiver. Pestaña ‘Target ’.

Figura 8.12. Canal de comunicaciones RFC receiver. Pestaña ‘ Advanced ’.

El siguiente paso sería la definición de los acuerdos de colaboración o

interlocución. Por un lado crearemos el Sender Agreement dondeespecificamos el servicio sender SERVICIO_PFC y la interfaz sender fichero,asignándole el canal de comunicaciones sender de tipo fichero que hemosdefinido a tal efecto.

Figura 8.13. Sender Agreement con el servidor del fichero.

En cuanto al Receiver Agreement habrá que especificar el sistemasender SERVICIO_PFC y el servicio receiver ECDCLNT100 así como lainterfaz receiver RFC, asignándole su canal de comunicaciones.


9/40



Figura 8.14. Receiver Agreement con el sistema SAP destino.

Por último solo nos quedaría definir los objetos de routing lógicos,determinación de interfaz y de receptor. Comenzamos con el InterfaceDetermination, donde especificamos el servicio e interfaz sender, el servicioreceiver, y en la lista inferior las interfaces receiver cada una con su InterfaceMapping (mapeo) diseñado en el repositorio; en nuestro caso solo tendremosnuestra interfaz receiver RFC.

Figura 8.15. Interface Determination.

Para acabar con el montaje creamos el Receiver Determination dondepara el servicio e interfaz sender SERVICIO_PFC le asignamos el sistemareceptor de una lista, en nuestro caso ECDCLNT100. Si todo está bienmontado, en el recuadro inferior debe aparecer el servicio asignadoECDCLNT100 del que colgarán la interfaz RFC receiver, el interface mapping yel canal de comunicaciones del receiver agreement. Si alguno no aparece o elrecuadro está en rojo es que debe haber ocurrido algún error en la definicióndel objeto: el receiver determination no consigue establecer la lógica del flujode comunicación del escenario.


10/40



Figura 8.16. Receiver Determination.

Si todo está correcto se activarán los canales y se podrá lanzar lainterfase dejando algún fichero en el directorio origen.


11/40



8.2. ESCENARIO 2. Un sistema SAP R3 realizará una llamada RFC síncrona aSAP PI pasándole ciertos parámetros con los que éste deberá llamar a unmétodo de un web service, el cual devuelve cierta información que tendrá queser remitida a SAP R3 en la vuelta de la llamada RFC síncrona. Gráficamente.


Como ya sabemos lo primero a diseñar son los tipos de datosempleados en nuestro escenario. Por el lado del sistema SAP la estructura dedatos está marcada por la RFC diseñada en SAP con lo cual solo tendremosque importárnosla en SAP PI como hemos visto anteriormente y queutilizaremos para crear el resto de objetos.

Figura 8.18. Estructura de la RFC síncrona.

En el otro lado la estructura de datos a emplear estará definida por lapropia estructura del servicio web con el que queremos integrarnos. En estecaso solicitaremos al proveedor del servicio web el fichero .wsdl con laestructura completa del servicio, el cual deberemos importarnos en SAP PI

como un External Definition. Cuando lo tengamos podremos ver todos losmétodos de los que se compone el servicio web, entre ellos el método objetode nuestra integración (en el presente ejemplo será el método deCompruebaProveedor).

sRFC SOAP

Web

ServiceSAP PI


12/40



Figura 8.19. External Definition con los métodos del servicio web.

El Message Interface del lado SAP es la propia RFC pero en el lado delweb service deberemos crearlo. Esta interfaz de mensaje será de tipo inboundya que es una interfaz de entrada en el servicio web y síncrono ya queesperamos la vuelta en la llamada. Debido al sincronismo deberemos indicarun tipo de mensaje de entrada (método del external definition llamante,compruebaProveedorRequest en este ejemplo) y un tipo de mensaje de salida(método del external definition respuesta, compruebaProveedorResponse).

Figura 8.20. Message Interface para la llamada al servicio web.

Una vez definidas las interfases de mensaje presentes en el escenarioprocedemos a la definición de los mapeos. Hay que tener en cuenta que elescenario de integración presentado es síncrono con dos sentidos de lacomunicación, llamada del sistema SAP R3 al web service y vuelta del web


13/40



service a SAP R3. Esto significa que tendremos dos mapeos distintos: elprimero mapeará los campos de la llamada de la RFC en los parámetros delmétodo request del web service y el segundo que mapeará la respuesta delweb service a los campos de vuelta de la RFC.

Figura 8.21. Mapeo de la RFC al web service.

Figura 8.22. Mapeo del web service a la RFC.

Veamos a continuación cómo indicar ambos mapeos en la definición delInterface Mapping. Al crearlo se indicará las interfaces fuente (la propia RFC) y


14/40



destino (el message interface antes creado) y pulsaremos el botón . Automáticamente se reconocerán las interfaces como síncronas y aparecerándos pestañas ‘Request ’ y ‘Response’ en la parte inferior donde indicar losprogramas de mapeo. Seleccionamos la pestaña ‘Request ’ e indicamos elmapeo de RFC a Web Service y en la pestaña ‘Response’ indicamos el mapeoWeb Service a RFC.

Figura 8.23. Inteface Mapping. Pestaña ‘Request ’.

Figura 8.24. Inteface Mapping. Pestaña ‘Response’.

Pasamos a la fase de configuración. Primero de todo asignaremos losservicios o parties al escenario, en nuestro caso serán el sistema

ECDCLNT100 (Business System) para el lado SAP y el servicioWebServiceClient (Business Service) para el lado del Web Service, ycrearemos para cada uno de ellos el canal de comunicaciones asociado. Elservicio WebServiceClient estará presente en cualquier SAP PI y no seránecesario declararlo.

Para el lado SAP definiremos un canal sender de tipo RFC, donde seespecificarán los parámetros de conexión con el servidor de la RFC y los


15/40


16/40



A continuación los acuerdos de interlocución, sender agreementindicando servicio, interfaz y canal sender básicamente.

Figura 8.27. Sender Agreement con sistema SAP.

Y receiver agreement, indicando servicio sender y servicio, interfaz ycanal receiver.

Figura 8.28. Receiver Agreeement con Web Service.

En cuanto a los objetos de routing definimos el Interface Determination,donde asignamos al servicio ECDCLNT100 e interfaz RFC sender cuyo serviciodestino es WebServiceClient la interfaz síncrona definida con su InterfaceMapping.


17/40



Figura 8.29. Interface Determination.

Por último creamos el Receiver Determination donde asignamos elservicio destino WebServiceClient al servicio sender ECDCLNT100. Si todoestá bien definido en el recuadro inferior aparecerá un resumen con interfaz,mapeo y canal de comunicaciones receptores asignados.

Figura 8.30. Receiver Determination.


18/40




19/40



8.3. ESCENARIO 3. Desde un Web Service (un portal) se llamará a SAP PIque desencadenará todo el proceso. Primero de todo PI actualizará una basede datos indicando en una tabla de control un valor para un campo status(indicando ‘en proceso’). Acto seguido se llamará a un sistema SAP R3 dondese invocará a una RFC síncrona con los datos pasados en el servicio web. Lainformación que devuelva la RFC será trasladada a la base de datos donde se

actualizarán dos tablas (realizando un borrado del registro y un inserción delnuevo registro), a la vez que se actualiza la tabla de control con otro valor parael campo status (indicando ‘realizado’). Gráficamente:


Vemos en este ejemplo una mayor complejidad; tenemos tres sistemas oservicios involucrados, Web Service, base de datos Oracle y sistema SAP. Además en uno de ellos (base de datos) se realizan dos llamadas diferentes.Cualquiera de estas dos particularidades del escenario conduce a la necesariadefinición de un Integration Process o BPM. Tengamos en cuenta que elnúmero de objetos a diseñar aquí es mucho mayor ya que ahora ademásentran en juego las interfaces abstractas para el BPM. Vayamos paso a paso.

Comenzamos con la definición de los tipos de datos. Crearemos elelemento de datos del web service; este caso es inverso al escenario anterior.Nosotros definiremos la llamada (tipo de mensaje) que deberá realizar el webservice y posteriormente generaremos el fichero .wsdl que enviaremos alproveedor para que implemente la llamada desde el web service (portal) a SAPPI. La llamada deberá tener los siguientes campos:

Figura 8.32. Data Type SOAP para el servicio web.

JDBC 1º sRFCSAP

BBDD

PI

WebService

Web

JDBC 2º


20/40



El siguiente tipo de datos será el necesario para realizar la primerallamada a la base de datos. Como vimos en secciones anteriores, cuandotengamos que manejar bases de datos el tipo de datos del mensaje deberátener la siguiente estructura necesariamente, con los niveles TABLENAME, ACTION, TABLE, ACCESS, KEY (opcional, solo para modificaciones) tal cualestán en la siguiente pantalla.

Figura 8.33. Data Type JDBC para la base de datos (1ª acción).

A continuación tendríamos la llamada a la RFC cuya estructura seimportará del sistema SAP en el que se encuentre, como ya hemos visto enescenarios anteriores. El último elemento de datos sería aquél que realice lasegunda actualización a la base de datos, borrando e insertando los registrosen dos tablas diferentes y finalmente modificando el estatus de la tabla de

control. Dicho tipo de datos debería tener una estructura como la siguiente (nose ha desplegado el nivel de ACCESS para visualizar el tipo de datos alcompleto; este nivel contiene toda la estructura de la tabla de la base de datosa actualizar).


21/40



Figura 8.34. Data Type JDBC para la base de datos (2ª acción).

De manera automática definimos todos los messages types basados enestos tipos de datos.

Figura 8.35. Message Type tipo SOAP para el servicio web.


22/40



Figura 8.36. Message Type JDBC para la base de datos (1ª acción).

Figura 8.37. Message Type JDBC para la base de datos (2ª acción).

Para cada tipo de mensaje definiremos los Message Interfaces,asignándoles el sentido de la interfaz y su categoría de sincronismo. En primerlugar tendremos la interfaz de mensaje de la llamada SOAP del web service;ésta es una interfaz outbound del servicio web y asíncrona. La primeraactualización a la base de datos es una interfaz inbound y asíncrona. Después


23/40



tendrías la propia RFC que es síncrona por definición y por último la segundaactualización a base de datos, inbound y asíncrona.

Figura 8.38. Message Inteface SOAP para el servicio web.

Figura 8.39. Message Interface JDBC para la base de datos (1ª acción).


24/40



.Figura 8.40. RFC síncrona.

Figura 8.41. Message Inteface JDBC para la base de datos (2ª acción).

En este punto vamos a definir los Messages Interface abstractos, quecomo se saben son las que utilizaremos dentro del BPM. Para saber quéinterfaces debemos crear imaginemos que el BPM es una caja negra en la queentran y sales interfaces (éstas serán las interfaces reales, en este ejemploserán la llamada del web service, la RFC y las llamadas a la base de datos).Todos los pasos que se desarrollen dentro del BPM tendrán que ir apoyadas eninterfaces abstractas. Analicemos el flujo: primero es necesario definir unainterfaz abstracta para recibir el mensaje SOAP asíncrono en el BPM, por tantoserá una interfaz abstracta asíncrona y con tipo de mensaje el SOAP de la


25/40



figura 8.35 (en el nombre que le asignamos es habitual poner la terminación“_AI” para reconocerla como Abstract Interface).

Figura 8.42. Interfaz abstracta tipo SOAP.

Segundo, esta interfaz dentro del BPM dará paso a la interfaz de

actualización del estatus en la base de datos. Por tanto nueva interfazabstracta y asíncrona y de tipo de mensaje JDBC:

Figura 8.43. Interfaz abstracta tipo JDBC para la base de datos.

A continuación tenemos la llamada RFC, con lo cual debemos crear unainterfaz abstracta y síncrona. El tipo de mensaje que llama a esta interfaz es elpropio web service y la respuesta va al tipo de mensaje que actualiza la basede datos.


26/40



Figura 8.44. Interfaz abstracta RFC síncrona.

Y finalmente la última llamada a base de datos que será asíncrona y detipo de mensaje JDBC.

Figura 8.45. Interfaz abstracta tipo JDBC para la base de datos.

Posteriormente en la definición del Integration Process se verá en quelugar y cómo se utilizarán estas interfases abstractas. Continuamos con el flujonormal del diseño y ahora sería el turno de los mapeos y que en este escenariotienen lugar dentro del BPM.

El primer mapeo que nos encontramos sería unir los parámetros del webservice a los campos de la estructura de actualización del estatus en la base dedatos. Seleccionamos ambos tipos de mensajes y mapeamos.


27/40



Figura 8.46. Mapeo del web service a la base de datos (1ª acción).

El siguiente mapeo consiste en el paso de los parámetros del webservice a la llamada RFC request. La respuesta de la RFC (es síncrona) exigeotro mapeo para pasar esa información de respuesta al tipo de mensaje que

actualizará la base de datos.


28/40



Figura 8.47. Mapeo del web service a la llamada RFC.

Figura 8.48. Mapeo de la respuesta RFC a la base de datos (2ª acción).


29/40



Ahora creamos los Interfaces Mapping que igualmente estarán dentrodel BPM (con lo cual aparecerán interfaces abstractas). Uno definirá la interfazfuente SOAP abstracta del web service con la interfaz destino JDBC deactualización del estatus con el mapeo que acabamos de definir. El segundo yúltimo define la interfaz abstracta síncrona (con el tipo de datos SOAP para lallamada y JDBC de actualizacion a base de datos en la respuesta) con la RFC

al sistema SAP. En este interface mapping estamos jugando con interfacessíncronas con lo cual debemos especificar los dos mapeos existentes uno paracada sentido, Request y Response.

Figura 8.49. Interface Mapping del web service a base de datos (1ª acción).


30/40



Figura 8.50. Interface Mapping de web service a RFC. Pestaña ‘Request ’.

Figura 8.51. Interface Mapping de web service a RFC. Pestaña ‘Response’.

Una vez declarados todos los objetos necesarios procedemos al montaje

o diseño de nuestro BPM o Integration Process. En el editor gráfico iremosañadiendo los elementos necesarios para completar el flujo de mensajes segúnnuestro escenario. En primer lugar nos vamos a encontrar con un elemento ostep (paso) ‘Receiver’ (recepción del web service en el BPM); lo seleccionamosde la lista de la izquierda del editor gráfico y arrastramos al dibujo. Acontinuación debemos completar su cuadro de propiedades o atributos. Esteelemento receiver tiene el contenedor de mensaje tipo SOAP, asíncrono ymarcado el flag de “Start Process” (comenzar proceso). El segundo elementoes un ‘Sender’ asíncrono (envío de actualización estatus a base de datos);


31/40



igualmente seleccionamos y arrastramos tras el ‘Receiver’ anterior. En sucuadro de propiedades tendremos modo asíncrono, mensaje contenedor tipoJDBC Status y marcado el flag de “Create New Transaction” (este flag semarca para que el BPM continue la ejecución sin esperar que termine laacción). Siguiente elemento del BPM es un ‘Sender’ síncrono (llamada RFC)con propiedades de modo síncrono obviamente, mensaje contenedor de la

llamada tipo SOAP (llama el web service) y mensaje contenedor de larespuesta tipo JDBC (de actualización de las tablas de la base de datos). Porúltimo otro elemento ‘Sender’ asíncrono con mensaje contenedor tipo JDBCpara la carga de los datos. Veamos todo gráficamente.

Figura 8.52. Integration Process.

Figura 8.53. Cuadro de atributos de los elementos senders del BPM.


32/40



Con la creación del Integration Process finaliza la fase de diseño deobjetos en el Integration Repository. A continuación procedemos a su montajeen la etapa de configuración. Como novedad en esta fase destacar que elIntegration Process o BPM va a ser visto en el Integration Directory como unservicio más, el cual deberemos importar del repositorio. Veamos.

Para empezar asignamos al escenario los sistemas o serviciospresentes y que nos traeremos del SLD. Serán los siguientes:WebServiceClient, como su propio nombre indica para el servicio web,SERVICIO_PFC será la base de datos externa y ECDCLNT100 será el sistemaSAP R3. Éstos van a ser los sistemas o servicios físicos presentes en nuestroescenario. Sin embargo, como acabamos de comentar el BPM es visto en lafase de configuración como un servicio en sí mismo y que importaremos delRepositorio asignándole el nombre de IP_TesoreriaSAP_ID, y que usaremospara la definición del resto de objetos de esta fase de configuración.

Para cada uno de los sistemas externos se definen los canales decomunicaciones involucrados; en principio habrá tres, uno tipo SOAP, un JDBC

(dos llamadas) y otro RFC. Sin embargo a la hora de detectar errores en losmensajes o fallos en los canales es recomendable definir dos canales JDBC,uno para cada llamada. Así pues, el SOAP será Sender y se especificará nivelde seguridad HTTP (normal) indicando la interfaz del mensaje como sigue:

Figura 8.54. Canal de comunicaciones SOAP sender.

En cuanto a los dos JDBC, se especificará el driver para base de datosOracle instalado y los parámetros de conexión con la base de datos incluyendousuario y password. En la pestaña ‘ Advanced ’ se indicará otra serie deparámetros (recomendables).


33/40


34/40



Por último tedremos el RFC Receiver donde se indicarán los parámetrosde conexión del sistema SAP con el que nos queremos conectar.

Figura 8.58. Canal de comunicaciones RFC receiver.

Una vez creados los canales procedemos a definir los Collaboration Agreement. Para los sistemas sender solo existe uno, el del web service con sucanal de comunicaciones tipo SOAP.

Figura 8.59. Sender Agreement con el servicio web.

Para los sistemas o servicios receptores tendremos tres: dos Receiver Agreement con la base de datos (servicio receptor SERVICIO_PFC) y uno conel sistema SAP R3 (servicio receptor ECDCLNT100), en los que hay queindicar sus respectivos canales e interfaces receptoras. Al crear los acuerdostambién hay que especificar el servicio sender para cada uno de ellos, que seráel BPM o Integration Process importado.


35/40



Figura 8.60. Receiver Agreement con base de datos (1ª acción).

Figura 8.61. Receiver Agreement con sistema SAP.

Figura 8.62. Receiver Agreement con base de datos (2ª acción).


36/40



A continuación definimos los acuerdos de routing lógicos que podríanresultar algo más complejos de entender, aunque si tenemos siempre en menteel esquema global del escenario nos facilitará la comprensión.

Partimos de nuestra interfaz del web service que “entra” en el BPM; portanto nuestro primer Interface Determination va de la interfaz del web service a

la misma interfaz pero abstracta del BPM sin mapeo ninguno (es el mismo tipode mensaje con lo que la asignación es directa).

Figura 8.63. Interface Determination del web service a BPM.

Seguidamente esta interfaz abstracta tipo SOAP pasa a la interfaz deactualización del estatus de la base de datos con su correspondiente mapeo(Interface Mapping).

Figura 8.64. Interface Determination del BPM a base de datos (1ª acción).

Después la interfaz abstracta síncrona del BPM llamará a la RFC,indicando igualmente su interface mapping, que si recordamos involucra dosmapeos ya que estamos ante interfaces síncronas.


37/40



Figura 8.65. Interface Determination del BPM a la RFC.

Por último la interfaz abstracta JDBC que actualiza las tablas de la basede datos de dentro del BPM se asignará directamente a la interfaz del mismotipo pero real, sin necesidad de mapeos.

Figura 8.66. Interface Determination del BPM a base de datos (2ª acción).

Para terminar nos queda determinar los receptores, ReceiverDetermination. Primero, al servicio WebServiceClient e interfaz tipo SOAP leasignamos el servicio receptor BPM. Automáticamente aparece en el recuadroinferior la determinación de interfaz, donde no incluye ni mapeo ni canal.


38/40


39/40



Figura 8.69. Receiver Determination para el BPM: sistema SAP.

Y finalmente al servicio BPM e interfaz abstracta tipo JDBC con laactualización a las tablas de la base de datos le asignamos de nuevo elreceptor de base de datos, donde la asignación de interfaces es directa sinmapeos.

Figura 8.70. Receiver Determination para el BPM: base de datos (2ª acción).


40/40


Con todo queda montado todo nuestro escenario que iremos ejecutandoy chequeando hasta comprobar el correcto funcionamiento del mismo.

En la siguiente sección realizaremos una pequeña introducción al áreade monitorización del SAP PI conocido como Runtime Workbench o área detrabajo en tiempo de ejecución. Allí podremos comprobar el estado de losmensajes, de los canales, e incluso configurar alertas, encaminado al correctofuncionamiento de nuestros escenarios.

8.Capítulo 8 - Ejemplos de Escenarios en SAP PI. Diseño y Configuración

Documents

Transcript of 8.Capítulo 8 - Ejemplos de Escenarios en SAP PI. Diseño y Configuración