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

Introduccin a la plataforma SAP NetWeaver.
Estudio de SAP Process Integration
CAPTULO 8
EJEMPLOS DE ESCENARIOS EN SAP PI.
DISEO Y CONFIGURACIN.
Una vez presentados todos los objetos que podramos encontrar en un

escenario de integracin de una forma terica, realizaremos a continuacin
diferentes ejemplos de situaciones reales muy habituales en cualquier montaje
de SAP PI.
Proyecto fin de carrera
Alberto Naranjo Moruno
Introduccin a la plataforma SAP NetWeaver. Estudio de SAP Process Integration
Cap.8. Ejemplos de escenarios en SAP PI. Diseo y configuracin

8.1. ESCENARIO 1. SAP PI leer un fichero de un directorio lo procesar y
realizar una llamada RFC a un sistema SAP R3 pasndole como parmetros
los valores extrados del fichero. SAP PI deber pasar el fichero procesado
correctamente a un directorio de backup eliminndolo del directorio origen.
Grficamente:
PI
FILE
FTP
SAP
RFC
Figura 8.1. Ejemplo grfico del escenario 1.
Comenzamos con el diseo de los objetos necesarios en el Integration

Repository. El primer elemento bsico a definir es el data type; en nuestro caso
solo deberemos definir el tipo de datos para la lectura del fichero ya que la
estructura de datos del lado de SAP est marcada en la RFC que deberemos
importar 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 el
fichero tiene un nivel RECORD (ocurrencia 1) que ser el nombre del recordset
utilizado para el content conversion en la configuracin del adaptador tipo
fichero (en el caso de que tengamos conversin del contenido; en este ejemplo
no usaremos conversin); este nivel debe existir siempre. De l cuelgan las
POSICIONES (ocurrencia 1unbounded) que contendrn cada una de las
lneas del fichero. Por debajo tendremos cada uno de los campos que
contendrn la informacin de cada lnea del fichero.
A continuacin definimos el Message Type asociado.
Figura 8.3. Message Type para leer de fichero.
Por ltimo dentro de los objetos de interfaz hay que definir el Message
Interface. En este caso solo hay que definir la de lado fichero ya que el otro
extremo est marcado por la RFC. Esta interfaz ser una interfaz Outbound ya
que es de salida del sistema externo (servidor de fichero o directorio de lectura)
y Asncrona porque la comunicacin ser en un solo sentido. Con todo,
creamos el message interface siguiente:
Figura 8.4. Message Interface para lectura de fichero.
El siguiente paso sera importarnos la RFC que nos indiquen para

montar el escenario. Para ello seguiremos lo pasos que definimos,
completando la IP del servidor del sistema SAP donde se encuentra declarada

la RFC, mandante, usuario y password. As
nuestra interfaz RFC.
tendremos en el repositorio
Figura 8.5. RFC importada de un sistema SAP.
Con todas las interfaces diseadas procedemos a definir el mapeo de

campos 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 Mapping

donde como se sabe indicamos las interfaces fuente y destino y el programa de
mapeo que acabamos de crear.
Figura 8.7. Interface Mapping de fichero a RFC.
Con todos los objetos diseados realizaremos la configuracin del

escenario en el Integration Directory. Para empezar asignaremos al escenario
que creemos los sistemas o servicios correspondientes, en nuestro ejemplo
deberemos tener por un lado el habilitador del fichero con nombre
SERVICIO_PFC (Business System) y por otro el sistema SAP en el que se
ejecuta la RFC con nombre ECDCLNT600 (Business System). En cada uno de
ellos se crear un canal de comunicaciones.
En el lado el fichero crearemos un canal de comunicaciones Sender tipo
fichero (File) en el que no usaremos conversin del contenido de los ficheros
ledos (con mscara tdpur*.*) y en el que se ejecutar un script de comandos
antes del procesado del mensaje.
Figura 8.8. Canal de comunicaciones fichero sender. Pestaa Source.
Figura 8.9. Canal de comunicaciones fichero sender. Pestaa Processing.
Figura 8.10. Canal de comunicaciones fichero sender. Pestaa Advanced.
En el otro servicio crearemos un canal de comunicaciones Receiver de

