martes, 16 de abril de 2013

Reset password OER/OSR


Algunas veces necesitamos resetear el password de algún usuario dentro del OER u OSR cuyo repositorio de usuarios está amarrado a una base de datos Oracle, a continuación demostraré una forma fácil de poder realizar esto, para ello necesitamos de lo siguiente:

  1. Conexión al esquema de OER/OSR
  2. Conocer el password de cualquier usuario

Cada herramienta OER/OSR mapea sus objetos a tablas relacionales, de igual manera los usuarios  y contraseñas.

La tabla donde se guarda los usuarios y contraseñas para OER es ENTSECUSERS, tal como se muestra en la siguiente imagen:


El OSR de igual manera mapea sus usuarios y contraseñas a una tabla relacional, la cual es PASSWD, tal como se muestra en la siguiente imagen:


Bueno, el metodo para resetear la contraseña es facil, se resume en lo siguiente:

Copiar el password encriptado del usuario del cual conocemos su contraseña y copiarsela al usuario del cual queremos resetear la password.

Por ejemplo, para el Oracle Service Registry (OSR):

SQL> select loginname, password from uddi.passwd;

deiby                                              wkBkLd75lDWMltqCwDYaWA==

admin                                            uRzRpUeBeQvqorr3QfpniQ==

Y sabemos que la contraseña del usuario "deiby" es "oracle" y el usuario al que queremos resetearle la contraseña es "admin", entonces hacemos el siguiente update:

update uddi.passwd set password='wkBkLd75lDWMltqCwDYaWA==' where loginname='admin';
commit;

¡Listo! Ahora podremos logearnos al OSR con admin/oracle :)

Como recomendación, reinicie el Managed Server del OSR/OER.

Los mismo puede realizarse para el OER:

select username, password from oer.ENTSECUSERS;

deiby                                              wkBkLd75lDWMltqCwDYaWA==

admin                                            uRzRpUeBeQvqorr3QfpniQ==

update oer.ENTSECUSERS set password='wkBkLd75lDWMltqCwDYaWA==' where username='admin';
commit;

¿Funcionará el método con el DBA_USERS? pruebelo..... :)



Oracle Service Registry Cannot obtain new connection


En algunas ocasiones es posible que el Oracle Service Registry (OSR) no pueda obtener una conexión desde el pool de conexiones creadas por el Data Source, esto puede producirse después de volver a realizar el despliegue de la aplicación del OSR.

Si buscamos errores en el log del Managed Server donde está desplegada la aplicación es posible que no encontremos información relevante. El log que se debería revisar es entonces:

$DOMAIN_HOME/servers/<server_name>/tmp/_WL_user/registry/<random_directory>/public/serviceRegistry_errorEvents.log

En éste log vemos que las siguientes líneas aparecen:

<2013-04-11 15:46:02,557> - <ID1365713947710> <ERROR> <WSP4005> com.systinet.uddi.webui.WebUIRawService -  - EXCEPTION: org.systinet.uddi.account.AccountException: Initialization of accounts has failed. For help please contact the administrator of the registry.
<2013-04-11 15:46:03,518> - <ID1365713947711> <WARN> <WSP4005> database_core.com.systinet.uddi.config.management.DatabaseConfig - Ignoring exception in event handler, it may be caused by unavailablity of database. - EXCEPTION: java.lang.RuntimeException: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.
<2013-04-11 15:46:03,561> - <ID1365713947712> <WARN> <WSP4005> database_core.com.systinet.uddi.config.management.DatabaseConfig - Ignoring exception in event handler, it may be caused by unavailablity of database. - EXCEPTION: java.lang.RuntimeException: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.
<2013-04-11 15:46:03,563> - <ID1365713947713> <ERROR> <WSP4005> uddi_inquiry_v3.com.systinet.uddi.inquiry.v3.database.Get - DatabaseCoreException - EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.
<2013-04-11 15:46:03,565> - <ID1365713947714> <ERROR> <WSP4005> permission.com.systinet.uddi.permission.database.DBPermissionApiImpl - DatabaseCoreException - EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.
<2013-04-11 15:46:05,471> - <ID1365713947715> <ERROR> <WSP4005> uddi_inquiry_v3.com.systinet.uddi.inquiry.v3.database.Get - DatabaseCoreException - EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

Como se logra ver en las lineas del log, claramente la conexión a la base de datos no se puede realizar. Entonces el problema puede ser causado por lo siguiente:

  1. El Data Source está creado en el weblogic con credenciales no validas.
  2. No hay comunicación entre la aplicación desplegada y el Data Sorce.

Sin embargo, al testear el Data Source desde el weblogic, se confirmó que el Data Source sí era válido y que las credenciales utilizadas eran correctas. Entonces solo queda una opción, el despliegue no se comunica con el Data Source.

Y aquí es donde viene la pregunta: ¿Cómo hace el despliegue para comunicarse con su Data Source?

