Crear una aplicación APEX (Parte 1)

Vamos a ver un paso a paso de cómo crear una sencilla aplicación en APEX desde cero. Esta aplicación servirá para revisar algunos conceptos como:

• Creación de objetos de base de datos desde SQL Workshop.

• Creación de una aplicación básica, sin páginas iniciales, todo desde cero.

• Creación de las reglas de seguridad para autenticación y autorización.

• Creación de listas de valores.

• Modificación de las páginas para adecuarlas a nuestras necesidades.

Voy a asumir que tienen conocimientos suficientes sobre esquemas de base de datos, claves primarias y foráneas (PRIMARY KEYy FOREING KEY). Además, pueden utilizar cualquier instancia de APEX para desarrollar este ejercicio, ya sea su computador o en la versión gratuita de Oracle APEX.

Importante: esta aplicación es apenas una demostración así que seguramente me tomaré algunas libertades que tal vez no haría en una aplicación para desplegar en un ambiente productivo.

Requerimientos del usuario

Vamos a crear una aplicación muy básica pero que nos permitirá ver conceptos importantes en la creación de aplicaciones APEX. Crearemos una aplicación que servirá a un departamento de Gestión Humana para registrar a los empleados de la compañía. Los requerimientos que tiene la aplicación son:

• Registrar los datos básicos de los empleados: nombres, apellidos, fecha de nacimiento, estado civil, etc.

• Registrar los datos de relación del empleado con la empresa: cargo, gerencia o departamento, sucursal o filial en la que trabaja, supervisor, fecha de ingreso, código del empleado asignado por RRHH.

• Registrar los datos de contacto del empleado: correo electrónico, número de teléfono / extensión, dirección de la oficina o cubículo asignado.

• Los usuarios de la aplicación que pertenezcan al departamento de RRHH podrán ver y modificar los datos de todos los empleados.

• El resto de los usuarios podrá ver sus propios datos y los datos básicos de contacto del resto de los empleados.

• La aplicación debe por ser usada tanto desde un computador como desde dispositivos móviles. Debe ser visualmente agradable y capaz de adaptarse a múltiples tamaños de pantalla.

• Cada usuario ingresará con su dirección de correo electrónico y una contraseña.

Definición de objetos de base de datos

El primer paso antes de comenzar a desarrollar la aplicación es la definición de los objetos de base de datos que serán el repositorio de la información. Estos objetos deben ser modelados según los requerimientos que nos han dado los usuarios. Comenzaremos definiendo los objetos de manera básica y luego los convertiremos en objetos de base de datos Oracle

En primer lugar, sabemos que debemos registrar los datos de los colaboradores, al menos la siguiente información:

• Nombre y apellido

• Fecha de nacimiento

• Estado civil (soltero, casado, unión libre, etc.)

Sabemos que también hay cierta información que es exclusiva de un único empleado (código de empleado, fecha de ingreso, correo electrónico, etc.) así que lo podemos ver como una relación 1:1, podríamos agregar esos datos en el mismo objeto que usaremos para guardar los datos básicos. De esta forma, una tabla de EMPLEADOS podría quedar de la siguiente forma:

Veamos un par de puntos con esta tabla antes de continuar:

• La columna ESTADO_CIVILes de un tamaño de apenas un carácter porque solo vamos a guardar un valor que luego podremos obtener en una lista de valores (por ejemplo S para 'Soltero', C para 'Casado').

• Al momento de crear la tabla debemos agregar una columna para la clave primaria, lo cual haremos usando un IDENTITY COLUMN.

• Siguiendo la misma línea del punto anterior, es por eso que la columna ID_DEPARTAMENTO es un campo numérico, haremos referencia al PRIMARY KEYde la tabla de departamentos. Haremos lo mismo con el cargo, de esa forma nos aseguramos que todos los empleados que sean "Analistas contables" tengan el mismo nombre de cargo.

Ahora veamos la tabla de departamentos, será una tabla muy simple con apenas algunas columnas:

Sucede lo mismo con los cargos:

Veamos ahora el caso de los números de teléfono del empleado, podríamos agregar una columna de número de teléfono en la tabla EMPLEADOSpero nos limitaría la cantidad de números que podríamos agregar. Un empleado puede tener muchos números de teléfono (una relación 1:N) por lo que crearemos una tabla para registrar estos números

Lo mismo podría pasar con las direcciones, podríamos querer guardar la dirección de la casa del empleado y la dirección de la oficina.

Definición de la seguridad

La seguridad de la aplicación debería ser definida desde un principio, ya que luego sería mucho más complicado implementarla. Veamos nuevamente los requerimientos relacionados con la aplicación

• Los usuarios de la aplicación que pertenezcan al departamento de RRHH podrán ver y modificar los datos de todos los empleados.

• El resto de los usuarios podrá ver sus propios datos y los datos básicos de contacto del resto de los empleados.

• Cada usuario ingresará con su dirección de correo electrónico y una contraseña.

Para cumplir con estos requerimientos haremos uso de algunos componentes propios de APEX para manejar la seguridad: Authentication Schemes y Authorization Schemes.

Hay varias formas de resolver el requerimiento relacionado a la autorización:

• Usar la funcionalidad nativa de APEX para el control de acceso, es la más sencilla pero he encontrado un par de debilidades:

  • Es poco flexible, en caso de ser necesario agregar un nuevo rol o asignar un usuario a un rol debe hacerse desde APEX directamente, no lo podría hacer un usuario de la aplicación.

  • Al exportar una aplicación e importarla en otro workspace, los usuarios que están dentro de los roles no son importados, por lo que es necesario agregarlos nuevamente de manera manual.

• Crear tablas para el manejo de los roles, este enfoque permite que la seguridad pueda ser administrada desde la misma aplicación por los usuarios finales, y es fácil de replicar entre ambientes.

Para este caso vamos a usar la segunda opción y veremos cómo aun es posible construir la seguridad de manera declarativa.

Primero definimos una tabla donde guardaremos los nombres de los roles

Un empleado puede tener múltiples roles, por lo que crearemos una segunda tabla con dicha relación.

Ahora que ya hemos definido los objetos que vamos a necesitar, podemos crearlos en la base de datos. Para hacerlo más interesante, veamos cómo crearlos usando Quick SQL, una funcionalidad de SQL Workshop.

Para ingresar a Quick SQL ingresamos a APEX - SQL Workshop - Utilities

Con Quick SQL escribimos en texto plano los nombres de las tablas y las columnas y automáticamente se generará el código SQL necesario para crear dichos objetos.

Comencemos con la tabla departamentos:

Solo fue necesario ingresar el nombre de la tabla y los campos en las líneas siguientes con un par de espacios y Quick SQL generó todo el DDL de manera automática, incluyendo la columna de primary keyque no coloqué en el texto original.

Sobre los modificadores que utilicé:

• /auditcolspermite agregar columnas de auditoría a la tabla (cuándo fue creado el registro, por quién, cuándo fue modificado) y los triggers necesarios para llenar dichos campos de manera automática

• /uniquepermite agregar un constraint uniquesobre las columnas de la tabla, en este caso el código del departamento.

Agregaremos la tabla de cargos y la tabla de empleados y le indicaremos a Quick SQL que existe una relación entre todas ellas.

De manera automática se crean los foreing keynecesarios en la tabla empleados, así como los índices sobre dichas columnas (utilizando el modificado /fk)

Completemos la tarea con el resto de las tablas que definimos en el análisis del requerimiento. Una vez que estemos satisfechos con el resultado (que siempre podremos modificar según nuestras necesidades) hacemos clic en Review and Run, esto nos llevará al Script Editor y allí podremos hacer las modificaciones que necesitemos, finalmente hacemos clic en Run

Es este caso vemos que todas las sentencias se ejecutaron correctamente.

En la siguiente parte crearemos la aplicación y definiremos el esquema de seguridad.