System messaging

System messaging is used for communication between modules. Thanks to the messaging the modules are loosely coupled.

• Hierarchical vs. Loosely coupled modules
  • Module Extension
  • Loosely coupled modules
• When use the system messages
  • Sender – Reviver is a dynamical connection
• When not to use messaging system
• Pre-defined system messages
  • Time based events:
  • Event-based events

AyMINE server uses internal messaging system for loosely coupled connection between modules.

Hierarchical vs. Loosely coupled modules

AyMINE supports several ways how modules could be integrated:

Module Extension

The strongest relation is an extension. B extends A means that B directly uses functionality of A and the UI from B is integrated into the UI of A.

Almost all modules extend framework basic module. Almost all add new UI modules to the major application dashboard.

Several modules build up its data logic on the tsk module. tskAbstractArea is used as a basic abstract class for all collectors of the business objects. It was developed as an abstract object and published for other modules as well.

tskAbstractArea has descendants (e.g. crmAddressbook from the CRM module) and server object implementation is based on the tskAbstractArea object implementation.

Loosely coupled modules

Loosely coupled modules could work independently but when both are loaded and available for a client, they interact together.

Loosely coupled modules never used direct object hierarchy. However, they can use object UI extension on the application level. Module B could propose extension for UI from A. When both B a A are enabled for user, UI is integrated, however if user has only B and not A, B extension of the A is not applied and not available.

Example of the loosely coupled modules are modules TSK and FI:

• TSK implements project management that could operate without finance management
• FI implements finance management that is designed universally and could be integrated by any other module.
• When both TSK and FI are available, finance management is integrated into the project management.

Loosely coupled modules are not hierarchical. Modules might support integration with any other module and so the integration of two or more modules could be implemented by both modules and so be more effectively implemented than if only single module support it.

When use the system messages

Server supports internal messaging system that allows generation of message about some event. The module and object that generates even does not bother about the receivers.

Each module register event listeners during the module installations. When a new message is raised, system finds all receivers that are registered for message acceptance and activates them.

Messages could also be used to get information from other module. However, if no listener is installed the caller gets back only information that there is no processor for the message.

Sender – Reviver is a dynamical connection

The processor is evaluated separately for each client and dynamically. Message that is raised in the client context could never be processed in the context of another client. Each client has optionally different cohort of active modules and some request for service could be implemented by module MC1 for client C1 and by module MC2 for client C2.

When event is raised it activates only receivers from modules that are active for the client. For C1 it would be MC1 but for C2 response comes from MC2. And if it would be CX client that has not appropriate module, event processing returns response that any processor was found.

When not to use messaging system

Messaging system is very effective solution for loosely coupled connections as well as for situations when various clients have different implementation of the service providers.

On the other hand, requesting data or call a method by a message is more than 100× slowly than just call the right method. The message is also more difficult to manage because it is much more complex to detect dependencies between methods and objects. Thus, don't use messages when both sender and receiver are from the same module. Both are managed by the same team and deployed together.

Also don't use message to call a service available by the object API from extended module. Published object API might even not be available for loosely coupled message-based interface. As mentioned earlier, object API is more than 100× more effective than messaging and keep application much more environment-friendly. And, BTW, it is under the static control (intelisense).

Pre-defined system messages

System supports several publicly available system events. They are generated by system and always available. Neither of them requests or process response:

Time based events:

• frm.time.Noon – activated close to the noon (never trust exactly the raise time!)
• frm.time.Midnight – close to the midnight
• frm.time.BOD – close to the morning; begin of the day (both working and non-working day)
• frm.time.EOD – end od day before evening
• frm.time.timeNightControl1 – 1st time gap for night controls and procedures. Exact time is not defiend and is managed by the system workload, It is processed single time each night between 10pm and 5am.
• frm.time.timeNightControl2 – 2nd time interval for night controls. Always processed after the 1st gap and between 0am and 6am

Recommendation: Use BOD / EOD events for scripts that could generate reminders or emails to the users. Midnight and night controls might disturb night!

Event-based events

There are few events that are generated automatically during the object manipulation:

• frm.objectDeleted – before some object will be deleted by user. Message is not generated systematically, when system deletes object within the business logic
• frm.objectUpdated – after the object update. Generated regularly also after the system-managed updates and always after the user object update
• frm.objectInserted – when user or system inserted the object