Guías para la Práctica (3): Uso de ActiveBPEL y Eclipse BPEL Designer
Introducción ActiveBPEL es un motor open-source que implementa BPEL4WS 1.1 y WS-BPEL 2.0. Mantenido por la empresa Active Endpoints, que comercializa versiones avanzadas del mismo. Otras opciones: JBOSS BPM, Apache ODE. Eclipse BPEL Designer es un plugin para Eclipse que permite crear gráficamente flujos BPEL. Hay algunas incompatibilidades: E.g. Las rutas Xpath generadas en las expresiones por Eclipse BPEL Designer pueden no funcionar directamente en ActiveBPEL (no necesarias en nuestra práctica). Los utilizaremos para la implementación de la práctica (parte opcional). Veremos primero ActiveBPEL y después Eclipse BPEL Designer.
ActiveBPEL: Instalación Instrucciones en docs/install_engine.txt Una vez fijada la variable de entorno CATALINA_HOME (home de Tomcat), ejecutar script install.sh (o install.bat ). En el laboratorio: Descomprimir apache-tomcat-6.0.18- activebpel.tar.gz que está en el directorio /opt/isyadoo-0809/softwarelocal/ Arrancar tomcat (desde que tomcat arranca, activebpel tarda aún unos segundos en estar disponible).
Deploy de procesos (1) Instrucciones en docs/deploy_bpel.txt Crear un directorio con los siguientes componentes: wsdl. Contiene los ficheros.wsdl que describen el servicio web resultante de nuestro proceso BPEL y los servicios web utilizados por éste. bpel. Contiene el fichero.bpel que define nuestro flujo. META-INF. Contiene el fichero wsdlcatalog.xml, que identifica los ficheros wsdl necesarios. Fichero.pdd que describe meta-información de deployment. Empaquetado: jar cf mybpel.bpr mybpel.pdd wsdl META-INF bpel Deploy: cp mybpel.bpr $CATALINA_HOME/bpr Esperar unos segundos hasta que ActiveBPEL detecte el proceso y finalice su deploy.
Deploy de procesos (2) Ver docs/fileformats.txt mybpel.pdd Especifica nombre y localización del proceso BPEL. Define un elemento partnerlink para cada partner del proceso, especificando su rol y un elemento EndPointReference (especificación WS-Addressing) para indicar cómo localizarlo. También especifica un conjunto de referencias a los ficheros.wsdl utilizados por el proceso.
Deploy de procesos (3) <?xml version="1.0" encoding="utf-8"?> <process name="bpelns:incidencesprocess" location="bpel/incidencesprocess.bpel" xmlns="http://www.active-endpoints.com/schemas/deploy/pdd.xsd" xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing" xmlns:bpelns="http://adoo.udc.es/bpel/incidencesprocess"> <!-- Partner Link for inbound request --> <partnerlinks> <partnerlink name= incidencesprovider"> <myrole service= incidencesprovider" allowedroles="" binding= MSG"/> </partnerlink> <!-- Partner Link for outbound request to crm --> <partnerlink name= internalcrm"> <partnerrole endpointreference="static"> <wsa:endpointreference xmlns:crm="http://adoo.udc.es/ws/internalcrm"> <wsa:address>crm:anyuri</wsa:address> <wsa:servicename PortName= InternalCRMProvider"> crm:internalcrmproviderservice</wsa:servicename> </wsa:endpointreference> </partnerrole> </partnerlink>
Deploy de procesos (4) <! Partner links para el resto de servicios </partnerlinks> <wsdlreferences> <wsdl namespace="http://adoo.udc.es/ws/internalcrm" location="project:/wsdl/internalcrmprovider.wsdl"/> <wsdl namespace="http://adoo.udc.es/ws/alerts" location="project:/wsdl/alertsprovider.wsdl"/> <wsdl namespace="http://adoo.udc.es/ws/incidencesresources" location="project:/wsdl/incidencesresourcesprovider.wsdl"/> <wsdl namespace="http://adoo.udc.es/bpel/incidencesprocess" location="project:/wsdl/incidencesprocess.wsdl"/> <wsdl namespace="http://adoo.udc.es/bpel/incidencesprocessartifacts" location="project:/wsdl/incidencesprocessartifacts.wsdl"/> </wsdlreferences> </process>
Deploy de procesos (5) El elemento process especifica el nombre (cualificado con espacio de nombres) y la localización del fichero.bpel en el fichero.bpr. Habrá un elemento partnerlink para cada PartnerLink definido en nuestro proceso BPEL. La primera definición de partnerlink del ejemplo identifica a nuestro proceso (myrole). El valor del atributo service será el nombre de nuestro servicio. El atributo binding dice cómo se invocará ( RPC o MSG ). RPC es un estilo obsoleto, por lo que usamos MSG. La segunda define el PartnerLink para el InternalCRM. El espacio de nombres debe ser el targetnamespace del fichero.wsdl del servicio. El atributo PortName debe tomar el valor del tipo de puerto definido en el fichero.wsdl del servicio. El contenido del elemento ServiceName debe ser el nombre del servicio definido en el fichero.wsdl.
Deploy de procesos (6) En el elemento wsdlreferences habrá un sub-elemento wsdl por cada fichero.wsdl que utilice nuestro flujo (incluyendo servicios web de apoyo y definición de partner link types). El valor del atributo namespace se ignora. El valor del atributo location es una clave para el fichero wsdlcatalog.xml.
wsdlcatalog.xml Deploy de procesos (7) <?xml version="1.0" encoding="utf-8"?> <wsdlcatalog> <wsdlentry location="project:/wsdl/internalcrmprovider.wsdl" classpath="wsdl/internalcrmprovider.wsdl"/> <wsdlentry location="project:/wsdl/alertsprovider.wsdl" classpath="wsdl/alertsprovider.wsdl"/> <wsdlentry location="project:/wsdl/incidencesresourcesprovider.wsdl" classpath="wsdl/incidencesresourcesprovider.wsdl"/> <wsdlentry location="project:/wsdl/incidencesprocess.wsdl" classpath="wsdl/incidencesprocess.wsdl"/> <wsdlentry location="project:/wsdl/incidencesprocessartifacts.wsdl" classpath="wsdl/incidencesprocessartifacts.wsdl"/> <schemaentry location="project:/internalcrmprovider_schema1.xsd" classpath= InternalCRMProvider_schema1.xsd" /> </wsdlcatalog>
Deploy de procesos (y 8) Una entrada wsdlentry por cada fichero wsdl utilizado. Una entrada schemaentry por cada fichero.xsd utilizado. Classpath identifica la ruta al fichero wsdl desde la ruta dónde se genera el fichero.bpr. Location es el valor de un atributo location de un elemento <wsdl> dentro de la sección wsdlreferences del fichero.pdd. Sólo necesario para los wsdl.
Administración y depuración Heramienta de administración en: http://maquina:puerto/bpeladmin Depuración en Deployment: Ver salida del Tomcat por la salida estándar. A veces los errores son más explicativos. Ver Deployment Log en la herramienta de administración. Ver Deployed processes para ver si el proceso ha sido instalado con éxito. Depuración en Ejecución: Puede activarse el log escogiendo la opción Configuration y marcando la casilla de Logging Enabled. Cada ejecución recibe un id (puede verse la lista con la opción Active Processes ). Haciendo click en el proceso, puede accederse a una traza gráfica de su ejecución, viendo el estado de cada variable y de cada actividad, así como acceder al log generado (pinchando en la lupa de la parte superior izquierda).
Pasos para la práctica (1) 1. Crear los servicios web de apoyo (Mock) 1. CRM Interno (basado en el existente). 2. Herramienta comunicación corporativa. 3. Asignación de recursos incidencias. NOTA: No es necesario considerar excepciones. 2. Colocar los ficheros wsdl de los servicios web de apoyo en el directorio wsdl de mi proyecto BPEL. 1. Colocar también los ficheros xsd de apoyo.
Pasos para la práctica (2) 3. Usar Eclipse BPEL Designer para crear el flujo. Normalmente generará: 1. Fichero wsdl describiendo la interfaz que ofrecerá el servicio web resultado de mi proceso BPEL. Normalmente tendrá la definición de tipos, mensajes, tipos de puerto y el partnerlinktype que modela la interacción con el cliente. 2. Un fichero WSDL llamado MyProcessArtifacts.wsdl que definirá los PartnerLinkTypes para los servicios web externos utilizados por el proceso BPEL. 3. El fichero MyProcess.bpel. 4. Pueden ser necesarios algunos pequeños cambios debido a bugs de Eclipse BPEL Designer (explicados más adelante). 5. Colocar los nuevos ficheros en su sitio y empaquetar e instalar nuestro proceso BPEL.
Pasos para la práctica (y 3) 6. Crear un cliente para invocar el servicio web de nuestro proceso BPEL. 1. Nuestro servicio colgará de: http://maquina:puerto/active-bpel/services/ 2. Recordad que la traza de ejecución puede verse en la admin web de ActiveBPEL, haciendo click en la lista de Active Processes.
Eclipse BPEL Designer BPEL es un lenguaje pensado para ser creado gráficamente (escribir el XML directamente es tedioso y propenso a errores). Eclipse BPEL Designer permite diseñar gráficamente flujos BPEL y validarlos. Es independiente del motor de ejecución utilizado. Actualmente, no hace el deploy del proceso ni permite ejecutarlo / depurarlo desde Eclipse. Tenemos que coger los ficheros generados y hacer el deploy manualmente en el motor de ejecución (en nuestro caso ActiveBPEL) para probarlo. http://www.eclipse.org/bpel/
Crear Proyectos 1. Crear Proyecto: 1. New - Project -BPEL 2.0 - Especificar nombre - BPEL 2.0 Facet. 2. Añadir fichero BPEL al proyecto: 1. New - Other -BPEL2.0 File - Escoger nombre para el proceso y espacio de nombres, 2. Escoger plantilla 1. Synchronous BPEL Process. Receive / Reply síncrono. El más adecuado para la práctica. 2. Asynchronous BPEL Process. Receive / Reply asíncrono 3. Empty BPEL Process. Proceso vacío. 3. Guardar en carpeta del proyecto.
Editar y Crear Partner Links (1) 1. Necesitamos un PartnerLink para el cliente y uno para cada servicio externo. 2. Si usamos la plantilla Synchronous Process, se nos crea ya un PartnerLink para el cliente. Puede ser conveniente editarlo. Para ello, debemos ir al fichero MyProcess.wsdl que se creó junto con nuestro proceso: 1. Podemos editar las partes de los mensajes de request y response ya creados, poniendo un nombre. 2. Para la práctica, seguramente querremos fijar Reference kind a "type" y escoger string (en las partes de ambos mensajes). 3. También podemos editar los nombres y parámetros de la operación (es la que nuestro servicio BPEL expondrá hacia los clientes). 4. Para refrescar los cambios en el fichero BPEL puede ser necesario cerrar Eclipse y volverlo a abrir.
Editar y Crear Partner Links ( y 2) 3. Para añadir los PartnerLinks para los servicios externos: 1. Pulsar + al lado de PartnerLinks. 2. Necesitamos crear un PartnerLinkType. Podemos hacerlo gráficamente partiendo de un tipo de puerto WSDL: 1. Pulsar Browse Pulsar botón Add WSDL. 2. Escoger File y añadir el fichero.wsdl del servicio externo. 3. Aparecerán los tipos de puerto, se selecciona el deseado (normalmente sólo habrá uno y se pulsa ok ). 4. Proporcionar un nombre para el PartnerLinkType 5. Añadir roles. Para cada rol hay que especificar un nombre y un tipo de puerto (en la práctica lo normal es que necesitemos un solo rol por PartnerLinkType). 6. Pulsar Finish. 3. En las propiedades del PartnerLink, escoger el nuevo rol como Partner Role.
Variables 1. Si usamos la plantilla Synchronous Process, se nos crean ya variables para la entrada y la salida del proceso: 1. Podemos editar las variables haciendo click y cambiando su tipo. Puede ser necesario hacerlo después de editar los mensajes del PartnerLink con el cliente. 2. Para añadir variables: 1. Pulsar + al lado de Variables. 2. Pulsar Browse para escoger el tipo. 3. Si el tipo es de un mensaje definido en un WSDL del proyecto, marcar Messages y escoger el adecuado. 4. Si es de un WSDL externo hay que marcar antes 'From Imports'.
Crear el Flujo 1. Si usamos la plantilla Synchronous Process, se nos crea una actividad Sequence que tiene dentro un receive y un reply. 2. Para añadir una actividad antes de otra, nos ponemos sobre la segunda y usamos el menú contextual Insert Before. 3. Para añadir nuevas actividades a un flow o un sequence puede usarse el menú contextual Add. 4. Para configurar una actividad hacemos click sobre ella y usamos el panel de propiedades. 5. Para añadir links en un flow, usamos el menú contextual Add Link desde la actividad origen y llevamos la flecha a la actividad destino. 6. Para añadir una transitioncondition, nos ponemos sobre el link y pulsamos New Condition en la pestaña de propiedades.
Expresiones y validación 1. En las actividades ASSIGN y en las condiciones de transición, podemos tener que definir expresiones. 2. Eclipse BPEL Designer incluye un editor de condiciones que sugiere opciones válidas en cada paso. 1. E.g. cuando tecleamos el prefijo utilizado para indicar una variable en una expresión ( $ ) se nos abre un desplegable con las variables definidas. Si tras el nombre de la variable ponemos. se nos muestran las partes de dicha variable, 3. El editor incluye un auto-validador. Los componentes mal configurados se muestran con un botón amarillo (warning) o rojo (error) en su parte inferior izquierda. Ratón sobre botón -> mensaje explicativo. Problemas: 1. Guardar o incluso reiniciar Eclipse para que refresque. 2. En ocasiones raras puede indicar algún warning o incluso algún error que no lo son realmente (bugs).
Deploy en ActiveBPEL (1) Los archivos.bpel y.wsdl generados los tenemos en el workspace de Eclipse, en el directorio del proyecto. Puede haber que editar manualmente los ficheros.bpel y.wsdl generados para que el deploy en ActiveBPEL sea exitoso. En Windows, BPEL Designer hace mal los imports de los WSDL externos (pone paths en lugar de URIs). Workaround: Ir al fichero MyProcessArtifacts.wsdl y modificar los import de los wsdl de los servicios web externos. Es suficiente con quitar la ruta, dejando sólo el nombre del fichero.wsdl (asumiendo que dicho fichero.wsdl va incluido en el directorio wsdl del fichero.bpr del proceso de ActiveBPEL, recordad instrucciones más atrás).
Deploy en ActiveBPEL (y 2) Eclipse BPEL Designer puede generar assigns para inicializar variables que no funcionan en ActiveBPEL. Ocurre con JAX-WS cuando las operaciones JAVA utilizan parámetros que pueden ser nulos (e.g. String). Ejemplo: tipo creado por JAX-WS para representar un parámetro de entrada simple de tipo String para una operación llamada getlasttradeprices. <xs:complextype name="getlasttradeprices"> <xs:sequence> <xs:element name="arg0" type="xs:string" minoccurs="0"/> </xs:sequence> </xs:complextype> Para que funcione correctamente, quitar minoccurs=0. Entonces, al inicializar una variable de ese tipo, Eclipse BPEL la inicializará a la cadena vacía. En caso contrario, la inicializará a nada y fallará en ActiveBPEL.