Fix ValidateHealthState null issue by correcting facade lifecycle and base class integration

[robertsmns]

Description
In OrderManagement, the OrderManagementFacade exposed ValidateHealthState as null during early calls from external endpoints (e.g., Factory Monitor) that resolve the facade via its interface before the facade is activated. This leads to a NullReferenceException on the first method invocation.
As a precedent, the ProcessEngine’s ModuleController activates its facades first, preventing this issue; OrderManagement behaved differently.

Already changed

• Updated the facade to inherit correctly from FacadeBase.
• Removed the redundant ValidateHealthState property.
• Converted Activate() and Deactivate() to proper overrides and added the required base calls.

What still needs to be done

• How should the activation order be handled in the module controller?
• Should the OrderManagement facade follow the same activation pattern as the ProcessEngine?

[dbeuchler]

Some things which are important here:

• A facade does not necessarily have to derive from FacadeBase. This is by design. It is good to inherit from the base class if the facade needs the life-cycle event. The API itself should never inherit from any facade interface.
• In your change call base.Activate at the beginning and base.Deactivate at the end. This is always a good option to use unless otherwise required.
• In general it is better to register to events on Activated because before it can happen that events are fired from the facade and the module is not finally started (problems like Publish notification events only after facade was fully activated #678 may arise). Unregister from events at OnDeactivate as the earliest point.

Answer to your questions:

How should the activation order be handled in the module controller?

This depends highly on the implementation. Maybe we could analyze the usages and find a more general solution or better automatism in MORYX 12. We also thought about Facade-proxies which provides the ValidateHealthState before each call to the facade.

Should the OrderManagement facade follow the same activation pattern as the ProcessEngine?

As I said before. This depends on the implementation. This must be analyzed. The ProcessEngine-facades register the events on activate and then start the internal components. This will raise events from the facade during the start process. I don't know if this has side-effects until now. I remember the NotificationSource-facade was activated very early to publish notifications during the start process. This was more or less an issue that the NotificationPublisher was not getting the actual state from the facade when it was activated.

---

• Yes it would be fine to have a general starting behavior in all modules (maybe automatic)
• This cannot simply be changed, we have to analyze dependent modules (especially when they are optional-dependencies)
• Maybe we could enhance the behavior with the NullRef by setting the delegate earlier