tipo RFC en el que bsicamente se especificar el tipo de servidor RFC
(normalmente sistema SAP), los datos de la mquina y parmetros de logon.
Figura 8.11. Canal de comunicaciones RFC receiver. Pestaa Target.
Figura 8.12. Canal de comunicaciones RFC receiver. Pestaa Advanced.
El siguiente paso sera la definicin de los acuerdos de colaboracin o

interlocucin. Por un lado crearemos el Sender Agreement donde
especificamos el servicio sender SERVICIO_PFC y la interfaz sender fichero,
asignndole el canal de comunicaciones sender de tipo fichero que hemos
definido a tal efecto.
Figura 8.13. Sender Agreement con el servidor del fichero.
En cuanto al Receiver Agreement habr que especificar el sistema

sender SERVICIO_PFC y el servicio receiver ECDCLNT100 as como la
interfaz receiver RFC, asignndole su canal de comunicaciones.
Figura 8.14. Receiver Agreement con el sistema SAP destino.
Por ltimo solo nos quedara definir los objetos de routing lgicos,
determinacin de interfaz y de receptor. Comenzamos con el Interface
Determination, donde especificamos el servicio e interfaz sender, el servicio
receiver, y en la lista inferior las interfaces receiver cada una con su Interface
Mapping (mapeo) diseado en el repositorio; en nuestro caso solo tendremos
nuestra interfaz receiver RFC.
Figura 8.15. Interface Determination.
Para acabar con el montaje creamos el Receiver Determination donde

para el servicio e interfaz sender SERVICIO_PFC le asignamos el sistema
receptor de una lista, en nuestro caso ECDCLNT100. Si todo est bien
montado, en el recuadro inferior debe aparecer el servicio asignado
ECDCLNT100 del que colgarn la interfaz RFC receiver, el interface mapping y
el canal de comunicaciones del receiver agreement. Si alguno no aparece o el
recuadro est en rojo es que debe haber ocurrido algn error en la definicin
del objeto: el receiver determination no consigue establecer la lgica del flujo
de comunicacin del escenario.
Figura 8.16. Receiver Determination.
Si todo est correcto se activarn los canales y se podr lanzar la

interfase dejando algn fichero en el directorio origen.
10

8.2. ESCENARIO 2. Un sistema SAP R3 realizar una llamada RFC sncrona a
SAP PI pasndole ciertos parmetros con los que ste deber llamar a un
mtodo de un web service, el cual devuelve cierta informacin que tendr que
ser remitida a SAP R3 en la vuelta de la llamada RFC sncrona. Grficamente.
Web
Service
PI
SAP
sRFC
SOAP
Como ya sabemos lo primero a disear son los tipos de datos

empleados en nuestro escenario. Por el lado del sistema SAP la estructura de
datos est marcada por la RFC diseada en SAP con lo cual solo tendremos
que importrnosla en SAP PI como hemos visto anteriormente y que
utilizaremos para crear el resto de objetos.
Figura 8.18. Estructura de la RFC sncrona.
En el otro lado la estructura de datos a emplear estar definida por la

