Architecture dashboard automatically classifies workflow modules (_WF) as end user modules.
This results in architecture violations as some of my _WF modules are providing services. An example is a conditional start that is set to public such that this can be triggered from the front end (the Backoffice). See attachment.
Am I really violating important architecture patterns or is this the right set-up, but does Architecture dashboard not know how to analyze this?
The only idea I can think of to avoid this finding is to add an attribute 'IsRejected' to the process entity for example and update this value from the backoffice and launch the conditional start OnUpdate instead of triggering it from the Backoffice.
But I would like to hear some other thoughts on this issue!
If there are no screen, then you can reclassify it to core instead of end-user
Can anyone else validate Win's answer here? Is this true?
It not having screens doesn't seem enough to look at. As soon as you have at least one human activity referencing (another module's) screen as destination, it can't be anything other than an end user module, as otherwise these would become upward references.
So I think no, you can't launch conditional starts in other modules without violating side reference rule.
Thanks Dorine. So you are saying that if you want to use the full functionality of BPT (and obey the architecture canvas rules) then the BPT logic has to be in a module within the same application as the front end of your application (if not directly in the front end itself)?
This seems a bit limiting...
Nope,
it just feels to me that a weak link as a side reference is somehow less ugly architecturally than a weak link upwards.
I kind of like the idea of an architecture where higher layers are in the know about lower layers but not the other way around.
But as it is a weak link, maybe it is perfectly ok for a core module to have a link to a screen.
Dorine
Ok, so from an architecture standpoint, weak links up and weak links between end user modules are seen as 'ok' then?
not entirely sure on that, more seasoned developers might know better,
but see for example answer by @Nuno Reis here
How about encapsulating it in an action (API/Service) to make it a weak dependency? This way, it would not violate the architecture.
https://success.outsystems.com/documentation/11/developing_an_application/create_case_management_and_workflow_apps/use_case_management_framework/create_a_case_management_app/
on this documentation you can see that they use the _WF as a Core module, maybe the reason why discovery tag it automatically as an end-user due to it having a screen?
This seems like the answer to me then. It should be seen as a core layer, and perhaps the Discovery tool needs to be updated then...
I'm not sure on how discovery tag it, but I think having a screen overwrites the module name, like if the module name is _CS and you have a screen there, I think discovery will tag it as an end-user