Hace ya bastante tiempo que hablamos de la plataforma de movilidad de Oracle en este post.

En el post de hoy continuaremos profundizando en la plataforma, centrándonos en el  desarrollo de Bots y en aquellos puntos que creemos que son importantes a la hora de diseñar nuestro bot. Hablaremos de Tipos de Bots, plataforma, canales, lenguajes, etc.

Tipos de bot

Últimamente tienen mucho éxito los ChatBots o aquellos bots con una interfaz conversacional lo mas humana posible. Nuestro enfoque de caso práctico está más orientado hacia los ChatOps, bots donde lo que se destaca ya no es tanto la conversación en sí sino la operativa o productividad que ofrecen. Es decir, poder explotar una plataforma de un modo más productivo.

Plataforma a explotar y Canales

Y que mejor plataforma destino para interactuar con un ChatOps que Jira y Confluence, herramientas de uso prácticamente diario en los equipos de desarrollo.

El objetivo es poder usar estas plataformas de una forma mas ágil y cómoda a través una aplicación de mensajería como podría ser Facebook Messenger, Slack, Microsoft Teams, Atlassian Stride, etc.

Destacar que no se trata de sustituir la interfaz tradicional o de gestionar nuestro proyecto vía una App de Mensajería, sino de habilitar una canal añadido que nos permita realizar una serie de operaciones de forma productiva sobre un canal que usamos a diario. En nuestro caso de ejemplo, nos hemos decantado por Slack como canal.

Actualmente desde la plataforma de Oracle, podremos desplegar nuestro bot prácticamente en cualquier canal, ya sea de forma nativa o vía WebHook.

Si hacemos uso de una integración via WebHook, los mensajes planos tipo texto no dan problemas. Necesitamos simplemente crear un integrador intermedio que orqueste los mensajes entre la plataforma de bots de Oracle y nuestro canal. Pero hay que tener en cuenta que si queremos hacer uso de algún tipo de componente como un carousel o un menú con enlaces, deberemos realizar una conversión entre lo que nos llega de la plataforma Oracle y el formato que necesita la plataforma final. Es decir, una conversión de formato entre componentes finales de cada una de las plataformas.

Aquí es muy importante que nuestra lógica de negocio este totalmente desacoplada del módulo que realiza las conversiones de formato entre canales, de modo que nuestro bot pueda evolucionar independientemente de la plataforma de despliegue.

A continuacion podemos ver una muestra de una posible arquitectura a alto nivel. En concreto, la que hemos usado internamente para nuestro ChatOps:

Como se puede observar, la plataforma de Oracle es totalmente flexible y nos permite hacer uso de todos los servicios de bots: diseño conversacional, intents, entities, su motor de aprendizaje, etc. Pero tener nuestra lógica de negocio fuera o dentro de la propia plataforma de movilidad. En este caso, a modo de ejemplo, hemos optado por un entorno basado en Node.js y express, donde reside toda la lógica de negocio de nuestro bot. Finalmente hemos optado por dockerizar la solución de modo que podemos hacer uso del ejemplo de una forma ágil y segura.

Para finalizar este apartado, os muestro con una captura uno de los casos de uso, la búsqueda en Confluence, a través de Slack:

Lo mejor de hacer uso de una plataforma como podría ser Slack, es que tendremos nuestro bot listo para ser usado prácticamente desde cualquier dispositivo, ya sea un ordenador convencional o un teléfono móvil.

Casos de Uso

Una vez tenemos elegido el tipo de bot y la plataforma debemos pensar en los casos de uso que queremos cubrir. Es importante que sean claros y sencillos.

Nosotros hemos realizado los siguientes:

• Crear Incidencias.
• Buscar Incidencias y dar la información relevante (asignación, tiempo invertido, estado, prioridad, etc.).
• Buscar asignaciones/carga actual de una persona.
• Añadir comentarios en una incidencia.
• Ver las issues del ultimo sprint activo (Desarrollo Ágil).

En el apartado de Confluence:

• Buscar páginas según texto.
• Buscar páginas según etiquetas de la página.
• Crear páginas.

Lógicamente estos son solo algunos de los ejemplos que creemos que pueden ser de utilidad, pero es cuestión de analizar el modelo y caso de uso concreto para desarrollar un bot que cubra las necesidades del equipo o personas que harían uso del bot.

Movilidad o Productividad.

Aunque generalmente solemos relacionar el uso de los bots con casos donde los usuarios finales requieren de movilidad (por ejemplo, realizar alguna acción sobre Jira cuando estamos de camino o fuera de la oficina), no hay que olvidar la mejora de productividad. Como ejemplo aquí tenemos una muestra de tiempos de apertura de una incidencia vía convencional (Navegador Web) o vía el ChatOps:

• Abrir Incidencia uso Convencional: 00:35:92
• Abrir Incidencia uso Bot       :  00:12:76

De modo que quizá sin necesidades de movilidad, puedo preferir el uso de un bot. Y si pensamos en el uso de Confluence, seguramente el éxito será dar respuesta a la problemática del usuario y no tener ni siquiera que salir de su canal de mensajería.

Bots+ Instant Apss

Por último y para finalizar este post sobre bots, hablaremos de una opción que brinda la plataforma de Oracle, las Instants Apps. Es una forma de crear una mini aplicación que se ejecuta dentro del bot y que puede dar solución a aquellos casos de uso, donde quizá las herramientas que tenemos en las plataformas de mensajería actuales no son suficientes.

Es una buena solución para aquellos casos mas complejos, donde quizá necesitamos algún componente tipo combo, alguna validación, trabajar con documentos, etc.

El objetivo era comentar algunas de las características de la plataforma Oracle de movilidad y bots y plantear aquellos aspectos, mas comunes y transversales, que consideramos importantes a la hora de afrontar un proyecto de este tipo.

Lo importante es que la plataforma a explotar tenga una API REST o de integración, moderna y sencilla. Del mismo modo que hemos escogido Atlassian, podríamos haber escogido cualquier plataforma con el objetivo de obtener productividad. Otro ejemplo muy interesante en el que hemos trabajado internamente es Jenkins. Consiguiendo una nueva forma de poder lanzar nuestros trabajos de construcción, pruebas e integración de una forma más productiva.

Si te ha gustado, ¡síguenos en Twitter!