Events generated by the framework modules

• System event behaviour
• Framework events
  • Time manager events
  • Time-stamp based events
• General operations linked with object change
  • Object insert - AFTER
  • Object update - AFTER
  • Object delete - BEFORE
  • Object delete - AFTER
• System events
  • User status changed
  • User is going to be deleted
  • User delete

AyMINE SOA framework provides set of time-based events that simplify regular back-end functionality.

The events are available to all modules and all clients. Neither handler could block other handlers on this events.

The events are intended for basic back-end management and process control. For more complex tasks, modules shall define their own events including events starter by the time stamps.

System event behaviour

• All time-based events are never stored in the queue. They are generated and processed immediately
• Events are raised out of client-context. Processors should manage client processing internally.

Framework events

Time manager events

Time events are always processed without user and client session settings

When some time interval fails do to system stop, new event is sent as soon as possible but always only once event when more interval passed

Periodical events

• frm.time.timeNew no attributes, Raises periodically according to the crone limit (usually 2 minutes in the production environment)
• frm.time.timeQH - every 15 minutes
• frm.time.timeHour - every hour
• frm.time.time47min - every 47 minutes

Notes:

• Exact time of the start is not predictable. Interval is restarted when SOA server restarts. They are not intended for exact process management
• When system is stopped events are never started backward. Processes cannot trust that the event occurs.

Time-stamp based events

• frm.time.Noon - 12:02
• frm.time.Midnight - 00:02
• frm.time.earlyMorning - 05:30, Begin of the Day
• frm.time.earlyAfternoon - 13:12, Early after the lunchtime - last chance to send something to the day-time-workers
• frm.time.BOD - 07:00, Begin of the Day
• frm.time.EOD - 18:00, End of the Day
• frm.time.timeNightControl21 - 21:21
• frm.time.timeNightControl22 - 22:22
• frm.time.timeNightControl23 - 23:23
• frm.time.timeNightControl1 - 01:00
• frm.time.timeNightControl2 - 02:00
• frm.time.timeNightControl3 - 03:00
• frm.time.timeNightControl4 - 04:00
• frm.time.timeNightControl5 - 05:00

Notes:

• Remember, that events are not raised in the exact time. Their time might alter according to the regular interval defined by the cron settings (usually 2 minutes).
• If the system is stopped for a long time, periodical events might not be raised. If system stops for less then 1 hour they are raised postponed. That means they are almost guaranteed but always guaranteed. In practice:
• Short breaks like periodical restart does not affect the events.
• They are raised if there is only single-server environment and the SOA server is stopped during maintenance.

General operations linked with object change

Object insert - AFTER

frm.objectInserted @event-objectName, @event-objectID

Event raised after save new object to the system permanent storage. Rasied both for objects saved by user and objects internally created by back-end functions.

Only object name and ID is in the event attributes. Handler shall request for details about the object and the request rights is a subject of object-right-access controls.

Event is processes asynchronously in an independent process.

Object update - AFTER

frm.objectUpdate @event-objectName, @event-objectID

Event raised AFTER sucesfull update, new values are already in database. However, changed (old) attributes from are part of the event messages. Raised for all updates managed by user. For updates processed by back-end processes event is raised only if the process raises it (not automatically).

When and how is the event raised

• Event is raised for objects deleted to the trash asynchronously so that they do not block delete operation.
• For objects deleted without using trash, event is raised synchronously so that is it processed before object disappear.
• For object that is in the trash and permanently deleted, event is not raised; it was already raised when deleted to the trash. So that is it not raised twice.

Object delete - BEFORE

frm.objectToDelete @event-objectName, @event-objectID

Event is raised BEFORE user deletes object. Internally raised for objects deleted by regular framework operations or by user.
The handler has not possibility to block deleting the object, but it can read and process information about object before it is deleted.

Object delete - AFTER

frm.objectDeleted @event-objectName, @event-objectID

Event raised after the object delete. Handlers can manage subsidiary deletes or propagate delete to other systems. Since object is already delete in the time when handler is processed, handler has only information from the event parameters (object name, object id).

System events

The following events are raised in reaction to the system module operations

New user

• sys.newUser @sysUserID @sysClientID

When new user inserted regardless if his account has been actiated or not

User status changed

sys.userChangeStatus @event-sysUserID @event-sysClientID @status

When status of the system user is changed. Called asynchronously after the status change. It is not raised when user is deleted to the trash.

User is going to be deleted

sys.userDelete @event-sysUserID @event-sysClientID

When user is going to be deleted to the trash.

Event is raised before delete synchronously and the processor can block the account delete. The block can be used if there is critical dependence related with user account.

Event is not raised when user account from trash is permanently deleted or forgotten according to the GDPR rules.

User delete

sys.userDeleted @event-sysUserID @event-sysClientID

Raises when user account was permanently deleted (from trash). Called after the delete.