propia estructura del servicio web con el que queremos integrarnos. En este
caso solicitaremos al proveedor del servicio web el fichero .wsdl con la
estructura completa del servicio, el cual deberemos importarnos en SAP PI
como un External Definition. Cuando lo tengamos podremos ver todos los
mtodos de los que se compone el servicio web, entre ellos el mtodo objeto
de nuestra integracin (en el presente ejemplo ser el mtodo de
CompruebaProveedor).
11
Figura 8.19. External Definition con los mtodos del servicio web.
El Message Interface del lado SAP es la propia RFC pero en el lado del
web service deberemos crearlo. Esta interfaz de mensaje ser de tipo inbound
ya que es una interfaz de entrada en el servicio web y sncrono ya que
esperamos la vuelta en la llamada. Debido al sincronismo deberemos indicar
un tipo de mensaje de entrada (mtodo del external definition llamante,
compruebaProveedorRequest en este ejemplo) y un tipo de mensaje de salida
(mtodo 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 escenario

procedemos a la definicin de los mapeos. Hay que tener en cuenta que el
escenario de integracin presentado es sncrono con dos sentidos de la
comunicacin, llamada del sistema SAP R3 al web service y vuelta del web
12

service a SAP R3. Esto significa que tendremos dos mapeos distintos: el
primero mapear los campos de la llamada de la RFC en los parmetros del
mtodo request del web service y el segundo que mapear la respuesta del
web 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 continuacin cmo indicar ambos mapeos en la definicin del

Interface Mapping. Al crearlo se indicar las interfaces fuente (la propia RFC) y
13
destino (el message interface antes creado) y pulsaremos el botn

.
Automticamente se reconocern las interfaces como sncronas y aparecern
dos pestaas Request y Response en la parte inferior donde indicar los
programas de mapeo. Seleccionamos la pestaa Request e indicamos el
mapeo de RFC a Web Service y en la pestaa Response indicamos el mapeo
Web Service a RFC.
Figura 8.23. Inteface Mapping. Pestaa Request.
Figura 8.24. Inteface Mapping. Pestaa Response.
Pasamos a la fase de configuracin. Primero de todo asignaremos los

servicios o parties al escenario, en nuestro caso sern el sistema
ECDCLNT100 (Business System) para el lado SAP y el servicio
WebServiceClient (Business Service) para el lado del Web Service, y
crearemos para cada uno de ellos el canal de comunicaciones asociado. El
servicio WebServiceClient estar presente en cualquier SAP PI y no ser
necesario declararlo.
Para el lado SAP definiremos un canal sender de tipo RFC, donde se
especificarn los parmetros de conexin con el servidor de la RFC y los
14

parmetros de conexin con el servidor donde se encuentra el repositorio con
el metadata de la RFC (ambos sern los mismos casi siempre).
Figura 8.25. Canal de comunicaciones RFC sender.
En el lado del Web Service se definir un canal receiver de tipo SOAP

donde se especificar la URL completa del servicio.
Figura 8.26. Canal de comunicaciones SOAP receiver.
15
A continuacin los acuerdos de interlocucin, sender agreement

indicando servicio, interfaz y canal sender bsicamente.
Figura 8.27. Sender Agreement con sistema SAP.
Y receiver agreement, indicando servicio sender y servicio, interfaz y

canal 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 servicio
destino es WebServiceClient la interfaz sncrona definida con su Interface
Mapping.
16
Figura 8.29. Interface Determination.
Por ltimo creamos el Receiver Determination donde asignamos el

servicio destino WebServiceClient al servicio sender ECDCLNT100. Si todo
est bien definido en el recuadro inferior aparecer un resumen con interfaz,
mapeo y canal de comunicaciones receptores asignados.
Figura 8.30. Receiver Determination.
17
18

8.3. ESCENARIO 3. Desde un Web Service (un portal) se llamar a SAP PI
que desencadenar todo el proceso. Primero de todo PI actualizar una base
de 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 donde
se invocar a una RFC sncrona con los datos pasados en el servicio web. La
informacin que devuelva la RFC ser trasladada a la base de datos donde se
actualizarn dos tablas (realizando un borrado del registro y un insercin del
nuevo registro), a la vez que se actualiza la tabla de control con otro valor para
el campo status (indicando realizado). Grficamente:
Web
WebService
PI
JDBC 1
BBDD
SAP
sRFC
JDBC 2
Vemos en este ejemplo una mayor complejidad; tenemos tres sistemas o

servicios involucrados, Web Service, base de datos Oracle y sistema SAP.
Adems en uno de ellos (base de datos) se realizan dos llamadas diferentes.
Cualquiera de estas dos particularidades del escenario conduce a la necesaria
definicin de un Integration Process o BPM. Tengamos en cuenta que el
nmero de objetos a disear aqu es mucho mayor ya que ahora adems
entran en juego las interfaces abstractas para el BPM. Vayamos paso a paso.
Comenzamos con la definicin de los tipos de datos. Crearemos el
elemento de datos del web service; este caso es inverso al escenario anterior.
Nosotros definiremos la llamada (tipo de mensaje) que deber realizar el web
service y posteriormente generaremos el fichero .wsdl que enviaremos al
proveedor para que implemente la llamada desde el web service (portal) a SAP
PI. La llamada deber tener los siguientes campos:
Figura 8.32. Data Type SOAP para el servicio web.
19
El siguiente tipo de datos ser el necesario para realizar la primera

llamada a la base de datos. Como vimos en secciones anteriores, cuando
tengamos 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 cual
estn en la siguiente pantalla.
Figura 8.33. Data Type JDBC para la base de datos (1 accin).
A continuacin tendramos la llamada a la RFC cuya estructura se

importar del sistema SAP en el que se encuentre, como ya hemos visto en
escenarios anteriores. El ltimo elemento de datos sera aqul que realice la
segunda actualizacin a la base de datos, borrando e insertando los registros
en dos tablas diferentes y finalmente modificando el estatus de la tabla de
control. Dicho tipo de datos debera tener una estructura como la siguiente (no
se ha desplegado el nivel de ACCESS para visualizar el tipo de datos al
completo; este nivel contiene toda la estructura de la tabla de la base de datos
a actualizar).
20
Figura 8.34. Data Type JDBC para la base de datos (2 accin).
De manera automtica definimos todos los messages types basados en

estos tipos de datos.
Figura 8.35. Message Type tipo SOAP para el servicio web.
21
Figura 8.36. Message Type JDBC para la base de datos (1 accin).
Figura 8.37. Message Type JDBC para la base de datos (2 accin).
Para cada tipo de mensaje definiremos los Message Interfaces,

asignndoles el sentido de la interfaz y su categora de sincronismo. En primer
lugar tendremos la interfaz de mensaje de la llamada SOAP del web service;
sta es una interfaz outbound del servicio web y asncrona. La primera
actualizacin a la base de datos es una interfaz inbound y asncrona. Despus
22

tendras la propia RFC que es sncrona por definicin y por ltimo la segunda
actualizacin a base de datos, inbound y asncrona.
Figura 8.38. Message Inteface SOAP para el servicio web.
Figura 8.39. Message Interface JDBC para la base de datos (1 accin).
23
.
Figura 8.40. RFC sncrona.
Figura 8.41. Message Inteface JDBC para la base de datos (2 accin).
En este punto vamos a definir los Messages Interface abstractos, que

como 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 que
entran y sales interfaces (stas sern las interfaces reales, en este ejemplo
sern la llamada del web service, la RFC y las llamadas a la base de datos).
Todos los pasos que se desarrollen dentro del BPM tendrn que ir apoyadas en
interfaces abstractas. Analicemos el flujo: primero es necesario definir una
interfaz abstracta para recibir el mensaje SOAP asncrono en el BPM, por tanto
ser una interfaz abstracta asncrona y con tipo de mensaje el SOAP de la
24

figura 8.35 (en el nombre que le asignamos es habitual poner la terminacin
_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

actualizacin del estatus en la base de datos. Por tanto nueva interfaz
abstracta y asncrona y de tipo de mensaje JDBC:
Figura 8.43. Interfaz abstracta tipo JDBC para la base de datos.
A continuacin tenemos la llamada RFC, con lo cual debemos crear una

interfaz abstracta y sncrona. El tipo de mensaje que llama a esta interfaz es el
propio web service y la respuesta va al tipo de mensaje que actualiza la base
de datos.
25
Figura 8.44. Interfaz abstracta RFC sncrona.
Y finalmente la ltima llamada a base de datos que ser asncrona y de

tipo de mensaje JDBC.
Figura 8.45. Interfaz abstracta tipo JDBC para la base de datos.
Posteriormente en la definicin del Integration Process se ver en que

lugar y cmo se utilizarn estas interfases abstractas. Continuamos con el flujo
normal del diseo y ahora sera el turno de los mapeos y que en este escenario
tienen lugar dentro del BPM.
El primer mapeo que nos encontramos sera unir los parmetros del web
service a los campos de la estructura de actualizacin del estatus en la base de
datos. Seleccionamos ambos tipos de mensajes y mapeamos.
26
Figura 8.46. Mapeo del web service a la base de datos (1 accin).
El siguiente mapeo consiste en el paso de los parmetros del web

service a la llamada RFC request. La respuesta de la RFC (es sncrona) exige
otro mapeo para pasar esa informacin de respuesta al tipo de mensaje que
actualizar la base de datos.
27
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 accin).
28

Ahora creamos los Interfaces Mapping que igualmente estarn dentro
del BPM (con lo cual aparecern interfaces abstractas). Uno definir la interfaz
fuente SOAP abstracta del web service con la interfaz destino JDBC de
actualizacin del estatus con el mapeo que acabamos de definir. El segundo y
ltimo define la interfaz abstracta sncrona (con el tipo de datos SOAP para la
llamada y JDBC de actualizacion a base de datos en la respuesta) con la RFC
al sistema SAP. En este interface mapping estamos jugando con interfaces
sncronas con lo cual debemos especificar los dos mapeos existentes uno para
cada sentido, Request y Response.
Figura 8.49. Interface Mapping del web service a base de datos (1 accin).
29
Figura 8.50. Interface Mapping de web service a RFC. Pestaa Request.
Figura 8.51. Interface Mapping de web service a RFC. Pestaa Response.
Una vez declarados todos los objetos necesarios procedemos al montaje

o diseo de nuestro BPM o Integration Process. En el editor grfico iremos
aadiendo los elementos necesarios para completar el flujo de mensajes segn
nuestro escenario. En primer lugar nos vamos a encontrar con un elemento o
step (paso) Receiver (recepcin del web service en el BPM); lo seleccionamos
de la lista de la izquierda del editor grfico y arrastramos al dibujo. A
continuacin debemos completar su cuadro de propiedades o atributos. Este
elemento receiver tiene el contenedor de mensaje tipo SOAP, asncrono y
marcado el flag de Start Process (comenzar proceso). El segundo elemento
es un Sender asncrono (envo de actualizacin estatus a base de datos);
30

igualmente seleccionamos y arrastramos tras el Receiver anterior. En su
cuadro de propiedades tendremos modo asncrono, mensaje contenedor tipo
JDBC Status y marcado el flag de Create New Transaction (este flag se
marca para que el BPM continue la ejecucin sin esperar que termine la
accin). Siguiente elemento del BPM es un Sender sncrono (llamada RFC)
con propiedades de modo sncrono obviamente, mensaje contenedor de la
llamada tipo SOAP (llama el web service) y mensaje contenedor de la
respuesta tipo JDBC (de actualizacin de las tablas de la base de datos). Por
ltimo otro elemento Sender asncrono con mensaje contenedor tipo JDBC
para la carga de los datos. Veamos todo grficamente.
Figura 8.52. Integration Process.
Figura 8.53. Cuadro de atributos de los elementos senders del BPM.
31
Con la creacin del Integration Process finaliza la fase de diseo de

objetos en el Integration Repository. A continuacin procedemos a su montaje
en la etapa de configuracin. Como novedad en esta fase destacar que el
Integration Process o BPM va a ser visto en el Integration Directory como un
servicio ms, el cual deberemos importar del repositorio. Veamos.
Para empezar asignamos al escenario los sistemas o servicios
presentes y que nos traeremos del SLD. Sern los siguientes:
WebServiceClient, como su propio nombre indica para el servicio web,
SERVICIO_PFC ser la base de datos externa y ECDCLNT100 ser el sistema
SAP R3. stos van a ser los sistemas o servicios fsicos presentes en nuestro
escenario. Sin embargo, como acabamos de comentar el BPM es visto en la
fase de configuracin como un servicio en s mismo y que importaremos del
Repositorio asignndole el nombre de IP_TesoreriaSAP_ID, y que usaremos
para la definicin del resto de objetos de esta fase de configuracin.
Para cada uno de los sistemas externos se definen los canales de
comunicaciones involucrados; en principio habr tres, uno tipo SOAP, un JDBC
(dos llamadas) y otro RFC. Sin embargo a la hora de detectar errores en los
mensajes o fallos en los canales es recomendable definir dos canales JDBC,
uno para cada llamada. As pues, el SOAP ser Sender y se especificar nivel
de 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 datos

Oracle instalado y los parmetros de conexin con la base de datos incluyendo
usuario y password. En la pestaa Advanced se indicar otra serie de
parmetros (recomendables).
32
Figura 8.55. Canal de comunicaciones JDBC receiver (1 accin).

Pestaa Connection.
Figura 8.56. Canal de comunicaciones JDBC receiver (2 accin).

Pestaa Connection.
Figura 8.57. Canal de comunicaciones JDBC receiver.

Pestaa Advanced.
33
Por ltimo tedremos el RFC Receiver donde se indicarn los parmetros

de conexin 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 su
canal 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 con
el sistema SAP R3 (servicio receptor ECDCLNT100), en los que hay que
indicar sus respectivos canales e interfaces receptoras. Al crear los acuerdos
tambin hay que especificar el servicio sender para cada uno de ellos, que ser
el BPM o Integration Process importado.
34
Figura 8.60. Receiver Agreement con base de datos (1 accin).
Figura 8.61. Receiver Agreement con sistema SAP.
Figura 8.62. Receiver Agreement con base de datos (2 accin).
35
A continuacin definimos los acuerdos de routing lgicos que podran

resultar algo ms complejos de entender, aunque si tenemos siempre en mente
el esquema global del escenario nos facilitar la comprensin.
Partimos de nuestra interfaz del web service que entra en el BPM; por
tanto 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 tipo
de mensaje con lo que la asignacin es directa).
Figura 8.63. Interface Determination del web service a BPM.
Seguidamente esta interfaz abstracta tipo SOAP pasa a la interfaz de

