Introduction to Apama > Apama Concepts > Understanding scenarios and blocks
Understanding scenarios and blocks
A scenario is a real-time, business strategy, involving multi-stage event analysis and action response. You can construct an event-based application from a single scenario or from several cooperating scenarios. At any time, you can add scenarios to the correlator, modify scenarios in the correlator, or remove scenarios from the correlator. You use Event Modeler to define scenarios.
Apama Studio’s Event Modeler editor provides the ability for less technical users to quickly create Apama applications in a graphical modeling environment rather than writing event processing logic directly in EPL or Java.
Examples of complex operations that you can implement in scenarios:
*Spotting key events, such as events that are unusual or events that cross a threshold. For example, reporting when a stock price goes above the monthly peak.
*Performing analytics on events or collections of events, to generate derived data that you can analyze. For example, continuously generating a 5-minute moving average for Microsoft’s stock price.
*Comparing or correlating values from events over time to detect trends. For example, detecting when the stock price for GE is 10% above the 5-minute moving average.
*Combining time-ordered key events in business patterns that indicate a complex phenomenon has been detected or a business process has completed. For example, spotting that a particular news bulletin has caused Ford’s stock price to move by 5%.
*Taking relevant action in response to a detected pattern. For example, automatically buying or selling stock in response to detecting a favorable opportunity.
Each scenario is a template for the instantiation of scenario instances. A good metaphor from object-oriented design is that the scenario is like a class and the scenario instance is like an object; that is, it is an instantiation of the class. The scenario itself can be a generic template, without the need to define the specific values on which to operate. A scenario instance is the running application with all the specific variables and values having been instantiated on creation.
Each scenario has the following components:
*Smart blocks — also referred to as simply blocks. Blocks are useful, reusable, building-block components that generate and/or respond to events. Any scenario can make use of one or more standard or custom blocks. Event Modeler provides a panel for selecting a block you want to use in your scenario.
*Rules — Scenario rules are configurable, if-then statements that interact with smart blocks to create application-specific event logic. Rules specify operations to perform and determine when control transitions from one state to another.
*States — States let a scenario move through different stages, to be able to handle more complex logic. In each state, a set of blocks and rules are active. If a rule causes control to move to a new state then a new set of blocks and rules become active.
*Variables — Each scenario instance uses a set of variables that you specify. You can identify individual scenario variables as being input variables or output variables. To create a scenario instance, you typically need to provide values for a number of input variables. Output variables let you observe the state of the scenario instance.
After you define a scenario, you use Apama Studio or correlator utilities to inject the scenario into the correlator. Once the scenario is in the correlator, you can create instances of it. During development, to create, modify, and delete scenario instances, you can use Apama Studio’s Scenario Browser or the scenario’s associated dashboard. When a scenario is in production, you use the scenario’s dashboard.
Any number of scenario instances can exist at the same time in the correlator. Each instance performs work that is distinct from the work done by the other instances. For example, consider a scenario that specifies a financial trading strategy. Each time someone creates an instance of this scenario, that user can define the instrument to be traded and the criteria for performing the trade.
By default the correlator finishes processing an event for one scenario instance before it begins processing that event for another scenario instance. But you can specify that the correlator should process events for a given scenario's instances in parallel with the processing of events for other scenario instances. For many applications, enabling parallel processing for a scenario improves application performance.
See Overview of Using Event Modeler in Developing Apama Applications in Event Modeler.
Apama blocks are encapsulated elements of CEP logic that you can use in scenario rules. For example, a block might represent:
*A computationally-intensive calculation within an algorithmic trading application
*A complex event pattern to be sought
*The connectivity that integrates Apama with a market data feed.
Blocks make the incorporation of such operations accessible to, not just power-users and programmers, but also business users.
Apama provides a number of standard blocks and these are documented in Developing Apama Applications in Event Modeler, Using Standard Blocks. Apama Studio provides a tool for defining custom blocks. When defining your scenario, you can add one or more copies of one or more blocks to the scenario. After you add a block to a scenario, you can use the block’s parameters, input feeds, operations, and output feeds in the scenario’s rules. When you add a block to a scenario, you are effectively specifying that instances of that scenario should each create an instance of that block running within them.
A number of sample scenarios are available in the samples\scenarios directory of your Apama installation directory. Examining sample scenarios is a good way to learn typical scenario construction. In addition, all of Apama Studio’s sample Apama applications use scenarios, so they also provide good examples from which to learn.
Copyright © 2013 Software AG, Darmstadt, Germany and/or Software AG USA Inc., Reston, VA, USA, and/or Terracotta Inc., San Francisco, CA, USA, and/or Software AG (Canada) Inc., Cambridge, Ontario, Canada, and/or, Software AG (UK) Ltd., Derby, United Kingdom, and/or Software A.G. (Israel) Ltd., Or-Yehuda, Israel and/or their licensors.