Escribir una 'Singleton' Proceso de BPEL

Un caso de uso típico en BPEL se conecta a un recurso externo / sistema que sólo admiten una única conexión a la vez. En este caso tenemos que proteger contra casos paralelos BPEL presentar solicitudes simultáneas a ese recurso.

Esto implica que necesitamos alguna manera de serializar las solicitudes de ese recurso (probablemente el primero en una base, en primer lugar). Un patrón de diseño común para lograr esto es el Singleton, documentado por primera vez en la Banda de los Cuatro patrones de libro (donde se utiliza una cola de impresión como ejemplo).

Ahora BPEL no apoyaron explícitamente la noción de un Singleton, sin embargo, le permite para simular una, que, a efectos de lo que estamos tratando de lograr es lo suficientemente bueno.

La idea básica es tener una explícita initiateSingleton operación que se utiliza para crear instancias de una instancia de proceso único, y luego dejar separada invokeSingleton operación que se utiliza para presentar cada solicitud real. El invocar la operación se coloca en un bucle, tan pronto como se procesa una solicitud se realiza un bucle de vuelta redonda para la siguiente.

Para este ejemplo, he creado un proceso simple que no pierde de vista el número de veces que se le ha llamado . Se toma un único parámetro, el nombre y devuelve una cadena con el siguiente formato:

Hola . Usted es el número de llamadas de este producto único.

Bastante simple, pero ilustra el punto. El proceso básico se muestra en la siguiente imagen:

La primera actividad en el proceso es una actividad de recibir, InitiateSingleton , que se utiliza para crear una instancia del proceso. Entonces tenemos una asignación simple que sólo pone la cuenta a cero. El resto del proceso, que se encarga de lainvokeSingleton operación se encuentra dentro del ámbito de aplicación ProcessRequest, que a su vez se coloca dentro de un bucle while, que por los siglos de los bucles. Contiene las siguientes actividades:

1. InvokeSingleton - Este recibe la siguiente solicitud para ser procesados por el singleton.
2. Espera - Esta espera por un período de 5 segundos. Es sólo para simular salir a un sistema externo. También nos permite ver el número de solicitudes múltiples para el singleton se cola por el Oracle BPEL PM Server.
3. SetResult - Aquí se acaba de establecer el resultado y el incremento de la cuenta por uno.
4. CallbackClient - Por último que acabamos de enviar el resultado al cliente, antes de bucle de nuevo todo el proceso a la siguiente solicitud.

Mensaje de Correlación

A primera vista todo parece engañosamente simple, sin embargo la complejidad viene cuando tratas de llamar a lainvokeSingleton operación.

La razón es que cuando se invoca una operación en un proceso BPEL, el mensaje es recibido por el Oracle BPEL PM controlador de mensajes, en función de la operación o bien se invoca un nuevo proceso para manejarlo (como con el initiateSingletonoperación) o la vía a través de a la instancia adecuada de un proceso ya se está ejecutando.

Este es donde se pone un poco complicado, cuando recibimos el mensaje para el invokeSingleton operación, a pesar de que sólo tenemos una única instancia del proceso de ejecución BPEL BPEL PM ¿cómo sabemos que es la instancia correcta para dirigir el mensaje? La respuesta es no.

Ahora bajo "normales" las circunstancias, donde tenemos una interacción asincrónica entre dos procesos, Oracle BPEL PM por defecto a usar WS-Addressing para garantizar que los mensajes son enviados con éxito entre dos instancias del proceso. Sin embargo, en estos casos, lo normal es que la interacción entre los dos procesos (por ejemplo A y B) comenzó el proceso A iniciar y B proceso de pasarlo detalles A (utilizando WS-Addressing) sobre sí mismo para que cuando el proceso B devuelve una respuesta que contiene información suficiente para que se encaminen a la instancia adecuada del proceso de A.

Sin embargo, con nuestro proceso de Singleton, cualquier proceso que llama la invokeSingleton operación no tendrá un conocimiento previo de ese proceso, por lo que para nuestros propósitos, no podemos utilizar WS-Addressing para correlacionar el mensaje.

Afortunadamente para los casos en WS-Addressing no es apropiado o disponible BPEL proporciona el concepto de conjuntos de correlación. Básicamente establece correspondencias le permiten utilizar un regalo de valor único en el cuerpo del mensaje de todos los mensajes intercambiados (por ejemplo, idpedido ) para vincular que el intercambio de mensajes relacionados entre sí.