Por intuición me recordé de aquella herramienta que el Oracle Service Registry trae con sus binarios llamada "setup.sh" o "setup.exe" según sea el SO sobre el cual este el OSR, me recordé que esta herramienta trae una opción de "reconfigurar la conexión a la base de datos", donde se puede elegir en crear un tablespace, utilizar un tablespace existe y crear el esquema adecuado o simplemente conectarse a un esquema ya existente.


Para ejecutar esta herramienta en modo consola agregar la opción " -c", ejemplo "./setup.sh -c"

Esta herramienta está ubicada en:

$REGISTRY_HOME/bin

Utilicé esta herramienta para reconfigurar la conexión a la base de datos. Seleccioné la opción de "conectarse a un esquema existente", ingresé los datos correctos de la base de datos: host, puerto, username, password, etc. La herramienta no retornó errores por lo que asumí que había realizado su tarea exitosamente.

Es necesario detenernos en este punto y revisar el log de la herramienta setup.sh, la cual se encuentra en:

$REGISTRY_HOME/log/setup.log

En este punto puede ser que muestre algún error relacionado con la librería "ojdbc6.jar" que debe estar agregada en el CLASSPATH del Managed Server donde está el OSR. Pero para mi problema, esta no fué la causa, pues la librería estaba correctamente agregada.

Bueno, prosigamos. Como indicaba, en el log del setup.sh no habian errores. Reinicié el Managed Server del OSR volví a ingresar a la aplicación y no, el problema no se habia solucionado, en el log seguía mostrando "Cannot obtain new connection". Por intuición pensé que esta herramienta "setup.sh" volvía a reconfigurar todo lo necesario para restablecer la conexión entre la aplicación y el Data Source, pero no, no fue así. Entonces volví a la misma pregunta  ¿Cómo hace el despliegue para comunicarse con su Data Source?

Investigando llegué a la solución, el despliegue utiliza un archivo XML para comunicarse con el Data Source, este archivo es llamado "database.xml" y está ubicado en:

$DOMAIN_HOME/servers/<server_name>/tmp/_WL_user/registry/<random_directory>/public/app/uddi/conf/database.xml

Este archivo es el que debe modificarse manualmente, indicando todos los datos correctos para lograr la conectividad con el Data Source: host, puerto, username, password, instance_name, data source name, etc.

Al modificar dicho archivo, reinicié el Managed Server del OSR, ingresé a la aplicación y pude por un momento imitar a Arquimides y exclamé ¡Eureka!

viernes, 5 de abril de 2013

Los sabores y colores de Oracle Exadata


Oracle está promoviendo fuertemente la solución Oracle Exadata, un servidor diseñado para procesar grandes cantidades de datos (Exabytes), optimizado para OLTP o para DWH. Recordemos un poco los prefijos:

103      kilo
106      mega
109      giga
1012    tera
1015    peta
1018   exa

Oracle sabe que constantemente los datos que se necesitan procesar se están incrementando, a continuación unos datos relevantes:

  • 2 billones de personas usan internet, y estas están generando cada vez más datos.
  • Un solo celular genera GB de información, multiplique esta información por el numero de celulares que existen ahora.
  • En el año 2,000 un Estudio dedicado a investigaciones espaciales registró en una semana más información que la que se había recolectado en toda la historia.
  • En 10 años una empresa de IT creció en datos hasta 140 Terabytes.

La arquitectura de este servidor es impresionante, toma en cuenta la optimización de varios aspectos como son IO, CPU, CACHE, Latencia, etc., desde el ensamblaje del hardware hasta los procesos que se ejecutan dentro de él. Consta principalmente de los elementos:

  • Exadata Database Servers
  • Exadata Storage Servers
  • Infiniband
  • Smart Flash Cache

Oracle Proporciona dos tipos de Oracle Exadata:
  1. Oracle Exadata X2-2
  2. Oracle Exadata X2-8

El Oracle X2-2 Posee los siguientes componentes de Hardware:


El Oracle X2-8 Posee los siguientes componentes de Hardware:



El Oracle Exadata X2-2 a su vez, existe en 3 formas:

  1. Oracle Exadata X2-2 Full Rack
  2. Oracle Exadata X2-2 Half Rack
  3. Oracle Exadata X2-2 Quarter Rack



¿Es escalable Exadata? Claro que sí. Existen expansiones de Oracle Exadata. Por ejemplo, si se tiene un X2-2 Quarter Rack, se puede expandir a Full Rack. Si un Full Rack ya no es suficiente, se pueden agregar más Exadata Machines (cualquier clase). ¡¡¡Con dos switches adicionales se puede llegar a tener hasta 36 Exadata Machines en una sola configuración!!!

¿Estas Listo para Exadata?


martes, 2 de abril de 2013

Variable Vacía en BPEL


Hace unos días encontré con otros colegas un problema en el desarrollo de un servicio web con BPEL en JDeveloper 11.1.1.5 que quizás no es tan común, pero que siempre es bueno saber la solución, ya que al principio parecería muy raro el comportamiento del Motor de SOA en el Weblogic (10.3.5), más sin embargo, el verdadero problema radica en cómo estemos describiendo nuestros servicios, en este caso el problema se encontraba en el XSD.

