WSO2 Complex Event Processor: Nueva versión liberada

Como estamos en días de liberaciones de nuevas versiones de las herramientas pertenecientes a la suite de WSO2 aquí les vengo con otra más, bien fresquita.

La versión 4.0.0 del WSO2 Complex Event Processor fue liberada en el día de hoy al igual que su documentación actualizada.


Sus detalles son los siguientes:

New Features

• [CEP-635] - Integrate Apache Storm into CEP
• [CEP-852] - Event Simulator with sending multiple events using uploaded files
• [CEP-879] - MQTT input Event Adapter for CEP
• [CEP-880] - MQTT output Event Adapter for CEP
• [CEP-881] - Input Websocket adapter for CEP
• [CEP-885] - Time Series Regression Extension to Siddhi
• [CEP-886] - Time Series Forecaster for Siddhi
• [CEP-887] - Outlier Detection Extension for Siddhi
• [CEP-888] - Initial storm solution for CEP
• [CEP-903] - Siddhi - Remove callback from stream functionality
• [CEP-909] - Input Websocket (with local websocket server) Adapter for CEP
• [CEP-910] - Output Websocket Adapter for CEP
• [CEP-911] - Output Websocket Adapter (using local websocket server) for CEP
• [CEP-942] - Siddhi partition implementation
• [CEP-945] - Improved Siddhi Query API and Compiler
• [CEP-958] - Siddhi-core adding support for aggregated attributes
• [CEP-959] - Siddhi-core supporting extensions
• [CEP-985] - Stationery Alert is one of the Geo Dashboard features which enable users to recieve alerts if a spatial object stayes in a specified area for a given specified time.
• [CEP-993] - Exchangeable views between form view and source view when creating event streams
• [CEP-1017] - cApp support for CEP components
• [CEP-1018] - Encrypting password fields of Input and Output Adapters
• [CEP-1028] - File Based Stream Definition Store
• [CEP-1029] - String Extension for Siddhi
• [CEP-1030] - Math Extension for Siddhi
• [CEP-1032] - Integrating Siddhi 3.0.0
• [CEP-1033] - Adding annotation,partitioning and query grouping support in Storm
• [CEP-1062] - Cron TimeWindow for Siddhi
• [CEP-1095] - Domain Specific Execution Manager
• [CEP-1132] - Improving HA support
• [CEP-1141] - Geo Dashboard Integration
• [CEP-1355] - Analytics Dashboard
• [CEP-1356] - Siddhi Try It Feature
• [CEP-1357] - JMX monitoring support for CEP
• [CEP-1358] - Adding Metrics support for CEP

Improvements