actualizacin 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 accin).
Despus la interfaz abstracta sncrona del BPM llamar a la RFC,

indicando igualmente su interface mapping, que si recordamos involucra dos
mapeos ya que estamos ante interfaces sncronas.
36
Figura 8.65. Interface Determination del BPM a la RFC.
Por ltimo la interfaz abstracta JDBC que actualiza las tablas de la base
de datos de dentro del BPM se asignar directamente a la interfaz del mismo
tipo pero real, sin necesidad de mapeos.
Figura 8.66. Interface Determination del BPM a base de datos (2 accin).
Para terminar nos queda determinar los receptores, Receiver

Determination. Primero, al servicio WebServiceClient e interfaz tipo SOAP le
asignamos el servicio receptor BPM. Automticamente aparece en el recuadro
inferior la determinacin de interfaz, donde no incluye ni mapeo ni canal.
37
Figura 8.67. Receiver Determination para el web service: BPM.
Despus al servicio del BPM e interfaz abstracta tipo SOAP le

asignamos el receptor de la base de datos (actualizacin de estatus). Aqu si
aparece mapeo y canal JDBC.
Figura 8.68. Receiver Determination para el BPM: base de datos (1 accin).
Seguidamente al servicio BPM e interfaz abstracta sncrona le

asignamos el sistema SAP para la RFC.
38
Figura 8.69. Receiver Determination para el BPM: sistema SAP.
Y finalmente al servicio BPM e interfaz abstracta tipo JDBC con la

