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.
Componentes de Oracle Endeca Information Discovery (OEID)
Oracle Endeca Information Discovery
- Oracle Endeca Information Discovery Studio. Es la herramienta para la creación y explotación de aplicaciones para descubrir información. Es 100% web y con ella, los usuarios de negocio podrán ir interrogando al motor, que les irá respondiendo y descubriéndo nuevos datos o relaciones que le llevarán a nuevas preguntas, para así ir tejiendo sobre la marcha, sin reglas preestablecidas, una red de nuevos conocimientos a medida que se va descubriendo la información. Las aplicaciones están compuestas por páginas que se organizan en pestañas que contienen los diferentes componentes gráficos que ofrecen las siguientes funcionalidades: navegar o buscar datos, mostrar información detallada, mostrar gráficas y otras representaciones de datos, manipular y analizar datos, resaltar datos específicos. Como complemento para agilizar el desarrollo y dar mayor independencia a los usuarios, dispone del Provisioning Service, una herramienta que permite a los analistas de negocio subir sus propias hojas de cálculo y empezar a crear sus aplicaciones a partir de ellas. Cabe destacar también que ofrece integración SOA.
- Oracle Endeca Information Discovery Integrator. Mediante el Integrator Acquisition System (IAS) proporciona las herramientas necesarias para la adquisición (desde sistema de ficheros, gestores de contenidos, servidores Web y orígenes de datos propietarios) y enriquecimiento de datos (normalización, cleansing, extracción de tags, análisis sentimientos, descubrir ubicaciones geográficas), más próximas a un perfil de usuario de TI, con necesidades o exigencias más complejas: porque requieren una cierta orquestación o de un proceso más elaborado para su extracción.
Oracle Endeca Server (motor MDEX)
Siendo SOA nativo, articula su funcionamiento a través de diversos web services, algunos de uso interno, y otros, como los que destacamos en el gráfico, lo comunican con el exterior: el WS Data Ingest es el que recibe los datos, bien provengan de un usuario de negocio vía Provisioning Service o de un origen más complejo que haya sido procesado mediante Integrator. Como alternativa a este WS, existe también un proceso llamado Bulk Load Interface, diseñado para cargas masivas de datos desde disco. La comunicación con la capa de aplicación, se realiza a través del Conversation WS.
Cómo implantar una arquitectura SOA (III): ¿Cómo controlamos los servicios?
El éxito de la implantación de una arquitectura orientada a servicios depende en gran medida de realizar de forma adecuada las acciones definidas en la Hoja de Ruta SOA (ver post Hoja de Ruta SOA), cuyo contenido se ha podido determinar gracias al conocimiento exacto del Nivel de Madurez SOA de la organización (ver post Nivel de Madurez SOA).
Pero sólo con esto no es suficiente. Una vez que se ha instalado la plataforma que da soporte a la arquitectura SOA, es necesario instaurar un Modelo de Gobierno SOA que gestione y controle los servicios que poco a poco se irán desplegando en los sistemas.
Según Gartner: El Gobierno SOA sigue siendo crucial.
”El Gobierno SOA trata sobre la disciplina y el aseguramiento para que las decisiones muy importantes pasen por las personas adecuadas y que éstas personas tengan la información adecuada para tomar esas decisiones. Eso es la mitad del problema de la gobernabilidad de SOA. La segunda mitad viene cuando se han tomado dichas decisiones, y el Gobierno SOA tiene que asegurar su aplicación efectiva.”
El Gobierno SOA tiene como propósito ejercer el control sobre los procesos de definición, creación y explotación de los servicios en una Arquitectura SOA. Esto implica definir una serie de procedimientos que aseguren y permitan controlar que se cumplen una serie de normativas y especificaciones cuyo cumplimiento garantice el éxito de la adopción de una Arquitectura SOA.
Las áreas sobre las que se deben especificar las normativas y procedimientos son las siguientes:
El Gobierno SOA debe establecer controles sobre cada una de las fases del ciclo de vida de un servicio. El ciclo de vida de un servicio se inicia cuando se estudia la posibilidad de creación de un servicio hasta que entra en retirada productiva. A continuación se muestra cada una de estas fases:
Hasta el momento, hemos indicado qué es lo que deberíamos hacer para la adecuada explotación de una Arquitectura SOA. El Gobierno SOA nos va a decir cómo debemos hacerlo. Los procesos de control del Gobierno SOA establecen acciones sobre cada una de las fases del ciclo de vida de un servicio.
Tras la especificación y definición de mecanismos de control de las distintas fases y etapas del ciclo de vida de los servicios, hay que poder ejecutarlos de forma adecuada y solvente. Para ello, se recomienda la creación de una Oficina Técnica SOA que garantice y articule el cumplimiento de las normativas y procedimiento establecidos en el Modelo de Gobierno. Si no hay suficiente volumen de servicios para la creación de una oficina técnica, bastará con disponer de al menos una persona que se encargue de las tareas de gestión y control del ciclo de vida de los servicios. De lo contrario, se corre el riesgo de desperdiciar todo el trabajo realizado en el modelo de gobierno y, lo que es todavía peor, que la implantación de la arquitectura SOA no se realice con éxito.
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…
Crónica Workshops Oracle ADF Mobile
Tras la buena acogida que tuvieron los desayunos de trabajo sobre ADF Mobile que realizamos en noviembre, los pasados días 10 y 25 de abril avanttic y Oracle hemos impartido, en Madrid y Barcelona, unos Workshops consistentes en una demostración de construcción de una aplicación para iOS atacando a web services, creados también durante la sesión y desplegados sobre un Oracle Service Bus alojado en Amazon EC2. Revisa aquí la agenda.
- Oracle ADF Mobile es una extensión de Oracle Application Development Framework (ADF) que permite el desarrollo unificado de aplicaciones de movilidad empresariales, para tablets y smartphones, y de momento bajo iOS y Android. Utiliza HTML5, CSS3, Javascript, Phone Gap y SQLite, y permite desarrollar aplicaciones móviles que interaccionan con el dispositivo (GPS, cámara, agenda de contactos, …) y que pueden trabajar de forma desconectada almacenando temporalmente los datos en una base de datos local.
- Oracle Service Bus gestiona la publicación de los servicios web y aporta toda la infraestructura necesaria a nivel de seguridad, monitorización y auditoría para permitir a las aplicaciones móviles integrarse con los sistemas de back-end de su organización.
Contacta con nosotros si deseas más información sobre las demostraciones realizadas.
Java 7 y Weblogic & Forms 11gR2
Muchos clientes tienen dudas sobre si las últimas versiones, tanto del servidor de aplicaciones Weblogic como de las aplicaciones desplegadas Forms, pueden ser compatibles con Java 7. La respuesta es que sí, pero no todas las versiones de Forms 11g ni de Weblogic sino la combinación de la última versión de Forms 11.1.2.1.0 con la versión de Weblogic Server 10.3.6 o superior. Sólo esta combinación está soportada y certificada por Oracle, según muestra su matriz de certificación.
Otro tema importante, sobre el que surgen dudas en muchos clientes, es si pueden convivir varias versiones diferentes de JRE en un puesto de usuario que tiene que ejecutar diferentes aplicativos Java. ¿Cómo podemos configurarlo en un PC de un usuario?
En este ejemplo nos vamos a apoyar en 2 versiones muy diferentes de JRE, la 1.6.0_04 y la 1.7.0_07, y los aplicativos son Forms 10gR2 (que no puede utilizar la versión JRE 1.7) y Forms 11gR2 (que sí la puede utilizar).
Pasos a seguir:
- Instalar las dos JRE. Se debe instalar la versión más antigua (1.6.0_04) primero.
- Configurar el archivo formsweb.cfg del servidor OAS 10gR2. Se debe de añadir el parámetro java_version=1.6.0_04 para obligar a la versión Forms 10gR2 a que se ejecute con el applet Java 1.6.0_04.
- Configurar el archivo formsweb.cfg del servidor OFMW 11gR2. Se debe de añadir el parámetro java_version=1.7.0_07 para obligar a la versión Forms 11gR2 a que se ejecute con el applet Java 1.7.0_07.
- Configuración en el panel de control de Java. Esto se debe realizar para que no aparezcan molestos mensajes (“La aplicación necesita una versión anterior de Java. ¿Desea continuar?”) de seguridad de Java cuando ejecutemos los aplicativos Forms 10gR2 que utilizan la versión menos reciente (1.6.0_04). Para ello deberemos ir en nuestro PC Windows a Inicio -> Panel de Control -> Java -> Pestaña Avanzado y modificar según se muestra en la siguiente imagen:
Archivo formsweb.cfg
Para la correcta ejecución de las aplicaciones Oracle Forms & Reports 10gR2 y 11gR2 en los diferentes navegadores (se ha probado con IE 9+, Firefox 18+ y Chrome 24+), se ha de modificar el fichero formsweb.cfg tal y como se muestra en el siguiente ejemplo:
# Page displayed to users to allow them to download Sun’s Java Plugin.
# Sun’s Java Plugin is typically used for non-Windows clients.
# (NOTE: you should check this page and possibly change the settings)
jpi_download_page=http://java.sun.com/products/archive/j2se/6u12/index.html
# Parameter related to the version of the Java Plugin
jpi_classid=clsid:CAFEEFAC-0017-0000-0011-ABCDEFFEDCBA à Si se ejecuta con Forms 11gR2
jpi_classid=clsid:CAFEEFAC-0016-0000-0014-ABCDEFFEDCBA
Si se quiere ejecutar con Forms 10gR2:
# Parameter related to the version of the Java Plugin
jpi_codebase=http://java.sun.com/update/1.6.0/jinstall-6-windows-i586.cab#Version=1,6,0,12
# Parameter related to the version of the Java Plugin
# jpi_mimetype=application/x-java-applet;jpi-version=1.7
jpi_mimetype=application/x-java-applet;version=1.7 à Obligatorio si se quieren ejecutar con Firefox y Forms 11gR2
jpi_mimetype=application/x-java-applet;version=1.6 à Obligatorio si se quieren ejecutar con Firefox y Forms 10gR2
java_version=1.7.0_11 à Si se quiere ejecuta con esta versión específica y Forms 11gR2
java_version=1.6.0_04 à Si se quiere ejecuta con esta versión específica y Forms 10gR2
# Applet parameter for Sun’s Java Plugin
legacy_lifecycle=false
ADF tips: Control de cambios pendientes
El control de cambios pendientes cuando el usuario abandona una página es siempre un problema muy a tener en cuenta, sobretodo cuando el usuario utiliza formas de navegación no controladas por la aplicación (como el botón atrás, cerrar el navegador, refrescar la página…).
ADF ofrece una manera muy sencilla de alertar al usuario cuando tiene cambios pendientes, simplemente debemos añadir el atributo uncommittedDataWarning dentro del tag af:document; como se muestra en la imagen.
Esta nueva propiedad provoca que cuando el usuario intenta cerrar el navegador, refrescar la página, ir atrás o una acción similar, salte un popup genérico que le alerte de que si continua puede perder sus cambios.
Además es posible forzar a que este aviso sea lanzado cuando se haga uso de algún elemento de navegación dentro de la propia pantalla, por ejemplo al pulsar un botón o hacer un cambio de pestaña. Para ello debemos añadir el atributo af:checkUncommittedDataBehavior dentro del componente deseado.
Aunque es una solución válida para evitar salidas descontroladas del navegador, en algunos casos puede que necesitemos personalizar este popup de alerta. Por ejemplo para ofrecerle al usuario la opción de guardar sus cambios desde el propio popup, forzar a deshacer todos los cambios antes de permitir la navegación o tal vez darle un aspecto más amigable al aviso. Para ello podemos acceder a la comprobación que internamente el framework ejecuta por nosotros para saber cuándo debe mostrar el mensaje de aviso; teniendo la opción de por ejemplo abrir un popup de aviso propio.
En resumen, gracias a la opción de uncommittedDataWarning podemos alertar al usuario de una forma rápida y eficaz de que va a perder los cambios pendientes, y en caso de que el aviso genérico no cumpla con todos nuestros requisitos, existe una forma alternativa de hacer la misma comprobación y controlar manualmente todas las opciones que el usuario tendrá disponibles.
Nuestra red social |
|
|
