I am exploring temporal and it’s rich cross signalling and workflow-id concept for handling network activation and the model that was chosen higher up results in multiple objects that related to each other resulting in some synchronisation issues. In some cases there will be two invocations and the second might need / have to wait for the first, but the order of this is not defined.
I was looking at signals to subscribe to the other workflow (if it was first and complete that can be caught with a simple activity up front) and then be notified when it had moved to a particular state releasing the second.
Use SignalWithStart to signal a workflow creating it if is not yet started.
I noted that, but the issue here is the flow that would set the StartWithSignal, would not have the information required to successfully start the workflow. it is important (and modelled) that the external caller sees two seperate identities.
Hence the limbo I’m in… Any idea’s?
Put succinctly I’m composing intent based on relationships, but each item is still unique and will have invocations seperate from each other. The single product occurs much much higher and beyond the view of this system, so it can’t be a child workflow.
(Actually thought of another way to describe this). If WF is currently running I want to await for it… If other WF has completed (I’ll know), if other WF has not started yet I want to sleep, wake up when it’s started, sleep, and continue when it’s reached a certain point.)
SignalWithStart cannot be called from another workflow directly anyway. So it has to be called from an activity. So the caller can invoke that activity and the activity implementation can be owned by the team that has all the info needed to start the workflow.
I do apologise it’s hard to adequately describe this mess, and the order of calls is not in my control. The interface is also our hands (i.e. we would be using this internally).
In a worst case scenario I could just do polling in a heartbeated activity to achieve most of this. I was just wondering if there was a more elegant way.
I still don’t understand why the signal with start called from an activity is not the best solution.
I’m not sure it isn’t :-), I’m not an expert.
But how do I handle the incoming call to officially start the workflow was started now with Signal with Start (as a pseudo-child)?
I will get two requests to start, I must get two requests to start, I must not start work on something without explicitly being told to (Or give the appearance of it). If the second request comes in and now tries to start the second workflow, it’s already running?
Heh the forum needs plantuml support
wf1 → wf2 : needs wf2 to be this far
wf2 → wf1 : you can go ahead now
The wrinkle here is I can’t control the timing of WF1 and WF2, it’s just sometimes WF1 is passed information saying your linked to an object that will be created but it might not be yet, and if so… it needs to sleep until wf2 reaches a certain state.
Then WF1 should wait for a single from WF2 notifying that it reached a certain state.
BTW have you considered having a single workflow instance for multiple entities? It is much simpler to coordinate objects inside a single workflow with shared memory.
If you could describe your business use case, I could provide a better answer.
I would adore to be able to do this. In my case we’re down in the bowels of Telco, changing the business logic is not possible.
In general I’m in a very awkward place between legacy and new methodology. Overall the top level’s want to mix and match between primitive objects and link them to each other. Here’s an endpoint over here and other over here and a bridge between them.
The issue is that the legacy systems connected to the actual devices do not work like that at all. So I can’t really make one workflow to push the entire structure, as the arrangment of these objects is totally arbitrary.
I do see your point about WF1 and WF2, my only awkwardness it was very difficult to know that WF1 was depending on WF2 (again, not my data), but it’s not impossible.
There are other methods, and temporal still looks like a good fit with some extra activities maybe polling with heartbeat. The concept of even trying to represent this without the workflow as code concept that temporal brings gives me cold sweats. Thanks for your info.