ITIL práctico, El Catálogo de Servicios (parte 6)

Parte 6, Monitorización de las Peticiones de Servicio (BonitaLife + WSO2BAM + Pentaho Suite)

En esta entrada veremos como monitorizar las Peticiones de Servicio, en concreto el tiempo de ejecución de las tareas asociadas y, por supuesto, el tiempo de ejecución global del proceso. Dentro de un ciclo PDCA esta fase correspondería con la fase de ‘Check’ donde analizamos la información de nuestros procesos para verificar que se cumplen los parámetros establecidos y asignamos planes de corrección para las desviaciones detectadas. La arquitectura propuesta es la siguiente:

BonitaBPM-Analytics-Store-Analyze

  1. STORE: Mediante los conectores de BonitaLife para WSO2BAM la información referente al tiempo de ejecución de las tareas y procesos serán enviados a los agentes del BAM para su almacenamiento.
  2. ANALYZE: Mediante Hive (analytics batch layer) se agregará la información almacenada de los tiempos de ejecución y se exportará a un datawarehouse (en nuestro caso una BD MySQL) para su explotación. Estos scripts se planificarán para su ejecución periódica. En este punto sería recomendable usar un motor optimizado para el trabajo con modelos estrella como, por ejemplo, InfiniDB/MySQL.
  3. VISUALIZE/EXPLORE: Mediante WSO2 Gadget Server y Pentaho Suite se explotará la información almacenada en el DW.
    • Ad-Hoc Informes (Pentaho)
    • OLAP Analysis (Pentaho)
    • Dashboards (WSO2 Gadget Server, Community Dashboard Framework)
    • Predictive Models (Weka)

Conectores BonitaLife para WSO2BAM

Mediante los conectores de BonitaLife podemos enviar la información del tiempo de ejecución de las tareas y procesos a los agentes de WSO2 BAM.

itil_p67

Actualmente disponemos de dos conectores:

  • blife-wso2bam-process-time, para el tiempo de ejecución de los procesos. Este conector se asocia al evento FINISH del proceso.
  • blife-wso2bam-activity-time, para el tiempo de ejecución de las actividades. Este conector se asocia al evento FINISH de la tarea.

itil_p61

itil_p64

En ambos casos los parámetros de configuración son:

itil_p63

donde

  • Dirección BAM, dirección donde se encuentra el agente de WSO2 BAM
  • Usuario, usuario para la conexión
  • Password, password para la conexión
  • Nombre del Stream, identificador del stream donde queremos que se almacenen los eventos
  • Versión del Stream, versión del stream a publicar.

A medida que los procesos se van ejecutando, la información sobre tiempos de ejecución es enviada a WSO2BAM para su almacenamiento.

itil_p68

itil_p69

itil_p610

itil_p611

itil_p612

Scripts de Análisis HIVE 

Una vez almacenados los eventos relativos al tiempo de ejecución de los procesos la siguiente tarea es preparar los scripts de análisis con el objetivo de agregar la información para su posterior explotación. Estos scripts se planificarán para su ejecución periódica. En nuestro caso, el resultado será la información agregada por día de los tiempos de ejecución y su exportación a una base de datos mysql. Como podremos observar, la estructura de tablas destino será un modelo de estrella que servirá como fuente de análisis para la suite de Pentaho.

itil_p613
dimProcessDefinition

DROP TABLE IF EXISTS blife_wso2bam_process_time;
CREATE EXTERNAL TABLE IF NOT EXISTS blife_wso2bam_process_time (key STRING, version STRING, processDefinitionId BIGINT, processDefinitionName STRING)
STORED BY 'org.apache.hadoop.hive.cassandra.CassandraStorageHandler' 
WITH SERDEPROPERTIES ( 
"cassandra.host" = "127.0.0.1", 
"cassandra.port" = "9160",
"cassandra.ks.name" = "EVENT_KS", 
"cassandra.ks.username" = "admin",
"cassandra.ks.password" = "admin", 
"cassandra.cf.name" = "blife_wso2bam_process_time2",
"cassandra.cf.validatorType" = "UTF8Type,UTF8Type,LongType,UTF8Type",
"cassandra.columns.mapping" = ":key, Version, payload_processDefinitionId, payload_processDefinitionName" ); 

CREATE EXTERNAL TABLE IF NOT EXISTS dimProcessDefinition
                         ( processDefinitionId BIGINT, processDefinitionName STRING )
