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!

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:

10³      kilo

10⁶      mega

10⁹      giga

10¹²    tera

10¹⁵    peta

10¹⁸   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?

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