• [CEP-209] - Cleanup SQL & Hazelcast query creation logic
• [CEP-216] - Optimize Siddhi partitions by chaining per queries together
• [CEP-391] - Better to specify different email subjects rather than specifying with SOAPAction
• [CEP-392] - Better if the passwords shown on xml on edit mode be hidden
• [CEP-537] - Sample with MB (As jms) with CEP
• [CEP-821] - the way CEP handles if the specified BAM user does not exist needs to improve
• [CEP-858] - CEP Input/Output Adapter runtime queue,batch size, etc defaults has to go to a config file
• [CEP-863] - Databases types needs to extensible for event tables like siddhi extension
• [CEP-872] - Implementing different stream clustering logics to siddhi event processor
• [CEP-884] - Improve jms input adaptor to pass advanced jms configs
• [CEP-889] - Blooms Filter for siddhi event tables
• [CEP-891] - Ability to create event stream based on event structure
• [CEP-892] - On Fly validation to fields if possible
• [CEP-965] - Make MySQL Output event adaptor generic for all RDBMS
• [CEP-969] - issue in validating the parameter count passed
• [CEP-1010] - Enabling event simulating via data in database
• [CEP-1011] - Extended Regex Functionality Support for Siddhi
• [CEP-1021] - Sort Execution Plans and Event Streams in alphabetical order
• [CEP-1036] - Important Improvements for CEP 4.0.0 (Siddhi)
• [CEP-1037] - Email Output Event Adapter
• [CEP-1038] - HTTP Output Event Adapter
• [CEP-1039] - SOAP Output Event Adapter
• [CEP-1040] - JMS Output Event Adapter
• [CEP-1045] - [Event tables] Event tables should support Oracle DBMS
• [CEP-1046] - JMS Input Event Adapter
• [CEP-1047] - MQTT Output Event Adapter
• [CEP-1048] - MQTT Input Event Adapter
• [CEP-1049] - Email Input Event Adapter
• [CEP-1051] - Create features for Event Output Adapters
• [CEP-1052] - Websocket & Websocket-Local Event Output Adapters
• [CEP-1053] - http input event adapter feature
• [CEP-1054] - Websocket & Websocket-Local Input Event Adapter
• [CEP-1055] - SMS Output Event Adapter
• [CEP-1059] - adding input event adapter features for event receiver
• [CEP-1060] - Adding cassandra output adapter feature for event publisher
• [CEP-1063] - Event Flow Improvement
• [CEP-1065] - Aligning Event Flow with the receiver/publisher architecture
• [CEP-1071] - Adding event definition pop-up for event receiver and publisher
• [CEP-1072] - Improve execution plan editor to incorporate new features
• [CEP-1079] - Adding auto-completion to Siddhi Query Editor
• [CEP-1080] - Improvements to code mirror syntax highlighting functionality
• [CEP-1084] - Fixes and improvements for Application Deployer
• [CEP-1088] - Improve Event Receivers' WSO2 Event mapping to add Stream Name and Version
• [CEP-1110] - Improve the SOAP Output Adapter to handle advanced config properties
• [CEP-1139] - Adding samples and integration tests for event publishers and receivers
• [CEP-1144] - Adding RegEx Support fot Siddhi
• [CEP-1159] - Add description to the Adapters
• [CEP-1195] - Connection pooling for JMS publisher
• [CEP-1197] - Add a cleanup method to remove all artefacts after a test case
• [CEP-1198] - Default image when there are no data on real time charts
• [CEP-1200] - Before deleting prompt for "Are you sure you want to delete ?" popup
• [CEP-1207] - [CEP 4.0.0] - Put a Clear Button to the Event Simulator
• [CEP-1209] - wso2event producer throughput reduces when increasing number of instances
• [CEP-1214] - Tenant Loading does not happen for some event receivers when it receives event
• [CEP-1227] - Scalability of CEP+Storm needs improvement
• [CEP-1240] - WSO2Event - Performance Tuning Recommendations documentation
• [CEP-1243] - Update lmax.distruptor to latest version
• [CEP-1245] - Update nexus and CEP for latest disruptor 3.3.2
• [CEP-1250] - Adding timestamp selection option for realtime gadget
• [CEP-1261] - Monitoring distributed deployment status
• [CEP-1265] - Add secure vault / cipher tool support to delivary manager password in event-broker.xml
• [CEP-1266] - Add secure vault / cipher tool support to mail.smtp.password in output-event-adapters.xml
• [CEP-1267] - Adding manipulation links when viewing artefacts
• [CEP-1273] - Add Analytics JMX Data Agent to CEP

Read More [...]

Posted in CEP, WSO2

WSO2 BAM/CEP: Escenario 1 de aplicación para eventos complejos.

El BAM de WSO2 en su versión 2.4.0 ya viene con las funcionalidades del CEP de WSO2 incluidas.
Esto permite no solo capturar eventos para mostrarlos posteriormente usando el dashboard del BAM,si no que los eventos se capturan en tiempo real usando las funcionalidades del CEP y se pueden procesar para la toma de decisiones también en tiempo real.

Como ejemplo les muestro una gráfica generada por el BAM del flujo de eventos recibidos.

Y debajo pueden ver como es el comportamiento de la cantidad de request/response/fault de los eventos recibidos.

  El escenario implementado para esta entrada es realmente sencillo a manera de "Hola Mundo" y estos son los pasos de manera general: 

• Configurar el AS de WSO2 para que publique los eventos del consumo de los servicios para el BAM. 

• Invocar a un servicio desplegado en el AS para que el BAM reciba un evento, de esta manera se crea automáticamente un Stream tal y como se muestra en la siguiente figura.

  En este caso se crea automáticamente el Stream de nombre “bam_service_data_publisher” versión 1.0.0 

• Crear un plan de ejecución que extraiga de cada evento que arribe el tiempo de respuesta del servicio y si es menor que determinada cantidad de milisegundos inserte el evento en un nuevo Stream, usando los atributos especificados.

Como pueden ver uso el Stream de entrada y si en un evento el response_time es mayor que 1s se selecciona el nombre del servicio, el nombre de la operación y el tiempo de respuesta y se insertan en un Stream nuevo.

