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.

La obtención de un WSDL implementados 10g BPEL Process

Este señor Antony Raynolds tiene una visión muy interesante de una arquitectura Orientada a Servicios,Surfeando en su blog encontrè este ejemplo, lo cual quiero compartir con ustedes y que tambien lo pueden encontrar en su libro SOA Suite de Oracle Developer's Guide

Aqui les va de manera textual...

Siempre hablamos de las virtudes de la articulación flexible con SOA, y la interfaz de servicio es un componente clave de esto. A menudo es necesario extraer la interfaz de servicio de un proceso BPEL desplegados con el fin de llamar al proceso, o recurrir a algunos de los cerca de de los mismos servicios que las llamadas proceso BPEL. Al implementar un proceso BPEL tanto el WSDLs desarrolla el proceso y el WSDLs invocado por el servicio están disponibles a través de la consola de BPEL.

Navegando a su proceso

La obtención de la WSDLs de un proceso es muy fácil. Entra en BPEL consola y seleccione la pestaña procesos.

image

A continuación, seleccione el proceso deseado.

image

Esto mostrará los detalles del proceso.

Obtener el WSDL aplicado por Nuestro Proceso

Para obtener la interfaz WSDL para el proceso haga clic en la ficha WSDL. Asegúrese de que tiene la versión correcta seleccionada.

image

Con ello se abre el WSDL asociado con el vínculo de socio a cabo por este proceso.

La obtención de la WSDLs Llamado por Nuestro Proceso

Para obtener la WSDLs convocada por el proceso, entonces vaya a la pestaña de descriptores.

image

Esto proporciona una lista de todos los vínculos socio en el proceso BPEL, incluido el socio enlaces a cabo por el proceso BPEL.

Desde aquí podemos seleccionar el WSDL que se necesita. También podemos ver las propiedades asociadas con el enlace asociado.

Tenga en cuenta que muchas veces el diseñador de BPEL se han creado un WSDL contenedor que añade información interlocutor de enlace que es requerido por BPEL. Si este es el caso, y será el caso de los documentos WSDL más externa, es necesario examinar el envoltorio WSDL y extraer el atributo de ubicación de la declaración de importación de WSDL.

image

Esto puede ser conectado a la envoltura de URL de WSDL para proporcionar el servicio real WSDL. Usuall esto también se puede obtener mediante la eliminación de la Ref. "suficiente de la relación socio WSDL.

image

Esto proporcionará el WSDL real que está siendo utilizado por nuestro proceso BPEL, más que el envoltorio que hace referencia a ella.

¿Por qué molestarse?

¿Por qué ir a todos estos problemas, ¿cuál es el valor en la obtención de la WSDLs empleado por un proceso BPEL?

Bueno hay varias razones. Algunos se describen a continuación

  • Puede haber diferencia de comportamiento entre los diferentes entornos y queremos confirmar que están utilizando las mismas definiciones WSDL.
  • Tal vez tengamos que crear un entorno de pruebas que nos obliga a emular a los servicios de WSDL proporcionan.
  • Es posible que desee verificar los detalles de punto final para garantizar que somos capaces de navegar a través de servidores de seguridad en nuestro entorno.
  • No puede tener acceso inmediato al proyecto BPEL y desea comprobar algunas configuraciones de interfaz WSDL.
  • Sólo puede ser entrometido!

Descargue el proceso BPEL Plenario

También es posible descargar toda la maleta BPEL (empaquetado proceso), seleccionando la pestaña Administrar del proceso que desea descargar en la pestaña Procesos.

image

En la parte inferior de esta pantalla podemos descargar la maleta haciendo clic en el botón Exportar proceso. Esta descarga de la maleta en un archivo zip.

Resumen

A menudo estamos viendo los procesos en funcionamiento sin fácil acceso al proyecto original de JDeveloper. A través de la consola de BPEL se puede comprobar tanto individuales como interfaces WSDL y descargar toda fuente de BPEL, por lo que es fácil comprobar lo que está sucediendo. Así que recuerda, la próxima vez se enfrentan a un comportamiento extraño y quieren verse en la fuente o detalles BPEL interlocutor de enlace, no es necesario llamar a los desarrolladores!

Software necesarias para el ensayo de Cluster Server 11g SOA

En mi última entrada hablé de algunas de las trampas que están involucradas en la creación de un clúster. En las entradas siguientes, voy a describir cómo construir una SOA Suite 11g de racimo para su uso en un entorno de prueba. En esta entrada vamos a vistazo a la arquitectura de destino y el software necesario.

Meta Arquitectura

