Skip navigation

Following the lead of TimHall, I created this post in order to say thanks to the Oracle Team who supports our community everyday. #ThanksODC

 

Recently joelkallman-Oracle created a poll in order to know what should be done about Team Development. The poll has not finished yet, these are the result by the moment:

But before they decide to deprecate and remove that component, I would like to share very quickly my point of view:

 

1.  Feedback. Is the feature that I like most. It's very cool that end users can report a bug or a comment directly from the app. In fact, it's really appreciate it when the company doesn't have a corporate management support tool.
After the end user submit their bug or comment, developers/support can check them and decided what to do about each one. They can convert it in a "To Do" or a "Feature" and submit comments and a public response.

 

2. Application Context, Environment and Session State. An easy way to know everything about the browser, version and session_id that end user was using by the moment which created the feedback.

 

3. Tracking Milestones, Features, To Dos, Bugs: I have to say that I don't use them all. I have found that Bugs and Features are very useful when you need to assign them to developers. Then you can track all their work easily, no need to ask anything!

 

In conclusion points 1 and 2 are a must-have feature, point 3 can be simplified.

El OTN Tour se transformó y ahora se conoce como Oracle Developer Community. Este año se realizó el 16 y 17 de Agosto en la ciudad de Barranquilla, Colombia.

 

El evento inicio el 31 de Julio en Chile y terminará el 28 de Agosto en Guatemala, para estar informado de los eventos que se realizan en Latinoamérica visita frecuentemente la página de LAUOC (Eventos – LAOUC ).

 

Se presentaron diversos temas y talleres muy interesantes para la comunidad creciente de productos Oracle en la región, entre ellos estuvieron:

 

 

- Edelweiss Kammermann

- Tim Hall

- Alexis López

- Pablo Sainz

- David López Abugattas

- Gustavo Gonzalez

- Mercedes Wyss

- Ricardo Gonzalez

- Nelson Calero

- Byron Motta

- Edgardo Sánchez

- Hilmer Chona

- Emerson Perdomo

- Javier Camargo

- Jose Niño

- Mónica Godoy

 

Es importante resaltar los tres programas con los que cuenta Oracle y al que pueden unirse si ya están creando y compartiendo contenido relacionado a los productos Oracle:

Para más información:

https://blogs.oracle.com/developers/new-developer-champion-program

https://apex.oracle.com/pls/otn/f?p=19297:3

 

El primer paso para ingresar a uno de los programas es hacer parte de la comunidad:

https://community.oracle.com/welcome

 

Puntos Clave:

Office Hours: https://asktom.oracle.com/pls/apex/f?p=100:500:::NO:RP,500::

OBIEE: https://www.oracle.com/technetwork/es/middleware/bi-enterprise-edition/tutorials/index.html

Hasta 3.500 horas para probar Oracle Cloud: https://cloud.oracle.com/tryit

 

Imágenes: ASUOC(@asuoc) y Oracle Developers LA (@OracleDevsLA)

En las utilidades del SQL Wokshop (Taller SQL), encontramos la opción Database Monitor. Esta opción nos brinda un panorama de toda la base de datos, las sesiones, estadísticas del sistema, consultas SQL y operaciones más largas.

Podemos utilizar esta información para identificar consultas SQL de bajo rendimiento y comprender mejor la carga de trabajo que tiene la base de datos.

 

Hoy veremos en detalle las denominadas Top SQL ó en español SQL Principal.

Lo primero que se requiere es activar el monitoreo en el workspace Internal:

En el workspace que quiere evaluar, ingresar a SQL Workshop -> Utilities -> Database Monitor.

Ingresar las credenciales de un usuario con privilegios de DBA.

Al ejecutar Top SQL veremos las sentencias SQL que se ejecutan con mayor frecuencia, que utilizan más recursos del sistema que otras sentencias SQL o que usan recursos del sistema con más frecuencia que otras sentencias SQL.

Al dar clic en la lupa podemos ver el SQL Plan, que contiene las siguientes secciones:

 

Query Plan: contiene un plan de explicación con código de color. Tenga en cuenta que las columnas no indexadas se muestran en rojo.

SQL Text: muestra el texto completo de la declaración SQL.

 

