A block’s lifecycle

1. You use Apama Studio to define a block. Apama Studio saves it as a Block Definition File (.bdf). This is an XML document, and it contains the interface of the block in XML elements as well as the EPL that defines the block’s functionality.

The EPL template for a block is the <code> section within the block’s .bdf file. This contains the actual implementation of the block, embedding the custom behavior that identifies the block.

2. A scenario is defined within Event Modeler. This scenario is made to import one or more instances of the block. The scenario is saved to disk in a Scenario Definition File (.sdf) which is also an XML document. This document contains a reference to the location of any imported blocks’ .bdf files. It does not embed the blocks themselves.

During this stage, the contents of the <code> section in the .bdf are read in and all EPL names that are tagged with # characters are replaced with unique names that distinguish this particular block instance from any other that the scenario imports. The modified block EPL is then added to the scenario’s EPL. Because certain elements of the EPL in the <code> section are renamed, this section of the code is often termed an EPL template.

3. The scenario and the referenced blocks are converted to an EPL file (.mon), either explicitly with File > Export > Apama > Export as EPL or implicitly when running the project from Apama Studio.

4. The EPL containing the combined scenario and block code described in Step 3 is injected into, and parsed by the correlator. Note that if the EPL supplied in the .bdf file is invalid, the correlator will reject the scenario at this stage. However, if the EPL is valid but does not correctly implement the block’s interface, it will still inject successfully. This situation cannot be detected until the scenario does not function as expected.

5. At this point the EPL for the scenario and its embedded block(s) is now in the correlator. This means that actual instances of the scenario can be created by end users. Assume that a dashboard has been created with Dashboard Builder to go with the scenario, and that end users can therefore interact with the scenario through the Dashboard Viewer. When a user logs into the scenario’s application and creates an instance (sometimes referred to as a strategy), the correlator will create a specific working instance of the scenario and of its embedded block(s). Each instance is unique and distinct. Therefore, if the scenario embedded two blocks (or even two copies of the same block), and three instances of it are created from a dashboard, there will then be three instances of the scenario and six block instances.

Therefore, when you add a block to a scenario in Event Modeler, you are effectively specifying that real instances of that scenario should each create an instance of that block running within them. Whether the block instance then starts executing some activity immediately or else 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 in Event Modeler. Since their operations, parameters and fields are clearly specified by their enclosing block instance’s name when invoked from the scenario there is no conflict at runtime. There is no restriction on the number of block instances that can be added to a scenario.