Events are the lifeline of WSO2 CEP/DAS. They not only process data as events, but also interact with external systems using events. Event is a unit of data, and an event stream is a sequence of events of a particular type. The type of events can be defined as an event stream definition. The following sections explain how to work with events in WSO2 CEP.
| Table of Contents | ||||
|---|---|---|---|---|
|
...
You can manage event streams through event stream definitions.
- Event stream definition
- Adding an event stream
- Using the source view
- Deleting an event stream
- Editing an event stream
- Creating sample events
...
Definitions of the event streams are stored in the filesystem as deployable artifacts in the <PRODUCT _HOME>/repository/deployment/server/eventstreams/ directory as .json files. These are hot deployable files and can be added/removed when the server is up and running. A sample event stream definition is as follows.
| Code Block | ||
|---|---|---|
| ||
{
"streamId": "org.wso2.test:1.0.0",
"name": "org.wso2.test",
"version": "1.0.0",
"nickName": "TestStream",
"description": "Test Stream",
"metaData": [
{
"name": "ip",
"type": "STRING"
}
],
"correlationData": [
{
"name": "id",
"type": "LONG"
}
],
"payloadData": [
{
"name": "testMessage",
"type": "STRING"
}
]
} |
The properties of the above event stream definition are described below.
...
The data the event contains. Data is divided into the following three categories for maintenance and usability. Thus gives more meaningful structure when it comes to aspects of data. It is not mandatory to have all three sections. But there should be at least one section defined.Also irrespective of these sections, they will be treated the same at the Siddhi level.
- Meta Data: Contains the meta information of the events. (Referred to as
meta_<attribute name>.) - Correlation Data: Contains the correlation information of the events. (Referred to as
correlation_<attribute name>.) - Payload Data: Contains the actual data that the event intends to have. (Referred to as
<attribute name>.)
...
Events are the lifeline of WSO2 CEP/DAS. They not only process data as events, but also interact with external systems using events. Event is a unit of data, and an event stream is a sequence of events of a particular type. The type of events can be defined as an event stream definition. The following sections explain how to work with events in WSO2 CEP.
| Table of Contents | ||||
|---|---|---|---|---|
|
Event streams
| Anchor | ||||
|---|---|---|---|---|
|
You can manage event streams through event stream definitions.
- Event stream definition
- Adding an event stream
- Using the source view
- Deleting an event stream
- Editing an event stream
- Creating sample events
Anchor Event stream definitions Event stream definitions
Event stream definition
| Event stream definitions | |
| Event stream definitions |
Definitions of the event streams are stored in the filesystem as deployable artifacts in the <PRODUCT _HOME>/repository/deployment/server/eventstreams/ directory as .json files. These are hot deployable files and can be added/removed when the server is up and running. A sample event stream definition is as follows.
| Code Block | ||
|---|---|---|
| ||
{
"streamId": "org.wso2.test:1.0.0",
"name": "org.wso2.test",
"version": "1.0.0",
"nickName": "TestStream",
"description": "Test Stream",
"metaData": [
{
"name": "ip",
"type": "STRING"
}
],
"correlationData": [
{
"name": "id",
"type": "LONG"
}
],
"payloadData": [
{
"name": "testMessage",
"type": "STRING"
}
]
} |
The properties of the above event stream definition are described below.
| Property | Description |
|---|---|
| Event Stream Name | Name of the event stream. |
| Event Stream Version | Version of the event stream. (Default value is 1.0.0.) |
| Event Stream Description | Description of the events stream. (This is optional.) |
| Event Stream Nick-Name | Nick-names of an event streams separated by commas. (This is optional.) |
| Stream Attributes | Stream Attributes contains the data of the event. These are divided into three logical separations to give more usability and maintenance to the user. It is not mandatory to have attributes in all three sections, but there should be at least one section with at least one attribute defined. Also attribute names should be unique within each section.
It is recommended to have logistic separation but the internal system does not differentiate or give privilege based on above separations. Also Please note if you edit and add another attribute to existing stream definition, other artifacts which are associated with the stream will be inactive. So that it is recommended to create a new definition and a version with the additional attribute. For example consider following attributes which exist in a single event. event_timestamp, request_IP_address, correlation_Id, price, symbol with there corresponding data types. We can logically separate the above attributes as following.
|
Adding an event stream Anchor Add Add
| Add | |
| Add |
...