SOA and Event Management

• Module configuration filed
• Event definition
• Event handler definition
  • Manually started processors
• Event Processor attributes

AyMine internally support both object-calls from higher-level modules to lower-level modules as well as event management and services initiated by the event request.

The Event Management System manages both synchronous and asynchronous event management.

All modules has right to manage their events and provide handlers of the events.

Module configuration filed

Events and handlers are defined by the module configuration file, that is loaded to the system. Configuration file can be reloaded repeatedly so that permanent changes in the event management configuration are always defined in the configuration.

Temporary changes (mostly block some event or event hander) are managed by the UI available for the system administrators.

Event definition

Example of the definition from the CRM module:

"raisesEvents":{
  "crm.ExtMessage.processTypeAssigned":{
    "desc":"New process type assigned to the event that has author from CRM evidence"
  },
  "crm.time.checkAutoGroups":{
    "type":"timeStamp", 
    "timeStamp":["6:05:00", "11:42:00"],
    "desc":"Timer for 2-day update of the dynamic crm group" 
  },
  "crm.crmSubject.PreferencesChange":{
    "desc":"Event generated when external subject used page with preferences to updates its own settings"
  }
}

Each input line describes:

• Name of the event
• Type of the event. Default value is module-raised, Time-raised events and Interval-based events are generated automatically by the SOA engine according to the specified conditions
• timeStamp defines when events are raised
• env – Environments, in which event is defined. It allows using the same configuration file in several environment (typically DEV, TEST, PROD) and allow the event only in dev & test during the develoment.
• Description for documentation

Event handler definition

Example from the CRM module:
(Note that events handlers are still in the array, not an object):

// lower number->higher priority (other modules aka gutta uses higher priority)
"eventHandlers":[
  {
    "event":"sys.ExtMessage.new",
    "priority":20,
    "a":"server.crmEventHandler.newExtMessage", 
    "icon":"extMessage",
    "desc":"Process new incomming message"
  },
  {
    "event":"sys.ExtMessage.changeProcessType",
    "a":"server.crmSbjGroupPrcSet.changeProcessType", 
    "desc":"Process user operation - change of the message process type"
    "icon":"extMessage"
  },
  {
    "event":"frm.time.timeNightControl1",
    "a":"server.crmCrm.midnightSteps", 
    "icon":"objects__delete", 
    "desc":"Delete old obsolete objects", 
    "manStart":true
  },
]

Each event processor is described by attributes:

• Event – name of the event processed by handler
• a – Function started by event
• icon, desc – Both are for documentation and better organisation in the administrator UI
• env – Environment in which processor is used
• manStart – mark, that processor can be started manually from system console

Manually started processors

Event processors with manual start are used for back-end operations started by system administrator. Those that are intended only for occasional use can be initiated directly from the SOA management console.

The following example describes usage of the manStart. Function starts import receipts from Abra system. It is started automatically by the event abra.time.importReceipts but when necessary, the system administrator can also be start it manually.

{
  "event":"abra.time.importReceipts",
  "a":"server.abraPosdocument.bulkToAy(durDays=2)", 
  "icon":"document__sync", 
  "client":"gbr32"
  "env":"PROD", 
  "object":"fiReceipt", 
  "desc":"RECEIPTS - bulk import", 
  "manStart":true
}

Event Processor attributes

The previous example also demonstrates start command with attributes server.abraPosdocument.bulkToAy(durDays=2). Event is activated only for a single client (gbr32) with additional attribute.

The attributes are passed to the processor without any change. SOA Event processor does not used the attributes internally.
Events and the event processors definitions in the module configuration file can be currently client-independent (when client attribute is not in the list of attributes) or client-dependent. Field client supports both string and array, i.e.:

client:["clientB", "clientA"]

For client identification, strings always use internal-logical names.

On the other hand, events generated during the system operations are:

• client-independent only when activated by the non-client back end processes.
• client-dependent where activated in the client-related process (most common)