Archivo
Regular los registros procesados por un DBAdapter polling
En este post se explicarán las propiedades del adaptador de base de datos de Oracle (para la SOA Suite y el OSB) que nos permiten regular el número de registros procesados en cada poll.
Para configurar de forma óptima la regulación, es necesario tener en cuenta las siguientes 3 propiedades:
<property name="PollingInterval" value="segundos"/> <property name="MaxRaiseSize" value="elementos"/> <property name="MaxTransactionSize" value="registros"/>
Veamos el significado de cada una:
- PollingInterval: Segundos entre consultas a la base de datos.
- MaxRaiseSize: Cantidad de elementos XML creados por instancia.
- MaxTransactionSize: Cantidad de registros a procesar en cada consulta a la base de datos.
A modo de ejemplo, si disponemos de 1000 registros a procesar y realizamos la siguiente configuración:
<property name="PollingInterval" value="60"/> <property name="MaxRaiseSize" value="20"/> <property name="MaxTransactionSize" value="100"/>
conseguiríamos una ejecución por minuto, que recuperaría 100 registros, generando 5 instancias con 20 registros en cada petición XML (100/20).
Una gran diferencia entre las propiedades de MaxRaiseSize y MaxTransactionSize puede afectar al rendimiento de nuestro proceso, por lo que se recomienda mantener un ratio de hasta 1:10, intentando, siempre que sea posible, acercarse al 1:1.
Cabe mencionar que con bases de datos no-Oracle se han encontrado comportamientos dispares. En estos casos conviene revisar la documentación del driver utilizado, para comprobar que dicho comportamiento esté soportado.
Cabeceras personalizadas y procesos Oracle BPEL
En el momento de definir nuestros servicios web, nos podemos encontrar con la necesidad de incluir cabeceras personalizadas que aporten información añadida a las distintas operaciones del mismo.
Si estos servicios van a ser consumidos por una aplicación SCA, como puede ser un proceso BPEL, recomiendo seguir el siguiente consejo: incluir nuestra cabecera en la definición el mensaje.
Seguimos el orden de definición del WSDL para explicar nuestro caso. Si nos ceñimos a los elementos del contrato que nos conciernen, empezamos por la definición de mensajes.
Es común crear un mensaje que represente nuestra cabecera personalizada para reutilizarlo e implementar el siguiente formato:
<wsdl:message name="HeaderPersonalizado"> <wsdl:part name="cabecera" element="client:miCabecera"/> </wsdl:message> ... <wsdl:operation name="operacion1"> <soap:operation style="document" soapAction="http://xmlns.Avanttic.com/Blog/HeaderPersonalizado/operacion1"/> <wsdl:input> <soap:body use="literal" parts="payload"/> <soap:header message="client:HeaderPersonalizado" part="cabecera" use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal" parts="payload"/> </wsdl:output> </wsdl:operation>
Aún siendo correcto, generar un contrato con este formato implica que el envío de la cabecera desde un proceso BPEL sea ligeramente más complejo. Veamos los pasos que realizaríamos para este caso:
- Generar una variable del tipo miCabecera:
<variable name="miCabecera" element="client:miCabecera"/>
- Asignar los valores correspondientes a la cabecera mediante la actividad Assign.
- Asignar esta variable a la cabecera de la actividad Invoke.
En este punto nos encontramos con la particularidad de que la IDE de JDeveloper no permite realizar este paso y es necesario acceder al código fuente de la actividad y agregar la propiedad bpelx:inputHeaderVariable:
<invoke name="Ejecutar" partnerLink="ServicioWeb" portType="client:HeaderPersonalizado" operation="operacion1" inputVariable="Ejecutar_InputVariable" outputVariable="Ejecutar_OutputVariable" bpelx:invokeAsDetail="no" bpelx:inputHeaderVariable="miCabecera"/>
Veamos ahora otra forma de pasar nuestra cabecera siguiendo la recomendación inicial: incluir la cabecera en la definición del mensaje.
Leer más…
Probando, probando… compatibilidad con Internet Explorer
Todo buen desarrollador web disfruta de los estándares y, sobretodo, de cómo cada navegador web decide interpretarlos y ceñirse a ellos.
Uno de los personajes principales, históricamente hablando, a la hora de comprobar visualmente nuestros desarrollos suele ser Internet Explorer. Para contextualizar un poco esta afirmación nos podemos fijar en la siguiente tabla que resume las estadísticas de uso de los distintos navegadores en los últimos 10 años según w3schools.com:
| Año | Internet Explorer | Firefox | Chrome | Safari | Otros |
|---|---|---|---|---|---|
| 2002 | 83,4 % | - | - | - | 16,6 % |
| 2005 | 68,9 % | 23,6 % | - | - | 7,5 % |
| 2008 | 46 % | 44,4 % | 3,6 % | 2,7 % | 6 % |
| 2010 | 27,5 % | 43,5 % | 22,4 % | 3,8 % | 2,8 % |
| 2012 | 15,1 % | 31,2 % | 46,3 % | 4,4 % | 3 % |
Si bien es cierto que hoy en día Internet Explorer ha perdido gran parte del delicioso pastel de usuarios que llegó a tener, hay que tener en cuenta que los usuarios suelen ser reacios al cambio, sobre todo si nos enfrentamos a usuarios de tipo corporativo.
Para la incomprensión de nuestro friki interior, aún quedan usuarios que navegan con IE6 o algún otro navegador prehistórico que no se ha logrado erradicar, pero somos buenas personas y queremos que todo usuario pueda navegar felizmente por nuestras aplicaciones web.
El principal interesado en que así sea es, obviamente, Microsoft, y para ello nos proporciona un interesante conjunto de Power PCs (máquinas virtuales ejecutables por Windows) con las versiones de Internet Explorer instaladas en los correspondientes sistemas operativos vigentes en el momento de su lanzamiento. También nos presentaron un conjunto de herramientas integradas en el propio navegador que decían comprobar la compatibilidad con versiones anteriores, pero se ha visto que no siempre son de fiar. Abrir el navegador original, seguro que no falla!
A continuación os dejo el enlace para que podáis ayudar a todos esos usuarios rezagados a disfrutar de vuestras creaciones:
Internet Explorer Application Compatibility
Y vosotros, ¿de qué herramientas echáis mano para comprobar la compatibilidad?
typeswitch: XQuery con elementos de tipo choice
El desarrollo de servicios en OSB (Oracle Service Bus) suele conllevar la necesidad de transformar datos mediante XQuery. En este post se presenta un caso concreto, con el fin de agilizar dichos desarrollos.
La función typeswitch nos permite tratar elementos XML de tipo choice. Estos elementos proporcionan un conjunto limitado de posibles elementos de nivel inferior al consumidor de dicho contrato.
En el momento de acceder al contenido del documento generado, podemos hacer uso de esta función XQuery. Se define el conjunto de posibles elementos que puede contener y el valor a devolver en cada caso:
- Definición:
<xsd:complexType name="telefono"> <xsd:choice> <xsd:element name="fijo" type="xsd:string"/> <xsd:element name="movil" type="xsd:string"/> <xsd:element name="extension" type="xsd:string"/> </xsd:choice> </xsd:complexType>
- Función XQuery:
...
typeswitch ($telefono/( ns0:fijo | ns0:movil | ns0:extension ))
case $fijo as element(ns0:fijo)
return
concat("El teléfono fijo es: ",$fijo)
case $movil as element(ns0:movil)
return
concat("El teléfono movil es: ",$movil)
case $ext as element(ns0:extension)
return
concat("La extensión telefónica es: ",$ext)
default
return ()
...
Incluido dentro de un bucle, nos permitiría obtener todos los datos de contacto de un usuario con repeticiones de cada uno de los elementos, por poner un ejemplo.
Consumir o exponer servicios REST con Oracle Service Bus 11g
Con Oracle Service Bus 11g es posible consumir servicios REST con el fin de integrarlos en la lógica de un proceso de negocio interno o de exponerlos mediante una interfaz SOAP. Cualquiera que sea la intención, el proceso resulta sencillo mediante los pasos expuestos en esta entrada.
En el ejemplo, el servicio REST recibe los parámetros por cadena de consulta (Query string) y devuelve un XML con el resultado de la ejecución.
Primero se ha de crear un servicio de negocio (business service):
- El tipo del servicio ha de ser Servicio de Mensajes (Messaging Service):
Tipología del servicio de negocio
- Para los mensajes, tanto de petición como respuesta, seleccionar XML:
Tipología de los mensajes de petición y respuesta
- Agregar la URI del servidor en el cual se encuentra el servicio a consumir.
- Si se desea o es necesario, modificar el resto de parámetros. En este caso se dejan por defecto.
Arquitectura orientada a componentes (SCA): El enfoque de Oracle
En la versión 11g, Oracle ha rediseñado su SOA Suite integrando la arquitectura orientada a componentes (SCA por sus siglas en inglés) al desarrollo de aplicaciones. La finalidad principal del cambio es reducir la dificultad en las fases de desarrollo, despliegue y gestión de las aplicaciones SOA, que han ido ganando en sofisticación y complejidad a lo largo del tiempo.
¿Qué es SCA?
La complejidad de los sistemas actuales y sus necesidades a la hora de desarrollar servicios, impiden una rápida puesta en marcha de los desarrollos. La arquitectura orientada a componentes es una especificación que define cómo crear y ensamblar los diversos componentes de negocio como componentes modulares, con la finalidad de incrementar la flexibilidad y facilidad de mantenimiento de los sistemas de información.
Acogiendo el símil de una placa base de PC, la arquitectura SCA está formada por componentes internos integrados entre sí, que se comunican con sistemas externos mediante conectores, todo ello a través de cables (wires). Ya sea en grandes sistemas SOA (Enterprise SOA) como pequeños (uso de Web Services para conectar sistemas), la pieza restante es un estándar que agrupe los servicios individuales en un servicio compuesto de alto nivel. Esta pieza es SCA.
Oracle, junto con otros fabricantes de software, ha formado parte de la creación de este estándar bajo el patrocinio del Open SOA Group. Actualmente es el consorcio OASIS el que se encarga de mantenerlo y evolucionarlo.
Oracle SCA
El principal beneficio de implementar SCA en Oracle SOA Suite 11g es la simplificación del ciclo de vida de las aplicaciones desde el desarrollo, pasando por el despliegue y su posterior gestión. La herramienta JDeveloper que Oracle pone a disposición de los desarrolladores, permite crear e integrar todos aquellos componentes necesarios para crear aplicaciones compuestas, con SCA como framework de unión. El plug-in para desarrollos SOA de JDeveloper hace que entender y desarrollar aplicaciones compuestas sea sencillo e intuitivo, agrupando las diferentes piezas o componentes de la aplicación en un único elemento denominado composite, siendo éste el único elemento a desplegar mediante un fichero SAR.
Todo esto se traduce en varios beneficios tangibles en el diseño, ejecución y posterior gestión / monitorización.
Los tres elementos principales que apoyan el desarrollo de aplicaciones compuestas SCA son:
- Herramienta de desarrollo en JDeveloper
- Infraestructura de ejecución unificada en SOA Suite
- Capacidad de gestión y configuración desde Enterprise Manager
La infraestructura unificada se presenta como un conjunto de motores de ejecución que proporcionan la funcionalidad necesaria para la ejecución de los elementos que componen el compuesto SCA (BPEL, Reglas de negocio, invocaciones, etc.).
Conectores
Debido a la naturaleza y filosofía que ha generado el estándar, es obvia la necesidad que puede encontrarse de integrar sistemas de terceros con las aplicaciones compuestas. Por defecto la SOA Suite 11g provee un conjunto de conectores tales como mySAP, PeopleSoft, Siebel, CICS, Tuxedo, etc. Todos estos conectores están desarrollados, siguiendo con la filosofía de utilizar estándares, en Java EE Connector Architecture (JCA) permitiendo el desarrollo de conectores propios integrables en los desarrollos.
La evolución de SOA a SCA llega con la ventaja principal de agrupar los distintos elementos que componen las aplicaciones compuestas de manera ordenada y proporcionando claridad sobre la interacción, tanto interna como externa, de todos sus componentes.Con Oracle SOA Suite 11g, se obtienen las herramientas necesarias para adentrarse en el desarrollo basado en componentes. Su herramienta de diseño, presentada como plug-in de JDeveloper, permite obtener una visión clara y sencilla de las aplicaciones composite, a la par de simplificar el desarrollo de las mismas.
Ejecutar un servicio securizado desde otro Proxy Service
Recientemente nos hemos encontrado con la necesidad de ejecutar, desde un Proxy Service, una operación en un servicio securizado con Oracle Web Service Manager (OWSM). Desde un Proxy Service, no podemos especificar las credenciales a utilizar en la invocación o enrutado a otro servicio proxy.
La solución planteada e implementada ha sido la de crear un Business Service con un Service Account asociado que haga de intermediario entre ambos servicios, consiguiendo así especificar las credenciales para el consumo de dicho servicio
Crear Service Account
Dado que se pretende ejecutar una operación en un servicio securizado, se ha de crear una Service Account (cuenta de servicio si tenemos el entorno traducido) con las credenciales necesarias, en nuestro caso y con la finalidad de simplificar el ejemplo, de tipo estático.
Generar Business Service
Creadas las credenciales, es cuestión de crear un servicio de negocio o Business Service para que haga de puente entre nuestros dos servicios proxy. En el apartado de Configuración de transporte HTTP seleccionamos el tipo de seguridad correspondiente y la cuenta de credenciales creada anteriormente:
Configurar Proxy Service
Una vez podamos consumir las operaciones securizadas del servicio, se puede integrar en cualquier servicio proxy que tengamos creado agregando un routing, publish o service callout a nuestro servicio proxy.
De este modo, con tres sencillos pasos, conseguimos ejecutar servicios securizados desde otros proxy services.
Nuestra red social |
|
|