actualizacin a las tablas de la base de datos le asignamos de nuevo el
receptor de base de datos, donde la asignacin de interfaces es directa sin
mapeos.
Figura 8.70. Receiver Determination para el BPM: base de datos (2 accin).
39
Con todo queda montado todo nuestro escenario que iremos ejecutando
y chequeando hasta comprobar el correcto funcionamiento del mismo.
En la siguiente seccin realizaremos una pequea introduccin al rea

de monitorizacin del SAP PI conocido como Runtime Workbench o rea de
trabajo en tiempo de ejecucin. All podremos comprobar el estado de los
mensajes, de los canales, e incluso configurar alertas, encaminado al correcto
funcionamiento de nuestros escenarios.
40

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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

Introduccin a la plataforma SAP NetWeaver.

Estudio de SAP Process Integration

Una vez presentados todos los objetos que podramos encontrar en un

Proyecto fin de carrera

Alberto Naranjo Moruno

Introduccin a la plataforma SAP NetWeaver. Estudio de SAP Process Integration

Proyecto fin de carrera

Alberto Naranjo Moruno

Cap.8. Ejemplos de escenarios en SAP PI. Diseo y configuracin

Figura 8.1. Ejemplo grfico del escenario 1.

Comenzamos con el diseo de los objetos necesarios en el Integration

