Úvod
- úvod - kratší recap toho o co jde a jak to funguje, detailnější úvod k jedn. entitám bude asi až později
Text níže vypadá celkem dobře. Hlavní myšlenky asi mohou zůstat.
Scenarios are the most interesting part of the computation. It is where the business logic is evaluated, where the most value is created.
Scenario is a stateful stream-processing program. It consumes one or more Runtime topics and processes them with the built-in logic. It’s important the logic can be stateful - state is created and maintained during the computation if needed. It is also important the computation is stream-processing, i.e. the computation has no end. It runs continuously, there is no end and no result. The results - side effects - are generated on the fly continuously. When a message arrives to the system, it is processed by the Normalizer, and consumed by a Scenario with minimal delay. Any side effects the message generates are handled immediately.
Scenarios are not bundled with ALTWORX, the are loaded from the Scenario artifacts. The artifacts
are located in the deployment in ENV/scenarios/, they are *.tar.gz files. The artifacts are
provided to you by ALTWORX and contains scenarios you have access to. There may be just one or
multiple artifacts.
Scenarios always consume Runtime topics. They cannot consume RAW and at the moment also Error and
Jitter topics. However, Runtime topics don’t have to consist of only events, you can use Runtime
topics for any other input the Scenario requires. For example, you can have a Runtime topic with
configuration. Configuration can also be provided statically, it is the only case when Scenario
consumes something that is not a topic. This configuration is, however, more of a static
customization of the program, it’s not an input per se. The static confirmation is located in the
deployment in ENV/scenario_config/, details depend on the specific Scenario. It is typically used
to customize a Scenario between different ENVs or projects.
The result of a Scenario are side effects. Because the computation has no end there is no result, so to speak. The result in this case are side effects generated during the computation. Side effect can be generated at any time, even where no messages arrive. Side effects can be of different types, the most typical are updating Reality Network and sending a notification. The scenarios must not perform any side effects directly, they have to use an API of the system to register side effects, which are later automatically carried out. This has the advantage that the system is in full control of the side effects, and can e.g. turn them off or store them so they can be inspected later.
Scenario is only the program, not the execution. When you want to start a Scenario with specific configuration on a specific data, you create a Run. Run is the specific execution of a Scenario, there can be multiple Runs at the same time, even of the same Scenario. While Scenarios are loaded from the Scenario artifact, Runs are created by users on the fly. You can learn how to start a run in the following chapters.
A example of Scenario/Run lifecyle is as follows.
- Start a new Run. When you want to execute a Scenario and start processing messages.
- Stop the Run. When you want to (temporarily) stop the run. Stopped Run will not process any messages.
- Continue the Run. When you want to resume stopped run from where it finished.
- Stop the Run.
- Revert the Run. When you want to get rid of the changes the Run did in Reality Network. All changes will be reverted.
- Delete the Run. When you want to delete the run. The side effects are not reverted, you must do so explicitly. External side effects (e.g. notifications) are non-reversible.