Database Reference
In-Depth Information
</playback-parameters>
</stream>
Surely, we should be aware of the events type we want to stream from the store
(the same cargoBooking as we recorded earlier); naturally, it should be the
same event provider with the same dataset.
4. Finally, some more fine-grained tuning of this event processing setup. In the
<stream> configuration presented previously, we will play all the recorded
event types from our event-type list (or all events if this list is omitted). In addi-
tion to this, for recorder and player, we can assign the time internals in which we
want to record and consequently replay the events using the <time-range>
group. In the following example, events will be recorded/replayed from 09:00 un-
til 18:00 on February 18:
<time-range>
<start>18-02-2014:09:00:00</start>
<end>18-02-2014:18:00:00</end>
</time-range>
Here, we have some differences between the recorder and player. This configura-
tion group is optional and can be omitted; however, without it, the player will
play all the recorded events, but the recorder will not record the events at all. To
record events, you will have to explicitly start the recording using the Visualizer
console or the command-line admin utility.
Alternatively (but not at the same time), you can define the duration of the record-
ing/playback as follows:
<time-range>
<start>18-02-2014:09:00:00</start>
<duration>09:00:00</duration>
</time-range>
As you can see, this definition is similar to the previous one.
For brevity, we will not discuss other parameters related to store policy, playback speed,
threads, event batching during the recording time, streaming parameters, and so on. We
will touch upon caching in a related session as it has a certain significance for SOA pat-
tern realization.
Search WWH ::




Custom Search