Figura 8.2. Data Type de lectura del fichero.

Proyecto fin de carrera

Alberto Naranjo Moruno

Introduccin a la plataforma SAP NetWeaver. Estudio de SAP Process Integration

A continuacin definimos el Message Type asociado.

Figura 8.3. Message Type para leer de fichero.

Figura 8.4. Message Interface para lectura de fichero.

El siguiente paso sera importarnos la RFC que nos indiquen para

Proyecto fin de carrera

Alberto Naranjo Moruno

Cap.8. Ejemplos de escenarios en SAP PI. Diseo y configuracin

Figura 8.5. RFC importada de un sistema SAP.

Con todas las interfaces diseadas procedemos a definir el mapeo de

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

Como ltimo objeto a definir en el Repositorio est el Interface Mapping

Proyecto fin de carrera

Alberto Naranjo Moruno

Introduccin a la plataforma SAP NetWeaver. Estudio de SAP Process Integration

Figura 8.7. Interface Mapping de fichero a RFC.

Con todos los objetos diseados realizaremos la configuracin del

Proyecto fin de carrera

Alberto Naranjo Moruno

Cap.8. Ejemplos de escenarios en SAP PI. Diseo y configuracin

Figura 8.8. Canal de comunicaciones fichero sender. Pestaa Source.