Voy a construir mi grupo 11g en 3 máquinas.

  • Máquina de DB será la sede de una base de datos 11gR1. Yo también lo usará para alojar un equilibrador de carga de software (usaré WebCache).
  • Máquina SOA1 acogerá dos instalaciones WebLogic. Una instalación de WebLogic 11g tendrá un dominio único de alojamiento SOA un clúster de SOA Suite, incluyendo BAM. WebLogic Un 10,3 instalación tendrá un único dominio de alojamiento OSB OSB un clúster.
  • Máquina SOA2 tendrá el mismo software que SOA1 y recibirá los mismos dos dominios.

Cuando OSB 11g se libera entonces la necesidad de dos instalaciones separadas WebLogic desaparecerán a medida que la intención es que OSB y el resto de SOA Suite para ejecutarse en la versión de WebLogic mismo software.

Como hay dos dominios WebLogic continuación, voy a correr un servidor de administración en cada máquina, un servidor de administración de dominios en SOA1 y el servidor de otros dominios admin el SOA2. Esto ayuda a reducir la huella de memoria.

Lógicamente, la arquitectura se muestra a continuación con un equilibrador de carga de la distribución de carga a través de la SOA y las agrupaciones OSB con una base de datos 11g backend.

LogicalCluster

En cuanto a las pruebas no tengo un balanceador de carga de hardware entonces corro el balanceador de carga en la misma máquina que la base de datos para dar la arquitectura física se muestra a continuación.

PhysicalCluster

Voy a ejecutar esta en 3 máquinas virtuales en un servidor con 8 GB de memoria, permitiendo que 2 GB para cada máquina virtual.

Como un gran número de clientes parecen estar corriendo Linux en estos días voy a utilizar Oracle Enterprise Linux 5.3. Usaré Linux de 64 bits para la máquina de DB y 32-bit Linux para las máquinas de SOA.

Es bastante común que los grupos a utilizar una base de datos de CCR en lugar de una base de datos de instancia única, pero eso fue una máquina virtual me sobra para sacarlo de mi cabeza.

Software necesario

Así que ahora hemos identificado la arquitectura lógica y física que necesitamos para identificar el software que se requieren. El software utilizado es todo disponible para descargar en OTN haciendo clic en el enlace de software como se muestra en la tabla de abajo. Nuestro equipo de destino para el software es también se muestra en la tabla.

Software

Propósito

Objetivo

Notas

Oracle WebLogic Server 11g Rel 1Requerido para SOA SuiteSOA1, SOA2
SOA SuiteNúcleo SOA SuiteSOA1, SOA2
Oracle 10gR3 Service BusServicio de autobusesSOA1, SOA2versión 11g estará disponible en breve.
UAB utilidad de creación deCrea repositorio de meta-datos para SOA SuiteDBSe puede ejecutar desde cualquier equipo con acceso a la red de base de datos.
Oracle Database 11g Release 1Sostiene Meta-Data repositorio para SOA SuiteDBCualquier base de datos certificada con SOA Suite se pueden utilizar.
Utilidades Web TierWeb contiene la memoria caché para su uso como un equilibrador de cargaDBOtro equilibrador de carga puede utilizarse.
Enterprise LinuxSistema OperativoSOA1, SOA2, DBCualquier sistema operativo certificado con base de datos o SOA Suite se pueden utilizar. Máquina PP puede ser un sistema operativo diferente a las máquinas de SOA.

Equilibrio de carga

Hay un número de programas disponibles y equilibradores de carga, incluyendo la funcionalidad incorporada en Linux, ¿por qué usé WebCache. Bueno, hay una serie de razones.

  1. Me gusta WebCache
  2. Tiene una agradable interfaz de usuario basada web para configurar y supervisar
  3. Apoya cookie afinidad basada (ver post anterior por la importancia de esto)
  4. Se hace el trabajo

Sólo tenga cuidado al utilizar WebCache con SOA Suite que no lo uso a los datos de la caché. Que yo sepa no hay pruebas de que se ha hecho dentro de Oracle con el uso de WebCache en relación con SOA Suite 11g, así que no incorporar este sistema en un entorno de producción.

Tengo que confesar que la idea de usar WebCache como un equilibrador de carga no era mío, pero mi colega Nick Cosmidis, por lo que Nick gracias.

Otros recursos

La creación de un clúster requiere almacenamiento compartido, ideal para el hogar de dominio, sino también para los recursos compartidos, tales como almacenes de mensajes JMS. Podría haber usado un aparato de iSCSI para ofrecer esto, pero yo optó por utilizar la máquina de DB como un servidor de archivos compartidos para el componentes de nivel medio.

