Extend Entity Framework workflows to allow handling both before and after save

[Danielku15]

Currently you have to decide whether you want to handle workflows before or after save. We are using the Audit events not only to simply persist them using a custom AuditDataProvider but we also use it as internal signaling mechanism that things have been changed and trigger actions based on it.

Now we have the use case that before saving we might want to use the information of Audit.net to react upon certain changes and additoinally modify things or trigger actions. e.g. handle some transitive changes.

And after the changes have been saved we want to persist the final done changes.

It would be great if we can simply tell Audit.net to signal our provider both before and after the save changes. Currently there is only SetEarlySavingAudit which allows you to choose whether you want to have it before or after saving.

We are currently trying to make an own interceptor replicating the default AuditSaveChangesInterceptor and DbContextHelper behavior but signaling at both times.

[thepirat000]

Actually, when you set EarlySavingAudit to true, the save operation will be triggered two times: before and after the changes are applied.

It depends on the data provider you are using, but the first time it will call the Insert/InsertAsync and the second will call Replace/ReplaceAsync on the data provider.

Also, you could use Custom Actions to act upon saving events, for example:

Audit.Core.Configuration.AddCustomAction(ActionType.OnScopeCreated, scope =>
{
});

Audit.Core.Configuration.AddCustomAction(ActionType.OnEventSaving, scope =>
{
});

Audit.Core.Configuration.AddCustomAction(ActionType.OnEventSaved, scope =>
{
});

[Danielku15]

This is a very interesting insight. Thanks a lot. I will try to dive into the custom actions and the possibility of utilizing Insert/Replace differently.

We currently have a custom DataProvider implementation which first translates the Audit.net models to custom ones and then "broadcasts" those to multiple listeners within the application to react upon certain changes. Some use cases:

• One is handling semantic client side cascade deletes. (needs to be before save to avoid DB level errors)
• One is handling semantic client side cascade updates. (currently is after save but we would like to have it before save)
• One is signaling the changes to a message broker for processing in other microservices (needs to be after save).