Remove report from operation interrupt behavior

[dbeuchler]

Background described in #736.

TODO:

• Remove Report during Interrupt, adjust all APIs (Facade, Manager, StateMachine,..)
• Replace report Dialog with MessageBox ("do you really want to interrupt?")
• Adjust Documentation and State-Charts

Discussion

• Do we still need the user during interrupt? Is there any value? @1nf0rmagician

Closes #736

[1nf0rmagician]

@dacky179, @slimberg91 correct me if I'm wrong, but have the user/operator that interrupts an operation is still a feature that is in active use. So yeah we still need it.

The idea was, however, to have a more granular config in future to define which operations require a user

[dbeuchler]

@dacky179, @slimberg91 correct me if I'm wrong, but have the user/operator that interrupts an operation is still a feature that is in active use. So yeah we still need it.

But only in combination with the report, correct? Since Interrupt will not raise a report anymore, the user is unused?

[slimberg91]

Well, I am not exactly sure. In a coarse research I haven't found a reference where our HYDRA module generally reacts to interrupt requests from the OrderManagement. Scenarios where interrupt is blocked due to a missing user seems to be blocked because of a report instead. Interrupt without previously partial report is not a good idea in our HYDRA-context, but still can be blocked by subscription to the interrupt request event.
So at least I am unsure if it is a restriction that is made by HYDRA or not. But I guess to remember (from behaviour of other machines) that HYDRA can block the beginning of an order without a signed in user (if configured so), but always allows the interrupt without a signed in user. Producing without signed in users does also work, but may lead to unwanted behaviour and results in HYDRA itself, but is currently accepted.

@dacky179: Anything I missed here?
@chaostrichter: What is your HYDRA-perspective here? Is it correct what I told? 🙂

So in short conclusion I would say @dbeuchler is right here. ✔️

And watch out: Partial reports should only be made while producing, not when being interrupted, but this is also restricted by our HYDRA modules, I guess. ⚠️

[dacky179]

The interrupt during OperationState Running does not need a Report dialog.
The interrupt during AmountReached should have a report dialog since it triggers interrupt in hydra and the remainnig unreported parts must be reported before.
@andreniggemann: please explain the problem with interrupt (the case that it has another behavior than a report that causes problems for us) maybe its a good point to change that behavior for us.

[slimberg91]

Thats the point where I would say it would be possible for us to add an interrupt restriction telling the user "you should perform a partial report before interrupting the operation". This would resolve the issue, but yes, then there is the possibility to interrupt without reporting the parts. I think a solution would be to make our restriction configurable as a warning or to block the interrupt. But this mustn't be a problem of the ordermanagement itself. And of course, the report button still exists, which is only an additional click event for the user.

[dbeuchler]

Thanks for all the infos. Summary

• Interrupt API will contain the user but no report anymore
• The interrupt dialog will be replaced by a simple message box which asks for interruption
• MORYX 10.x: Add new dialog for interrupt with user selection

[dbeuchler]

@1nf0rmagician help wanted for the ui-part here. Server and APIs are ready

[andreniggemann]

@dacky179 there are problems with our current handling of the hydra MES-System.
The problem comes down to the fact that the MES-System has configurable rules and we made the design decision to not try and replicate all there rules locally (and some we couldn't replicate completely without a bad user experience.

Additionally there can be timing dependent behavior, because tasks that can stop us from interrupting or closing an order can be generated anytime.

Currently there are three ways we can handle interrupting in the MES-System:

Before the interrupt get's to the OrderManagement

This is what we do with reports currently and what we did in the old version of the Framework for instance.
The problem here is that there can be rules in the Ordermanagement that prevent an interrupt (User requirements for instance).
Then this leaves us in a state where the OrderManagement regards the Operation as still running while it is already interrupted in MES. An additional problem is the fact that it is hard to intercept all request to the OrderManagement Facade. Historically we did that by creating a separate WCF endpoint which worked for most use cases, but there were some edge cases where interrupts where initiated by other modules and not the UI.

Handling the Interrupt/Report Requested events.

There are a few problems here to. The event handling is synchronous. This means we have to block the thread while doing our long running communication with hydra. Additionally there can be other events and rules blocking the request, which means we would land in the same spot. An interrupted order in MES and a running operation in the OrderManagement.

Handling the Interrupted event

This is the case we really wanted to avoid. Having the interrupt succeed in the OrderManagement and that failing in our report to MES, because of some rule we did not replicate locally.

I am honestly not really sure how to improve this. I guess my favorite way would be to split the Ordermanagement up.
I know I have talked to @1nf0rmagician about this before, but it's certainly not feasible for MORYX 10.
But in my rough idea there would be a MES-Facade interface that is used for reporting and that is asked for beginning and interrupting. There could be a "local" Moryx MES implementation that works as the current OrderManagement or you could replace it completely with a Hydra MES or any other MES System you like. Than the only reporting rules enforced would be those of the MES System and we would not have any conflicts anymore.

[dbeuchler]

As @andreniggemann already explained very well, I also believe that we cannot deliver a truly generic order-management solution and simply extend it with plugins or adapters. We have tried this approach for several years, and it has proven impossible to address every limitation or constraint imposed by the super-systems (in your case HYDRA).

@dacky179 @slimberg91 @andreniggemann

It may be time for you to implement a custom order-management solution that leverages general APIs but introduces tailored operations and state handling. This approach offers several advantages:

• By reducing complexity and avoiding abstraction layers, you can create a solution that is easier to maintain and less prone to integration issues.
• Custom implementations can optimize for the exact data flows and processes of the super-system, eliminating unnecessary overhead.
• You can still reuse proven components from Moryx.Orders, ensuring consistency and reducing development effort.
• A custom solution allows you to define precise responsibilities for order handling, state transitions, and MES integration without being constrained by a one-size-fits-all model.
• As requirements evolve, a custom implementation provides more flexibility for targeted enhancements without breaking generic assumptions.
• General module implementation provided by Moryx.Orders.Management