Visa denna sidaEditera denna sidaLås denna sidaLänkar till denna sidaBilagor till denna sidaHistorik för denna sidaSwikins toppSenaste ändringarSök i SwikinHjälpguide

Subscription coding

Create event

When an event possible to subscribe to has occured, a new event should be created. E.g.
Q2ModifyCaseTxn>>postMaster
	super postMaster.
	self session addEvent: (Q2ModifiedCaseEvent for: case).
	self session addEvent: (Q2ModifiedRelatedCaseEvent for: case). 
The event created must know the object it has modified. For example a Q2CaseEvent modifes a Q2Case and a user event adds/modifies a user.
All events are added to the current session, and is collected at the end of the action where the events were generated. All actions initiated from the web UI is called through one of the methods in Q2Model's category "transactions". In these methods, the transaction(s) and the event(s) are created for a single user action. It is possible that one user action generates several transactions and events, but Gjallar must flush and process the session's event queue when everything generated from this action at the same time.
In Q2Model>>runEvents, a Q2NotificationRun is created and populated with the list of events. All notification runs are stored in a queue handled by the Q2NotificationRunService. This is queued to not hang the UI for too long time.

Handle events

At at configurable interval the queue is flushed and each notification run (with all its collected events) is handled. The events are iterated and for each event the subscriptions triggered by this event is collected. The triggered subscriptions are iterated and for this user a notification is created with information of the subscription and the triggering event. When iterating the events in this run, the same subscription could be triggered several times. In this case, all events will be collected in the same notification.

The user/notifications combination is stored in a Dictionary with the user as a key, and the notifications as value.
This dictionary is then iterated, and for each user either a mail is created (for non digesting users) or the notifications are stored for later digest.

Digesting user notifications

The service Q2NotificationDigestService is used for users digesting their notifiations. When the service is run, it asks the model to send the notifications for the users where the digest time has expired.
When it is time to digest, a mail is created for the collected notifications and queued to the service Q2NotificationsSenderService.

Sending notifications

In the Q2NotificationsSenderService each prepared mail is sent.

Uploaded Image:Notifications picture.pngSame picture with higher resolution