Descripción:

Se realiza una invocación de un Servicio Web externo, mediante el elemento "invoke" del BPEL. El servicio web invocado es síncrono, por lo que recibe una entrada de datos y retorna datos de salida. Por lo tanto, en un elemento "invoke" se debe asociarle dos variables de BPEL, llamemosla "vinput" para la variable de entrada de datos y "voutput" para la variable de salida de datos.
Los datos retornados por el servicio mediante "voutput" se pasan a la variable de salida del servicio BPEL.

A continuación el diagrama del BPEL en JDeveloper, como verán es sencillo:


Síntomas:

Al debuggear la instancia de ese servicio SOA en el Enterprise Manager, se ve que la invocación del servicio externo es exitosa, se le envía datos de entrada y retorna los datos correctos de salida. Es decir la variable "vinput" es poblada por nosotros y la variable "voutput" es poblada por el "invoke", todo esto es exitoso.
Al querer utilizar los datos de "voutput" y pasarlos a la salida final del servicio SOA, el motor de SOA encuentra a la variable "vouput" VACIA y por lo tanto el nuestro servicio SOA no retorna datos.

A continuación una imagen donde se puede ver que se "voutput" es poblada con los datos de salida, pero en el "transform" NO hay datos.




El elemento "transform" es utilizado correctamente, se toman los campos de "vouput" y se mapean a los cambos de la salida del servicio SOA, se utiliza un elemento "for-each" pues el servicio retorna un array de datos.

A continuación la imagen del XSL.


Solución:

En el XSD del servicio Externo se utilizan las siguientes clausulas dentro del tag <XSD:SCHEMA>:

attributeFormDefault="qualified" elementFormDefault="qualified"

Al remover estas clausulas y volver a desplegar el servicio, la ejecución fue exitosa.

Antes:

<xsd:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="https://.......

Despues:

<xsd:schema targetNamespace="https://......



domingo, 31 de marzo de 2013

SOA, la última Innovación Tecnológica


En los 70:

Al principio, usted gestionaba su negocio con métodos manuales y basados 100% en procedimientos que realizaban personas. Con la llegada de los ordenadores y los programas informáticos, usted empezó a resolver partes de la operativa de su negocio de forma mecanizada y por tanto recicló a su personal para que en lugar de procesar datos, los introdujera en una máquina de tarjetas perforadas y el ordenador realizará los cálculos correspondientes. Más tarde, se evolucionó a las aplicaciones informáticas. Con este gran paso, le gestionábamos de forma mecanizada su cartera de clientes con la aplicación Gestión de clientes, sus proveedores con Gestión de Proveedores, su stock con Gestión de Almacén, su Contabilidad con una aplicación de Financiera y así un largo etcétera.

Dichas aplicaciones se desarrollaban a gusto y medida del cliente, pero encarecían notablemente los costes de mantenimiento y evolución de dicho software, ya que cada cliente debía pagar de forma individual sus propias adaptaciones a normativas, regulaciones, mercado, nuevas  líneas de negocio…Además, las empresas invirtieron de nuevo en formación y/o reciclaje de sus empleados: Operaciones, Finanzas, Almacén….todos debían ser capaces de utilizar las aplicaciones que les correspondían e intercambiarse la información necesaria entre los distintos departamentos que la requerían. Resultado: montañas y montañas de papel pijama que paseaban en carritos de una mesa a otra. Sólo les habíamos cambiado las herramientas de trabajo y aunque el circuito y el proceso era el mismo, el negocio ganaba en rapidez de gestión y por tanto de respuesta al mercado y a sus clientes.  Un nuevo reto para los CI y una nueva solución tecnológica.

Los 80:

Desarrollamos aplicaciones estándar para todos los clientes e integramos dicha aplicación con el resto de las existentes. Así conseguimos que el intercambio de información sobre un medio físico como el papel se transformara en intercambio de datos de forma automática entre las aplicaciones. ¡Bravo, señores informáticos¡. Conseguimos reducir costes de mantenimiento, ya que los posibles errores del software, las mejoras y evoluciones se distribuyeron a todos los clientes que habían adquirido dichas licencias por un módico porcentaje anual sobre el precio inicial de las mismas. Pero no olvidemos los costes de adaptación a las particularidades de los grandes clientes, que lógicamente exigían.

Y respecto a la integración, otro ¡bravo¡ Ya habíamos creado el famoso ¡¡¡spaghetti!!! Cada aplicación recibía información del resto para procesar y entregar otra tanta cantidad de la misma para todas las demás. Esto implicaba un nuevo sin fin de programas que tratasen y generasen respectivamente dichos datos. Consecuentemente, la ventana horaria del tratamiento batch se ampliaba, se complicaba la dependencia entre aplicaciones y creamos los equipos de guardia para resolver lo que pudiera ocurrir fuera del horario establecido de trabajo. Además, se ahorraba en costes de gestión, ya no era preciso tanto personal administrativo, se necesitaban informáticos de desarrollo, de técnica de sistemas, de explotación, bases de datos,….Pero tranquilos señores clientes, los CI somos fundamentalmente “solucionadores”.

