Archive

Posts Tagged ‘pl/sql’

Oracle REST Data Services como alternativa a mod_plsql en Oracle Forms & Reports 12c

En la nueva versión 12c de Oracle Forms & Reports observamos que se han eliminado los siguientes módulos de Oracle HTTP Server:

  • mod_perl
  • mod_fastcgi / mod_cgi
  • mod_plsql

En esta entrada nos centraremos en el módulo mod_plsql, usado muchas veces en aplicaciones coexistentes con Forms & Reports. Este módulo nos permite crear páginas dinámicas a partir de packages/procedimientos PL/SQL almacenados en base de datos y es ideal para desarrollar páginas rápidas y flexibles, tanto en Intranet como en Internet.

plsqlarch

Como se puede leer en la hoja de ruta de APEX, Oracle HTTP Server (OHS) /Mod-PLSQL (Doc ID 1945619.1), a partir de la versión 12.1.3  la funcionalidad mod_plsql ha sido deprecada y, en la nueva release 12c que incluye Forms & Reports, ya no se encuentra disponible.

Para los que aún no han migrado a la versión 12c, Oracle recomienda cambiar a Oracle REST Data Services (Oracle APEX Listener) como alternativa a mod_plsql.

Oracle REST Data Services (ORDS) es una alternativa, basada en Java EE, para Oracle HTTP Server y mod_plsql, ofreciendo más funcionalidades, seguridad mejorada, caché de ficheros y servicios Web RESTful. ORDS soporta despliegues usando Oracle WebLogic Server, GlassFish Server y Apache Tomcat.

ordsarch

Como alternativa a ORDS y mod_plsql, aunque no soportado por Oracle, podemos instalar mod_owa.

Desarrollos corporativos utilizando el framework Oracle más adecuado

febrero 9, 2016 Deja un comentario

Ruben Rodriguez, Java and ADF Specialist en avanttic, escribió en el número 6 de la revista Oracleando un artículo sobre las novedades en las plataformas y frameworks de desarrollo web y mobile de Oracle presentadas durante Oracle OpenWorld 2015.

Siempre que pensamos en Oracle OpenWorld sabemos que Oracle va a poner en el mercado nuevos productos y nuevas versiones de productos ya existentes. Este año no iba a ser menos y, en cuanto a plataformas de desarrollo de aplicaciones web y mobile, ha sido un OOW cargado de emocionantes novedades.

IMG

Oracle pretende dotar, a clientes y partners, de herramientas y frameworks adaptados a cada necesidad, en función del tipo de desarrollo a realizar (centrado en la BBDD, web/mobile o sobre el cloud) y del perfil de los desarrolladores de que se disponga:

1. Los desarrolladores PL/SQL podrán utilizar APEX o Forms para desarrollar aplicaciones con la lógica de negocio almacenada en la BBDD.

2.  Los desarrolladores Java podrán utilizar Oracle ADF y Oracle MAF para desarrollar aplicaciones web y mobile.

3.  Los desarrolladores JavaScript podrán utilizar Oracle JET para desarrollar la capa de presentación, tanto de las aplicaciones web como las de mobile.

4.  Todo tipo de desarrolladores Cloud, e incluso los usuarios de negocio, podrán crear aplicaciones sin tener que realizar programación en un lenguaje específico, utilizando las dos nuevas plataformas de desarrollo cloud: Oracle Application Builder Cloud Service y Oracle Mobile Application Accelerator (dentro de Oracle Mobile Cloud Service).

En este artículo podrá conocer más detalles sobre todos estos frameworks y plataformas de desarrollo web/mobile que tenemos a nuestra disposición e intentaremos descubrir la estrategia de Oracle que se vislumbra detrás de estos lanzamientos.

Si desea orientación sobre qué framework sería el más adecuado para alguna necesidad concreta, no dude en ponerse en contacto con nosotros.

Ofuscar código PL/SQL

octubre 3, 2014 1 comentario

En ocasiones deseamos que nuestro código PL/SQL no sea fácilmente accesible a los usuarios y/o administradores de las BBDD en las que lo tenemos instalado, sea para evitar copias o modificaciones no autorizadas.

En parte estos objetivos los podemos conseguir “ofuscando” nuestro código. Notar que el objetivo no es “cifrar” el código, ya que existen maneras de llegar a revertir el proceso, mas bien se trata de no permitir un acceso libre a él. Es posible conseguirlo utilizando la utilidad de línea de comando PL/SQL Wrapper o el procedimiento de base de datos DBMS_DDL.WRAP.