STORED BY 'org.wso2.carbon.hadoop.hive.jdbc.storage.JDBCStorageHandler'
TBLPROPERTIES ( 
'mapred.jdbc.driver.class' = 'com.mysql.jdbc.Driver' ,
'mapred.jdbc.url' = 'jdbc:mysql://localhost/bpmdw' ,
'mapred.jdbc.username' = 'bpmdw' ,
'mapred.jdbc.password' = 'bpmdw' ,
'hive.jdbc.update.on.duplicate' = 'true' ,
'hive.jdbc.primary.key.fields' = 'processDefinitionId' ,
'hive.jdbc.table.create.query' = 'CREATE TABLE dimProcessDefinition 
                                (processDefinitionId BIGINT, processDefinitionName STRING, PRIMARY KEY (processDefinitionId)) ');

insert overwrite table dimProcessDefinition
select distinct cast(processdefinitionid as BIGINT) as ProcessDefinitionId, cast(upper(processDefinitionName) as STRING)
from blife_wso2bam_process_time
where version='1.0.0';

dimActivityDefinition

DROP TABLE IF EXISTS blife_wso2bam_activity_time;
CREATE EXTERNAL TABLE IF NOT EXISTS blife_wso2bam_activity_time (key STRING, version STRING, activityDefinitionId BIGINT, activityDefinitionName STRING)
STORED BY 'org.apache.hadoop.hive.cassandra.CassandraStorageHandler' 
WITH SERDEPROPERTIES ( 
"cassandra.host" = "127.0.0.1", 
"cassandra.port" = "9160",
"cassandra.ks.name" = "EVENT_KS", 
"cassandra.ks.username" = "admin",
"cassandra.ks.password" = "admin", 
"cassandra.cf.name" = "blife_wso2bam_activity_time2",
"cassandra.cf.validatorType" = "UTF8Type,UTF8Type,LongType,UTF8Type",
"cassandra.columns.mapping" = ":key, Version, payload_activityDefinitionId, payload_activityDefinitionName" ); 

CREATE EXTERNAL TABLE IF NOT EXISTS dimActivityDefinition
                         ( activityDefinitionId BIGINT, activityDefinitionName STRING )
STORED BY 'org.wso2.carbon.hadoop.hive.jdbc.storage.JDBCStorageHandler'
TBLPROPERTIES ( 
'mapred.jdbc.driver.class' = 'com.mysql.jdbc.Driver' ,
'mapred.jdbc.url' = 'jdbc:mysql://localhost/bpmdw' ,
'mapred.jdbc.username' = 'bpmdw' ,
'mapred.jdbc.password' = 'bpmdw' ,
'hive.jdbc.update.on.duplicate' = 'true' ,
'hive.jdbc.primary.key.fields' = 'activityDefinitionId' ,
'hive.jdbc.table.create.query' = 'CREATE TABLE dimActivityDefinition 
                                (activityDefinitionId BIGINT, activityDefinitionName STRING, PRIMARY KEY (activityDefinitionId)) ');

insert overwrite table dimActivityDefinition
select distinct cast(activitydefinitionid as BIGINT) as ActivityDefinitionId, cast(upper(activityDefinitionName) as STRING)
from blife_wso2bam_activity_time
where version='1.0.0';

dimUserDefinition

DROP TABLE IF EXISTS blife_wso2bam_activity_time;
CREATE EXTERNAL TABLE IF NOT EXISTS blife_wso2bam_activity_time (key STRING, version STRING, userId BIGINT, userName STRING)
STORED BY 'org.apache.hadoop.hive.cassandra.CassandraStorageHandler' 
WITH SERDEPROPERTIES ( 
"cassandra.host" = "127.0.0.1", 
"cassandra.port" = "9160",
"cassandra.ks.name" = "EVENT_KS", 
"cassandra.ks.username" = "admin",
"cassandra.ks.password" = "admin", 
"cassandra.cf.name" = "blife_wso2bam_activity_time2",
"cassandra.cf.validatorType" = "UTF8Type,UTF8Type,LongType,UTF8Type",
"cassandra.columns.mapping" = ":key, Version, payload_userId, payload_userName" ); 

CREATE EXTERNAL TABLE IF NOT EXISTS dimUserDefinition
                         ( userDefinitionId BIGINT, userDefinitionName STRING )
STORED BY 'org.wso2.carbon.hadoop.hive.jdbc.storage.JDBCStorageHandler'
TBLPROPERTIES ( 
'mapred.jdbc.driver.class' = 'com.mysql.jdbc.Driver' ,
'mapred.jdbc.url' = 'jdbc:mysql://localhost/bpmdw' ,
'mapred.jdbc.username' = 'bpmdw' ,
'mapred.jdbc.password' = 'bpmdw' ,
'hive.jdbc.update.on.duplicate' = 'true' ,
'hive.jdbc.primary.key.fields' = 'userDefinitionId' ,
'hive.jdbc.table.create.query' = 'CREATE TABLE dimUserDefinition 
                                (userDefinitionId BIGINT, userDefinitionName STRING, PRIMARY KEY (userDefinitionId)) ');

insert overwrite table dimUserDefinition
select distinct cast(userid as BIGINT) as UserDefinitionId, cast(upper(userName) as STRING)
from blife_wso2bam_activity_time
where version='1.0.0';

cubeProcessExecutionTime

DROP TABLE IF EXISTS ProcessExecutionSecs;
CREATE EXTERNAL TABLE IF NOT EXISTS ProcessExecutionSecs (key STRING, version STRING, unixtime BIGINT, processDefinitionId BIGINT, processDefinitionName STRING, segundos BIGINT)
STORED BY 'org.apache.hadoop.hive.cassandra.CassandraStorageHandler' 
WITH SERDEPROPERTIES ( 
"cassandra.host" = "127.0.0.1", 
"cassandra.port" = "9160",
"cassandra.ks.name" = "EVENT_KS", 
"cassandra.ks.username" = "admin",
"cassandra.ks.password" = "admin", 
"cassandra.cf.name" = "blife_wso2bam_process_time2",
"cassandra.cf.validatorType" = "UTF8Type,UTF8Type,LongType,LongType,UTF8Type,LongType",
"cassandra.columns.mapping" = ":key, Version, Timestamp, payload_processDefinitionId, payload_processDefinitionName, payload_segundos" ); 

CREATE EXTERNAL TABLE IF NOT EXISTS cubeProcessExecution
                         ( dimDate STRING, processDefinitionId BIGINT, count_process BIGINT, sum_secs BIGINT)
STORED BY 'org.wso2.carbon.hadoop.hive.jdbc.storage.JDBCStorageHandler'
TBLPROPERTIES ( 
'mapred.jdbc.driver.class' = 'com.mysql.jdbc.Driver' ,
'mapred.jdbc.url' = 'jdbc:mysql://localhost/bpmdw' ,
'mapred.jdbc.username' = 'bpmdw' ,
'mapred.jdbc.password' = 'bpmdw' ,
'hive.jdbc.update.on.duplicate' = 'true' ,
'hive.jdbc.primary.key.fields' = 'dimDate,processDefinitionId' ,
'hive.jdbc.table.create.query' = 'CREATE TABLE cubeProcessExecution 
                                (dimDate DATETIME, processDefinitionId BIGINT, count_process BIGINT, sum_secs BIGINT, PRIMARY KEY (dimDate, processDefinitionId)) ');

insert overwrite table cubeProcessExecution
select from_unixtime(cast(unixtime/1000 as BIGINT), 'yyyy-MM-dd') as dimDate, cast(processdefinitionid as BIGINT) as ProcessDefinitionId, count(*) as count_process, sum(segundos) as sum_secs
from ProcessExecutionSecs
where version='1.0.0'
group by from_unixtime(cast(unixtime/1000 as BIGINT), 'yyyy-MM-dd'), cast(processdefinitionid as BIGINT);

cubeActivityExecutionTime

DROP TABLE IF EXISTS ActivityExecutionSecs;
CREATE EXTERNAL TABLE IF NOT EXISTS ActivityExecutionSecs (key STRING, version STRING, unixtime BIGINT, processDefinitionId BIGINT, activityDefinitionId BIGINT, activityDefinitionName STRING, userId BIGINT, segundos BIGINT)
STORED BY 'org.apache.hadoop.hive.cassandra.CassandraStorageHandler' 
WITH SERDEPROPERTIES ( 
"cassandra.host" = "127.0.0.1", 
"cassandra.port" = "9160",
"cassandra.ks.name" = "EVENT_KS", 
"cassandra.ks.username" = "admin",
"cassandra.ks.password" = "admin", 
"cassandra.cf.name" = "blife_wso2bam_activity_time2",
"cassandra.cf.validatorType" = "UTF8Type,UTF8Type,LongType,LongType,LongType,UTF8Type,LongType,LongType",
"cassandra.columns.mapping" = ":key, Version, Timestamp, payload_processDefinitionId, payload_activityDefinitionId, payload_activityDefinitionName, payload_userId, payload_segundos" ); 

CREATE EXTERNAL TABLE IF NOT EXISTS cubeActivityExecution
                         ( dimDate STRING, processDefinitionId BIGINT, activityDefinitionId BIGINT, userId BIGINT, count_activity BIGINT, sum_secs BIGINT)
STORED BY 'org.wso2.carbon.hadoop.hive.jdbc.storage.JDBCStorageHandler'
TBLPROPERTIES ( 
'mapred.jdbc.driver.class' = 'com.mysql.jdbc.Driver' ,
'mapred.jdbc.url' = 'jdbc:mysql://localhost/bpmdw' ,
'mapred.jdbc.username' = 'bpmdw' ,
'mapred.jdbc.password' = 'bpmdw' ,
'hive.jdbc.update.on.duplicate' = 'true' ,
'hive.jdbc.primary.key.fields' = 'dimDate,processDefinitionId,activityDefinitionId,userId' ,
'hive.jdbc.table.create.query' = 'CREATE TABLE cubeActivityExecution 
                                (dimDate DATETIME, processDefinitionId BIGINT, activityDefinitionId BIGINT, userId BIGINT, count_activity BIGINT, sum_secs BIGINT, PRIMARY KEY (dimDate, processDefinitionId, activityDefinitionId, userId)) ');

insert overwrite table cubeActivityExecution
select from_unixtime(cast(unixtime/1000 as BIGINT), 'yyyy-MM-dd') as dimDate, cast(processdefinitionid as BIGINT) as ProcessDefinitionId, cast(activitydefinitionid as BIGINT) as ActivityDefinitionId, cast(userid as BIGINT) as UserId, count(*) as count_activity, sum(segundos) as sum_secs
from ActivityExecutionSecs
where version='1.0.0'
group by from_unixtime(cast(unixtime/1000 as BIGINT), 'yyyy-MM-dd'), cast(processdefinitionid as BIGINT), cast(activitydefinitionid as BIGINT),cast(userid as BIGINT);

Exportación de la información agregada

Como podemos observar en las tareas de análisis HIVE, la información generada es exportada a una base de datos MySQL que actúa como intermediario entre las herramientas de visualización/explotación.
itil_p619

itil_p620

itil_p621

Visualización de la información agregada

Una vez tenemos la información agregada la podemos explotar con WSO2 Gadget Server, que viene incluido en la distribución del BAM. Crearemos dos gadgets, uno para el tiempo medio de ejecución de los procesos y otro para el tiempo medio de ejecución de las tareas. El resultado final será el siguiente;

itil_p622

Para la creación de los gadgets utilizaremos la herramienta “Gadget Gen Tool”.

itil_p623

itil_p624

itil_p625

itil_p626

itil_p628itil_p629

 

En la siguiente entrada veremos como explotar esta misma información desde la suite de Pentaho. Esta suite nos provee de un toolset de herramientas de Inteligencia de Negocio que nos permite profundizar en nuestros análisis. Entre las herramientas incluidas nos encontramos: Pentaho Report Designer, OLAP (Mondrian), Dashboards (CDF).

 


ITIL práctico, El Catálogo de Servicios (parte 4)

Parte 4, Creación de los Procesos de Negocio en Bonita BPM

El siguiente paso será crear los procesos de Negocio, según la especificación definida en su ficha, en la herramienta Bonita BPM. En este caso nos centraremos en la Petición de Servicio “Solicitud bloqueo de horario”.

WSO2DSS, Data Services Server

Con el fin de abstraer el acceso a los Sistemas de Información desde la capa de Negocio, cualquier servicio (set/get) necesario sobre ellos se creará dentro de WSO2DSS, siendo así accesible desde la capa de negocio mediante Servicios SOAP.

Modelo de Datos

Para el ejemplo supondremos que disponemos del siguiente modelo de datos:

  • Base de Datos MySQL “clinica”.
    • Tabla “clinica.dentistas”, con la lista de dentistas.
    • Tabla “clinica.bloqueos”, con los bloqueos por fecha/dentista.
    • Tabla “clinica.citas”, con las citas de los clientes por fecha/dentista/hora.

Los pasos a seguir serían los siguientes:

  1. Creación de los Servicios en WSO2 Data Service Server.
  2. Creación del proceso con Bonita Studio.
  3. Construcción del fichero de carga del proceso.
  4. Carga del proceso en el motor Bonita Engine.

1. Creación de los Servicios en WSO2 Data Service Server.

Dado el carácter práctico de este grupo de entradas no entraremos en el detalle de como configurar un Servicio dentro de WSO2DSS.

WSO2DSS-Servicios

  • DentistasDS: Servicio de Datos que engloba las operaciones referentes a los Dentistas dentro del Sistema de Información.
    • getDentistas: Acceso a la lista de Dentistas configurado en el Sistema.

WSO2DSS-DentistasDS

DentistasDS-SQL

DentistasDS-Operations

  • BloqueosDS: Servicio de Datos que engloba las operaciones referentes a los Bloqueos de fechas dentro del Sistema de Información.
    • addBloqueo: Nuevo bloqueo para la fecha/dentista seleccionado.

WSO2DSS-BloqueosDS

BloqueoDS-SQL

BloqueoDS-Operatiions

  • CitasDS: Servicio de Datos que engloba las operaciones referentes a las Citas de los clientes.
    • getCitasByDentista: Lectura de las citas de un dentista dado.

WSO2DSS-CitasDS

CitasDS-SQL

CitasDS-Operaciones

2. Creación del Proceso en Bonita Studio

El diagrama BPMN2.0 de la Petición de Servicio “Solicitud bloqueo de horario” sería el siguiente:

Solicitud Bloqueo Horario-1.0

  • Variables del Proceso
    • fecha (del bloqueo)
    • id_dentista (dentista que requiere el bloqueo)
    • motivo (del bloqueo)
    • lista_dentistas (listado de los dentistas)
    • lista_cambios (listado de citas ese día para ese dentista, en caso de existir)

BonitaBPM-VariablesDelProceso

  • Tareas
    • RRHH / Datos del Bloqueo:
      • Tipo: Tarea de usuario con el formulario con los datos referentes al bloqueo.
      • Formularios: Formulario para solicitar la fecha, el dentista (de la lista que se obtendrá del conector de entrada) y el motivo.
      • Conectores: A la entrada de la tarea hemos enlazado un conector al WSO2DSS/DentistasDS/getDentistas para leer la lista de dentistas y mostrarla en una lista de selección dentro del formulario.
    • TI / Bloqueo Consulta:
      • Tipo: Tarea automática que registra el bloqueo en el Sistema de Información (Servicio SOAP WSO2DSS).
      • Conectores: A la salida de la tarea hemos enlazado un conector al WSO2DSS/BloqueosDS/addBloqueo para registrar el bloqueo en el Sistema de Información. Se le facilita al servicio la fecha del bloqueo y el código de dentista seleccionado en el paso anterior.
    • TI / Leer Citas:
      • Tipo: Tarea automática que obtiene las citas ya asignadas para el dentista seleccionado en la fecha del bloqueo (Servicio SOAP WSO2DSS).
      • Conectores: A la salida de la tarea hemos enlazado un conector al WSO2DSS/CitasDS/getCitasByDentista para obtener el listado de citas para el dentista facilitado en la fecha del bloqueo. Se le facilita al servicio la fecha del bloqueo y el código de dentista seleccionado en pasos anteriores.
    • Gestión Consulta / Cambio Consulta:
      • Tipo: Tarea de usuario que indica que existen citas dentro de una fecha bloqueada que deben ser cambiadas. Este paso solo se ejecuta en caso de existir citas en la fecha de bloqueo para el dentista seleccionado.
      • Formularios: Listado de los clientes citados en la fecha del bloqueo para el dentista seleccionado.

BonitaBPM-getDentistas

BonitaBPM-addBloqueo

 

3.  Construcción del fichero de carga del proceso.

Para compilar y crear el ejecutable (.bar) del proceso procedemos con la opción de Bonita Studio:

Servidor > Compilar …

compilar

Simplemente debemos seleccionar el proceso que queremos compilar y la ruta destino del fichero.

4. Carga del proceso en el motor Bonita Engine.

El último paso será cargar el fichero compilado en el paso 3 dentro del motor de procesos de Bonita BPM.

  • Conectar al portal de Bonita BPM con usuario con credenciales de Administrador

credencial-administrador

  • Seleccionar la opción Gestión de aplicaciones > Aplicaciones

gestion-aplicaciones

  • + Instalar Apps, seleccionar fichero compilado en Bonita Studio

instalar-apps

  • Configurar aplicación

config-apps


ITIL práctico, El Catálogo de Servicios (parte 3)

Parte 3, Creación del Catálogo de Servicios IT

En la parte 1 de este grupo de entradas vimos como identificar nuestros Servicios IT y como documentarlos mediante Fichas de Servicio.

En esta entrada vamos a ver como crear la vista técnica de nuestro catálogo y, de qué forma podemos hacer accesible esta información a los integrantes del departamento IT mediante Liferay Portal.

Creación de la Organización “IT Department”

Crearemos una nueva organización, en caso de no existir, para el Departamento de IT.

parte3-1

Subir las Fichas de Servicio y documentos de Acuerdo de Nivel de Servicio (SLA)

En la zona de “Documents and Media” de la organización creada subiremos las Fichas de Servicio y los documentos de Nivel de Servicio. Para una mejor clasificación crearemos la siguiente estructura de directorios:

  • Servicios_IT
    • Fichas
    • SLA

parte3-2

parte3-3

parte3-4

parte3-5

Creación de un “Site Template” para la parte privada de la organización “IT Department”

Dadas las características de la vista técnica del catálogo su sitio natural será la parte privada de la organización IT. Para ello, crearemos un nuevo “Site Template” encargado de gestionar la parte privada de nuestra organización.

parte3-6

Creación de un “Web Content” con la documentación de nuestros Servicios IT

Una vez disponibles los documentos y creada la plantilla de la parte privada, nos dispondremos a crear una nueva página con contenido Web que enlazará con dichos documentos.

parte3-7

parte3-8

Por último, antes de concluir esta entrada, comentar que existen diferentes formas de enlazar con las Fichas de Servicio IT. Otra opción sería crear una estructura de datos en Liferay con la información contenida dentro de la Ficha de Servicio y crear, asociada a esta estructura, una plantilla para solicitar y formatear su contenido. De esta forma cada Ficha de Servicio sería un contenido Web formateado desde la estructura de datos asociada.


ITIL práctico, El Catálogo de Servicios (parte 5)

Parte 5, Creación de un “auto-servicio” para las Peticiones con BonitaLife

En la anterior entrada vimos como crear el proceso de negocio asociado a nuestras Peticiones de Servicio y como desplegarlas en nuestro motor de procesos, Bonita BPM.

En esta entrada veremos como consumir estos procesos de negocio desde Liferay Portal haciendo uso de BonitaLife. Utilizaremos la Petición de Servicio “Solicitud Bloqueo Horario” como ejemplo.

BonitaLife

BonitaLife es un proyecto que nos brinda la posibilidad de consumir procesos desplegados dentro de Bonita BPM desde el portal Liferay. Consta de 3 portlets:

  • Process Launcher: Portlet que nos permite abrir (instanciar) procesos.
  • Users Tasks: Portlet que nos permite interactuar con las tareas asignadas al usuario autentificado en Liferay.
  • Available Cases: Portlet que nos permite ver los procesos que hemos solicitado y su estado actual.

1. Instalación y configuración de BonitaLife

Podemos encontrar información sobre la instalación y configuración en la página web del proyecto, www.bonitalife.org

2. BonitaLife Process Launcher

Para crear el auto-servicio utilizaremos el portlet Process Launcher. Este portlet nos muestra, agrupados por categoría, los procesos disponibles para ser consumidos por el usuario.

blog5-1-2

Información del Proceso

blog5-3

3. BonitaLife Available Cases

Para ver los procesos que hemos solicitado y su estado utilizaremos el portlet Available Cases.

blog5-4-2

3. BonitaLife User Tasks

Para ver las tareas que tenemos asignadas utilizaremos el portlet User Cases. Mediante este portlet podemos gestionar directamente las tareas sin necesidad de entrar en el portal de Bonita y, como nueva funcionalidad, ver de una forma gráfica el camino que ha seguido dicha tarea.

blog5-4-3

blog5-5

blog5-6blog5-7

blog5-8-2

Como hemos podido ver en esta entrada, gracias a BonitaLife podemos gestionar el ciclo completo de un caso sin necesidad de entrar al portal de Bonita BPM actuando, de esta forma, como núcleo de integración entre el portal y nuestro motor de procesos.

De esta forma conseguimos crear nuestro auto-servicio y hacerlo accesible desde el Portal Liferay. Cada ver que despleguemos un nuevo proceso en nuestro motor de Bonita este estará disponible en el Portal de manera automática (siempre que el usuario tenga autorización para lanzar el proceso). A su vez, los usuarios implicados en el proceso podrán ver los casos que tienen abiertos y gestionar sus tareas directamente desde el Portal, así como insertar comentarios y ver el estado de los mismos .

 


Aplicando Inteligencia Operacional (OI) sobre un proceso de mantenimiento preventivo

Uno de los temas más interesantes sobre los que actualmente estoy trabajando es conocido como “Inteligencia Operacional” (Operational Intelligence), categoría del Business Analytics encargada de responder ante los eventos que se producen en el negocio en tiempo real, de manera dinámica.

En una de mis últimas colaboraciones con mi buen amigo Roger Carhuatocto (@chilcano, Chakray) nos planteamos la opción de responder a los sensores de una planta industrial mediante Procesos de Negocio. Esta entrada es la Prueba de Concepto (Proof Of Concept) resultado de nuestra investigación.

La POC tendrá como objetivo el mostrar, desde un punto de vista práctico, como podemos aplicar Inteligencia Operacional sobre un proceso de mantenimiento preventivo en una planta industrial. Para ello, seguiremos la arquitectura de referencia expuesta en mis dos anteriores entradas:

  • Integración SCADA/OPC UA con WSO2 CEP y WSO2 BAM y
  • Integración WSO2 CEP con Bonita BPM mediante BonitaLife

Proceso de Manufactura, cinta transportadora

Como base para la demostración y con el objetivo de mostrar las posibilidades que ofrece de la arquitectura, supongamos que disponemos de una cinta transportadora capaz de enviar los datos de los productos procesados a un servidor OPC UA (Unified Architecture). Según el fabricante, cada 10000 productos procesados por cinta esta debe tener un mantenimiento preventivo, encargado de la sustitución y engrase de diversas piezas.

Teniendo en cuenta la arquitectura de referencia, la solución tendría el siguiente esquema:

CEP-Architecture-Demostracion

  1. El sensor enviaría los datos (productos procesados) al Servidos OPC-UA.
  2. El listener-opc captura estos cambios y envía el evento al WSO2 CEP mediante un stream personalizado.
  3. El stream dentro del WSO2 CEP se filtra en función de los planes de ejecución, creando una alerta al detectar un valor superior a 10000 (en este caso, 10000 productos procesados).
  4. Gracias al conector BonitaOutputEventAdaptor, WSO2 CEP crea una nueva instancia del proceso de negocio (bpm) “preventive maintenance process”, pasando los datos del sensor y el valor origen de la alerta.
  5. A partir de este punto, la gestión del proceso de mantenimiento se gobierna desde el motor de procesos Bonita BPM. Los usuarios podrán interactuar con el proceso mediante el portal propio de Bonita BPM Portal o con la solución Liferay Portal + BonitaLife 2.0.

Configuración del listener-opc

La función principal del listener-opc es monitorizar los endpoint’s del Servidor OPC-UA y notificar de los cambios al CEP de WSO2. Para ello, el primer paso será configurar los endpoint’s que queremos monitorizar mediante el fichero de texto sensors.ini. Este fichero de texto contiene una línea por cada endpoint que queremos monitorizar. Un ejemplo del fichero sería:

Objects/1:Devices/1:[simul-extractor]/1:_Meta:Writeable/1:WriteableInteger5
Objects/1:Devices/1:[simul-temperatura]/1:_Meta:Writeable/1:WriteableInteger5
Objects/1:Devices/1:[simul-cinta1-counter]/1:_Meta:Writeable/1:WriteableInteger1

Según el ejemplo, cada cambio que se produzca en el registro “1:_Meta:Writeable/1:WriteableInteger1” del sensor “Objects/1:Devices/1:[simul-cinta1-counter]” sería notificado al WSO2CEp en tiempo real, es decir, justo en el momento que se produzca el cambio.

Creación del Proceso de Negocio “Mantenimiento Preventivo”

La respuesta al evento de 10000 productos procesados será un BPM que se gestionará desde el motor de procesos de Bonita BPM. Para ello, crearemos el proceso de negocio desde Bonita Studio y posteriormente los desplegaremos en el Servidor de Procesos.

Proceso “Mantenimiento Preventivo”

Demo-Mantenimiento-Preventivo-2-0

 

Variables del Proceso, que serán inyectadas por el conector BonitaOutputEventAdaptor desde el CEP:

  • meta_opc_node_id: Endpoint que ha generado la instancia del proceso. En nuestro ejemplo tomará el valor de Objects/1:Devices/1:[simul-cinta1-counter]/1:_Meta:Writeable/1:WriteableInteger1
  • opc_node_value: Valor del endpoint en el momento de generar el evento de respuesta. En nuestro caso tomará el valor de 10000.
  • opc_tipo_mantenim: Tipo de mantenimiento que se debe realizar. En nuestro caso tomará el valor de “CINTA01_10000”.  La descripción de este tipo de mantenimiento estará almacenado en el Sistema de Información de Mantenimiento, donde indicaremos los pasos a seguir por el operario para realizarlo y las piezas que se necesitarán.

Pasos del Proceso:

  1. “Leer EAM”. Tarea automática (no requiere de la intervención humana) encargada de leer del Sistema de Información de Mantenimiento las tareas y piezas requeridas para realizar el tipo de mantenimiento asignado. La lectura la realizaremos mediante WSO2 Data Services Server, donde expondremos el acceso a los datos de la Base de Datos mediante Servicios Web SOAP. Podemos ver un ejemplo de este proceso en el blog personal de Jack A. Rider, http://itscenario.wordpress.com/2013/11/10/integracion-mysql-wso2-dss-bonita-bpm-bonitalife-liferay/
  2. “disponibles?”. Puerta donde se validará la existencia de stock necesario de las piezas requeridas por el tipo de mantenimiento.
  3. “Solicitud de Compra”. Sub-Proceso encargado de gestionar el pedido de las piezas requeridas para el mantenimiento, en caso de no haber stock.
  4. “Orden de Trabajo”. En caso de existir stock o de haber recibido el pedido de compra, el siguiente paso será la propia orden de trabajo asignada al equipo de mantenimiento. Esta tarea será accesible y gestionada desde el Protal por los usuarios asignados al equipo (grupo) de mantenimiento. El procedimiento a seguir será “assing to me” and “do”.
  5. “Registro EAM”. Tarea automática  encargada de registrar el mantenimiento realizado dentro del Sistema de Información de Mantenimiento.
  6. “Cerrar Orden”. Una vez finalizado y registrado el mantenimiento, el responsable del departamento cerrará la orden y verificará su correcto cumplimiento.

Creación del Plan de Ejecución en WSO2 CEP

Dentro de WSO2CEP, el Plan de Ejecución es el encargado de aplicar las reglas de ejecución sobre los streams de entrada y arrancar los conectores de salida en caso de su cumplimiento. Para nuestro ejemplo crearemos un plan de ejecución sobre el stream enviado desde el listener-opc. Esta regla verificará si el valor es superior a 10000, ejecutando en caso afirmativo el conector BonitaOutputEventAdaptor.

blog-scada-event-formatter

 

 

blog-cep-execution-plan

 

blog-scada-event-formatter-config2

donde:

  • Output Event Adaptor Name: Conector de salida, BonitaOutputEventAdaptor
  • Text Mapping: Variables que queremos pasar al proceso, formato XML Asignadas a las variables globales del proceso una vez arrancado.
    • meta_opc_node_id, asignado al valor {meta_opc_node_id} del stream de entrada.
    • opc_node_value: asignado al valor {opc_node_value} del stream de entrada.
    • opc_tipo_mantenim: en nuestro caso asignamos la cadena CINTA01_1000 que, como hemos indicado posteriormente, se obtendrá del Sistema de Información de Mantenimiento.
  • Bonita Process UUID: Identificador del proceso que deseamos instanciar (valor que otorga el motor Bonita BPM para cada proceso desplegado).

Una vez configurado el Plan de Ejecución, el sensor Objects/1:Devices/1:[simul-cinta1-counter]/1:_Meta:Writeable/1:WriteableInteger1 se monitorizará en tiempo real, respondiendo con el proceso “Mantenimiento Preventivo” justo en el momento se detecte el valor 10000.

Aquí os dejo un vídeo con la solución en funcionamiento. Como Servidor SCADA utilizaremos un versión de demostración de Ignition HMI/SCADA. Como servidor OPC utilizaremos el propio que viene integrado dentro de Ignition.

Demo Conector WSO2 – SCADA mediante OPC UA from Chakray on Vimeo.


Integración WSO2 CEP con Bonita BPM mediante BonitaLife

La siguiente entrada es una prueba de concepto (Proof of Conecept) en la que he estado trabajando últimamente que tiene como objetivo el responder en tiempo real a eventos (CEP) mediante Procesos de Negocio (BPM).

Para ello utilizaremos las siguientes herramientas:

Arquitectura

Como punto central para la integración crearemos un conector de salida (Custom Output Event Adaptor) en WSO2 CEP el cual, mediante la librería de BonitaLife 2.0, instanciará los procesos necesarios en Bonita BPM. Este conector lo utilizaremos como respuesta a las reglas de correlación que crearemos dentro del CEP.

CEP-Architecture-BonitaEventAdaptor

 

WSO2 CEP > BonitaOutputEventAdaptorTest > Bonita BPM

Para el funcionamiento del conector es necesario configurar los siguientes parametros:

blog-scada-event-formatter

blog-scada-event-formatter-config2

  • Output Event Adaptor Name: Conector BonitaOutputEventAdaptorTest, creado para esta POC.
  • OutputMapping Context: Mapeo de variables entre WSO2 y el proceso de Bonita BPM. Los valores del evento se asignaran al nuevo caso creado en caso que de existan como variables globales (variables de proceso) dentro del mismo. En este ejemplo, si existe dentro del proceso una variable global llamada “opc_node_value”, al instanciar el caso esta variable se asignará con el valor {opc_node_value} del evento/stream origen. En la imagen observamos como se asigna el id y valor del sensor así como una nueva variable llamada “opc_tipo_mantenim” con valor “CINTA_10000”.
  • Bonita Process UUID: En esta propiedad se asigna el valor UUID del proceso que queremos que se instancie al recibir el evento.

Podemos ver el conector en funcionamiento en la siguiente entrada o si se prefiere en el siguiente vídeo, donde se muestra un ejemplo para el mantenimiento preventivo de una cinta transportadora dentro de una planta industrial.

 


Integración SCADA/OPC UA con WSO2 CEP y WSO2 BAM

La siguiente entrada es una prueba de concepto (Proof of Conecept) en la que he estado trabajando últimamente que tiene como objetivo el integrar en tiempo real los eventos generados por los sensores industriales dentro de WSO2CEP y WSO2BAM.

Como resultado tendremos una arquitectura capaz de responder en tiempo real a los eventos que se produzcan en los sensores industriales (con Procesos de Negocio, como mostramos en esta entrada) y a su vez almacenarlos en una arquitectura Big Data (BAM) para su posterior agregación y análisis.

Para ello utilizaremos las siguientes herramientas:

  • WSO2 Complex Event Processor (CEP), como motor encargado de la gestión de los eventos (recopilación, procesado, y respuesta) (http://wso2.com/products/complex-event-processor/).
  • WSO2 Business Activity Monitor (BAM), como arquitectura Big Data para el almacenamiento (Cassandra) y posterior análisis/agregación de los mismos (Hadoop). Posteriormente el resultado lo podremos explotar con herramientas BI como Pentaho o Jasperserver. (http://wso2.com/products/business-activity-monitor/)
  • listener-opc.jar: Desarrollo encargado de capturar los eventos de los sensores industriales, mediante OPC-Unified Architecture, y posterior envio a los Data Receivers de WSO2CEP y WSO2BAM.

Arquitectura

Como punto central para la integración crearemos un listener en java encargado, como ya hemos comentado anteriormente, de monitorizar los sensores industriales y posterior envío a los Data Receivers de WSO2. Como resultado obtendremos un almacén de eventos (EDW OPC) y sistema de respuesta en tiempo real a los mismos.

CEP-BPM-Propuesta-Arquitectura

Podemos ver el listener en funcionamiento en la siguiente entrada o si se prefiere en el siguiente vídeo, donde se muestra un ejemplo para el mantenimiento preventivo de una cinta transportadora dentro de una planta industrial.

 


ITIL práctico, El Catálogo de Servicios (parte 2)

Parte 2, Identificación y Documentación de las Peticiones de Servicio

En esta parte vamos a ver como identificar las Peticiones de Servicio y documentarlas mediante una serie de plantillas generales, que serán las mismas que las utilizadas para definir un proceso de Negocio.

Definición de Petición de Servicio

Solicitud de un usuario para obtener información, consejo o acceso a un ‘Request for Change’ (RfC) estándar o Servicio IT. El ejemplo más típico sería la solicitud de un usuario para cambiar su contraseña de acceso.

Históricamente, en los departamento de IT no se ha hecho ninguna distinción entre Petición e Incidente, siendo en realidad conceptos totalmente diferentes. ¿Tiene sentido gestionar una solicitud de cambio de contraseña del mismo modo que un fallo en el servidor de dominios?. Parece que no.

En al revisión del 2011, dentro de la fase de Operación del Servicio, ya se incluye un proceso para la gestión de Peticiones de Servicio, separando así los incidentes de las peticiones.

Procedimiento de Trabajo

Aunque no es un concepto ITIL, me gustaría comentarlo ya que es un concepto que suelo utilizar bastante. Un procedimiento de trabajo es un agrupación de Peticiones para realizar un trabajo conjunto dentro de un proceso de negocio.

Pensemos, por ejemplo, en el proceso de nueva incorporación de RRHH. Llegará un punto donde solicitará un teléfono (Servicio IT), creación de la estación de trabajo (otro Servicio IT), creación de las credenciales (otro Servicio IT), etc… Pues el procedimiento de trabajo IT nueva incorporación será una pasarela entre RRHH e IT, agrupando de una manera transparente para RRHH las diversas Peticiones dentro de IT que intervienen en el proceso de incorporación.

Mapa de Peticiones de Servicio

El primer paso será definir el Mapa de Peticiones de Servicio. En este documento mostramos el listado de Peticiones de Servicio y Procedimientos de Trabajo disponibles y sus relaciones con los diferentes Servicios IT. Un ejemplo del Mapa de Peticiones de Servicio sería:

ClinicaGestion_MapaPeticionesDeServicio

Plantilla para definir una Petición de Servicio

Una vez creado del Mapa de Peticiones crearemos una plantilla asociada a cada una de ellas donde se describirá la Petición y el procedimiento asociado a la misma. Este documento, como ya hemos comentado, será el mismo que para definir un proceso de negocio. En este caso lo identificaremos como Ficha de Petición de Servicio. Los datos necesarios se indican en la siguiente plantilla:

Posteriormente, como veremos en la parte 4 y 5, crearemos el proceso asociado a la Petición de Servicio con Bonita BPM, publicaremos el documento dentro del Portal Liferay y gestionaremos el proceso mediante los portlets de Bonitalife.


ITIL práctico, El Catálogo de Servicios (parte 1)

Parte 1, Identificación y Documentación de los Servicios

En esta entrada vamos a ver como identificar y documentar  nuestros Servicios mediante una serie de fichas generales. Posteriormente, colgaremos las fichas en el Portal Liferay, como veremos en una entrada posterior.

Definición de Servicio

Un servicio es un conjunto de actividades que buscan responder a las necesidades de un cliente (http://es.wikipedia.org/wiki/Servicio)

En otras palabras, un conjunto de actividades agrupadas cuyo objetivo es satisfacer las expectativas de nuestros clientes. Para ello, en la fase de Estrategia del Servicio debemos alinear estas necesidades con la estrategia global de la Organización. Una buena manera para ello pueden ser iniciativas Six Sigma, como la Voz del Cliente (estrategia a corto plazo) o Voz del Mercado (estrategia a largo plazo). Pero esto será materia de otro grupo de entradas.

Definición de Servicio dentro del marco ITIL v3

En la versión 3 de ITIL inicialmente se hablaba de 3+1 tipos de Servicios:

  • Servicios de Negocio, que dan soporte directo a procesos de Negocio. Accesibles por los usuarios.
  • Servicios IT, que dan soporte a los procesos internos de Negocio. Accesibles por los usuarios.
  • Servicios de Infraestructura, los de más técnicos y de nivel más bajo. Sólo son accesibles a través de los Servicios IT, y
  • Servicios de Soporte, referidos al soporte externo de terceros.

En la revisión del 2011, se clarifican los conceptos y nos hablan de:

  • Servicios orientados a clientes externos, con valor directo para los clientes, asociados a la capa de negocio de la organización. Un ejemplo sería el Servicio de conexión a Internet para los clientes de una clínica especializada.
  • Servicio orientados a clientes internos, con valor directo a los empleados. Un ejemplo lo tendríamos en el Servicio de conexión a Internet pero en este caso a disposición de los empleados.
  • Servicio de Soporte, referidos en este caso a la relación de Servicios internos a IT y que nos son consumidos directamente por los clientes (tanto internos como externos). Por ejemplo la administración de los Servidores donde se alojan las aplicaciones de la clínica.

Con el objetivo de unificar conceptos, en esta serie de entradas los nombraremos como:

  • Servicios IT externos (orientados a clientes externos).
  • Servicios IT internos (orientados a clientes internos).
  • Servicios de Infraestructura, propios del servicio IT y no accesibles directamente por los usuarios.
  • Servicios de Soporte, internos al servicio IT pero prestados por proveedores externos.

Un Servicio, dos puntos de Vista

Diferentes roles del sistema necesitan acceder a distinta información del Servicio. Un primer concepto dentro de ITIL V3 que hay que conocer es la diferencia que existe entre el Portfolio de Servicios y el Catálogo de Servicios.

  • Portfolio de Servicio: dentro de la fase de estrategia del Servicio, muestra información desde el punto de vista del Negocio, dirigida a gerentes de Negocio, CIO’s, etc…
  • Catálogo de Servicios: dentro de la fase de diseño del Servicio, es la parte del Portfolio de Servicios accesible por los clientes, usuarios y departamento técnico. Diferenciamos:
    • Catálogo de Servicios Negocio, con la información accesible por el cliente. Puede actuar como herramienta de venta.
    • Catálogo de Servicios Técnico, con la información técnica necesaria para prestar el Servicio por parte de IT. No suele ser accesible por el cliente.

Nosotros nos centraremos en el Catálogo de Servicios y sus dos vistas: la de Negocio y la Técnica.

Diagrama de Servicios

Un primer paso para la documentación del Catálogo de Servicios es la creación del diagrama de Servicios. Este diagrama es un esquema jerárquico que nos muestra la relación entre los diferentes tipos de Servicio.

Un ejemplo de este diagrama sería:

ClinicaGestion_ServiceCatalog

  • En la primera capa nos encontramos las unidades organizativas y los procesos de negocio que necesitan consumir Servicios IT.
  • En la segunda capa nos encontramos los Servicios IT (internos o externos), asociados a los procesos de negocio que dan soporte.
  • En la tercera capa nos encontramos los Servicios de Infraestructura internos al departamento IT. Estos no pueden ser consumidos directamente por los usuarios/procesos.
  • Por último nos encontramos los Servicios de Soporte que son prestados por terceras empresas, así como su relación con los Servicios de Infraestructura.

La información contenida en el Diagrama de Servicio es consultada frecuentemente por diversas áreas:

  • Los gestores IT para, por ejemplo, cuantificar el impacto que tendrían dentro del negocio determinadas decisiones sobre los Servicios.
    • ¿Que impacto tendría un fallo en el Servicio “ClinicaGestion?
    • ¿Que servicios se verían afectados por un corte en el acceso a Internet?
    • ¿Que impacto tendría la eliminación de un determinado contrato de soporte?
  • El Service Desk IT, para determinar los Servicios afectados y la causa raíz del incidente.
    • ¿No se puede acceder a ClinicaGestion?¿Problema en el Servidor?¿En la aplicación?¿En el acceso a Internet?¿…?

Normalmente el Diagrama de Servicio es un documento de consulta interno para IT, ya que contiene información que no es relevante para los usuarios, como los Servicios de Infraestructura y Soporte externo.

Ficha de Servicio

Una vez definido el Diagrama de Servicios, crearemos una Ficha de Servicio para cada uno de ellos. Cada Servicio tendrá asociado un SLA (Service Level Agreement) donde indicaremos los tiempos de atención para cada tipo de Problema. Cada incidente se clasificará en función del binomio Prioridad/Urgencia, determinando así la severidad del incidente. Los datos necesarios se indican en las siguientes plantillas:

Un ejemplo de la Ficha para el Servicio IT de Clínica Gestión sería:

Estas plantillas son sólo un ejemplo que reflejan los datos que, desde mi punto de vista y según diversa biografiaría, son necesarios para definir el Servicio. Por supuesto se pueden añadir o eliminar cualquiera de ellos.

En  la siguiente entrada veremos como identificar las Peticiones (Service Request) asociadas a un determinado Servicio.


ITIL práctico, El Catálogo de Servicios (Introducción)

Esta es la primera entrada de una serie cuyo objetivo será mostrar como implementar de una manera práctica un Catalogo de Servicios IT, tomando como referencia el código de buenas prácticas  ITIL (Information Technology Infraestructure Library) en su versión 3.

¿Qué conceptos vamos a tratar?

Los conceptos que vamos a tratar en esta serie de entradas son:

  • Catálogo de Servicios
    • Servicios IT externos (orientados a clientes externos).
    • Servicios IT internos (orientados a clientes internos).
    • Servicios de Infraestructura propios del servicio IT y no accesibles directamente por los usuarios.
    • Servicios de Soporte prestados por proveedores externos.
  • Petición de Servicio (asociadas a un Servicio), hacia el EMR (Enterprise Request Management)

¿Qué pasos vamos a seguir?

Los pasos que seguiremos para implementar el Catálogo de Servicio IT serán:

Parte 1, Identificar y documentar los Servicios que entrarán dentro del alcance del proyecto

Parte 2, Identificar y documentar las Peticiones de Servicio de cada uno de estos Servicios

Parte 3, Creación del Catálogo de Servicios IT

Parte 4, Creación de los Procesos de Negocio asociados a cada una de las Peticiones de Servicio (SR)

Parte 5, Creación de un “Auto-Servicio” para el consumo de las Peticiones de Servicio

Parte 6, Monitorización de los Procesos de Negocio

ITIL-CatalogoDeServicios-Pasos

¿Qué herramientas vamos a utilizar?

Las herramientas que vamos a utilizar en esta serie de entradas son:

Nos basaremos en la siguiente arquitectura:

Arquitectura_Clinica

  • Liferay Portal como Intranet Corporativa. Crearemos un repositorio con la documentación relacionada con los Servicios y Peticiones de Servicio IT.
  • BonitaLife como interfaz de comunicación entre el Portal Liferay y el motor de procesos de Bonita BPM.
  • Bonita BPM como motor de procesos de negocio.
  • WSO2 Data Services Server como herramienta SOA para el acceso unificado a los Servicios.
  • WSO2 Business Activity Monitor como herramienta de monitorización, encargada de la recopilación y análisis de las métricas asociadas a los procesos (Peticiones de Servicio). Utiliza métodos de Big Data como noSQL (Cassandra) y Hadoop para su análisis.
  • Pentaho BI Community + Community Dashboard Framework como herramienta de Business Intelligence para la explotación de los datos agregados por WSO2BAM.

La siguiente entrada estará dedicada a la identificación y documentación de los Servicios, primera parte de este grupo de entradas.