Best Practice for Retrieving Original Object Before Save

0
Hi all,   I have a use case where I want to log all changes made to a specific object. I’m aware of the Audit Trail module, but it doesn’t quite fit my requirements, so I’m implementing a custom solution.   My idea is to use a microflow when the user presses Save. Before saving the updated object, I retrieve the current version from the database and pass both the old and new versions to another microflow that compares them and returns a nicely formatted string with all the changes.   Here’s the issue: I initially tried retrieving the original object using the Name attribute, but since users can change this value, I can’t reliably find the old version if the name has been modified. I was hoping to use the internal Mendix object ID to retrieve the original, but I’ve read that using the system-generated ID is discouraged. So my question is:   Is there a smarter or recommended way to retrieve the original object before saving? Would love to hear how others have tackled this!   Thanks in advance!
asked
2 answers
0

Hi Sebastiaan,

 

If by "using the internal Mendix object ID" you mean retrieving an object like this, then that is perfectly fine.

image.png

Using the internal ID as an external identifier is discouraged, so for reference by external systems by publishing the id through a published rest service for example. The reason is that, theoretically, Mendix could decide to renumber the ids at any time without prior notice. Mendix has been warning for this for years, but in practice this never happened.

answered
0

Hey Sebastiaan ;) 

 

The Audit Trail module is still the right solution from my perspective. It's actually a dedicated module for your described use-case. From my perspective the module has multiple advantages:

 

1. Speed and Reduced Development Cost 🚀

 

Your custom solution requires you to design, build, test, and debug the entire logging logic. The Audit Trail module provides this functionality out-of-the-box.

  • Your Custom Build: You need to handle retrieving old/new values, formatting strings, creating log objects, and managing the commit process.

  • Audit Trail Module: You install it, configure which entities and attributes to monitor from a simple UI, and it starts working immediately. The development effort is measured in minutes, not hours or days.

 

2. Robustness and Reliability (It Handles the Edge Cases) ✅

 

A simple comparison works for basic attributes, but a robust audit log needs to handle much more. The Audit Trail module has been developed and refined over years to handle complexities you might not have considered yet:

  • All Data Types: Correctly logging changes for decimals, booleans, enumerations, and dates.

  • Associations: Logging when an object is linked or unlinked from another (e.g., a Ticket is assigned to a different User). This is very complex to implement manually.

  • File Documents: Tracking changes to files.

  • Deletion: Your current plan only covers updates (Save), but a full audit log must also capture Create and Delete events, which the module does automatically.

  • Transaction Integrity: The module is built to ensure that log entries are created correctly within the transaction and rolled back if the main object commit fails.

 

3. Long-Term Maintainability and Future-Proofing ⚙️

 

When you create a custom solution, you own its maintenance forever.

  • Team Knowledge: A standard module is easy for any Mendix developer to understand and work with. A custom solution requires documentation and training for new team members. If the original developer leaves, it can become "technical debt."

 

4. Rich, Pre-Built Feature Set

 

The module isn't just a logging engine; it's a complete solution that includes UI components to easily view the history, which you would otherwise have to build yourself. This allows you to quickly see who changed what, and when, directly in your application.

 

To put it even simpler, you will be basing your work on the principle of reusability 

 

image.png

answered