[midPoint] Repost again! Is it possible to force sending unchanged attributes in updateDelta (ConnId)?

[Pavol Mederly]

Om, 

you're right - this should work, at the expense of additional read operation as you said. 

Please note it's an experimental feature. It has a some limitations, e.g., it doesn't take shadow caching into account. 

Best regards, 
Pavol 


From: "midPoint General Discussion" <midpoint at lists.evolveum.com> 
To: "midPoint General Discussion" <midpoint at lists.evolveum.com> 
Cc: "Om Bhallamudi" <om.bhallamudi at proton.ch> 
Sent: Wednesday, April 15, 2026 7:38:20 PM 
Subject: Re: [midPoint] Repost again! Is it possible to force sending unchanged attributes in updateDelta (ConnId)? 

Hi, 

I've used attributeContentRequirement ​ for this before. Note that this causes a pre-read of object for every update. Internally, Midpoint will convert {changes like add, remove to some attributes} -> {replace of every attribute}. 
<cap:update>
    <cap:attributeContentRequirement>all</cap:attributeContentRequirement>
</cap:update> 



Thanks, 
Om 

On Friday, 10 April 2026 at 11:58, Pavol Mederly via midPoint <midpoint at lists.evolveum.com> wrote: 




Hello Ali, 

answers are inline. 

Best regards, 
--
Pavol Mederly
Interim Chief Product Officer
evolveum.com 
On 09/04/2026 20:47, Али Саад via midPoint wrote: 

BQ_BEGIN

Hello again, repost again!

I have a question regarding midPoint provisioning behavior and ConnId
connectors.

As I understand, during update operations midPoint invokes updateDelta()
and only sends changed attributes (AttributeDelta set).

However, in my integration scenario the target system API requires some
attributes to be sent on every update request, even if they have not
changed.

For example:
- login (identifier)
- system/source field
- some mandatory attributes required by API contract

The problem is that these attributes are not always included in
AttributeDelta, since they are not modified.

My questions:

1. Is there a way to force midPoint to always include certain attributes in
updateDelta, even if they are unchanged? 




I don't know of any. 

There is a similar feature in asynchronous provisioning (AFAIK), but that's a very specific case. 
BQ_BEGIN

2. Would outbound mappings with strength=strong guarantee that these
attributes are always sent? 

BQ_END
No. 
BQ_BEGIN

3. Or is the recommended approach to enrich the request on the connector
side (service/mapper layer)? 

BQ_END


Currently it seems to be to be the only option. I don't like it very much, for the same reasons as you, but don't see an alternative. 

Maybe someone from the community has more experiences in this area? 
BQ_BEGIN

I would like to understand what is considered a best practice in such
scenarios.

I am trying to avoid mixing transport-level requirements (API contract)
with business logic inside the connector, so I am looking for the most
appropriate architectural approach. 

BQ_END


BQ_BEGIN

Thank you. 

_______________________________________________
midPoint mailing list [ mailto:midPoint at lists.evolveum.com | midPoint at lists.evolveum.com ] [ https://lists.evolveum.com/mailman/listinfo/midpoint | https://lists.evolveum.com/mailman/listinfo/midpoint ] 

BQ_END

BQ_END


_______________________________________________ 
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/20260417/5a0b1e74/attachment.htm>