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.

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 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.

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.

]]> http://blog.avanttic.com/2013/05/08/como-implantar-una-arquitectura-soa-iii-que-debemos-hacer-para-controlar-los-servicios/feed/ 0 antoniojosemolina avanttic_SOA_3-3 Áreas y Beneficios del Gobierno SOA Fases del ciclo de vida de un servicio http://blog.avanttic.com/2013/05/02/cabeceras-personalizadas-y-procesos-oracle-bpel/ http://blog.avanttic.com/2013/05/02/cabeceras-personalizadas-y-procesos-oracle-bpel/#comments Thu, 02 May 2013 15:23:30 +0000 Marc Pérez http://blog.avanttic.com/?p=8644 ]]> 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:

1. Generar una variable del tipo miCabecera:

   <variable name="miCabecera" element="client:miCabecera"/>

2. Asignar los valores correspondientes a la cabecera mediante la actividad Assign.
3. 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.

Con este fin, procedemos a agregarla como parte del mensaje de entrada:

<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>

Con esta definición del mensaje, logramos que al crear la variable de entrada del servicio, podamos asignar valores a la cabecera con la interfaz gráfica:

La cabecera forma parte del mensaje

Y con esto hemos visto dos métodos para agregar una cabecera personalizada a la llamada de un servicio web y cómo generar un contrato WSDL que nos facilite la implementación de dichas llamadas.

• 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.

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

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.

A grandes trazos, podemos ejecutar tareas de 4 formas:

• Sistema operativo
• Tareas de la consola de administración
• Jobs de BBDD
• Scheduler de BBDD

Sistema operativo

Podemos programar tareas desde sistema operativo mediante el “crontab” en entornos Unix/Linux o el “Programador de tareas” en Windows.

Es bueno saber que en el caso concreto de los entornos Linux las tareas programadas en el crontab se almacenan de manera particular para cada usuario (cada uno puede tener las suyas) y, además, existen unos directorios de cron “horario”, “diario” y “mensual” en los que si dejamos algún script se ejecutará en esos intervalos de tiempo.

Tareas de la consola de administración

Podemos programar tareas desde la DBConsole o el Enterprise Manager/Grid Control, almacenándose en la BBDD de repositorio de estos productos. Pueden realizar tareas de todo tipo, sobre diferentes objetivos locales y remotos, hosts, BBDD, Servidores de Aplicaciones… (en el caso de objetivos remotos mediante agentes y solo en el caso del EM/GC).

Es bueno saber que estas tareas pueden generar confusión en el caso de la DBConsole, ya que en muchos casos se confunden con tareas de BBDD. Si por ejemplo programamos una “Tarea de Backup de BBDD” desde la DBConsole, se programará como una tarea de consola y solo podremos controlar su ejecución y logs desde la misma, además no se ejecutará si la consola está parada. En la siguiente imagen podemos ver el link de las tareas programadas en la DBConsole:

Jobs de BBDD

Estas eran las tareas típicas de BBDD hasta la versión 9.2. Consisten en un programador “simple” que permite ejecutar código PL/SQL o SQL de manera repetitiva a ciertos intervalos. Podemos programar estas tareas mediante el paquete de PL/SQL DBMS_JOB y controlar las tareas que tenemos programadas en la tabla DBA_JOBS (las que están en marcha en  DBA_JOBS_RUNNING).

Es bueno saber que si el código programado no finaliza correctamente la tarea se intentará repetir a intervalos de tiempo que se irán doblando en cada iteración (en 1 minuto, en 2 minutos, en 4 minutos… hasta llegar al tiempo programado de la próxima ejecución “normal” prevista), al llegar a los 16 intentos la tarea se marcará como “broken” y no se repetirá. Esto es importante si tenemos una tarea que realiza ciertas modificaciones parciales antes de fallar, ya que estas modificaciones parciales se podrían repetir múltiples veces.

Otro detalle interesante es que podemos decidir cuántas tareas se pueden ejecutar simultáneamente (o parar completamente la ejecución de tareas) mediante el parámetro de inicialización “JOB_QUEUE_PROCESSES”, este parámetro es dinámico (lo podemos cambiar sobre la marcha sin parar el gestor). Por ejemplo si lo definimos a cero dejan de ejecutarse tareas mediante el sistema de JOBS.

Scheduler de BBDD

Finalmente tenemos el “SCHEDULER”, un sistema avanzado de programación de tareas aparecido en la versión 10g de la BBDD y que se ha ampliado y mejorado en versiones posteriores. Podemos crear una biblioteca de tareas, lanzar scripts de sistema operativo, crear cadenas de trabajos, ejecuciones condicionadas a eventos, ventanas de ejecución, vincular tareas al gestor de recursos, etc.  En resumen, mucho más potente que el anterior sistema de jobs.

Se pueden programar las tareas mediante el paquete DBMS_SCHEDULER o desde el apartado de tareas de la BBDD en la DBConsole o en el EM/GC. Este es el sistema recomendado para programar tareas en las BBDD 10g y superiores.

En la siguiente imagen tenéis el resumen de componentes que forman el scheduler y sus relaciones:

Es bueno saber que si nos interesa arrancar la BBDD sin que se ejecute ningún job del scheduler, y estamos en versión 11.2, podemos definir a cero el parámetro job_queue_processes ya que en esta versión no solo desactiva los DMB_JOBS sino también los trabajos del scheduler. Para otras versiones tendremos que arrancar la BBDD en modo MIGRATE o UPGRADE y ejecutar el siguiente código:

exec dbms_scheduler.set_scheduler_attribute(‘SCHEDULER_DISABLED’,'TRUE’);

En la siguiente imagen tenéis la entrada de la DBConsole correspondiente a la programación de tareas en el Scheduler:

Develop once, Deploy anywhere… Securely

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 (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.

En estos workshops, impartidos por consultores preventa de avanttic y Oracle, los desarrolladores de su organización podrán conocer este framework y asistir a una demostración de construcción de una aplicación mobile (iOS + Android) que accede a una BD de back-end alojada en Amazon Elastic Compute Cloud (Amazon EC2), utilizando servicios web desplegados sobre Oracle Service Bus.

Agenda:

- Carles Biosca (Preventa Middleware, avanttic)
- Sergio Moreno (Principal Sales Consultantt, Oracle)

Calendario de los Workshops:

• ¿Qué pasos tenemos que dar para adoptar SOA en nuestra organización?
• ¿Cómo tengo que dar esos pasos para asegurar el éxito?
• ¿A quién necesito para hacer la implantación?
• ¿Qué hardware y software me da garantías?
• ¿Recuperaremos la inversión?
• …

Las tareas y acciones que se definen están orientadas a mejorar en cada una las áreas del Modelo de Referencia SOA, y por tanto, a aumentar el nivel de madurez SOA. Recordemos que se llega al nivel más alto de la escala de niveles cuando las aplicaciones dan soporte al negocio de forma rápida y barata. Las áreas del Modelo de Referencia SOA son las siguientes (encontraréis más información en  el post anterior ¿De dónde partimos?):

• Estrategia
• Procesos
• Gobierno
• Organización
• Métodos
• Arquitectura
• Infraestructura
• Aplicaciones

Un posible ejemplo de acciones a realizar para mejorar el área de Organización podría ser el siguiente:

Estas tareas y acciones se deben realizar en un plazo concreto de tiempo que determinará el alcance la hoja de ruta. El plazo de cobertura de una hoja de ruta debe oscilar entre 1 y 3 años en función de las necesidades y objetivos de la empresa. Por lo tanto, en base al plazo establecido, el número de acciones variará sensiblemente.

Una vez establecidas todas las tareas a realizar, se deben ordenar en el tiempo para facilitar su elaboración de forma adecuada. El ritmo de tiempo tiene que estar adaptado a la dinámica de la empresa y a los recursos asignados para su realización.

Adicionalmente al calendario de acciones, en la Hoja de Ruta se debe especificar de forma clara cuál es el objetivo de madurez que se pretende alcanzar para cada una de las áreas del Modelo de Referencia SOA. Este avance en cada área depende de las acciones que hayan sido especificadas para cada una de las mismas.

Además de todo lo indicado hasta ahora referente a aumentar el nivel de madurez SOA, la hoja de ruta debe incluir información sobre distintos aspectos que son necesarios para justificar y facilitar la implantación de esta arquitectura:

• Objetivos de negocio. Hay que establecer de forma precisa los objetivos de negocio que se persiguen al implantar esta arquitectura, por ejemplo, mayor competitividad al reducir los tiempos y costes de desarrollo de aplicaciones de empresa.
• Solución tecnológica. La arquitectura SOA se apoya en un software de base. Se debe elegir entre las distintas opciones que hay en el mercado.
• Metodología SOA. Se debe establecer una metodología a utilizar para la gestión del ciclo de vida de los servicios.
• Proyectos iniciales. Definir qué proyectos serán los primeros en hacerse con la nueva arquitectura.
• Formaciones necesarias. Fijar las formaciones necesarias en el corto plazo para facilitar el aprendizaje sobre la nueva tecnología.
• Gobierno SOA. Fijar las bases de un Modelo de Gobierno SOA que será el encargado de gestionar y controlar el ciclo de vida de los servicios.
• Recursos necesarios. Definir los recursos que van a ser necesarios para llevar a cabo la hoja de ruta.
• Estimaciones económicas. Realizar una estimación económica del coste de la ejecución de la hoja de ruta.

En resumen, la hoja de ruta SOA no sólo va a marcar el camino a seguir, sino que también deja claro cuál es el objetivo y qué implicaciones tiene sobre la empresa. Se trata de tener bien definido todo el trabajo durante el periodo de cobertura de la hoja de ruta. No obstante la hoja de ruta debe revisarse de forma periódica para comprobar si se está llevando a cabo de la forma esperada. Si no fuera así, sería necesario hacer una revisión para adecuar su ejecución a la realidad.

]]> http://blog.avanttic.com/2013/03/26/como-implantar-una-arquitectura-soa-ii-que-debemos-hacer/feed/ 1 antoniojosemolina avanttic SOA Ejemplo de Tareas en el área de Organización Hoja de Ruta Objetivos de la Hoja de Ruta