Esto se realiza en BPEL, en primer lugar la definición de una propiedad que se corresponde con el valor único, y a continuación, definir un alias de la propiedad para cada mensaje en el intercambio, que define cuando esta propiedad se encuentra dentro del mensaje. A continuación, definir un conjunto de correspondencias que puede constar de una o más propiedades (ver la documentación del producto o de la SOA Suite de Oracle Developer's Guide para más información sobre cómo crear conjuntos de correspondencias).

Para nuestro propósito, he definido un elemento simple llamado singletonId que figura tanto en el initiateSingleton yinvokeSingleton operaciones.

A continuación se ha definido un conjunto de correspondencias SingletonCS que se utiliza en el InitiateSingleton yInvokeSingelton operaciones.

En el initiateSingleton operación que ha definido este para iniciar el conjunto de correlaciones (ver imagen abajo), este medio que sea, el valor se encuentra con la singletonId en la operación de inicio debe estar presente en el invokeSingletonoperación para que pueda ser enviada a través de la presente instancia de proceso.

La siguiente parte del problema es la respuesta para volver de nuevo a la persona que llama adecuada del proceso. Esto al principio puede parecer extraño, pero recuerdo que pueden tener varios procesos de llamar al singleton, al mismo tiempo, por lo que todos esperan una respuesta. Necesitamos asegurarnos de que cada respuesta se devuelve a la instancia adecuada.

Ahora usted probablemente ya habrá adivinado que tenemos que utilizar los conjuntos de correlación de nuevo (como hemos inhabilitado WS-Addressing para este Link Partner). Esta vez el proceso de llamada tendrá que generar una clave única que pasa en la solicitud ( RequestIP ) del singleton. El singleton entonces devolver esta en la respuesta al solicitante.

Si nos fijamos en la SingeltonAccessor proceso, utilizamos el operador XPath generateGUID para generar este valor.

Especificación de la Dirección de respuesta

Así que ahora todo se ve bien, así que podemos seguir adelante y ejecutar el proceso no; así bastante! Si lo hace, se dará cuenta de esta petición del SingeltonAccessor éxito llega a nuestro proceso de Singleton. Pero alguna razón la respuesta de la Singleton nunca para llegar al SingeltonAccessor, de hecho, si usted toma un examen más detenido de la pista de auditoría Singleton para la actividad de devolución de llamada, verá que en realidad omite la devolución de llamada!

Ahora resulta que se trata de un buen comportamiento racional por la sencilla razón de que el Singleton en realidad no sabe donde enviar sus mensajes de devolución de llamada. Esto es porque en tiempo de diseño el que llama a un proceso asíncrono por lo general no se conoce, y por lo tanto la dirección de devolución de llamada es necesario especificar en el momento de Porra. De hecho si inicia una sesión en la consola de BPEL y examinar el WSDL para devolver la llamada operación, podrás ver que el jabón: ubicación de la dirección de la variable se define como:

http://set.by.caller

Ahora por defecto de Oracle BPEL PM utiliza WS-Addressing para manejar esto, así, cuando invoco un proceso asíncrono, que forma parte de la carga útil SOAP contiene una dirección de retorno para el proceso asíncrono, sin embargo acabamos de discapacitados WS-Addressing para este intercambio de mensajes ya que estamos utilizando conjuntos de correlación.

Así que, ¿cómo garantizaremos la respuesta a la dirección? Bueno una solución sería pasar esto en el marco del mensaje de solicitud y, a continuación parejas el uso de enlaces dinámicos a establecer el replytoaddress .

Sin embargo una manera más simple es definir los replytoaddress propiedad en la PartnerLink para que apunte a la dirección de respuesta. Esto tiene el siguiente formato:

/ PartnerLinkTypeName /] rollName [

Así que en nuestro caso:

http://server:port/orabpel/default/SingletonAccessor/1.0/Singleton/SingletonRequester

Ahora bien, si finalmente implementar esta debería funcionar. Para ejecutar el ejemplo, primero ir a la consola de BPEL e iniciar el proceso Singleton (juego de Id Singleton "Singleton/1.0" ).

Desde la consola de incoar el SingletonAccessor entrar en cualquier valor que desee para la denominación . Usted podría poner en marcha una serie de ellas para ver qué pasa.

Loose Ends

Así que todas las obras, sin embargo hay dos problemas básicos con este enfoque:

• En primer lugar para invocar el Singleton lo que necesita saber el valor de la SingletonId. Esto en nuestro caso se fija en el proceso de SingltonAccessor.
• En segundo lugar, el proceso de Singleton referida solamente devolver un resultado al proceso SingletonAccessor (ya que esto se soluciona mediante la especificación de la replytoaddress). ¿Qué pasa si queremos llamarlo desde otro proceso o cliente de servicios web?

En realidad, la solución a esto es muy sencillo; se utiliza el SingletonAccessor como punto de entrada para acceder al Singleton. Así, el cliente real siempre llamar a la SingletonAccessor .

Así, el cliente nunca tiene que saber la SingletonId , y en segundo lugar como WS-Addressing permanece encendida entre la"real" del cliente y el SingletonAccesor el cliente no necesita preocuparse acerca de los conjuntos de correlación o de especificar unreplytoaddress .

Una última pregunta que usted pueda tener es ¿cómo puedo evitar varias instancias del proceso de Singleton se inició con una equivocación? Pues por qué no intentarlo? Usted verá que todo el tiempo que especifique el mismo valor para la SingletonId , BPEL PM lanzará un "conflicto recibir" la culpa como un equivalente de recibir la actividad ya ha sido habilitado por el original Singleton.

Conclusión

Como podemos ver, la aplicación de un Singleton en BPEL es relativamente sencillo. Si bien esto no es una solución totalmente limpia, se logra el efecto deseado.

Haga clic aquí para descargar ejemplo de trabajo

Mensaje orientada a la interoperabilidad entre los canales WCF y Oracle Application Server WSIF

Jesús Rodríguez, ha escrito una serie de interesantes artículos muy en servicio de interoperabilidad entre Web. NET y Oracle Fusion Middleware. Un reciente sobre un mensaje orientado a la interoperabilidad entre los canales WCF y Oracle Application Server WSIF vale la pena leer.

Consultar instancias de procesos BPEL

El Oracle BPEL Console proporciona una gran herramienta para monitorear la situación de a bordo y completado el proceso.

Sin embargo, es a menudo un requisito de presentar esta información a un usuario de negocio dentro de una visión empresarial específica. Una forma de lograr esto es utilizar el BPEL Portlets Oracle.

Esto está bien cuando usted quiere dar al usuario una lista específica de instancias de proceso, por ejemplo una lista de todos los actualmente en ejecución procesos de orden de compra. Pero ¿qué pasa cuando hay que darles una lista más filtrada a sus requisitos empresariales específicos, por ejemplo:

• ¿Cómo puedo encontrar todos los procesos de orden de compra abierta para un cliente concreto?
• ¿Cómo puedo encontrar todos los procesos de servicio de asistencia se gestionan por un representante de servicio al cliente en concreto?
• ¿Cómo puedo encontrar todos los procesos abiertos de gastos que están esperando la aprobación?

Además, una vez que hayas encontrado una instancia de proceso, ¿cómo puedo proporcionar al usuario acceso a los datos pertinentes que figuran en el proceso? Una vez más la consola de BPEL proporciona un mecanismo para la perforación en el proceso y mirando a la pista de auditoría para los datos. Pero muchas veces queremos que proveen estos datos en una vista de negocio resumen diseñado específicamente para las necesidades del usuario de negocios.

El Oracle BPEL PM Server ofrece una serie de API's que permiten cumplir con estos requisitos.

De hecho lo que no es a menudo dado cuenta es que la consola de BPEL se hace uso de estas API's, que le da la flexibilidad para completamente re-escritura de la consola si eso es lo que se necesita!

En realidad esto es raramente el caso, por lo general, el requisito es proporcionar a los usuarios de negocios con un simplificado considera adaptado a sus necesidades concretas. Una forma sencilla de conseguirlo es mediante el uso de estas API's, este es el tema de este artículo.

Localización de un proceso de Instancia

El Oracle BPEL PM cliente API proporciona una clase Localizador para permitir una aplicación cliente para buscar los procesos, instancias y actividades. La clase Localizador proporciona un número de constructores, que le permiten conectarse a un dominio alojado en BPEL sea a nivel local o remota del servidor J2EE.

A los efectos del proceso de localización de casos concretos que proporciona dos métodos muy útiles:

• listInstances (wc WhereCondition)
• listInstancesByIndex (wc WhereCondition)

Cada método devuelve un array de objetos de tipo InstanceHandle, que luego pueden ser utilizados para realizar operaciones en la instancia del proceso correspondiente.

El parámetro clave para cada uno de estos métodos es la WhereCondition, que se utiliza para construir una consulta para restringir los casos son devuelto por el método.

Nota: En caso de objetos condición puede ser concatenados entre sí para formar una consulta más amplia. Los métodos append y anteponer permiten al usuario añadir una cláusula (en formato de cadena) o incluso un objeto WhereCondition todo al principio o al final de la actual, en la condición.

El fragmento de código siguiente se muestra cómo construir un WhereCondition para devolver todas las instancias de proceso que se ejecuta para el "LoanFlowProcess", donde su estatus actual es "CheckingCredit".

String pProcessId = "LoanFlowProcess";
pStatus String = "CheckingCredit";

/ / Construye una condición en la que las búsquedas para las instancias abiertas
WhereCondition donde = WhereConditionHelper.whereInstancesOpen ();

/ / Extender la condición de que para filtrar en el proceso de identificación
WhereCondition whereProcessId = WhereCondition nueva ("process_id =?);
whereProcessId.setString (1, pProcessId);
where.append (whereProcessId);

/ / Extender la condición de filtro en los procesos con el estado 'CheckingCredit'
whereStatus WhereCondition nueva WhereCondition = ("status = '" + + pStatus ");
whereStatus.setString (1, pStatus);
where.append ("y"). append (whereStatus)

/ / Buscar instancias
IInstanceHandle [] = instanceHandles locator.listInstances (donde);

En el último paso, el real clase de localización está realizando una consulta en la deshidratación de la tienda BPEL, similar a la que se ilustra a continuación:

"Cikey seleccionar cube_instance donde" + whereCondition.getClause ();

Usamos el WhereCondition (que envuelve una declaración preparada SQL donde la condición), con el fin de restringir el conjunto de resultados devuelto por la consulta.

Vale la pena explorar en un poco más de detalle las diferentes partes de la WhereCondition.

Para el primero de utilizar la clase WhereConditionHelper para restringir la consulta a los procesos actualmente en ejecución solamente. Esta es una clase sencilla utilidad que ofrece una variedad de métodos estáticos para la creación de varios fragmentos de consulta (por ejemplo, proceso de retorno instancia cuyo estado está abierta, completa, abortados, rancio, etc) que luego se pueden anexar a otras donde las condiciones para crear la consulta necesaria .

Por nuestra condición de segundo que son, literalmente, añadiendo la condición

cube_instance.process_id = "LoanFlowProcess"

de nuestra declaración preparada. Aquí puede especificar más o menos cualquiera de las columnas de la tabla cube_instance base de datos (por ejemplo, Process_Id, Revision_Tag, Prioridad, Estado).

En realidad, en lugar de nombrar explícitamente esta columna, debemos utilizar las constantes adecuados definidos en com.oracle.bpel. client.util.SQLDefs (por ejemplo, SQLDefs.CI_process_id para nuestro ejemplo).

El resultado final es similar al segundo en el que estamos consultando sobre el estado del proceso. Pero ¿cuál es el estado del proceso? Bueno, no debe confundirse con el estado del proceso, que consultan en la primera WhereCondition.

Más bien el estado del proceso es una variable que toma nota de dónde en el proceso de una instancia de proceso en particular es. Cuando el proceso se inició primero, este valor se establece en "iniciados". Este valor se actualiza cada vez que usted entra en un nuevo ámbito de aplicación dentro de un proceso que contiene el nombre del ámbito de aplicación.

Tenga en cuenta: Cuando se han anidado ámbitos, contendrá el nombre de menor alcance más anidados de que el proceso está bajo, es decir, contiene el alcance último que se escribió. También cuando un proceso deja un ámbito de aplicación el valor de estado no se restablece, es decir, que todavía contiene el nombre del ámbito de aplicación anterior hasta que entra en un nuevo ámbito de aplicación.

Proceso de índices

listInstances El método es muy útil, pero aún así no nos permiten realizar una consulta basado en datos reales, celebrada en la instancia de proceso, como por ejemplo simplemente devuelva el proceso de flujo de préstamos para 'Dave'.

Para solucionar este problema, BPEL permite un proceso para tener un máximo de 6 índices y crear una condición en donde a través de uno o más de estos índices.

Esencialmente hay dos pasos a este: en primer lugar es necesario establecer los valores de índice en la instancia del proceso real, en segundo lugar se utiliza el índice de valores en una consulta a retirar todos los procesos por un valor índice determinado de una manera similar al anterior.

Establecer el valor del índice

La forma más sencilla de lograrlo es integrar un pedazo de Java (Java usando el Widget de tareas) al inicio del proceso de llamar a la API setIndex para establecer el valor de índice basado en un valor en el mensaje inicial, como se muestra en el ejemplo a continuación:

/ / Establecer index1 de Nombre de cliente
de customerName String = ((com.collaxa.cube.xml.dom.CubeDOMText)
getVariableData ("input", "carga útil", "/ auto: loanApplication / auto: de customerName / ()")) texto . gettext ();
setIndex (1, de customerName);

Nota: El método getVariableData se utiliza para recuperar la de customerName de la "entrada" variable, la sintaxis de los parámetros es similar a la "de" un componente dentro de asignar la construcción.

Consultar Procesos

El fragmento de código siguiente se muestra cómo construir un WhereCondition para volver todas las instancias de proceso que se ejecuta en index_1 es igual a 'Dave'.

pCustomerName String = "Dave";

/ / Construye una condición en la que busca en el índice 1
WhereCondition donde = WhereCondition nuevo (SQLDefs.CX_index_1 + "=?");
where.setString (1, pCustomerName);

/ / Buscar instancias
IInstanceHandle [] instanceHandles = locator.listInstancesByIndex (donde);

Sin embargo, hay un problema menor con el presente; debajo de las cobijas el método listInstances está realizando una consulta en la tabla de base de cube_instance, mientras que el listInstancesByIndex está realizando una consulta en la base de datos ci_indexes tabla .

La cuestión aquí es que si queremos realizar una consulta que es una combinación a través de estas dos tablas, es decir, me muestra todos los procesos LoanFlow para Dave. La API no WhereCondition (naturalmente) se une a permitir, sin embargo hay dos soluciones posibles:

La primera consiste en establecer el índice de valores para contener los datos adicionales requeridos por la consulta, por ejemplo set index_1 para contener el nombre del proceso y para celebrar index_2 el ID de cliente.

El segundo es ampliar el estado en que pasa al método listInstance para disponer de una condición de que las consultas en la tabla de base de datos ci_indexes, como se muestra a continuación:

/ / Extender el donde la condición para devolver sólo los procesos abiertos con la
nueva whereIndex WhereCondition WhereCondition = ("cikey en (cikey seleccionar ci_indexes donde index_1 =?");
whereIndex.setString (1, pCustomerName);
where.append ("y" ). append (whereIndex)

Nota: He utilizado los nombres de tablas y columnas para mayor claridad, pero en realidad usted debe utilizar las constantes definidas por SQLDefs.

El uso de un índice para establecer el estado

Anteriormente, en el artículo buscamos ay cómo podemos utilizar estado del proceso para realizar un seguimiento de dónde estamos actualmente en un proceso (recuerde estado contiene el nombre del alcance última que entró).

Sin embargo, mientras que esto es útil que haya un par de inconvenientes, uno es que si utilizamos el método listInstancesByIndex para localizar un proceso, no podemos en realidad el filtro sobre el estado del proceso. Sin embargo, la otra es que nos basamos en asegurar que los alcances se ha acertado el nombre, diseño, etc para realizar un seguimiento de dónde nos encontramos en el proceso. Sin embargo, en realidad, sólo puede tener una clave de algunos hitos que nos interesa, y estos abarcan varios ámbitos pueden o podemos tener más de un hito que figuran en el mismo ámbito.

Una alternativa es usar un índice para sostener el estado de la proceso, y sólo actualizar el estado del proceso mediante el método setIndex en los lugares adecuados en el proceso.

Obtener acceso a datos del proceso

Una vez que tenemos nuestra lista de los procesos de los casos, la fase final es tener acceso a los datos de hecho pertinentes que figuran en la instancia para mostrar al usuario de negocio .

Esto es simplemente el caso de la iteración a través de nuestra gama de ejemplo asas. Una vez que tienes la instanceHandle para un proceso, a continuación, puede utilizar este para acceder a las variables del proceso contenido en la instancia de proceso utilizando el método GetField.

No obstante, debe cuidar que todo lo variable que intenta acceder se encuentra visible en el ámbito de los activos el proceso. Me parece la forma más sencilla de hacerlo es definir una variable global (es decir, definir la variable a nivel del proceso) y puesta en él al principio del proceso basado en el contenido del mensaje inicial recibido por el proceso. Luego, durante la vigencia del proceso de actualización de la variable como sea necesario para reflejar el verdadero estado del proceso.

El siguiente fragmento de código muestra cómo podemos procesar cada instancia devuelta por la localización y acceso a la variable "LoanApplicationSummary" definido en el proceso BPEL.

/ / Buscar instancias
IInstanceHandle [] = instanceHandles locator.listInstancesByIndex (donde);

/ / Proceso de cada instancia
for (int i = 0; i instanceHandles.length <; i + +)
(
instanceHandle IInstanceHandle instanceHandles = [i];

/ / Obtener Solicitud de Préstamo Resumen variable
loanApplicationElement Elemento = (Element) instanceHandle.getField ("LoanApplicationSummary");

/ / Crear Solicitud de Préstamo Bean
loanApplication LoanApplication = LoanApplicationFactory.createFacade (loanApplicationElement);

/ / Proceso de Solicitud de Préstamo Bean como lo exige
...
)

Para acceder a la variable que utiliza GetField método en la instancia de la manija, como se muestra a continuación:

/ / Obtener Solicitud de Préstamo Resumen variable
loanApplicationElement Elemento = (Element) instanceHandle.getField ("LoanApplicationSummary");

Esto devolverá un DOM (Document Object Model), que representan el código XML contenido en la variable del proceso. Puede utilizar el API actual DOM para analizar y manipular el contenido XML, sino para cualquier estructura compleja que esto puede ser bastante complicado.

Para hacer este sencillo, Oracle BPEL Process Manager proporciona un modelo de objetos de Java ligero-como JAXB en la parte superior de XML, un modo llamada fachada XML. La fachada ofrece una-como antes de finales de frijol de Java para un documento XML / elemento. Fachada clases tienen una clase de fábrica correspondiente que analizar el documento XML / elemento para crear la fachada, como se muestra en el fragmento de código a continuación:

/ / Crear Solicitud de Préstamo Bean
LoanApplication loanApplication = LoanApplicationFactory.createFacade (loanApplicationElement);

Una vez que la fachada se ha creado, puede utilizar sus métodos getter para acceder a los datos requeridos.

Nota: Las fachadas son generados mediante la herramienta schemac enviado con Oracle BPEL Process Manager. Usted puede utilizar schemac para generar las fachadas de WSDL o XSD archivos (ver el Oracle BPEL PM guía para desarrolladores para más detalles).

Resumen

Como hemos visto Oracle BPEL PM proporciona una potente API de cliente que hace que sea relativamente fácil crear un negocio específicas "de la consola "adaptados a las necesidades del usuario.

Para más información sobre la API debería ver el Oracle BPEL Process Manager API del cliente de referencia

Escribir un proceso recursivo BPEL

Ahora La recursividad es un patrón de programación clásica, y, en teoría, debería ser bastante sencillo para un proceso para el sistema. Sin embargo, a primera vista no es tan evidente.

La cuestión aquí es que la forma en que un BPEL Process dice en voz alta a otro proceso es arrastrar un Link Partner a su BPEL Process y luego usar el servicio Examinador de seleccionar el proceso de despliegue que se desea llamada.

Por supuesto, con nuestro escenario, la primera cuestión que golpeó es que aún no hemos implementado el proceso como todavía estamos a escribir en él! Lo obvio de hacer aquí es crear un proceso trozo, con la base y recibir una justa respuesta de operaciones definidas y luego desplegar el talón. Esto funciona muy bien, ahora podemos seleccionar el proceso en el 'Service Browser "y terminar la aplicación del proceso.

Sin embargo, el siguiente problema se produce cuando tratamos de volver a implementar el proceso terminado. Aquí el despliegue falla con un error que no puede validar el WSDL para el Link Partner. El asunto aquí es que, como parte del proceso de implementación que son "sobre-escribir" la versión antigua trozo del proceso, con una nueva versión (ya que queremos mantener el número de versión de la misma).

La forma BPEL PM para alcanzar este objetivo, es un-instalar la versión anterior del proceso, antes de implementar la nueva versión. Como parte del despliegue, el motor BPEL valida el WSDL para todos los enlaces incluidos nuestros socios de la ONU desplegadas recientemente la versión del proceso y como resultado no!

Afortunadamente, existe una sencilla evitar. En primer lugar crear e implementar el proceso de sub como antes, a continuación, una vez desplegado ir a la consola de BPEL y seleccione el proceso desde el tablero de instrumentos. A continuación, seleccione la ficha WSDL y haga clic en la dirección de la ubicación de WSDL.

Esto abrirá un explorador que contiene el WSDL para el proceso de BPEL, guarde el archivo en el sistema de archivos local (Archivo-> Guardar como en IE) como. wsdl archivo. Ahora, cuando usted crea su Link Partner en el proceso, en lugar de utilizar el 'Navegador' el uso de servicios en "Examinar WSDL archivos de su sistema local de archivos 'y seleccione el archivo WSDL que acaba de guardar.

Nota: Cuando se le solicite hacer una copia local especificar ' sí ».

Desde aquí se podrá aplicar e implementar el proceso de BPEL sin ningún problema.

Ejemplo

He creado un proceso simple ejemplo, basado por supuesto en el ejemplo factorial clásico. Puede descargar este aquí.

Consideraciones de implementación

El único inconveniente de este enfoque es que el archivo WSDL contendrá ahora la ubicación de punto final para el servicio dentro de la misma. Así es que iban a implementar el proceso en un servidor diferente que sería un error en tiempo de ejecución.

Así que hay que modificar el archivo WSDL en tiempo de despliegue de manera que el punto final refleja el nombre y el número de puerto donde el proceso es en realidad se va a desplegar. La forma más sencilla de hacerlo es actualizar el script de manera que la hormiga de forma automática lo hará por ti.

Pensamiento Final

Ahora, en teoría, podría haber anidado increíblemente procesos que utilizan este enfoque, sin embargo le aconsejo es una mala práctica y es probable que tenga consecuencias en el rendimiento.

Por ejemplo, si nos quedamos el proceso para elaborar factorial factorial 50, que se traduciría en proceso de casos 50. Ahora bien, si espera que manejar 1000 proceso que se ejecuta en paralelo, esto daría lugar a 50.000 casos el proceso - por lo que el número real de instancia de proceso podría aumentar de manera muy dramática.

Así que se recomienda utilizar este método con precaución para asegurarse de que no dé lugar a un aumento dramático en el número total de instancias de proceso.

Uso de esquemas anidada dentro de BPEL

Cuando el desarrollo de cualquier solución basada en BPEL, pronto encontrará que usted está definiendo un conjunto común de objetos de datos que se utilizan en múltiples procesos.

El lugar más obvio para definir los objetos de datos se encuentra en uno o más esquemas XML que puede hacer referencia a cada uno de sus procesos BPEL.

Oracle BPEL PM 10.1.3 ofrece ahora la posibilidad de importar estos esquemas como parte del Proyecto de Creación de BPEL Asistente (en versiones anteriores se tuvo que importar el esquema después de que el proyecto fue creado - que se puede, por supuesto, todavía lo hacen en 10.1.3).

Todo esto funciona muy bien, sin embargo hay un problemita sencillo, que he visto coger una serie de personas, y ahí es cuando se importa el esquema, que ellos mismos esquemas de importación.

Tomemos un ejemplo sencillo. Un escenario común es tener un esquema que define los objetos comunes, tales como dirección, phoneNo, etc Esto sería compartida a través de esquemas de dominio específico múltiples tales como los clientes (por ejemplo, que importa el esquema común el uso de la dirección, el tipo phoneNo para celebrar el equivalente la información de un cliente).

Ahora bien, si iban a importar el esquema de los clientes en nuestra BPEL Process, por defecto, todos los que estamos importando son las definiciones contenidas en Customer.xsd. Esto causa problemas cuando tratamos de analizar el esquema de cliente como el analizador no puede hacer referencia a las definiciones en el esquema común.

La respuesta obvia es simplemente para importar el esquema común también. Sin embargo, esto no funciona. Para entender por qué vamos a ver las declaraciones de importación creadas en el elemento del archivo WSDL para el proceso BPEL:



La cuestión aquí es que cada uno de los esquemas ha sido importado en un "aparte" del esquema, por lo tanto el esquema común no es visible para el esquema del cliente. Sin embargo, para solucionar este problema, simplemente editar el archivo WSDL para combinar las importaciones en un solo esquema, como se ilustra a continuación:

Uso del correo electrónico para iniciar un proceso BPEL

El servicio de notificación en Oracle BPEL Process Manager te permite enviar una notificación por correo electrónico (así como mensajes de voz, fax, buscapersonas o SMS) desde un proceso BPEL.

Sin embargo, otro requisito es ser capaz de utilizar la recepción de un correo electrónico a iniciar un proceso BPEL. Este es el tema de este blog, muchas gracias a Muruga Chinnananchi en cuyo original se basa este ejemplo.

Esencialmente queremos crear un EMailActivation proceso simple que recibe un correo electrónico enviado a una dirección de correo electrónico en particular. Para ello hay dos pasos básicos:

1. Configuración del servidor de BPEL para poder conectarse a la cuenta de correo.
2. Definir el proceso BPEL que se iniciará a la recepción de un correo electrónico.
   

Nota: Descarga ejemplo de trabajo.

Configurar cuenta de correo electrónico

Para configurar la cuenta de correo electrónico que el servidor debe conectarse a BPEL, tenemos que colocar un archivo de configuración xml MailAccount (en nuestro ejemplo BpelMailAccount.xml) en el directorio siguiente:

\ BPEL \ domains \ \ default metadatos \ MailService

Nota: Usted tendrá que crear los metadatos y directorios MailService.

El archivo en sí mismo puede tener cualquier nombre (aunque debe terminar con. xml) como se puede definir de varias cuentas. Sin embargo tome nota del nombre ya que se necesita para enlazar su BPEL Process para la cuenta de correo real.

Aquí está nuestro archivo de ejemplo:



El servicio SMTP saliente no tiene que estar configurado (como usar el servicio de notificación para enviar sus correos salientes ). Sin embargo la cuenta entrante está definido por las siguientes etiquetas:


[protocolo POP3 o IMAP]
imap [o servidor POP3]
imap [o pop3 cuenta]
imap [o pop3 contraseña]
[sólo IMAP, la carpeta Bandeja de entrada]


Nota: la hora de definir el nombre de cuenta, tener cuidado de no utilización efectiva del nombre de la cuenta de la dirección de correo electrónico, ya que no son siempre los mismos.

Proceso de Creación de BPEL

El primer paso es usar JDeveloper para crear un proceso asincrónico iniciado por un mensaje de solicitud con una carga útil que contiene un elemento de tipo MailMessage (definido en el Correo . xsd instalado como parte de BPEL PM).

Para ello utiliza el Proyecto de Creación de BPEL asistente para crear un proceso BPEL de la forma habitual. Después de introducir el nombre del proceso y se indique la plantilla de proceso que se asincrónica, seleccione "Siguiente".

Esto le llevará al siguiente paso del asistente donde se especifica la entrada y salida de esquemas elementos, haga clic en la luz del flash para el esquema de entrada y seleccione Mail.xsd (ubicado en \ BPEL \ xmllib \ system) como se muestra en la figura 1 a continuación.

Figura 1 - Especificar de entrada y salida de elementos

Esta se abrirá la ventana de selector de tipo para seleccionar el elemento a utilizar en el esquema importado. Seleccione el elemento MailMessage como se muestra en la figura 2.

Figura 2 - Tipo de Selector

Una vez que el proceso se ha creado puede eliminar la actividad callBackClient ya que no lo necesitarán.

Común de importación de esquema

Si ahora tratar de compilar el proceso, usted encontrará que falla con un mensaje de error. Así es porque el propio Mail.xsd importa un esquema (common.xsd), por lo que es necesario importar este esquema también.

Para importar el esquema de correo en su BPEL Process, garantizar la vista del diagrama de su proceso de BPEL es abierto y seleccionado en JDeveloper. Luego, dentro de la estructura de ventana de BPEL, haga clic derecho en el nodo del proyecto de esquemas y seleccione "esquemas de importación" (como se muestra en la figura 3).

Figura 3 - Esquema de Importación

Nota: Una vez importada, actualice manualmente el archivo WSDL para garantizar las declaraciones de importación, tanto para el Mail.xsd y common.xsd están contenidas dentro de la misma elemento o todavía no podrá compilar. Ver blog anterior - Uso de esquemas anidados con BPEL para más detalles.

Mail Definir activación Agente

El proceso en sí ya está listo para su despliegue. Sin embargo nos falta para completar una actividad final, que consiste en atar el proceso BPEL a un agente de la activación de la cuenta de correo electrónico que hemos definido anteriormente.

El Agente de activación sondea al buzón de correo electrónico definido para mensajes de correo electrónico y luego por cada email que recibe invocar una instancia del proceso de manejarlo.

Para ello es necesario agregar la siguiente definición para el archivo bpel.xml, después de la elemento:


className ="com.collaxa.cube.activation.mail.MailActivationAgent"
heartBeatInterval ="60" >
name ="AccountName"> BpelMailAccount



Cuando heartBeatInterval es la frecuencia con que queremos para sondear la cuenta de correo electrónico de nuevos correos electrónicos, y la AccountName corresponde al nombre de la cuenta de configuración archivo que definimos anteriormente.

Por último implementar el proceso y enviar un correo electrónico a la cuenta correspondiente.

Gotcha! - Si modifica el proceso BPEL en JDeveloper, el archivo puede perder su bpel.xml cambios (es decir, la definición activationAgent), y como un resultado, el proceso nunca conseguirá inició - por lo que siempre compruebe el archivo bpel.xml se define correctamente antes de implementar el proceso.

Servidor de correo

Para hacer más fácil las pruebas, he instalado mi propio servidor de correo local. Para esto he utilizado James (que es un código abierto de Java Servidor de correo de Apache).

Instalación de James es muy sencillo simplemente descargarlo y descomprimirlo en una ubicación adecuada. Para iniciarlo, utilice la secuencia de comandos o run.bat run.sh, dependiendo de su sistema operativo en el james-2.3 .0/bin directorio.

Para configurar James acaba de llegar a una sesión de telnet (en el puerto 4555) para que aparezca la herramienta de administración remota desde la que puede crear las cuentas necesarias. Por ejemplo, para crear las cuentas de BPEL y jsmith (donde la contraseña es Welcome1) escriba lo siguiente:

JAMES remoto Herramienta de administración 2.3.0
Por favor, introduzca su nombre de usuario y contraseña
Login ID:
raíz
Contraseña:
raíz
Bienvenido raíz. AYUDA para obtener una lista de comandos
adduser Welcome1 BPEL
BPEL usuario añadido
adduser jsmith Welcome1
jsmith usuario añadido
listusers
existentes 2 cuentas
de usuario: BPEL
usuario: jsmith
salir
Bye

Seguimiento mensajes SOAP entre BPEL Procesos

Al depurar los procesos BPEL en algún momento puede ser muy útil para ver realmente los mensajes que fluyen entre los procesos.

Ahora, con frecuencia la pista de auditoría en la consola de BPEL proporciona información suficiente para ver que esta pasando, y haciendo clic en la invocación por caso, percibir una actividad o respuesta se puede ver el contenido de la carga útil que fue enviado o recibido.

Sin embargo esto es sólo la mitad de la historia, ya que no muestran detalles del mensaje de SOAP auténtico y, en particular los detalles, como los encabezados SOAP utilizado para WS-Security y WS -Addressing.

Ahora usted puede saber que Oracle BPEL PM buques obtunnel una herramienta para el seguimiento de los mensajes SOAP intercambiados entre dos partes, por ejemplo, entre BPEL y un servicio web externo.

Para los que no están familiarizados con obtunnel, es un monitor de TCP que funciona escucha en un puerto y luego reenviar el mensaje a otro (es decir, cuando el servicio efectivo se encuentra).

La forma más sencilla de configurar un proceso para llamar a un servicio web a través de obtunnel es establecer la propiedad ubicación en la de Asociaciones y volver a implementar el proceso de . El valor especificado aquí será reemplazar el punto final de servicio web especificado en el documento WSDL.

Esto funciona bien para las invocaciones de servicio indivdual. Sin embargo, si queremos controlar los mensajes entre varios procesos BPEL diferente, entonces tener que modificar socio enlaces múltiples a través de múltiples procesos puede ser muy tedioso y requiere que volver atrás y modificar todos ellos para corregir hay valor.

Además de los procesos asincrónicos que es más complicada, ya que el proceso llamante pasará una llamada de vuelta al proceso de localización invocado, que como consecuencia provoca respuestas a mediante su tarjeta de obtunnel-, por lo que no veo las respuestas a volver.

Lo ideal sería que lo que queremos es una manera simple de configurar BPEL PM a siempre ir a través de obtunnel cuando se llama a un proceso BPEL, sin la necesidad de realizar ningún cambio en la definición del proceso. Este es el tema de esta nota técnica.

Configuración del servidor de BPEL para usar como un proxy obtunnel

Oracle BPEL PM puede ser fácilmente configurado para utilizar un proxy, normalmente esto es para scenrios como la colocación de una puerta de enlace HTTP en frente de un servidor de BPEL. Sin embargo, podemos utilizar el mismo método para establecer obtunnel como proxy.

Para lograr esto, necesitamos establecer dos propiedades; soapServerUrl y soapCallbackUrl en el archivo de configuración del servidor.

soapServerUrl

Esta dirección se publica como parte de la dirección SOAP de un proceso en el WSDL archivo.

El nombre del host y el puerto para esta URL debe ser personalizado para que coincida con el anfitrión y el puerto de escucha de la instancia de obtunnel. Asumiendo que se están ejecutando obtunnel en la misma máquina que su BPEL Server, sólo tiene que cambiar el número de puerto.

soapCallbackUrl

Esta URL es enviado por el proceso (con WS-Addressing) como parte de la dirección de devolución de llamada asincrónica para decirle al receptor de la solicitud donde enviar la respuesta al.

Una vez más el nombre de host y el puerto para esta URL debe ser personalizado para que coincida con el nombre y el puerto de escucha de la instancia de obtunnel, de modo que debe tener el mismo valor que soapServerUrl.

La forma más sencilla de establecer estas propiedades se encuentra en la pestaña de configuración de BPEL administrador (para acceder a esta entrada en la pantalla de la consola de BPEL BPEL goto seleccione Administrador). Una vez configurado, necesitará reiniciar su BPEL Server.

Nota: Usted tendrá que volver a implementar todos los procesos actualmente desplegados en el servidor para que puedan volver a ser compilado (por ejemplo, generar WSDL) con las direcciones correctas.

Configuración del dominio BPEL

Una vez que hemos configurado el servidor, cualquier llamada externa de un proceso que ahora tendrán acceso tanto el WSDL y el servicio a través de la dirección del proxy.

Sin embargo, el comportamiento predeterminado de un proceso es pasar por alto este poder, ¿por qué? Bueno en realidad por razones de rendimiento, sino que simplemente no tiene sentido para un proceso para llamar a otro proceso a través de SOAP como la sobrecarga sería grande, más bien un proceso, simplemente llama a otro proceso a través de una llamada directa en la memoria de Java que es mucho más rendimiento .

Sin embargo, para nuestro propósito, podemos desactivar esta opción mediante el establecimiento de la optSoapShortcut propiedad en false. El más simple de configurar esto es en la consola de BPEL, haga clic en Administrar dominio BPEL (esquina superior derecha), y, a continuación, actualice la propiedad en la pestaña de configuración.

Nota: En la versión 10.1.3.0.1, esta propiedad no está realmente especificado en el archivo de configuración del dominio, por lo que tendrá que agregar manualmente al archivo de configuración de Domin, que se encuentra en:

[] bpel_home / domains / domain] [/ config / domain.xml

Una vez añadido tendrá que volver a arrancar el motor que para recoger el cambio (a partir de entonces se puede modificar la forma habitual en la pestaña de configuración de dominio).

Correr obtunnel

La forma más sencilla de ejecutar obtunnel, es poner en marcha el desarrollador del sistema BPEL, esto simplemente lanza una línea de comandos con todo el ambiente adecuado varaiables conjunto. A partir de aquí, simplemente escriba el comando obtunnel.

Una vez puesto en marcha sólo tiene que especificar el puerto que se va a escuchar y, a continuación el nombre de host y el puerto de su BPEL Server.

Resumen

El uso de este enfoque que usted puede monitorear fácilmente los distintos mensajes SOAP entre los procesos, sin la necesidad de realizar ningún cambio real en la configuración del proceso. Todo lo que se necesita es para implementar en una versión del servidor de BPEL PM configurado para utilizar el proxy.

Nota: Si usted desarrolla sus Procesos BPEL contra el "Proxy BPEL PM Server", a continuación, los lugares en el WSDL del Socio contendrá la hostia y N º de puerto del proxy del servicio. Esto no suele ser un problema, ya que volver a configurar estas como parte del proceso de implementación de los procesos a una prueba / producción BPEL PM Server.