Creating a Standalone Execution Plan
WSO2 DAS uses execution plans to store event processing logic. An execution plan is bound to an instance of Siddhi Data Analytics Server runtime, which is responsible for the actual processing of events. DAS allows users to configure multiple execution plans and provides multiple isolated event processing environments per execution plan. A typical execution plan consists of a set of queries and related input and output event streams.
Writing an execution plan
Follow the instructions below to write an execution plan.
- Start WSO2 DAS and log into its Management Console. Click Main and then click Execution Plans to open the Available Execution Plans page.
Click Add Execution Plan to open the Create a New Execution Plan page in which a template is displayed as shown in the example below.
You can edit this template to create a new execution plan. Follow the steps below to edit the template and create a new execution plan.The execution plan editor supports auto completion.
To view the suggestions made by the editor, press control+space keys together.
The suggestions contain two sets.
- Siddhi keywords, in alphabetical order
- All the other words which are already inserted into the editor. For example, stream names which are defined in step 2 will be suggested when writing the queries in step 3. These will appear in alphabetical order after the keyword list.
In addition to the above, press shift+2 keys together to view suggestions on annotations.
Supported annotations
The annotations supported for execution plans are as follows.
Annotation | Description | Example |
---|---|---|
| The name of the execution plan. | @Plan:name('ExecutionPlan') |
@plan:description (<description about execution plan>) | This provides a description about the execution plan. Details such as the business requirement of the execution plan can be mentioned here. |
|
@plan:async (bufferSize=<event queue size>) | WSO2 DAS has a disruptor based implementation to handle streams that are disabled by default. This annotation can be used to enable the disruptor at execution plan level that affects all the streams in the execution plan. The buffer size is an optional parameter. The default buffer size is 1024 . | @plan:async(bufferSize=2) |
@async(bufferSize=<event queue size>) | Using this you can enable the disruptor only for a specific event stream. The event flow of the specified stream passes through the disruptor when enabled. |
|
@import (<DAS stream definition>) | This is used to import a DAS event stream definition and map it to a Siddhi stream definition. For more information about event stream definitions, see Understanding Event Streams and Event Tables. |
|
@export (<DAS stream definition>) | This is used to export a Siddhi event stream definition and map it to a DAS event stream definition. |
|
Step 1: Add execution plan info
Add Execution Plan Name
Give a meaningful name to the execution plan by replacing ExecutionPlan
in @Plan:name('ExecutionPlan')
with the new name.
For example, if the new name should be 'NewExecutionPlan'
, then replace @Plan:name('ExecutionPlan')
with @Plan:name('NewExecutionPlan')
.
Description
This is the description of the execution plan. Giving a description is optional.
To give a description to the execution plan,
- uncomment the line
-- @Plan:description('ExecutionPlan')
. - replace
'ExecutionPlan'
with the description
For example, @Plan:description('This is the description for my NewExecutionPlan')
.
Step 2: Import streams
An execution plan processes one or more streams. Therefore it is mandatory to import streams into an execution plan.
Importing a stream means mapping an available event stream to another internal stream. This internal stream is then used in query expressions, which will be written in Step 3: Add query expressions. This internal stream is meant to be used by the Siddhi runtime.
To import a stream:
- Select an existing stream for the Import Stream parameter. This is the event stream from which events will be taken to be processed by the execution plan.
- Enter a meaningful name for the stream in the As parameter. This is the name that is used when feeding the stream to the Siddhi engine. This can contain only alphanumeric characters and underscore (_).
Select the Include Arbitrary check box if you want to append arbitrary configurations to the stream definition when performing the import.
If this check box is selected for an import stream, the
arbitrary.data='true'
setting is added to the import stream definition in the execution plan. In addition, an attribute namedarbitraryDataMap Object
is added to the attribute list of the input stream definition in the execution plan. The keys and values on this attribute of theobject
type can be accessed via the map extension of Siddhi. This allows arbitrary data of the import stream to be copied to the export stream. Arbitrary data are events that are received without themeta
_ or acorrelation
_ prefix, and at the same time do not match the payload attributes defined in an event stream.- Click Import.
This will import an available event stream as a new stream.
Step 3: Add query expressions
Query expressions are event processing logic written in Siddhi Query Language. When defining more than one query, each query should end with a semi colon.
Step 4. Export streams
Defines the mappings between the exported (output) stream of the Siddhi runtime to one of the available event streams (defined inside query expressions). The parameters are as follows.
- Value Of: The name of the stream exposed by the Siddhi runtime. This can contain only alphanumeric characters and underscore (_).
- StreamId: The ID of the event stream to which the output events are sent from the execution plan.
- Include Arbitrary: If this check box is selected, the
arbitrary.data='true'
setting is added to the export stream definition in the execution plan. This allows you to publish arbitrary data from that stream.
- It is not mandatory to define export streams in an execution plan.
- Siddhi Event tables cannot be exposed as streams. Event tables are only considered as streams within Siddhi.
Step 5. Add execution plan
Before adding the execution plan to the Siddhi runtime, it can be validated by clicking Validate Query Expressions.
Click Add Execution Plan to deploy the execution plan.
Once an execution plan is created as saved, its configuration in WSO2 Siddhi Query Language format is saved in the <DAS_HOME>/repository/deployment/server/executionplans
directory.
Editing a deployed execution plan
Follow the procedure below to edit an execution plan.
- Start WSO2 DAS and log into its Management Console. Click Main and then click Execution Plans to open the Available Execution Plans page. The available execution plans are listed in this page.
- Click Edit in the row of the execution plan you want to edit. The Edit Execution Plan Configuration page will open.
- Edit the execution plan as required and click Update.
Alternatively, you can write your execution plan in a text file and save it with the .siddhiql
extension (which stands for Siddhi Query Language), and place it in the <PRODUCT_HOME>/repository/deployment/server/executionplans
directory. Since hot deployment is supported you can also add/remove execution plan files to deploy/undeploy execution plans from the server.
Deleting a deployed execution plan
Follow the procedure below to delete an execution plan.
- Start WSO2 DAS and log into its Management Console. Click Main and then click Execution Plans to open the Available Execution Plans page. The available execution plans are listed in this page.
- Click Delete in the row of the execution plan you want to delete. Click Yes in the message which appears to confirm whether the execution plan should be deleted.