Este Stream nuevo la herramienta nos permite crearlo muy fácilmente y es el que se llama “OutMediationStatsStream”

  

• Creamos un adaptador de salida de tipo email.

Que tiene la siguiente configuración.

• Ahora se crea un formateador de eventos, que usará el adaptador de salida previamente creado y nos permite formatear el evento de salida tal y como se muestra en las siguientes imágenes.

• Ahora ya se puede probar la configuración creada, para ello solo es necesario invocar a un servicio desplegado en el AS y observar los resultados.

En nuestro caso usamos el SOAPUI para generar una prueba de carga.

Y estamos usando el servicio Echo, con la operación echoString.

Les muestro nuevamente las gráficas generadas:

Y un ejemplo de un correo enviado:

Se ha detectado el consumo de servicio echo, en la operacion echoString con un tiempo de respuesta de 2502 el cual se encuentra por encima del valor establecido

En otras entradas estaremos viendo planes de ejecución más complejos que usen diferentes tipos del filtros y ventanas para capturar escenarios complejos, así como diferentes formas de generar los eventos y de generar las salidas como respuesta a los eventos complejos.

Read More [...]

Posted in BAM, CEP, WSO2

WSO2. CEP. II - Input Event Adaptors

Hola buenas,

  Ya que este es mi primer post me voy a presentar primero, me llamo Andrés Gómez Ferrer y soy estudiante de ingeniería de telecomunicación en la Universidad de Sevilla, España.

    Introducción

  Como ya os advirtió Jorge en el último post acerca de WSO2-CEP, vamos a hablar para comenzar de la primera parte de CEP, ya que podemos decir que esta separada en módulos como se puede ver en la figura1.

Figura1. Modulos de CEP.

  En este post nos vamos a centrar concretamente en el modulo de entrada o también conocido como "Input Event Adaptor". El software de CEP trae por defecto en su paquete los siguientes adaptadores:

1. email
2. jms
3. ws-event
4. ws-event-local
5. wso2event

  Donde podemos encontrar más información acerca de ellos en el siguiente enlace: Input Event Adaptors

  Aparte de estos adaptadores, también podemos crear los nuestros personalizados que posteriormente se integran en el sistema con bastante comodidad. Esto quizás pueda ser más interesante y ya que la información es algo más escasa en la web nos detendremos algo más, de todas formas aquí os dejo el enlace al manual: Custom Event Adaptors .

  Comenzar mencionando que hay dos tipos de Custom Event Adaptors, los de entrada y los de salida en este post vamos a analizar únicamente los de entrada, y posteriormente en otro post comentaremos los de salida.

    Preparación del entorno.

  Mi recomendación para trabajar con los custom event adaptors es utilizar un IDE como puede ser ECLIPSE o NETBEANS ambos software libre y fácil de encontrar. El adaptor de entrada se crea a partir de un OGSI Bundle, por lo que debemos empezar creando un proyecto de este tipo. Personalmente trabajo con netbeans y es fácilmente crear un proyecto MAVEN del tipo OGSI Bundle, si usamos MAVEN deberemos incluir en el pom.xml el siguiente repositorio:

<repositories> 
     <repository> 
          <id>wso2-maven2-repository</id> 
          <name>WSO2 Maven2 Repository</name> 
          <url>http://dist.wso2.org/maven2</url> 
     </repository> 
</repositories>

y las siguiente dependencia:

<dependency>

         <groupId>org.wso2.carbon</groupId>

         <artifactId>org.wso2.carbon.event.input.adaptor.core</artifactId>

         <version>1.0.0</version>

 </dependency>

  Que sera necesario para acceder a las librerías que usa el adaptor, por otro lado si preferimos incluir las librerías como jar, también las podemos encontrar en <CEP_HOME>/repository/components/plugins/org.wso2.carbon.event.input.adaptor.core_1.X.X.jar

    Profundizando en el código

Tenemos que crear una clase que extienda de la clase "AbstractInputEventAdaptor", la cual contiene los siguientes métodos:

-> Metodo que devuelve un string con el nombre que se mostrada en la web de gestión de CEP.

String getName()

-> Devuelve una lista con los tipos de mensajes soportados para el event builder, pueden ser:
       * JSON
       * MAP
       * TEXT
       * XML
       * WSO2EVENT 