Los 90 (principios):

Les creamos los ERP – y seguimos con las siglas -Enterprise Resource Planning ó Planificación de Recursos Empresariales. Una solución global y completa para gestionar todo el negocio de su Compañía, incluyendo las áreas comunes de cualquier negocio (Financiero, Recursos Humanos, Provisión,…) con las específicas de su sector de mercado. Paralelamente, introducimos el concepto de modularidad, es decir, desarrollamos aplicaciones más sofisticadas y que cubrían más operativa, pero independizando partes de la misma que llamaríamos módulos y que pueden ser reutilizadas desde distintos programas. Así creamos el “súper paquete de software” con un conjunto de módulos comunes y otro conjunto con aquellos específicos que componían la vertical del negocio y consiguiendo tener todo integrado desde el punto de vista de datos. ¿Pero la naturaleza del sector de negocio es tan distinta entre unos y otros? (un Banco vs una Operadora de Telecomunicaciones, por ejemplo) y la competencia de mercado tan alta, que pasa por ofrecer productos propios de cada Compañía a sus clientes finales. Ahí es donde el ERP empieza a no encajar del todo, porque cada empresa tiene necesidades diferentes y objetivos propios. Incluso perteneciendo al mismo sector, debe diferenciarse de la competencia y aportar su propio valor añadido, sus propios productos y soluciones; y claro, sus sistemas de información no pueden ser los mismos que los de la competencia. Bien, adoptamos el ERP para los procesos de gestión y administración de la Compañía y seguimos con nuestras aplicaciones específicas del negocio. ¿Reducimos integración? Poca cosa. Ahora teníamos que comunicar las aplicaciones propietarias con el ERP que nos exigiría unos formatos concretos e incluso unos desarrollos con un lenguaje de programación concreto formatos concretos e incluso unos desarrollos con un lenguaje de programación concreto. Fuimos modularizando y nuestras aplicaciones pasaron a ser multi-país, multi-entidad, multi-moneda, …, pero el spaghetti crece y crece. No olvidemos a las personas. Formamos a los de negocio para que se adapten a las nuevas tecnologías y evolucionamos a los informáticos con nuevos lenguajes y técnicas de programación.

Los 90 (mediados):

Diseñamos una solución software y de arquitectura de sistemas (“middleware”), que permitiese que las aplicaciones heterogéneas, en distintas máquinas y ubicaciones físicas pudieran intercambiarse información tanto en tiempo real (on line) como diferido (batch),
comunicándose con un único intercambiador de información y no directamente entre ellas una a una. Bienvenido el EAI – Enterprise Application Integration ó Integración de Aplicaciones de Empresa. Las aplicaciones requerían y suministraban información a partir de este gestor que funcionaba como una “cola de peticiones” o “cola de mensajes”. Ya no teníamos comunicación spaghetti, ahora nuestro formato era en estrella. No obstante, seguimos realizando una entrega por cada petición.

Los 90 (finales):

Los Grupos empresariales, la internacionalización de las Compañías y la inmediatez de los servicios, requería la apertura de nuevos canales (telefonía, Internet,..) que permitiese a los clientes finales contactar en cualquier momento y desde cualquier lugar.  Las redes de computadores cada vez se hacen más amplias y están más deslocalizadas. Necesitábamos de un dispositivo software que actuase como Application Server ó Servidor de Aplicaciones, que gestionara la mayor parte de la lógica de negocio y acceso a los datos de la aplicación. Los clientes finales van utilizando cada vez más los servicios que ponen a su disposición las Compañías a través de los distintos canales de acceso, el negocio crece y crecen exponencialmente las peticiones de información, y el cliente requiere inmediatez. El formato “cola de mensajes” ya no es suficiente y se evoluciona al “bus de datos” y concepto “publicación –suscripción”. Ahora, la aplicación origen sólo entrega la información una vez al “bus” y desde ahí, la captura cada aplicación que la requiera. Los CI tenemos mucho trabajo adaptando los Sistemas de Información a las nuevas tecnologías.

El 2000 y su efecto:

