Isolated events

With Business Central 2022 wave 1, a new setting for event publishers was introduced. Until this version, any error in any event subscriber caused interruption to the current running process and stopped the whole activity. In some cases (such as log-in), this is definitely unintended.

For this reason, Microsoft introduced Isolated Event Publishers. These events work the same as Codeunit.Run(..) – each call is executed in its own transaction, all errors are trapped, and only the event subscriber that caused the error is rollbacked.

To define a publisher as an Isolated Event, a new optional parameter was added to the publisher definition (see the image below).

Example

Let’s start with creating a new event publisher (nonIsolated – the third parameter in IntegrationEvent() is set to FALSE).

    internal procedure RaiseIsolatedEvent()
    begin
        OnSomething();
    end;

    [IntegrationEvent(false, false, false)]
    local procedure OnSomething()
    begin
    end;

And also create two event subscribers for our event.

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"TST W1 Isolated Events", 'OnSomething', '', false, false)]
    local procedure FirstSubscriber()
    begin
        Message('Calling the first subscriber.');

        if true then
            Error('Error in the first subscriber.');
        Message('End of the first subscriber.');
    end;

    [EventSubscriber(ObjectType::Codeunit, Codeunit::"TST W1 Isolated Events", 'OnSomething', '', false, false)]
    local procedure SecondSubscriber()
    begin
        Message('Calling the second subscriber;');
        if true then
            Error('Error in the second subscriber.');
        Message('End of the second subscriber.');
    end;

If you raise the event, only one of the subscribers is called – one message followed by an error message is shown.

Now let’s change the third parameter of IntegrationEvent(..) to true (to define the event as Isolated).

    [IntegrationEvent(false, false, true)]
    local procedure OnSomething()
    begin
    end;

If you raise the event once again, the behaviour is entirely different. Two messages without any error are shown, meaning no interruption to any running processing!

Conclusion

This new configuration for event publishers is an excellent way to manage external integration better. As a developer of an ISV solution or any solution extended by a third-party company, you may want to manage whether extensions can interrupt your processes (or define only specific events where error can happen).

Even more, with the combination of ClearLastError() and GetLastErrorText(), you can manage the errors in your processes much more easily – just clear the error before the event is called and check whether any error happened after all subscribers finished.

On the other hand, it also adds more complexity to the design of your solution. You should not make all your events Isolated (to be more specific, you should make the event Isolated ONLY if you really know the impact of this change), as after that, extending the application can not stop code from the executing!