Indexes: muestra todos los índices en la tabla en la consulta. Hay una marca de verificación cuando ese índice se usa en la consulta.

Table Columns: muestra todas las columnas en todas las tablas o vistas en la consulta.

 

Module: El esquema, aplicación y página de APEX donde se ejecuto el SQL por última vez.

CPU: Tiempo de CPU en segundos que este SQL tomó en ejecutarse la última vez.

Buffer Gets / Rows Processed: El número de bloques leídos dividido por el número de filas devuelto. Será nulo si las filas procesadas son cero.

Action: El punto en que se está ejecutando el SQL en la página de APEX.

Disk Reads: La cantidad de bloques leídos desde el disco la última vez que se ejecutó este SQL.

Buffer Gets / Executions: Número de bloques leídos dividido por el número de veces que se ejecutó una consulta. Entre más alto sea el valor indica un mayor número de lecturas de bloques por ejecución.

Executions: Número de veces que se ha ejecutado este SQL.

Rows Processed: Número de filas que este SQL devolvió la última vez que se ejecutó.

Buffer Gets: Número de bloques en memoria a los que accedió este SQL la última vez que se ejecutó.

 

Nota: Las imágenes se presentaron en Inglés porque se entiende mejor que la traducción realizada en Español.

Dentro de las utilidades de APEX se encuentra el Diccionario de Atributos.

Hoy veremos como sacarle partido a esta opción, para esto voy a crear una aplicación de cero e ir al diccionario de atributos.

En el diccionario podemos añadir elementos y columnas de los reportes. En este ejemplo veremos la aplicabilidad en los elementos de una página, sin embargo el funcionamiento es el mismo para las columnas.

Allí crear una nueva entrada con el nombre EJEMPLO y dos sinónimos:

- EXAMPLE

- TEST

 

Crear una página y tres elementos con los nombre: EJEMPLO,EXAMPLE y TEST.

Al volver al diccionario, tenemos dos opciones:

1. Actualizar la página con los atributos del diccionario.

2. Actualizar el diccionario con los atributos de la página.

 

Siguiendo la primera opción,

Definir que elementos y que atributos se actualizarán:

Al ejecutar la página efectivamente utiliza los atributos indicados en el diccionario.

Para la segunda opción, realizar modificaciones sobre el elemento EJEMPLO de la página creada. Como los tres elementos comparten los mismos atributos, al modificar el principal los demás heredarán estos cambios.  Actualizar el diccionario para guardar los cambios realizados en la aplicación.

Al ejecutar la página se ven los cambios realizados en todos los elementos.

En el caso de que la aplicación ya tenga todos los elementos, añadir estos elementos al diccionario. En este punto, ya será posible hacer modificaciones sobre el diccionario y actualizar fácilmente todos los elementos o columnas de las páginas de la aplicación que se hayan incluido en el diccionario.

Es muy interesante utilizar esta utilidad porque nos asegura unificación en los atributos de los elementos y columnas utilizados a lo largo de la aplicación, así como también nos ahorra mucho tiempo cuando se requiera hacer algún cambio sobre los elementos.

Recientemente vi esta imagen que al principio me hizo reír mucho pero que realmente no es la mejor manera de depurar una aplicación.

Hoy les mostraré como depurar una aplicación que ejecuta una función de la base de datos utilizando SQL Developer.

 

Para el ejemplo utilizaré:

- Una aplicación de APEX (versión 5.1.1.00.08) con acceso al esquema HR y que ejecute la función HR.TESTING_DEBUG.

- SQL Developer (versión 4.0.2.15)

- Credenciales de los usuarios SYS y HR

- Función HR.TESTING_DEBUG.

 

Para iniciar necesitamos otorgar los siguientes privilegios, los cuales se deben ejecutar con un usuario con privilegios de DBA (Por ejemplo, SYSTEM):

GRANT DEBUG CONNECT SESSION TO HR;

GRANT DEBUG ON HR.TESTING_DEBUG to PUBLIC; 

 

Crear una conexión con el esquema HR desde SQL Developer, dar clic sobre la conexión creada y seleccionar "Remote Debug".

Asignar los parámetros por defecto para el puerto y tiempo de espera. En la dirección local usar la dirección IP donde se esta ejecutando SQL Developer.

                                                                                                                                                        

 