El grupo también exige que las direcciones IP. Obvios, pero hay requisitos diferentes para las direcciones IP. La dirección IP para el equilibrador de carga debe una ruta desde todos los clientes del clúster. La base de datos, SOA Suite y OSB casos puede tener sin enrutamiento IP direcciones, siempre y cuando pueden hablar unos con otros y el equilibrador de carga. Los clientes no tienen que ser capaces de acceder a la base de datos, SOA Suite o directamente OSB, ya que pasará por el balanceador de carga.

Virtualización

Estoy ejecutando esto en un entorno virtualizado, una sola máquina de 8 GB de alojamiento las tres máquinas. El software de virtualización sólo el pleno apoyo de Oracle Oracle es la máquina virtual. Esto no quiere decir que no funciona en otros entornos de virtualización de software como VMware, sólo que no es que totalmente compatible con los entornos. Para obtener más información sobre el apoyo de la política de Oracle con respecto a la virtualización en general, controlen a cabo este enlace . Para información específica sobre VMware ofrece soporte a continuación, comprobar Nota 249212,1 en de MetaLink.

Cosas que debe saber al aplicar un parche adaptadores para SOA Suite

Es posible que haya visto algunos errores como ClassNotFound, MethodNotFound o NullPointerException después de aplicar un parche que contiene la corrección de errores para Oracle Application Server tecnología de adaptadores, como el DB Adapter, adaptador AQ, etc En este artículo se explica por qué se produce tal error y qué solución podría utilizar para resolver este problema ..

En primer lugar, echemos un vistazo en el directorio de instalación de adaptadores y de sus estructuras en Oracle SOA Suite 10.1.3.x.

Cuando los adaptadores se desplegó por primera vez al servidor de aplicaciones, archivos rar adaptador será copiado en Inicio diferentes adaptador que es de $ ORACLE_HOME/j2ee / / Conectores / , Donde es el nombre del contenedor SOA, y es el directorio creado para cada adaptadores para almacenar archivos binarios y los descriptores de despliegue. A continuación, el servidor de aplicaciones que va a extraer estos archivos rar en un subdirectorio que contiene un archivo jar con todas las clases de java compilado, y una carpeta donde META_INF los descriptores de despliegue, como ra.xml, OC4J-ra.xml o weblogic ra.xml- se almacenan. Todos estos archivos serán mantenidos por el servidor de aplicaciones que se sabe cuándo volver a cargar la vesion nuevas de estos archivos mediante la comparación de las marcas de hora.

Cuando se intenta aplicar un parche para estos adaptadores. Opatch sólo se actualizará el archivo RAR con el archivo jar parcheado, pero no el archivo jar en el subdirectorio adaptador en adaptador de Interior. En situación normal, el archivo jar debe estar sincronizado con el de archivo rar, pero en algunos casos, especialmente cuando las marcas de tiempo de información para el rar y jar se corrompe, servidor de aplicaciones no será capaz de identificar los cambios realizados en el rar archivo, y hará que la inconsistencia entre el rar y jar.

¿Cómo resolver este problema? para asegurar el archivo jar siempre me actualiza correctamente después de un nuevo parche se aplica, como una buena práctica, se debe eliminar manualmente la carpeta de adaptador y la fuerza el archivo jar generado por servidor de aplicaciones.

Otra práctica es que vosotros todos los días debe tener una copia de seguridad los archivos de descriptor de despliegue antes de aplicar el parche contiene correcciones para los adaptadores. Se debe a que los archivos antiguos serán sustituidos por el predeterminado, y su configuración anterior se perderá.

Como habilitar el registro para depurar problemas de seguridad BAM 11g

Para depurar BAM 11g Las cuestiones de seguridad, tales como la autenticación de usuarios o la autorización, se recomienda establecer oracle.bam.adc.security y oracle.bam.common.security madereros para FINEST, entonces revise el ORACLE_HOME / user_projects / domains / / Servers/bam_server1/logs/bam_server1-diagnostic.log para más información.

Cómo notificar por correo electrónico en BPEL 10.1.3.3

Este artículo explica cómo funciona el correo electrónico de notificación en BPEL 10.1.3.3

Es un paso de procesamiento asíncrono con el motor BPEL dos asas de la actividad de correo electrónico de notificación.
  • Creación de notificación y persistencia - BPEL Process Manager primero crear un aviso de un objeto, incluso NotificationID única, notificación y otras propiedades de carga del mensaje, e insertar los detalles de notificación a la tienda de deshidratación BPEL, a continuación, se enviará un vacío de mensajes JMS con la notificación a la propiedad ID una cola interna para notificar que el mensaje esté listo para la entrega.

  • Notificación de entrega - Cuando el mensaje llega JMS en la cola, un hilo de MDB se asignarán y consume el mensaje. En el OnMessage () de los bancos multilaterales de desarrollo, se tratará de consulta de la tienda deshidratación habida cuenta de la notificación de identificación, a continuación, enviar los datos de notificación a través del correo electrónico de canal configurado previamente. Tenga en cuenta que la entrega de mensajes que ocurre en un subproceso independiente que el hilo de ejecución BPEL.

