I am not able to pull data as part of Single account aggregation - HTTPS operation I have configured. Not getting any error or aggregation logs also. So, not sure if this is syntax error or what.
passing below in the context URL :
/UserManagement/GetUser?userGUID=$getObject.nativeIdentity$
Note : Passing the authorization token similar as in the full accounts agg operation which is working.
I am not entirely sure if this is the issue, but can you try $getobject.nativeIdentity$ instead of $getObject.nativeIdentity$ (lowercase ‘o’)? The Keywords documentation has this as all lowercase and could be causing the issue.
Can you also try with $plan.nativeIdentity$ instead of $getObject.nativeIdentity$ ($getObject.nativeIdentity$ should also work but try with plan).
If you are not able to find the reason, then I would recommend you use before and after operation rule. Using the rule, you will get to know where the problem is.
Print following:
BeforeOperation_Rule:requestEndPoint and oldResponseMap
AfterOperation_Rule:rawResponseObject and processedResponseObject
To rule out the issue with variable, put static value in URL. You might have userGUID handy , put that value and go to any account from that source and try running single account agg.
No, I tried with both $getobject.nativeIdentity$ and $getObject.nativeIdentity$ it’s not working. I tried with $plan.nativeIdentity$ also. Again no luck.
Have you tried full account aggregation in this source and is it working?
Have you tried the same context URL with an actual userGUID value in the API call and were you able to get the response?
Have you defined the account schema in your source?
In your response mapping, have you ensured that you’re putting in the exact same schema attributes that you’ve defined in the account schema of the source?
Hi Aeshad,
Thanks, Please find my answers inline :
Have you tried full account aggregation in this source and is it working?
Yes, tried. It’s working. I am passing the Bearer access token in exactly same way in this as in the account aggregations operation. Used the content type & accept header paramters also in same way.
Have you tried the same context URL with an actual userGUID value in the API call and were you able to get the response?
Tried this (passing a static valid ‘userGUID’ in context url), not getting values for the attributes which I configured in the Response mapping. Getting the response from Postman using the same userGUID. So, no issue with userGUID also.
Have you defined the account schema in your source?
Yes. with exact same case senstivity as provided by application API. Data types of accunt attributes also checked & confirmed. There are few attributes which are common on the response from all account aggregation operation & single account agg. Only single agg. operation that attribute is not getting populated. Full account agg is working.
In your response mapping, have you ensured that you’re putting in the exact same schema attributes that you’ve defined in the account schema of the source?
Not all account schema attributes I have mapped in response mapping. For testing only few of those done.
I would add the rest of the response mappings, most importantly the one for your Account ID and whatever is being used for correlation in the schema so the account can be properly correlated to the same identity it’s already aggregated to. You not having all the mappings set up could certainly be the issue.
Thanks Patrik.
This was really the issue. I have not mapped all the attributes in the response mapping & I think most importantly the Account ID was missing. Once I added it, it fixed the issue.
Although it not the same for all APIs, as I have previously done without mapping all available attributes in the response mapping. Seems it depends API to API.
Thanks Patrick, and all other for your inputs. Really appreciate.