En APEX, ir a Taller de SQL -> Comandos SQL y ejecutar:

begin

dbms_debug_jdwp.connect_tcp('192.168.0.3',4000);

end;

* Reemplazar 192.168.0.3 por su dirección local.

 

En SQL Developer, con el esquema HR buscar la función, compilarla para debug y definir los puntos de corte (breakpoints):

Ejecutar la aplicación activando la opción Debug en la barra del desarrollador:

Esto nos mostrará la depuración en SQL Developer por cada uno de los puntos de corte que se definieron previamente. Esto nos permite visualizar el valor de cada variable y parámetro utilizados en la función de una manera mas rápida y efectiva.

La aplicación de APEX quedará en espera mientras se esta ejecutando la depuración y al terminar podremos ver el resultado de la ejecución de la función.

Recientemente terminó el ODT 2017 en Colombia, el cual hizo parte del evento ODT que se realiza en centro y sur américa. Este evento nació como la evolución del APEX Tour con la finalidad de incluir más tecnologías relacionadas a Oracle.

Este año se llevo a cabo en los siguientes países:

- México. Octubre 30.

- Costa Rica. Octubre 31.

- Panamá. Noviembre 1.

- Colombia. Noviembre 2 y 3.

- Ecuador. Noviembre 7.

- Paraguay. Noviembre 8.

- Brasil. Noviembre 9 y 10.

- Argentina. Noviembre 13 y 14.

- Chile. Noviembre 17.

 

En Colombia tuvimos la oportunidad de contar con los speakers:

- Joel Kallman (@joelkallman)

- David Peake (@orcl_dpeake)

- Emilio Urrutia (@emiliourrutia)

- Alexis López (@aa_lopez)

- Hernan Morello (@hernan_morello)

- Edgardo Sanchez

- Yury Yineth Niño Roa

- Jose Niño

- David Lopez Abugattas (@dlopezabugattas)

- Hillmer Chona  (@hchona)

- Mónica Godoy (@signal006)

 

Hubo conferencias y talleres relacionados con Java, MySQL, Docker, emprendimiento y Oracle APEX, el cual fue el tema mas hablado.

Aunque poco se conoce de Oracle APEX en Colombia, el público se emocionó al conocer esta herramienta la cual satisface los requerimientos y desafíos que afrontan en este momento. Como es el caso de la migración de Forms a APEX, la integración con la E-Bussiness Suite, la facilidad para crear los reportes y la incorporación de IoT a las aplicaciones.

Sin duda alguna, después de este evento serán muchas las empresas que empezarán a utilizar Oracle APEX como herramienta principal de desarrollo.

¡Hemos creado una fiebre de APEX en Colombia!

 

DNuOtYAUMAAq7hy.jpg

Seguimos con la segunda parte para evaluar la seguridad de nuestras aplicaciones. Para este caso, voy a usar la aplicación empaquetada "Opportunity Tracker".

En el home del workspace encontramos el link para ejecutar APEX-SERT:

 

Damos clic y se abrirá una nueva ventana con la aplicación.

Las aplicaciones que nos muestra en la lista de valores son las aplicaciones que existen en el workspace donde ejecutamos APEX-SERT.

Ahora, seleccionamos la aplicación que queremos evaluar:

 

Al terminar la evaluación, encontramos las vulnerabilidades por cantidad, clasificación, impacto y severidad:

Ahora miremos en detalle una de las vulnerabilidades, damos clic sobre uno de ellos (en este caso, revisaremos Form Autocomplete) y podemos ver todas las páginas donde esta sucediendo la vulnerabilidad en cuestión.

Aquí podemos hacer tres cosas:

1. Ir a editar la página donde se presenta la vulnerabilidad.

2. Crear una excepción a la vulnerabilidad.

3. Crear un comentario sobre la vulnerabilidad detectada.

 

Vamos con la primera, editar la página. La vulnerabilidad que estamos evaluando es Form AutoComplete, así que vamos a la región de seguridad y ponemos en off  esta opción:

Así podríamos hacer con las demás páginas que tienen activo el auto completar. Cuando volvamos a evaluar la aplicación, estas vulnerabilidades habrán cambiado de estado. Con solo este cambio ya hemos mejorado la seguridad de la aplicación en un 10% aproximadamente.

 