Falsos profetas, malos augurios, el fin del mundo….Los CI hemos dedicado mucho tiempo y esfuerzo, pensando, diseñando y desarrollando soluciones que redunden en mejorar los Sistemas de Información de las Compañías y por tanto su negocio. Hemos ido cubriendo con capas y capas de tecnología a esos “viejos” programas Cobol de los 70, a esos millones y millones de líneas de código que siguen ejecutándose día tras día, utilizando los mismos modelos de Base de Datos. Datos que costaba mucho almacenar en los 70 y que los CI reducíamos al máximo, empaquetándolos, no guardando datos calculables, definiendo la longitud mínima….Grabando los datos de fecha con las dos últimas posiciones y realizando los cálculos entre fechas con el mismo formato. ¿Quién pensaba que 30 años después estos “programas dinosaurios” seguirían funcionando?.
A las puertas del siglo XXI, batallones de becarios recién titulados con la ilusión puesta en las nuevas tecnologías, hijos de la Playstation y de los CI de los 70, ampliaron los modelos de datos y revisaron línea por línea los programas de sus progenitores adaptándolos al “efecto 2000”.¿Frustrante? Nada que no arregle el dinero. Así que paguemos a los becarios lo que nos pidan que lo trasladaremos a las empresas. A fin de cuentas, gracias a nosotros, los CI, el negocio cada vez va mejor y las Compañías no van a escatimar en gastos con todo lo que se juegan. El 31 de diciembre de 1999, millones de CI en todo el mundo hicimos guardia al pie del ordenador con todo el dispositivo posible de contingencia activado. La suerte y como no, nuestro buen trabajo, nos permitió que tras las 12 campanadas respiráramos con alivio: las comunicaciones, la electricidad, el gas,…., hasta los cajeros automáticos funcionaban. Con los ordenadores a salvo, los CI podíamos centrarnos de nuevo en la evolución de la Tecnología.


2000-2001:

Con el siglo recién estrenado, creamos los Portales de Internet, donde el Servidor de Aplicaciones y el middleware son piezas fundamentales; y que permite a las empresas gestionar y divulgar su información, desde un único punto de acceso a usuarios internos (empleados) y externos (clientes, proveedores, organismos reguladores,…). Señores de negocio, hemos inventado el e-Business y con él más siglas: B2B (Business to Business ó negocio entre empresas); el B2C (Bussines to Customer ó a Clientes) ó B2G (Business to Goverment ó con Organismos gubernamentales). Su negocio, antes local, está ahora abierto a la globalización. Ha transformado su empresa en una e-Communitie.

Efecto crisis 11M – 2001:

…y efecto de la globalización, los siguientes tres años serán duros para la economía mundial. El sector Servicios, y por tanto los CI arrastrados por ella ven como se reduce la inversión en Tecnología. Imposible soportar los salarios inflados de los junior en un momento donde las Compañías que tanto negocio nos han dado para así potenciar y desarrollar el suyo, reducen sus necesidades y reclaman que bajemos nuestras tarifas. Resultado, EREs -expedientes de regulación de empleo (las siglas no sólo las usamos los CI) y a apretarse el cinturón. Ya se sabe cuando el hambre aprieta da alas a la imaginación. Las crisis se remontan y los buenos tiempos vuelven. Nuevo reto para los CI, aprovechemos para pensar en la siguiente evolución Tecnológica.

2004 y siguientes:

Y aquí estamos, inventando de nuevo la rueda y hablando de BPM - Business Process Management ó Gestión de Procesos de Negocio y SOA - Service-Oriented Architecture ó Arquitectura Orientada a Servicios.

Recordemos la introducción:
  • BPM es la metodología empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión sistemática de los procesos de negocio.
  • SOA es un concepto de arquitectura de software que define la utilización de los servicios para dar soporte a los requisitos del negocio.

 Veamos como aterrizamos los CI este discurso a los no CI. Hasta aquí el negocio se había adaptado a las limitaciones que le forzaba la tecnología. Nótese que en los últimos 30 años nuestro discurso había sido que la tecnología ayudaba a gestionar mejor y por tanto hacía prosperar al negocio. Ahora es el negocio quien define las actividades y procesos a través de un modelado, lográndose un mejor entendimiento y la oportunidad de mejorarlos. Claro, antes los requisitos nos los inventábamos los CI en lugar de proporcionarlos el usuario de negocio. La automatización, administración y monitorización de los procesos, reduce errores, asegura una ejecución eficiente y permite explotar la información que de ello se obtiene para optimizarlos.

¿Hasta aquí algo nuevo?.

Evidentemente, para desarrollar una estrategia de BPM es necesario contar con una suite de soluciones y herramientas denominadas BPMS – Business Process Management System ó Sistema de Gestión de Procesos de Negocio -, que nos permitan construir aplicaciones bajo esta metodología. El negocio puede definir paso a paso los procesos utilizando una herramienta WFM – Workflow Management ó Gestión de Procesos – donde bajo un entorno totalmente gráfico y amigable para el usuario, éste define los pasos a seguir o actividades a realizar, los puntos de control, las alertas a emitir, los roles asignados a cada actividad, las personas asociadas a dichos roles y el nivel de escalado de información y autorizaciones correspondiente. Complementado con una herramienta BAM – Business Activity Monitoring ó Monitorización de Actividades de Negocio – podemos medir los tiempos dedicados a cada acción, la carga de trabajo asignada, la eficiencia de los empleados, etc. Por supuesto, una herramienta BAM nos permitirá documentar los procesos para su mejora y así poder definir, seguir y cumplir un SLA – Service Level Agreement ó Acuerdo de Nivel de Servicio; y nos ofrecerá en múltiples formatos de gráficos y agrupaciones de datos, la información relevante para mejorar el negocio. Además, facilitará la visualización de las alertas definidas según grado de criticidad y al nivel de dirección y gestión adecuado. De forma que un usuario de negocio pueda “orquestar” las actividades y “modelar” sus procesos y que ello se traduzca en un software que se ejecute y realice las acciones requeridas, para lo que es preciso una nueva arquitectura que nos permita diseñar estas aplicaciones. Y aquí entra SOA que define las siguientes capas de software o para entendernos, que “trocea” nuestras antiguas aplicaciones en programas o “servicios” cada vez más concretos, limitados y específicos:

  • Básicos: Programas desarrollados bajo cualquier tecnología, geográficamente dispersos y bajo cualquier figura de propiedad. Por ejemplo, validación lógica de una fecha.
  • Funcionales: Las funcionalidades del negocio se exponen como servicios.
  • Integración: Facilitan el intercambio de datos entre aplicativos.
  • Composición de Procesos: Define el proceso en términos de negocio adaptados a sus particularidades.
  • Entrega: Despliegue de los servicios a los usuarios finales.