Por lo tanto, hay dos temas diferentes que se encargan de la persistencia de la notificación y entrega de correo electrónico, respectivamente. motor BPEL tiene que resolver la manera de coordinar los hilos de ejecución, de lo contrario la condición de carrera podrían ocurrir. Por ejemplo, cuando llega el mensaje del sistema anterior a la confirmación de la transacción para la inserción de notificación en la base de datos, el hilo MDB se iniciará en primer lugar, ya que los datos no fueron aprobadas, sin embargo, el identificador de notificación no puede ser recuperada mientras buscaba las tablas de Notificación de la MDB hilo. En este caso, la notificación por correo electrónico se producirá un error.

El escenario anterior puede funcionar muy bien en la situación normal, pero si hay algún fallo de la debida notificación al servidor de correo electrónico abajo, o problemas de red, etc BPEL lo puede hacer al respecto?

Un planificador de cuarzo se utiliza en BPEL 10.1.3.3 para manejar esta situación. Un planificador de cuarzo se iniciará un hilo que se ejecutará cada 15 minutos por defecto para enviar un lote de envases vacíos de mensajes JMS con identificadores únicos a la cola de JMS. Pero esta vez, no hay persistencia de mensajes, en cambio, los identificadores de la notificación se obtienen mediante la consulta el almacén de la deshidratación en el estado es o reintentar o SEND. En otras palabras, si hay registros en la base de datos donde el Estado es reintentar o SEND, estos registros se convertirán en candidatos a entregar. hilo MDB entonces buscará detalles de la tienda de deshidratación mensajes y entregarlos a través de correos electrónicos. En la fase de entrega, será comprobar cómo muchas veces el servidor ha intentado entregar el mensaje, el intento máxima es de 3 por defecto. Si todos estos intentos fallan, se actualizará el estado de esta notificación en el almacén de la deshidratación a error

las siguientes dos propiedades pueden ser configuradas en SOA_Oracle_Home/ BPEL / system / servicios / config / wf_config.xml.

  • oracle.bpel.services.notification.maxattempt - valor por defecto es 3. La propiedad es el uso para controlar los intentos de un máximo de MDB se expedirá un aviso de notificación identificado por el ID. Si los intentos máxima se alcanza, el estado de notificación se ha cambiado a "ERROR", de lo contrario, el estado será cambiado a "Intentar de nuevo.

    Si la notificación es "ERROR" de estado, la única manera de volver a intentar la entrega de mensajes, es ejecutar el siguiente script para actualizar el BPELNotificationestado de tabla para RETRY. Por ejemplo:

    UPDATE BPELNotification
    de SET status = 'RETRY',
    ATTEMPTEDNUMBER = 0
    WHERE ID = <>

  • oracle.bpel.services.notification.publisher_interval - el valor por defecto es 15 (minutos). Esta propiedad se utiliza para indicar la frecuencia con un trabajo de programador de cuarzo se llevará a cabo la búsqueda de la notificación a entregar y enviar mensaje de notificación a través de JMS vacío. El valor por defecto debería ser suficiente en casos más. Si hay un montón de errores en la entrega de mensajes o desea que el programador para empezar con más frecuencia, entonces usted puede reducir este valor.

    Pero si la propiedad es un valor muy pequeño, por ejemplo, 1 (minuto), entonces hay una posibilidad de que usted conseguirá duplicar los mensajes enviados al servidor de correo electrónico. Aquí hay un escenario que podría suceder en el mundo real.

    BPEL PM Cuando los procesos de la actividad de notificación, se deshidrata los detalles de notificación y que la notificación se convierte en un candidato a MDB para entregar. Supongamos que la entrega no ha terminado de procesar, con lo que el registro de notificación todavía reside en el almacén de la deshidratación con el estado "SEND". Si el trabajo de programador de cuarzo se ejecuta al mismo tiempo, también se recogerá la misma notificación como candidata a entregar, causando así la duplicación de mensajes enviados por bancos multilaterales de desarrollo

Esperemos que este artículo puede ayudarle a entender cómo el servicio de notificación trabaja en BPEL. Si tiene alguna duda, por favor, puesto que aquí, voy a intentar mi mejor esfuerzo para responder. Si tiene algún problema con el correo electrónico de notificación, los errores, es muy recomendable para ir a la consola de BPEL y establecer registrador collaxa.cube.services de depurar, a continuación, comprobar el ORACLE_HOME / OPMN / logs / para más información