Open manosbatsis opened 6 years ago
If I understand - you mean that a single point in a process can be drilled down into a more detailed process diagram. That could probably be catered for by naming of the diagrams. But could probably do with a better structure.
Is this what you mean?
More or less. Consider a code base with two classes/workflows, each using it's own diagram name. It should be possible to allow clicking a step in the diagram UI to browse the subflow where appropriate already, based on the processid and timestamps alone for simple cases.
However, updating codeflow's HTTP endpoints with support for clients to unilaterally track nested flows by including an optional parent reference within a request, will provide more flexibility to clients. It will also be easier to implement.
In any case, i would suggest for flow relationships to be handled on an ad hoc basis, i.e. without requiring any maintenance for the codeflow side
That ties in with an approach I was thinking of...
You simply point some config to a project folder that contains all of your diagrams. Instead of having to open each one manually, codeflow opens it automatically if it receives a trigger for it.
The child-parent relationship sounds interesting - so you click on a node in the parent diagram and the child process is displayed.
This also means that you can record sessions with just the data, save it and render it again at any time.
That final bit nails it, Seems diagrams could be automatically created and perhaps maintained and versioned by data alone for common cases.
Steps could abstract deeper levels of diagrams. There shouldn't even be a need to manually maintain the structure/hierarchy while defining diagrams, the proccessid and timestamp of each call should be enough for the UI to support browsing different levels of flow for a specific process.