About blocks

Blocks are ready packaged modules that you can use in your scenarios. They can accept inputs, execute some logic of their own, and generate output.

A block is defined in a Block Definition File, or .bdf. This XML file describes the functionality of the block and its implementation in Apama Event Processing Language (EPL), which is the new name of Apama MonitorScript. EPL is the native language of the correlator.

Note: Within the product, both EPL and MonitorScript are used and should be treated as synonymous.

Input feeds – an input feed can be hooked up to a live stream of event data, like a price quote stream. Within it, an input feed will define one or more input fields, which can be mapped to data in the stream. When event data arrives, the fields’ values are updated. These fields are typed in the same way as scenario variables.

Output feeds – an output feed is a stream of output data that can be generated by the block. Each output feed corresponds to an event that can be generated by the block, and embeds one or more output fields. The fields are updated as a result of operations carried out by the block. These fields are typed in the same way as scenario variables.

Parameters – a block can have a number of parameters, which, when set, configure its behavior. Parameters differ from input fields, in that the latter are like work packages for the block to process. Typically, you use parameters to initialize the block or change its core behavior. Parameters are typed in the same way as scenario variables. Parameters are all provided at initialization time and can then be updated individually. Input fields are expected to change often and at any time.

Operations – in addition to any standard behavior that is hard-wired into it, a block can also have a number of explicit operations that can be invoked by the scenario. For example, typical operations are start and stop, which cause the block to begin processing events or to cease. If an operation requires any configuration information, this is usually passed in through a block parameter.

Apama provides a library of useful blocks, which can be viewed and selected from the Catalogs tab. For information about provided blocks, see Using Standard Blocks.

There is no restriction on the number of block instances that can be added to a scenario. The Blocks tab shows the blocks that have been added to a scenario. When you add a block to a scenario you are effectively specifying that instances of that scenario should create an instance of that block running within them. Whether the block instance then starts executing some activity immediately or waits for some operation on it to be called depends entirely on how the block itself was written.

It is possible to add multiple instances of the same block to a scenario. Each instance will have its operations, parameters and fields clearly tagged by its unique name to ensure there is no conflict.

If there is no standard block that meets your needs, you can create a custom block. There are several ways to do this:

Use the Apama Studio block editor to create a block by defining its parameters, operations, input feeds and output feeds.

Use the Apama Studio block editor to create a block from an event definition.

Save a scenario as a block. This lets you create composite scenarios when you use such blocks in other scenarios. However, you cannot save a scenario as a block if you mark that scenario as parallel. Nor can you save a non-parallel scenario as a block and then mark the block as parallel-aware. For details, see Working with Blocks Created from Scenarios.

For more information on the structure of a block and for instructions on how to create your own blocks, see Creating Blocks in Using Apama Studio.