thanks for the additional details! Just to make sure we’re not talking past each other:
- UI nodes allow humans to say “that machine is working on order X”
- machine twin has some validation logic that decides on the effect of these assignments (may decline them)
- ERP exporter (same as DB exporter) takes the machine’s decisions and updates external system
From the UI perspective the user wants some feedback, so once the machine “answers” you want to show the response. As long as the machine doesn’t answer, the user won’t get a response (no matter how you do it).
Finding out whether the machine can currently answer is the same as making a request, so adding another mechanism doesn’t really change the situation: even if the pre-flight check came back okay, the real request may still not work due to some network issue. My recommendation therefore is to send the assignment event in any case, transition the UI into a “pending” state and perhaps allow the user to send a cancellation event to get out of that state. Technically speaking, once the network works again, both events (assignment and cancellation) will very likely be sent to the machine together, so they will be processed one right after the other.
From the machine’s perspective, you just need to code your validation logic, which will observe all assignment requests from UI nodes and emit confirmation or rejection events accordingly. The ERP exporter then books the confirmations into the external system.
In general, the idea of Actyx is that you never check whether something else is reachable before doing what you locally decided is the right thing to do. You record your decisions and let others react to them once they receive the information.