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

[Om Bhallamudi]

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:
>
>> 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.
>
>> 2. Would outbound mappings with strength=strong guarantee that these
>> attributes are always sent?
>
> No.
>
>> 3. Or is the recommended approach to enrich the request on the connector
>> side (service/mapper layer)?
>
> 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?
>
>> 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.
>
>> Thank you.
>>
>> _______________________________________________
>> 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/20260415/816d419c/attachment.htm>