Multiple endpoint aggregation account overwrite

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

Hello,

So I have application definition that uses multiple endpoint aggregation. The thing is that it aggregates in such a manner that each endpoint might be an independent account. They always differ from one another by 2 attributes for example :

application schema:
name
email
attribute1
extra1
attribute2
extra2
attribute3
extra3

endpoint1 response mapping:
name
email
attribute1
extra1

endpoint2 response mapping:
name
email
attribute2
extra2

endpoint3 response mapping:
name
email
attribute3
extra3

So for example: endpoint1 returns one valid account for identity asd123, endpoint2 doesn’t contain valid account for that identity, but endpoint3 does contain another valid account for identity asd123. They may differ only in attributes “attributeX” and “extraX”. But in the end they are overwritten instead of filling the application schema.

Hi @blazejbadzio,

This is expected behaviour, especially since the NativeIdentity doesn’t appear to be unique per endpoint.

1 Like

try to eliminite email from EP2 & EP3

@enistri_devo - Email would be needed though (assuming that is the NativeIdentity) if the account doesn’t exist in EP1.

@blazejbadzio if I understood correctly?

For the sake of this post we can assume that email is the nativeidentity that is the key to correlate it to identity afterwards. (Since that kind of attribute exists and indeed is not chaning through every endpoint) I should also point out that this kind of aggregation for single object works as expected (account is created as in schema, provided that each endpoint had a valid account).

ok I thought the name was the username of identity

Is there a way to catch the “about to be aggregated” account and merge it with previously created account if such exist all in a single multiple endpoint aggregation task?

Hi @blazejbadzio,

I think your best option in this custom solution would be to keep EP1 and build a WebServiceAfterOperationRule to run EP2, EP3 and EP4.

That way you have full control of which account you want to pull in, what details you want to overwrite (or not), conditional statements, etc.

Hope this helps.

Thanks, I’ll try this after my other idea which is to put read accounts into state in customization rule and check whether account already exists then either save it or append it.

So customization state idea worked, but the issue exists in single account aggregation, because it won’t create a link if the main request won’t return an account, where i did what You proposed which is aggregation in after operation rule, but i guess no link will be created if the main request won’t be satisfied with empty return body so it won’t create a link even if other aggregation will succeed and afterOperation rule would return some data in a map. Is there a way to do it so I’ll be able to create a link even if main request returns nothing?

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.