Y son esos pequeños “servicios” los que se asocian en el workflow y generan una aplicación BPM.


Fuente:
CCB – Octubre 2008
Para MorellConsultor.es

miércoles, 27 de marzo de 2013

¿Qué es BPEL?


Siempre ha existido una necesidad continua en las empresas para integrar los sistemas y aplicaciones que utilizan los procesos de negocio. Con el surgimiento de la tecnología de servicios web se ha hecho más fácil solucionar este problema con las aplicaciones y sistemas disponibles dentro de la empresa y también haciendo posible la publicación de estas funcionalidades para que puedan ser consumidas por externos. La primera fase de la evolución de los servicios web es establecer las bases para la descripción, publicación y distribución de los servicios web, esto incluye los protocolos de transporte de internet (HTTP, SMTP, HTTPS, ETC), los modelos de datos (basados en XML), el intercambio de mensajes (SOAP), la descripción de las operaciones de servicio y tipos (WSDL) y la publicación y descubrimiento (UDDI).

Ninguna de estas especificaciones de los servicios esenciales web (SOAP, WSDL, UDDI, ETC) se habían diseñado para proporcionar mecanismos por sí mismos para describir cómo los servicios web individuales se pueden conectar para crear soluciones empresariales fiables y seguras con el nivel adecuado de complejidad, es aquí donde se asociaron empresas como IBM, Microsoft, BEA, Oracle; con el objetivo de crear un Lenguaje de Ejecución de Procesos (BPEL).

Se considera que la tecnología de servicios web nos está envolviendo cada vez mas y nos está obligando a conocer la compleja necesidad de los clientes. La habilidad de integrar y ensamblar Servicios Web en estándares basados en procesos de negocios es un importante elemento del servicio orientado a empresas y BPEL integra muy bien los servicios Web.

BPEL son las siglas de  Lenguaje de Ejecución de Procesos de Negocio. Lo podemos definir como un estándar basado en XML diseñado especialmente para la “orquestación” de servicios Web.

El orquestamiento de servicios web es la forma ordenada en el que los servicios web se  ejecutan de tal manera que cumplan con una funcionalidad coherente para el negocio. Esto significa que permite el control centralizado de la invocación de diferentes servicios Web con cierta lógica de negocios, definiéndose cuál, cómo y cuándo se ejecutará un proceso determinado.

Entonces, BPEL es un estándar diseñado para integrar una variedad de aplicaciones y conseguir los objetivos de negocio independiente de las plataformas y tecnologías con mayor escalabilidad y flexibilidad. BPEL se convierte en el pegamento para enlazar los servicios web dentro de soluciones del negocio.

Cuando un proceso de negocio es ejecutado mediante la interacción de servicios Web significa que gracias a BPEL existirá una interfaz única para soportar mensajes XML, independiente de las plataformas asociadas, con lo cual se evita tener que usar múltiples protocolos y formatos e interfaces distintas. Aunque no todas las actividades están actualmente implementadas como servicios Web en las organizaciones, sus efectos a nivel interno son tangibles, puesto que ayudan a simplificar y hacer más veloz la interacción y la ejecución de un proceso de negocio. Un proceso de negocio usando BPEL puede orquestar muchos servicios web y efectivamente crear aplicaciones nuevas y completas, con sus propias interfaces públicas para los usuarios finales.

BPEL provee un motor de orquestación para describir cambios de información interna o externamente. BPEL maneja de manera muy explícita los aspectos funcionales de los Procesos de Negocios utilizando funciones como bucles, tareas humanas, compensaciones, secuencias paralelas, conversaciones o transacciones asíncronas o síncronas, largas unidades de trabajo, etc. BPEL apunta principalmente a los cambios de un proceso de negocio, comunicaciones con servicios de manera asíncrona, envió de mensajes, cambio de mensajes, flujos paralelos de actividades, manipular datos a través de interacciones con otras herramientas, soporta grandes transacciones de negocios y actividades y provee consistentes manejos de excepciones.