List<String> getSupportedInputMessageTypes()

-> Metodo que se llama a la hora de ejecutar. Normalmente se usa para indicar las Propiedades.

void init()

-> Se definen la características configurables desde la web para tu custom adaptar.

List<Property> getInputAdaptorProperties()

-> Se definen la características configurables desde el eventBuilder.
List<Property> getInputMessageProperties()

-> Es el metodo que se va a ejecutar y el cuerpo de nuestro custom adaptor, se llama al instanciarlo.
 String subscribe(
            InputEventAdaptorMessageConfiguration inputEventAdaptorMessageConfiguration,
            InputEventAdaptorListener inputEventAdaptorListener,
            InputEventAdaptorConfiguration inputEventAdaptorConfiguration,
            AxisConfiguration axisConfiguration)

-> Es el metodo que se va a ejecutar cuando se cierre el wso2-CEP.
void unsubscribe(
            InputEventAdaptorMessageConfiguration inputEventAdaptorMessageConfiguration,
            InputEventAdaptorConfiguration inputEventAdaptorConfiguration,
            AxisConfiguration axisConfiguration, String s)

  Vamos a centrarnos algo más en el metodo suscribe donde ya que es el corazón de nuestro adaptor, comenzamos mencionando algunos de los parámetros que tienen mayor intereses.

  * inputEventAdaptorMessageConfiguration: Obtenemos la configuración introducida en la ventada de eventBuilder para ello usamos el metodo getInputMessageProperties().

  * inputEventAdaptorListener: Podemos considerarlo la puerta de enlace entre nuestro adaptador y CEP, ya que mediante su metido .onEvent() se envían los mensajes a CEP.

  * inputEventAdaptorConfiguration: Obtenemos la configuración introducida en la ventada de eventBuilder para ello usamos el metodo getInputProperties().

  Después de configurar a nuestro gusto el adaptor, tenemos que crear una clase que implemente "InputEventAdaptorFactory" la cual solo contiene un metodo llamado: AbstractInputEventAdaptor getEventAdaptor() el cual devuelve una instancia creada de la clase de nuestro adaptor "AbstractInputEventAdaptor".

En el próximo post, seguiremos hablando de los Input Event Adaptors y analizaremos a fondo un Custom Adaptors para apache-Kafka-0.8.1 con zookeeper.

Un saludo,

Andrés Gómez

Read More [...]

Posted in CEP, InputEventAdaptor

WSO2 y su Procesador de Eventos Complejos. CEP. I

Todas las empresas para sus operaciones y transacciones diarias deben generar un sinnúmero de información a ser intercambiada entre emisores y receptores. Si estas acciones son automatizadas en sistemas informáticos pues tendremos un gran flujo de información a través de las redes de la empresa y hacia y desde el exterior. Este flujo de información consiste en un flujo constante de eventos que se generan y aquellas empresas que son capaces de capturar y analizar en tiempo real los eventos tienen una ventaja mayor con respecto a sus competidores. Esto se debe a que pueden saber qué pasa en todo momento en su negocio y reaccionar rápidamente ante eventos o patrones incorrectos.

Claro que implementar una solución que capture los eventos, los procese y genere respuestas en dependencia de los patrones que ocurran no es tarea fácil, y es ahí donde WSO2 viene a nuestra ayuda.

El CEP o Complex Event Processor de WSO2, que en español vendría siendo “Procesador de Eventos  Complejos” es una herramienta que recibe eventos generados por el resto de las herramientas de la suite y cualquier otra solución que se configure para ello, y es capaz de determinar en tiempo real si determinados patrones de eventos están ocurriendo y reaccionar ante ellos. Está de más decir que la herramienta está bajo licencia apache v2, y que tiene un alto rendimiento y escala de lo mejor.

Cuando comentaba que recibe eventos de las herramientas de la  suite y de cualquier otra herramienta que se configure para que lo haga, es que en el caso de las herramientas de la suite hay que ajustarlas para que todos los eventos generados por ella sean enviados al servidor del CEP, y en el caso de otros tipos de herramientas o soluciones informáticas pues igualmente hay que implementar para que hagan lo mismo. Por suerte es muy similar a como se hace con el BAM.

La arquitectura del CEP puede verse como un poco compleja al inicio, pero es bastante fácil de entender:

Como ven los eventos son generados de diferentes maneras, bien sea a través de brokers de mensajería, a través de los publicadores de datos de WSO2, vía email o por llamadas REST.

