[midPoint] How to connect a resource that only really implements a sync method for a particular object class

[Pavol Mederly]

Hello Chris,

we have recently implemented this "messaging-only" approach for 
Grouper-midPoint integration demo prepared for Internet2 InCommon 
Trusted Access Platform.

It does not use ConnId resources, mainly because of the architectural 
mismatch regarding "sync token" concept; and the acknowledgment of 
processed messages. (This is not to say that ConnId cannot be used in 
this case! It just does not fit perfectly.)

Instead it uses a new mechanism called asynchronous update. (Now I see 
it's not much documented... but some ideas are here: 
https://wiki.evolveum.com/display/midPoint/Messaging+Resources#MessagingResources-SourceResources).

The connector we use has two parts:

 1. fully functional REST connector that works synchronously,
 2. asynchronous connector that receives and processes AMQP messages.

This is the configuration: 
https://github.internet2.edu/docker/midPoint_container/blob/master/demo/grouper/midpoint_server/container_files/mp-home/post-initial-objects/resources/resource-grouper.xml. 
(With the related custom function library: 
https://github.internet2.edu/docker/midPoint_container/blob/master/demo/grouper/midpoint_server/container_files/mp-home/post-initial-objects/functionLibraries/function-library-grouper.xml).

Now, back to your question:

 1. What we have done corresponds to your option "a". Besides
    asynchronous part there is also a fully functional synchronous part.
    The main reason of its existence is that we need to be able to do
    occasional full reconciliation - something that is not possible with
    pure messaging approach. Note that we have the caching turned on
    even if we have this option. We need to be able to quickly determine
    group membership information from the cached group information.
 2. But your "b" way should be also possible. You should be able to
    simply declare connector as "not supporting queries" and rely on
    shadow caching. We have some tests in this respect, see e.g.
    https://github.com/Evolveum/midpoint/blob/a30ecaafa648564f619c3d7e3936a66300c3b61e/model/model-intest/src/test/java/com/evolveum/midpoint/model/intest/async/TestAsyncUpdateUcf.java.

Note that the "asynchronous update" feature is somewhat experimental for 
now. But it seems to be working well. It supports AMQP sources only but 
was designed to be easily adaptable to other types of data sources. JMS 
is obvious first candidate.

Best regards,

Pavol Mederly
Software developer
evolveum.com

On 26/04/2020 16:32, Chris Woods wrote:
>
> Dear all,
>
> we have just finished implementing the Org Management code for our SAP 
> HCM connector. We receive the messages via JMS and have implemented 
> the sync code for that. All working fine too – the focus objects 
> (Organisations) are created ok. The only issue is, there is no query 
> method available as this is purely JMS based – so trying to perform 
> recalculation on an organization throws a connectorexception regarding 
> the non-implementation for this objectclass.
>
> What options do we have? a) implement a query method for this 
> objectclass (ok, this will obviously fix the problem – but require 
> more work) b) Make a new instance of the connector only for this 
> objectclass and switch on shadow caching c) something else that I 
> haven’t thought of?
>
> Does this maybe need converting to a task rather than syncing through 
> the connector?
>
> Any ideas greatly appreciated J
>
> Regards
>
> *CHRIS WOODS*
>
> Identity Management
>
> Information and Business Technology
>
> Rohde & Schwarz GmbH & Co. KG
>
> Mühldofstraße 15| 81671 München
>
> Telefon: +49 89 4129 15735
>
> Internet: https://www.rohde-schwarz.com <https://www.rohde-schwarz.com/>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20200427/080322cd/attachment.htm>