Question

Mendix Business Events - Suitable to implement fat events or only thin?

0

Hi there, We’ve started implementing events with the Mendix Business Events services, available since Mendix 9.18 (I think). Currently we’re using 9.24. From a perspective of decoupling apps, I’m in favor of fat event, events holding all the data necessary for the consumer to properly receive (and process) the event. Without the need to do a callback to the app that published the event. The Mendix Business Events can only contain a flat object, as is confirmed in the FAQ on Business Events (https://docs.mendix.com/appstore/modules/business-events/#8-frequently-asked-questions) Can I send related or associated objects as a single business event? No, only a flat object. For complex data structures, provide an API where the consuming app can retrieve the complex structure upon retrieval of a Business Event. Alternatively, you can use a string attribute in the Business Event to store JSON or XML using mappings. This leaves me with the question if Mendix Business Events are suitable for fat events or not. Interested to hear opinions on this ...

asked 2023-05-02

Toon Verschoor

2 answers

Andrej Koelewijn · Answer 1 · 2023-05-02

Hi Toon,

The main purpose of Business Events is to provide notifications of interesting events in other apps, to be used in combination with APIs.

Currently, when you have multiple apps connected through APIs, and realtime processing is crucial, you either:
* need to poll frequently for changes (introduces delays, and high overhead on the service),
* implement webhooks including retry mechanisms (complex to build),
* or have a tight coupling between service and clients where the service calls the relevant clients.

Business Events allows you to build apps that respond in near real-time to other apps in an easier and more decoupled way.

With fat events you need to consider security: who might receive this event in the future, and what data can i include in the fat event that doesn’t risk security? A thin event only provides a notification of the event, and an id of the relevant object. Any details can be retrieved securely using the id through an API (either REST or OData).

If you want to build fat events, the option is to mapping the objects into a json structure with export mappings, and place the resulting json payload in a string attribute of the business events. Due to the security considerations, and the strict ordering requirements on event processing we advice to use thin notication events.

Feel free to contact me (andrej.koelewijn at mendix.com) to discuss details.

Toon Verschoor · Answer 2 · 2023-05-02

He Andrej,

Thanks for the answer! It’s great to understand Mendix’ ideas behind the implementation of Business Events.

My main point of concern is the asynchronous processing of the events and the possibility that introduces to retrieve the wrong state via the API. Assuming events are processed sequentially, which is true in our case, here is the challenge. If the subscribed app takes some time processing an event, it is possible that the publishing app has fired mulltiple events already, which are queued at the consumer app. The moment the subscribing app picks up the next event, the state of the data in the publishing app could have been changed multiple times already. The subscribing app is picking up the current state of the data and is doing that for every queued event. This results in one interesting change and a serie of non changes.

The result is that it is not possible for the subscribing app to receive all the separate changes.

If that’s not important for the receiving app, that’s not a problem. If there is no change, nothing needs to be done. But if the subscribing app needs to be aware of all the changes, it is a problem.

What do you think? Is this a corner case or is this a legitimate concern?

Discussing this with myself in my head: I can imagine that, if it is important to be aware of every change, you should model for that and capture every change explicitly – in a change log or something. And that, normally, changes can be stacked and processed as one change instead of multiple smaller ones.