You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/migrations/6.4.0_6.5.0.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,10 @@ Instead of always sending all notifications, it only enables the ones with a rel
32
32
33
33
Make sure you have all the necessary sections present in the configuration file before upgrading.
34
34
35
+
### Custom backends for `mod_event_pusher`
36
+
37
+
If you have a custom backend implemented for `mod_event_pusher`, you need to update it to handle the `push_event` hook instead of implementing the `mod_event_pusher` behaviour (which no longer exists).
38
+
35
39
### Deprecation
36
40
37
41
MSSQL backend is deprecated and will be removed in the next release.
Copy file name to clipboardExpand all lines: doc/modules/mod_event_pusher.md
+32-10Lines changed: 32 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,10 @@
1
1
## Module Description
2
2
3
-
This module is a generic interface for event-pushing backends.
4
-
It defines a single callback, `push_event/2` that forwards the event to all registered backends.
5
-
Each backend decides how and if to handle the event in its `push_event/2` implementation.
6
-
3
+
This module is a generic interface for pushing **events** to the configured **backends**.
4
+
The events include presence updates and incoming/outgoing messages.
7
5
Currently supported backends include [http], [push], [rabbit] and [sns].
8
6
Refer to their specific documentation to learn more about their functions and configuration options.
9
7
10
-
### How it works
11
-
12
-
The events are standardized as records that can be found in the `mod_event_pusher_events.hrl` file.
13
-
Common events like user presence changes (offline and online), chat and groupchat messages (incoming
14
-
and outgoing) are already handled in the `mod_event_pusher_hook_translator` module, which is a proxy between various hooks and the `push_event/2` handler.
15
-
16
8
!!! Warning
17
9
This module does not support [dynamic domains](../configuration/general.md#generalhost_types).
18
10
@@ -46,6 +38,36 @@ The `[modules.mod_event_pusher]` section itself is omitted - this is allowed in
46
38
[modules.mod_event_pusher.rabbit]
47
39
```
48
40
41
+
## How it works
42
+
43
+
The events are standardized as records that can be found in the `mod_event_pusher_events.hrl` file.
44
+
Common events like user presence changes (offline and online), chat and groupchat messages (incoming and outgoing) are handled in the `mod_event_pusher_hook_translator` module.
45
+
Each event has a corresponding [hook](../developers-guide/Hooks-and-handlers.md), e.g. `user_send_message` is run when a user sends a message.
46
+
`mod_event_pusher_hook_translator` has a handler function for each supported hook.
47
+
48
+
Handling an event includes the following steps:
49
+
50
+
1. The event hook is executed, and the corresponding handler function in `mod_event_pusher_hook_translator` is called.
51
+
1. The handler function calls `mod_event_pusher:push_event(Acc, Event)`.
52
+
1.`mod_event_pusher:push_event/2` runs another hook called `push_event`.
53
+
1. All configured backend modules have handlers for the `push_event` hook, and all these handlers are called.
54
+
55
+
### Custom event processing
56
+
57
+
By implementing your own module handling the `push_event` hook, you can:
58
+
59
+
- Push the events to a new service, such as a message queue or a database.
60
+
- Filter the events by returning `{ok, ...}` to keep an event, or `{stop, ...}` to drop it.
61
+
- Add a map with **metadata** to the events. The keys need to be atoms, and the values need to be atoms, binaries or numbers.
62
+
63
+
There is an example [mod_event_pusher_filter.erl](https://github.com/esl/MongooseIM/blob/master/big_tests/tests/mod_event_pusher_filter.erl) module, demonstrating how to filter the events and append additional metadata.
64
+
65
+
!!! Note
66
+
Execution order of handlers depends on their priorities. In particular, filtering events or adding metadata needs to happend before pushing notifications to external services. The example handler has the priority value of 10, while backends have the priority of 50.
67
+
68
+
!!! Warning
69
+
Currently only the [rabbit](mod_event_pusher_rabbit.md#additional-metadata) backend supports adding metadata to the published notifications.
Copy file name to clipboardExpand all lines: doc/modules/mod_event_pusher_rabbit.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -185,6 +185,10 @@ and for "received" events:
185
185
}
186
186
```
187
187
188
+
## Additional metadata
189
+
190
+
If you decide to [customize the events](mod_event_pusher.md#event-customization) with additional metadata, the additional key-value pairs will be added directly to the JSON object. You can override existing properties, but it is counter-intuitive and thus not recommended.
191
+
188
192
## Metrics
189
193
190
194
The module provides some metrics related to RabbitMQ connections and messages
0 commit comments