On 12/07/24 17:33, Feder, Stephan wrote:
Hallo Francesco!
On Fri, Jul 12, 2024 at 04:54:29PM +0200, Francesco Chicchiriccò wrote:
On 12/07/24 16:32, Feder, Stephan wrote:
...
Users cannot self-register, they are not created manually at all. Instead,
external processes provide data sets which are modelled as anyObjects in
syncope. Each data-set is linked to one user, and every user is linked to
arbitrarily many data-sets. Each data-set provides specific information for how
to link, and if there is no matching user yet, it has to be created.
...
is it correct to assume that, anytime a data-set gets created, it might or
might not trigger the creation of a linked user?
Yes, absolutely. Every time, either a matching user is found or it has to be
created.
If so, you might extend the AnyObject provisioning manager [1], by:
1. providing a reference to user's provisioning manager
2. override the create() method so that, once the any object create is
complete, in case no matching user is found, the user provisioning manager's
create() is triggered (and the payload contains a relationship between the user
being created and the any object just created)
In other words, the correct approach would be invoking the user provisioning
manager's create() instead of the user workflow's create(). But should this
not work from within the anyObject workflow as well? What is different from
calling create() from within the anyObject provisioning manager? There seems to
be some fundamental misunderstanding on my part about how things work in
syncope.
There are a couple of fundamental differences between Provisioning Manager and
Workflow Adapter in Syncope - I invite you to take a read at the Reference
Guide to understand more:
1. the Provisioning Manager is orchestrating the whole provisioning process,
including both workflow (e.g. changes inside Syncope) and propagation (e.g.
changes going outside Syncope)
2. transaction management: each workflow operation lies under the same
transaction
Finally, your approach to provide a whole new, Flowable-based workflow adapter
for Any Objects appears to be overkill.
The advantage of such approach is that there is less customization around, and
also processes remain separated.
WDYT?
For me, changing syncope's codebase would be a last resort, because it would be
a maintenance nightmare. I would much prefer to only add some generic code
(like the FlowableAnyObjectWorkflowAdapter and the task for creating
anyObjects), and to put all business logic into the flows and related tasks.
I am not suggesting to change Syncope's codebase at all.
Working with Syncope-based IAM deployments shall never imply (changing and)
building the Syncope codebase from scratch.
I am suggesting instead to follow the standard practice we adopt when working
with Syncope deployments:
1. create your own project from archetype [1]
2. add your own class extensions or Java implementations [2]
3. build and deploy to Java EE container or via Docker
Above I am supposing your are at [1] and suggesting to create a class named
MyAnyObjectProvisioningManager extending DefaultAnyObjectProvisioningManager
and overriding the create() method as indicated.
Experience has proven such approach being the right balance between
customization and easiness to follow upstream upgrades.
I do not understand what you mean by "processes remain separated". Creating the
user happens in the same process as processing the data-set, only I am doing it from with
the anyObject workflow, and you are doing it at a later point. Or maybe you are referring
to workflow processes?
As said above, there are sensible differences.
Hope this clarifies.
Regards.
[1] https://syncope.apache.org/docs/3.0/getting-started.html#maven-project
[2] https://syncope.apache.org/docs/3.0/reference-guide.html#implementations
[3] https://syncope.apache.org/docs/3.0/reference-guide.html#customization
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