Al usar BPEL para definir procesos de negocios muchas compañías se han fortalecido por seleccionar e incorporar lo mejor del mercado para sus procesos ya que obtienen flexibilidad para reemplazar o actualizar ciertos aspectos en el negocio sin impactar a los sistemas que utilizan y que se encuentran trabajando bien. Por nombrar una compañía puede cambiar de proveedor de servicios sin impactar el orden de manejos de sistemas incluso los mismos empleados que participen en procesos importantes.

En la actualidad los servicios Web son un tema especial para el comercio y la integración. Las compras, las solicitudes, los mensajes, etc., solo un conjunto de datos a considerar y que son vía Servicios Web por mencionar algunos.

BPEL está basado en un lenguaje XML que permite a los usuarios a conectarse vía servicios web facilitando la orquestación e interacción.

En términos más técnicos, BPEL es un lenguaje de flujo de procesos, el cual será desarrollado normalmente usando un editor visual para crear un diagrama de flujo. lo anterior incluye esperar por un evento, transformarlo en mensaje, definir la trayectoria y momento en el que proceso se ejecutará, invocar un servicio externo y esperar respuesta, advertir alguna falla y definir un proceso compensatorio si corresponde. El proceso compensatorio es muy importante porque durante un proceso de negocios un servicio externo puede ser llamado y dicho servicio completará y hará los cambios necesarios, en caso de que el estado siguiente del proceso falle, realizándose otras transacciones para solucionar el problema eventual.

A continuación una "orquestación" realizada con la herramienta de BPEL proporcionada por Oracle:



martes, 26 de marzo de 2013

¿Qué hay de nuevo en Oracle Database 12c?


Pluggable Databases: Permitirá contener una colección de esquemas u objetos de esquemas que aparecerán para un cliente en Oracle Net como una base de datos separada, independiente. A la característica Pluggable Databases también se le es referenciada únicamente por las siglas PDB. Un Container Database (CDB), es una base de datos que incluye una o más PDB’s. Es posible sacar un determinado PDB de un CDB y volverlo a incluir dentro de un diferente CDB. 


Resource Manager soportado por PDBs: El Resource Manager es una herramienta que gestiona  recursos, esta herramienta también estará soportada para ser usada  a nivel de CDB  y a nivel de PDB. Se puede crear un plan de recursos para CDB que permitirá asignar recursos al CDB completo y a individuales PDBs. Se podría asignar más recursos a una determinada PDB y menos recursos a las demás PDBs dentro del CDB, o también se podría especificar que todas las PDBs dentro de un CDB poseerán igualdad de recursos.


 Full Transportable export/import: Esta característica permitirá mover bases de datos desde una instancia a otra. Transportando una base de datos es mucho más fácil y rápido que otros métodos, tales como full export/import. Adicionalmente, se puede usar la característica “Full Transportable export/import” para mover una base de datos no-CDB o una base de datos 11.2.0.3 dentro de un PDB que es parte de un CDB.

Nuevos privilegios administrativos para diferentes tareas de administración: Oracle 12c ahora provee privilegios para tareas relacionadas con Oracle Recovery Manager (Oracle RMAN), Oracle Data Guard y Encriptación de datos. Cada nuevo privilegio de administración sede el minimo privilegio requerido para realizar dichas tareas. Estos nuevos privilegios evitan la necesidad de asignar el rol SYSDBA para todos los DBA’s. Más bien cada DBA tendrá una tarea asignada y en base a esa tarea serán sus privilegios. Para las tareas de Backup y recuperación con RMAN está creado el rol backupdba, para las tareas de Data Guard está creado el rol dgdba y para las tareas de encriptación de datos está el rol kmdba, por supuesto aún siguen existiendo los role dba y asmdba.

Database Smart Flash Cache soportado para múltiples dispositivos flash: Una instancia de base de datos puede acceder y combinar múltiples dispositivos flash para crear un Database Smart Flash Cache sin requerir un volumen manager. Está característica fue introducida en 11g, sin embargo, en 11g es necesario un volumen manager y no todos los dispositivos flash son soportados.

Temporary Undo: El Undo generado por los objetos temporales es almacenado en un Tablespace Temporal, ya no más en un Tablespace de tipo Undo. Al usar Undo temporal se reduce la cantidad de Undo almacenado en el tablespace de tipo Undo y el tamaño de los redo log. También facilita la realización de Data Manipulation Languaje (DML) en tablas temporales en una Base de Datos standby de tipo “Physical” creada con Data Guard.

Mejoras en el Database Resident Connection Pool (DRCP): Se puede hacer uso de las características que provee Oracle Advanced Security  con DRCP, incluyendo fuerte autenticación y encripción con la opción de Advanced Security. Las conexiones creadas con  DRCP  soportan varios tipos  de autenticación entre ellos Kerberos y Enterprise User Security.