Figura 8.9. Canal de comunicaciones fichero sender. Pestaa Processing.

Figura 8.10. Canal de comunicaciones fichero sender. Pestaa Advanced.

En el otro servicio crearemos un canal de comunicaciones Receiver de

Proyecto fin de carrera

Alberto Naranjo Moruno

Introduccin a la plataforma SAP NetWeaver. Estudio de SAP Process Integration

Figura 8.11. Canal de comunicaciones RFC receiver. Pestaa Target.

Figura 8.12. Canal de comunicaciones RFC receiver. Pestaa Advanced.

El siguiente paso sera la definicin de los acuerdos de colaboracin o

Figura 8.13. Sender Agreement con el servidor del fichero.

En cuanto al Receiver Agreement habr que especificar el sistema

Proyecto fin de carrera

Alberto Naranjo Moruno

Cap.8. Ejemplos de escenarios en SAP PI. Diseo y configuracin

Figura 8.14. Receiver Agreement con el sistema SAP destino.

Figura 8.15. Interface Determination.

Para acabar con el montaje creamos el Receiver Determination donde

Proyecto fin de carrera

Alberto Naranjo Moruno

Introduccin a la plataforma SAP NetWeaver. Estudio de SAP Process Integration

Figura 8.16. Receiver Determination.

Si todo est correcto se activarn los canales y se podr lanzar la

Proyecto fin de carrera

Alberto Naranjo Moruno

Cap.8. Ejemplos de escenarios en SAP PI. Diseo y configuracin

Figura 8.17. Ejemplo grfico del escenario 2.

Como ya sabemos lo primero a disear son los tipos de datos

Figura 8.18. Estructura de la RFC sncrona.