com.prosyst.mprm.rule.time.sequence

Interface TimeSequence

All Superinterfaces:

Externalizable

All Known Subinterfaces:

TimeSequenceBE

All Known Implementing Classes:

CronSequence, FixedDelaySequence

public interface TimeSequence
extends Externalizable

Implementations of this interface can be used to define timer-based triggering of Rules. Objects of this type can be provided to the TimerTrigger#create(TimeSequence) method and created in this way trigger to be added into the Rule. The system provides two standard implementations of the TimeSequence interface:

CronSequence - this implementation uses a poplar approach for time scheduled fires via Cron expressions. FixedDelaySequence - this is implementation for periodic fires in a fixed-delay execution mode.
fixed-rate (CronSequence) vs. fixed-delay (FixedDelaySequence) execution modes:

In fixed-rate execution, each execution is scheduled relative to the scheduled start time. If an execution is delayed for any reason (such as temporary stopping of the mPRM or the system is too busy), two or more executions will occur in rapid succession to "catch up." Fixed-rate execution is appropriate for recurring activities that are sensitive to absolute time, such as ringing a chime every hour on the hour, or running scheduled maintenance every day at a particular time. Finally, fixed-rate execution is appropriate for scheduling multiple repeating timer tasks that must remain synchronized with respect to one another.

The opposite of fixed-rate is the fixed-delay execution. In fixed-delay execution, each execution is scheduled relative to the actual execution time of the previous execution. If an execution is delayed for any reason subsequent executions will be delayed as well.

Besides using the standard system-provided implementations, the system also allows custom implementations of TimeSequence to be provided by the users in order to define more specific timer-based Rule fires that are beyond the scope of the standard system-provided implementations. Custom implementations should take into account that

they must implement Externalizable, i.e., must make their objects transferable to the backend they must provide the implementation classes on the backend, i.e., java packages should exported on backend osgi framework (Export-Package bundle manifest header) it is recommended to provide text-representation of the time sequence definitions, so that custom definitions can participate in the textual representation/definition of Rules and Tasks. Handling of text representations can be done by a service - com.prosyst.mprm.backend.rules.spi.time.sequence.TimeSequenceProvider registered on the backend. The service should declare the same type as the type provided in getType() of the custom TimeSequence object.