Mover Datafile online: En oracle 12c es posible mover un datafile a un diferente dispositivo de almacenamiento cuando esta online y siento accedido. Esta capacidad simplifica las operaciones de mantenimiento reduciendo los Downtime.

Múltiples índices en el mismo conjunto de columnas: Esta característica permite crear multiples índices en el mismo conjunto de columnas para realizar migraciones de aplicaciones sin eliminar existentes índices y recrearlos con diferentes atributos.

Mover una partición o subpartición online: Esta característica permitirá que las operaciones DML continúen ejecutándose sin interrupción mientras una partición o subpartición está siendo movida.

Redefinición de tablas con múltiples particiones online: Oracle 12c permitirá minimizar el Downtime cuando se está redefiniendo una tabla con múltiples particiones. Se podrá redefinir dicha tabla con sus particiones en una sesión sencilla y de manera online.

Nuevo parámetro en el procedimiento FINISH_REDEF_TABLE: El parámetro “dml_lock_timeout” está disponible en Oracle Database 12 y permitirá establecer al procedimiento FINISH_REDEF_TABLE un límite de tiempo de espera para que las transacciones pendientes realicen “commit”.

Columnas invisibles: Esta característica permitirá crear columnas individuales de manera invisible. Cualquier acceso genérico hacia una tabla con columnas invisibles, no mostrará dichas columnas, por ejemplo:

SELECT * FROM table
DESCRIBE table

Una consulta genérica a una tabla no mostrará los valores de la columna invisible, a menos que explícitamente se escriba en la sentencia “SELECT” el nombre de la columna. No se podrá insertar un valor en una columna invisible en la sentencia “INSERT”, a menos que explícitamente se escriba el nombre de la columna.

Usted puede hacer uso de Columnas invisibles si se está realizando  cambios en dicha tabla pero no se desea afectar las aplicaciones dependientes.

Sentencia ALTER TABLE ADD COLUMN optimizada: Una columna “nullable” es una columna que ha sido creada sin usar la restricción “NOT NULL”. Para ciertos tipos de tablas, cuando se agregan columnas nullables, dichas columnas poseen un valor por defecto. La base de datos en su versión 12c tiene la capacidad de poder optimizar los recursos y poder almacenar el valor por defecto de dicha columna en la “metadata” de la tabla. Es decir, en lugar de insertar el valor por defecto en cada registro insertado a la tabla, dicho valor es almacenado como “metadata”, de esta manera se evita la inserción del valor en todos los registros de la tabla.

Clonación Copy-on-Write de una Base de Datos: Cuando se está clonando una base de datos, Oracle 12c puede crear los archivos en la nueva base de datos haciendo uso de la tecnología Copy-on-Write, esto permite que únicamente los bloques de datos que están siendo utilizados requieran espacio adicional el ambiente de nuevo. Esto elimina el problema que para cada ambiente de pruebas nuevo se tenga que copiar en cada uno de ellos todos los datafiles del ambiente de producción, redundando espacio.

Log DDL: Cuando se habilita el registro de las sentencias DDL, éstas sentencias son registradas en un archivo log diferente al archivo de alerta de la base de datos (alert log).

Log Debug: Información importante que la instancia provee puede ser usada para poder realizar debug a la base de datos. Esta información es registrada en un archivo de log diferente al archivo de alerta de la base de datos.

Palabras reservadas para la herramienta SRVCTL: Para mejorar la usabilidad, cada opción de SRVCTL es una palabra reservada en lugar de una letra sencilla identificando la opción a usar.

Ahora la sintaxis que espera la herrameinta SRVCTL es:

SRVCTL <comando> <objeto> <opción>

Donde:

Comando: es un verbo tal como “start”, “stop” o “remove”.
Objeto: es un componente en que SRVCTL realizará la operación, tal como base de datos, listener, etc.
Opción: Extiende la operación a realizar especificando adicionales parámetros, por ejemplo “-db”, “-service”.

SRVCTL es sensible a mayúsculas y minúsculas.

Trnasaction Guard and Application Continuity: Si un corte de conexión ocurre entre la aplicación (cliente) y la base de datos (servidor), el cliente en versiones anteriores recibía un mensaje genérico de error el cual prácticamente decía que la comunicación se había perdido. Este mensaje no informa al cliente sobre si la transacción finalizó satisfactoriamente o hubo un fallo en la operación commit.

Transaction Guard usa un nuevo concepto llamado Identificador de transacciones lógicas (LTXID), el cual es un identificador único global. Cuando existe un error recuperable, Transaction Guard usa LTXID para determinar el resultado de la transacción. Este resultado es retornado al cliente en lugar de un mensaje genérico de error. El usuario entonces toma la decisión de volver a ejecutar la operación o no.

Nuevos tipos de Jobs: Varios tipos de jobs han sido agregados los cuales permiten ejecutar personalizados scripts usando sqlplus, o RMAN o una terminal convencional.

Oracle ACE Director Award - Deiby Gómez

Thanks #OracleACE Program for this awesome certificate recognizing the work I have done in the community for the last year. Looking forwa...