Cuando estos eventos llegan al CEP son recibidos por un “Input Event Adaptor” que se corresponde a la forma en que se mandó el evento recibido. Lo interesante es que si hemos implementado una aplicación que manda los eventos al CEP de una manera no registrada aquí, pues podemos implementar nuestro propio adaptador e incluirlo dentro del CEP. Espero que pronto veamos un trabajo realizado en este tema en el blog.

Luego los eventos son pasados al “Event Builder” que se encarga de convertir el formato de los eventos a un formato estándar “WSO2Event” y de esta manera llegan los eventos al core del CEP, el “Event Processor”.

En el “Event Processor” se manejan diferentes planes de ejecución con la ayuda de Siddhi, que es el framework base usado por el CEP para el manejo de eventos. Aquí es donde ocurre la “magia”. Y veremos como se hace en otras entradas de esta serie sobre el CEP.

Luego los eventos son nuevamente convertidos de “WSO2Event” a su formato de destino  en el “Event Formatter”.

La publicación de los eventos ocurre entonces en el “Output Event Adaptor ” encargado de mandar los eventos publicados a sus destinatarios.

Para entender la utilidad del CEP veamos algunas cosas que se pueden hacer:

• Se puede implementar un plan de ejecución que detecte en tiempo real cuando el precio de determinadas acciones en el mercado han cambiado un más de un 2% en menos de 1min, y notificar a los usuarios subscritos a este evento.

• Se puede implementar un plan de ejecución que detecte en tiempo real cuando un vuelo viene retrasado y notifique a los usuarios subscritos a este evento, bien sea vía correo electrónico, sms, o a través de una aplicación web.

• Se puede implementar un plan de ejecución que detecte múltiples intentos de autenticación erróneos usando una misma cuenta, por ejemplo desde diferentes IP, o con un criterio de más de 5 intentos en un segundo, y notificar al dueño de la cuenta.

Y así cualquier cosa que se quiera detectar se puede implementar usando el CEP de WSO2, y lo más interesante es que será en tiempo real.

Read More [...]

Posted in CEP, WSO2

Introducción a la Plataforma de WSO2. IV

Para terminar con la serie que describe las herramientas de la suite de WSO2 vamos a revisar las últimas 4 herramientas.

 

1.       Business Rules Server: en la entrada anterior habíamos hecho mención de servicios de regla de negocio y eso es precisamente lo que hace esta herramienta. Nos permite el desarrollo de servicios web que exponen reglas de negocio. la utilidad consiste en que podemos extraer de los sistemas las reglas de negocio, implementarlas como servicios y exponerlas para cualquier aplicación que las requiera y que tenga permiso para acceder a ellas. Estas reglas de negocio se implementan gracias al uso de Drools como motor de reglas y a la implementación de clases que definen los mensajes de entrada y de salida que cargan los parámetros de entrada que sirven para evaluar la regla y los parámetros de salida que determinan la respuesta a entregar al cliente.

2.       API Manager: esta es una de las herramientas más nuevas de la suite. Permite el desarrollo de APIs así como la gestión de su ciclo de vida, el control de acceso a la misma y la gestión de la calidad del servicio o QoS.

3.       Cloud Gateway: esta herramienta actúa como una pasarela entre los recursos empresariales de una  empresa y aquellos recursos desplegados en una nube permitiendo la comunicación segura y confiable entre ambos extremos.

4.       Complex Event Processor: la gestión de eventos complejos siempre es un tema importante en las empresas, el cómo se responde a un conjunto de eventos que ocurren en tiempo real o casi real es de suma importancia. Eso es lo que nos permite implementar esta herramienta. Su combinación con el BAM es fundamental para la monitorización de una organización y sus activos de tecnología.

Hay una herramienta que no incluí en este listado y creo que es de las más interesantes y que menos se comentan dentro de la comunidad de desarrolladores de WSO2, me estoy refiriendo al AppFactory. Esta herramienta pretende cubrir todo el ciclo de desarrollo gracias a la integración continua, lo cual pueden observar en la imagen debajo. No la he probado ni se si la liberarán bajo la misma licencia y de manera gratis lo que si se es que constituye un paso de avance significativo para su comunidad de desarrollo.

 

Read More [...]

Posted in API, AppFactory, BRS, CEP, Cloud, Gateway, WSO2