It's been almost 18 months since the release of elemental_ux , and we haven't been resting....
elemental_log is our take on audit logging. Built to be super fast to log changes and even faster to integrate into your own solutions. In just a few minutes you can add a full JSON based audit trail to your solution that can track changes to whatever fields you want. We've also included an intuitive configuration tool for choosing what to log - no hard coding required.
Other Features include:
Fast - We've put a LOT of effort into making this as fast and scalable as we can, and we think the results are pretty awesome.
Easy - A lot of care has been put into building our simple and intuitive integration process. You can get up and running in just minutes.
JSON based - We love JSON and have used this as the basis of our logging framework.
Preparation is a breeze - we've built tools to help you prepare for logging, just click and you're done.
JSON to FileMaker - JSON is the starting point, but the real power is in our Populate tool to transform this into FileMaker records in an audit log.
Full Audit log viewer - We've included an easy to use audit log viewer to allow developers to find those changes they need.
Contextual viewer - this is cool! You can run this viewer from anywhere in your own solution to see all changes related to the records (and related records) on your layout - with no other work required!
Fully documented and supported
We're so happy with this and hope you will be too.
You can download a trial today at http://www.elemental-fm.com . This lets you see it in action to determine if it is right for you.
I'd love to test it but unfortunately it's FMP 19 only! Is there a need for this or can you release it for FMP 18 as well? My journey will stop with FMP18 because it's the last version that supports Runtimes.
Great news Daniel. We’ve tested a number of audit systems and have not been happy with any of them.
As an aside, we currently use Reactor. Thankfully still working in current versions. Is there a planned future for this or has current technology passed it by?
Andy, is FM AuditLog Pro 2.0 (by 1-more-thing) one of the implementations you tested? I am curious about this product and would like to hear more about it, more so if there is a lot of different offerings to consider.
@Bobino, FM AuditLog does ring a few bells, but I believe it was before v2.0 was released. It has been some time since and, at the time, we opted for the DataGuard plug-in, which is now long in the tooth.
We did investigate a number of audit solutions, including releases from well known developers such as NightWing and I believe we reported results to the original community, which are probably lost now.
Our main issue was that, as data size increased, the systems slowed down accordingly. If you are going to test, do make sure you have a representative data set.
hi @AndyHibbs Thanks for the comment. Hopefully this audit logging meets your needs In regards to Reactor, we did just do a final release of it a while back, but as you allude to, current tech has basically surpassed the need for it exclusively. It does still have it's merits though in that it makes it easy to bundle multiple required files into a single blackbox file for serving up in a web viewer, plus it has built in frameworks for FM/webviewer communications (something that made it pioneering back in the day).
We don't really have much intention of doing anything further with it at this stage.
audit logging systems (e.g. elemental_log and ultralog which is nightwings offering) will suffer over time from growth of the changelog data that sits on the records if this data is not properly cleared over time - that's an important part of the logging process. All too often people set them up and forget to to this part meaning yes any time a change is made, it is recorded on the record, and the size of the record grows over time.
Also, as the changelog field itself grows in size, time taken to append further changes can get slower. In testing we tried to get this impact down as low as possible, but it essentially comes down to how long it takes to append text to an ever increasing size of text - this is a FileMaker limitation at a certain point.
elemental_log does use a JSON based changelog on records but the entire point of it is that we encourage people to clear this periodically and populate an audit log table, essentially transferring the JSON into record data, this process then clears the JSON logs on records keeping overall record size low and logging fast. In elemental_log this can be set up as a scripted process on server, which you might run nightly for example.
Other factors affecting the log size is the size of the fields you are tracking for changes (e.g. if you're tracking a field of 100 paragraphs which is regularly changing, it will track the entire contents for each change..) OR if you are tracking hundreds or thousands of fields in a single table. This is less of an impact but depends on how frequently those fields are being modified.
