When events hit to Herogi engine, engine checks available scenarios to apply incoming events. Scenario is nothing more than set of rules.
Scenario is consisted of states and transitions so in technical terms it’s a state machine and can be represented using a graph diagram;
Any two states can connect each other with a transition. Transition is just combination of event and validations. So when an event hits to scenario, Herogi engine checks whether there’s a transition from latest state of the session with that specific event. If it finds a transition then checks for validation to run (if it’s available), if the validation succeeds then moves session to next state and run relevant actions in that state.
If there’s more than one transition with succeeded validations, Herogi engine picks first transition. In practice your scenario should be complete and only one transition should be valid at any time. This doesn’t necessarily mean you should always have one transition between any two states. On the contrary Herogi encourages you to have because it empowers you to have custom logics. Tricky point you shouldn’t have with succeeded validations.
Let’s try to understand example scenario we introduced in the beginning;
Initially all sessions/users are in start
state. It means no one exists in scenario.
Any event will trigger state change from start
to state 1
. Now sessionId
in the event saved as state 1
event1
with same sessionId
will trigger state change from state 1
to state 2
. Now sessionId
in the event saved as state 2
.
Tip: Different events or sessions will have no effect.
state 2
has two transitions, one to state3
with event2
and another one to state4
with event1
event2
with same sessionId
will trigger state change from state 2
to state 3
event1
with same sessionId
will trigger state change from state 2
to state 4
Tip: Different events or sessions will have no effect.
Once session arrives state 3
, it’ll exit the scenario because of the special end
state connected to it.
If session arrives state 4
, it’ll repeat itself for each coming event1
.
Each scenario has default built-in states called Start and End in addition to states created by you.
It’s default state. Any session/user is not in scenario yet, can be counted in Start state. All these sessions/users don’t have any record in scenario and their last state is none exist.
So you should think it as entry point to your scenario.
For example, from none to state1
with event1
defines how new sessions will be interacting your scenario initially. In this case event1
is your initial event for that scenario.
Tip: You can have multiple entry points for your scenario
It’s default state. Any session/user is about to leave scenario yet, can be counted in End state. All these sessions/users will be removed from scenario. Once session exited the scenario, it’ll be counted as in Start state and they will be eligible to apply scenario again.
Tip: All session data, aggregation records will be reset
So you should think it as exit point to your scenario.
For example, from state2
to none defines how existing sessions will be exiting scenario. In this case once a session/user arrives to state2
will go to end state and exit the scenario eventually.
Tip: You can have multiple entry points for your scenario
Scenario designing is really simple. Just go scenario page and select the scenario you want to design then click editor link on top.