El objetivo de este post va a ser mostrar cómo ofuscar el código PL/SQL de nuestras aplicaciones mediante la utilidad de línea de comando PL/SQL Wrapper.

  • La documentación para la versión 11gR2 en el momento de creación de este post se puede consultar en este link.
  • Se puede ofuscar el código de paquetes (tanto especificación, como cuerpo, como ambos), tipos (tanto especificación, como cuerpo, como ambos), funciones y procedimientos. No se puede ofuscar triggers, aunque desde el trigger sí se puede referenciar a un procedimiento ofuscado.
  • El código ofuscado se puede compilar, exportar e importar como el código “en claro”, pero hay que tener cuidado con las versiones de base de datos, ya que no existe compatibilidad hacia atrás, es decir, el código compilado en una versión 11g no funcionará en una 10g, el de la 10g no funcionará en una 9i y así.
  • Oracle no proporciona mecanismos ni herramientas para revertir esa ofuscación una vez se ha ofuscado el código,  y, aunque existen formas de conseguirlo, no es el alcance de este post. Si se desea modificar el código es necesario editar el fichero original, volverlo a ofuscar y cargarlo en la base de datos.

Leer más…

Categorías:Seguridad Etiquetas: , , , ,

Desarrollos ADF: mono-plataforma vs multi-plataforma

junio 26, 2014 2 comentarios

adfUna decisión que hay que tomar a la hora de afrontar un proyecto en ADF es cómo y dónde vamos a desarrollar el código que soporte la lógica de negocio. Las dos posibilidades más obvias son:

  1. basar todo el desarrollo en Java, a nivel de aplicación, o
  2. implementar la lógica de negocio en PL/SQL en la base de datos, y usar java desde la aplicación para gestionar las capas de vista, controlador y modelo, dejando esta última capa como un mero acceso a BD.

Veamos las ventajas que aporta cada uno de los enfoques:

Ventajas desarrollo 100% ADF

  • Todo el equipo de desarrollo tiene el mismo perfil. No debemos buscar especialistas en java y especialistas en PL/SQL (o especialistas en ambas cosas a la vez). De todos modos, alguien tendrá que saber SQL.
  • Al tener un único origen de datos la gestión del control de versiones se simplifica.
  • Por el mismo motivo, los despliegues no incluyen scripts de compilación de objetos de base de datos (procedimientos, funciones, paquetes o triggers), además del fichero que desplegaremos en Weblogic.

Ventajas desarrollo ADF + PL/SQL

  • Los tiempos de desarrollo suelen ser menores, al ser PL/SQL un lenguaje de programación totalmente orientado al proceso de datos de BD.
  • Los procesos intensivos de datos son más eficientes y proporcionan mejores tiempos de respuesta.
  • Reutilización: al mantener la lógica de negocio junto a los datos, el impacto al cambiar el front-end es menor. Por ejemplo, si necesitamos llevar una parte de nuestra aplicación a una app móvil, no tendremos que volver a re-escribir código.
  • Podemos mantener los datos coherentes en cualquier caso, independientemente de la aplicación (por ejemplo totales de facturas basados en la suma de sus líneas; relaciones en arco; etc).

Encontraremos una ventaja añadida al desarrollo ADF + PL/SQL si pensamos en el largo plazo. Nuestra experiencia nos muestra que la base de datos suele ser el último componente que se descarta en el ciclo de vida de una aplicación. En este caso disfrutaremos durante más tiempo de la inversión que hayamos hecho escribiendo la lógica de negocio en BD.

Sin embargo hay quien opina justo lo contrario, que no se debe ubicar nada en la BD y que esta debe ser un puro contenedor de datos, de modo que se pueda cambiar de un gestor de BD a otro, pero… ¿conoces a alguien que haya cambiado?. Por supuesto, cualquier decisión en un sentido u otro debe tomarse tras un análisis mucho más detallado y tomando en consideración más factores que los pueden citarse en una entrada de blog.

Categorías:ADF / Java Etiquetas: , ,

Normalización de cadenas de texto en PL/SQL

octubre 16, 2013 5 comentarios

La normalización de cadenas de texto es uno de los temas recurrentes en el desarrollo de procesos ETL. Cuando se tratan datos anagráficos, es muy común encontrarse con duplicados debidos a errores tipográficos y de data entry.

Consideremos el siguiente ejemplo:

Ejemplo Datos Duplicados

Se puede ver que los dos registros se refieren a la misma persona física, pero hay elementos que impiden considerar los registros como duplicados perfectos. El NIF ha sido transcrito mal. Es presumible que el error venga de una introducción manual de los datos ya que la N y la H están muy cerca en el teclado español. Tanto el nombre como el domicilio aparecen en dos formatos distintos, mientras que en el caso de la población es el acento el que hace que no coincidan las dos cadenas.

¿Qué herramientas tenemos en PL/SQL para matchear los dos registros y eliminar los duplicados?

La función SOUNDEX devuelve una representación fonética de una cadena. El resultado es la codificación de cómo se pronunciaría un texto en inglés. A pesar de que estemos trabajando con texto en otro idioma, la función puede resultar útil.

Si la aplicamos por ejemplo a la población, tendremos:

SELECT POBLACIO, SOUNDEX(POBLACIO)
FROM CLIENTES
WHERE NOMDES LIKE '%SCOTT%'

Ejemplo SOUNDEX

En este caso, el código resultante es el mismo y podríamos utilizarlo para considerar que tienen igual valor.

En otros casos, como el nombre, el resultado de la función SOUNDEX no nos ayuda.

SELECT NOMDES, SOUNDEX(nomdes)
FROM CLIENTES
WHERE NOMDES LIKE '%SCOTT%'

El package UTL_MATCH contiene unas funciones desarrolladas para facilitar la detección de duplicados. Hay cuatro funciones:

  • EDIT_SIMILARITY: la función calcula la distancia de Levenshtein. Esta medida debe el nombre al científico ruso que desarrolló un algoritmo para medir la distancia entre dos cadenas de texto s1 y s2. La distancia se calcula como numero de inserciones, cambios, cancelaciones de caracteres que permiten pasar de la cadena s1 a la cadena s2. La función devuelve un número que representa la distancia entre las dos cadenas: 0 indica dos cadenas idénticas. En el ejemplo, si asumimos que el formato correcto es “NOMBRE APELLIDO”, la función devuelve:
SELECT nomdes, utl_match.edit_distance(NOMDES, 'SCOTT TIGER')
FROM clientes
WHERE NOMDES LIKE '%SCOTT%'Ejemplo EDIT_DISTANCE

La distancia entre las dos cadenas no es muy grande y podríamos considerar las dos cadenas como coincidentes.

  • EDIT_DISTANCE_SIMILARITY: actúa como la función EDIT_SIMILARITY pero devuelve un valor normalizado entre 100 (cadenas coincidentes) y 0 (total discordancia).
  • JARO_WINKLER: esta función utiliza el algoritmo de Jaro-Winkler que calcula un índice de similitud entre dos cadenas, para intentar tener en cuenta posibles errores tipográficos. El valor 1 representa dos cadenas coincidentes.
    Ejemplo JARO-WINKLER
  • JARO_WINKLER_SIMILARITY: la función utiliza el algoritmo de Jaro-Winkler y normaliza los resultados entre 0 y 100.

Las funciones del paquete UTL_MATCH permiten definir un umbral de aceptabilidad para establecer si dos cadenas coinciden “lógicamente” y pueden resultar una herramienta muy útil en el proceso de data cleansing.

Categorías:SQL Etiquetas: , ,

Recursividad en PL/SQL (II) – Implementación alternativa

noviembre 28, 2010 1 comentario

Ref. ”Recursividad en PL/SQL – Un ejemplo

Como bien se identifica en el ejemplo de la referencia, se está tratando con datos existentes en la BBDD que tienen estructura jerárquica. También se identifica una relación unívoca entre un ‘maestro’ / ‘detalle’ (‘Carpeta’ vs ‘Documento’) y operaciones donde si se actúa sobre la entidad ‘maestro’ implica acciones sobre la ‘detalle’ –operación de ‘DELETE’-.

Partiendo de esas dos premisas iniciales, a continuación se expone una propuesta de nuevo modelo de programación a partir del caso del ejemplo de la referencia que, aunque considerándose como un ejemplo muy acertado, permitirá ver otro tipo de soluciones más óptimas

1.- Uso del Modelo Relacional

Por definición, si un registro de ‘Carpeta’ es borrado, carece de sentido la existencia de registros asociados en ‘Documento’. Es más, por integridad referencial no es posible borrar una carpeta que tenga documentos vinculados.

Por lo tanto es recomendable modificar la relación establecida y definida a nivel de ‘CONSTRAINT’ de clave foránea -‘FK’- :

Leer más…

Categorías:SQL Etiquetas: , , , ,

Consideraciones generales sobre recursividad

noviembre 22, 2010 1 comentario

La utilización de técnicas de recursividad dentro de la programación en cualquier tipo de lenguaje (en este caso PL/SQL) dota al código de un gran nivel de ‘factores de calidad’ (calidad + simplicidad + potenciabilidad). Características que conjuntamente con las de elegancia y sencillez dotan a esta técnica como de uso muy recomendable.

Unos de los casos más representativos de la aplicación de esta técnica, por su propia definición, es la del cálculo matemático del ‘factorial’ de un número:

n! = n * (n-1) * (n-2) * (n-3) * … * 1

Indicar como excepción a la recursividad tradicional, situaciones en las que la información susceptible de tratamiento está ubicada en la Base de Datos en un modelo de ‘Estructura Jerárquica‘. Esta puede ser tratada por ‘SQL‘ mediante consultas ‘jerárquicamente relacionales‘ (‘CONNECT BY PRIOR …‘). A esta excepción se le denomina ‘recursividad por estructura en relación reflexiva‘  (ver más detalladamente a continuación).

Leer más…

Categorías:Metodología Etiquetas: , , ,