La segunda opción es crear la excepción, después de creada un usuario con permisos de aprobación podrá aprobar o desaprobar la excepción. En caso de que sea aprobada, esta vulnerabilidad no afectara el puntaje de seguridad de la aplicación.

Para administrar los roles y permisos sobre los workspaces, ir a la aplicación: http://<ip>:<puerto>/ords/f?p=SERT_ADMIN

 

Finalmente, la última opción es crear anotaciones o comentarios sobre las vulnerabilidades detectadas. Pueden ser útiles para mantener trazabilidad o algún comentario útil para todo el equipo de desarrollo.

 

Para más información de APEX-SERT: https://github.com/OraOpenSource/apex-sert

¿Alguna vez has probado tu aplicación de APEX para revisar sus vulnerabilidades de seguridad? Ó tan pronto terminas la aplicación, la publicas en el ambiente de producción?

 

Bueno, en este artículo veremos como evaluar nuestras aplicaciones APEX desde el punto de seguridad. Para esto, vamos a utilizar la herramienta APEX-SERT (Security Evaluation and Recommendation Tool for Oracle Application Express) antes conocida como eSERT y que ahora podemos utilizar completamente gratis.

 

¿Qué es APEX-SERT?

Es una aplicación APEX open source diseñada por Scott Spendolini para evaluar nuestras aplicaciones APEX en busca de vulnerabilidades de seguridad.

¿Cómo funciona?

Se instala en la instancia de APEX una vez e instantáneamente queda disponible para cualquier desarrollador utilizando sus credenciales de APEX existentes.

Versiones Soportadas:  APEX 4.2 y  APEX 5.0

 

Requerimientos:

- Una instancia de Oracle APEX.

- Acceso con la cuenta SYS de la base de datos.

- Acceso a la administración de APEX.

- Crear un tablespace (opcional).

 

Ahora si, vamos con los pasos para instalar APEX-SERT:

1.  Descargar la última versión: https://github.com/OraOpenSource/apex-sert/releases. En la guía se hará con la versión APEX-SERT 5.0 Beta 2.

2.  Descomprimir el archivo e ir a la carpeta de releases. Descomprima este archivo y tendrá una nueva carpeta llamada sert con estos directorios y archivos.

Los scripts ins.sql (instalación) y unins.sql (desinstalación) son los que vamos a necesitar.

 

3.  Una vez hecho esto, vamos a crear el tablespace para los objetos de APEX-SERT.  A continuación el ejemplo para crearlo:

4.  Desde el editor de comandos, localizar el directorio sert que habíamos descomprimido. Nos conectamos a la base de datos como sysdba y ejecutamos el script ins.sql. Las capturas de pantalla a continuación se hicieron en Windows, pero los pasos son los mismos en cualquier sistema operativo:

 

Al final de la instalación, vamos a tener dos esquemas:

SV_SERT_050000 -  Contiene todos los objetos APEX-SERT y metada.

SV_SERT_APEX - se utilizará como "Parse as schema" para las aplicaciones.

 

5. El script pedirá confirmación y va a probar el ambiente.

6. A continuación, el script nos solicitará la contraseña para el esquema y para el usuario administrador.

7. En los siguientes pasos, el script va a pedir algunos detalles, como "Parse as schema", asignación de identificación automática y, finalmente los pasos posteriores a la instalación.

8. Para que podamos utilizar APEX-SERT necesitamos hacer unos últimos pasos:

Vamos a ingresar al workspace INTERNAL y editamos el mensaje del sistema:

Copiamos el mensaje:

Finalmente tenemos el link para ejecutar APEX-SERT:

Seleccionamos el workspace y aplicación que queremos evaluar. Después del procesamiento, tendremos un informe de las vulnerabilidades que tiene la aplicación seleccionada.

 

Desintalar APEX-SERT:

Desde el editor de comandos, localizamos el directorio sert que habíamos descomprimido inicialmente, nos conectamos con el usuario SYS y ejecutamos el script unins.sql

 

NOTA: Si están usando la base de datos XE, deben comentar las siguientes lineas para poder ejecutar el script de instalación:

En la segunda parte, evaluaremos una aplicación y revisaremos sus vulnerabilidades.