WebService Connector Aggregation Issue

Hi Everyone,

Here we have custom authentication for web service application where no authentication is required but when I tried to aggregate accounts from endpoint it got successful but I don’t see any single account aggregated not even errors I suspect something on response path , Can anybody tell what should be the response root path for below response ,its showing in odd way but we received similar response from application team.

[{“EmailId":"[email protected]”,“Id”:“0000065”,“Location”:“MUMBAI”}]

Try using this root path: $[*]

1 Like

Hello Priya, Thanks now I am getting error on aggregation after adding this path $[*], but it seems some progress on our activity.

It says 401 in error but here is one problem that we are using custom authentication where no user id, password, ClientID or secret is required however in account aggregation what value should I pass in headers as there is no access token? any idea on this, currently no values we are passing under headers for account aggregation operation as there is no authentication required for this application

@LearningStar -

You should set the Response Root Path as:

$

If your application does not require any authentication, simply set the Authentication Type as Custom Authentication. No need to set any header etc.

Cheers!!

No it’s not working, it’s showing 401 as response means authentication error but surprisingly there is no authentication specified for this source moreover our test connection got successful but for account aggregation it is showing 401 as response

@LearningStar -

Could you share the postman request and response for a successful aggregation. Also share your screenshot for the application configuration in sailpoint.

Cheers!!!

So if you are using custom authentication then you need read response properly and store in customvariable and use in other configuration for account and group aggregation
If there is no authentication that means no token no basic auth or any details then make sure end point is correct and you are using proper response and content-type to read.
Finally if you are using everything proper then please print the logs in webservice after rule for tetsing and read response and see how it look like.
401 you are getting if something wrong passing on variable.
in the end u can check with sailpoint or network team if they can trace the call and see if that is failing because of firewall or something issue

1 Like

Hey this application is not exposed to http although we have run curl command from Va to verify the response, it showed results on cURl command.

Try adding Content-Type: application/json in the headers and ensure there aren’t any repeated characters between the base URL and the aggregation context URL. If possible, share some screenshots of the HTTP operations, by masking details. Hope, the account schema is in place.

Give context url endpoint like users
in response information give your json end point $.Users[*]
in schema mapping give all the account schema available

@LearningStar If theres no authentication then custim authentication is right path. Where you just pass some gibberish values and it should Work.
But as you mentioned that test connection works whereas aggregation fails with 401 Unauth. Error
Few things to check here.
Can you check in your test connection Api call what headers have been used and replicate the same in the aggregation api call. If you see some encrypted value that probably means Some Authorization key is being added.
Another point to note here is sometimes you may get authorized endpoint make sure you are using the same in aggregation Api call.

As for your next query of account not getting reflect try the root path as $[*]

and then add the response schema mapping.
P.s $[*] will only work if the response is [{key:value}]
whereas if its something like data:[{key:value}]the root path will change to $data[*]

1 Like

Hi @LearningStar

I also have faced this kind of issue once where when i was checking the api response from postman body was bit different.
The best case scenario is create one after operation rule and attach with http operation and observe the response you are getting. from logs

For your reference I have used this

Debugging Rule - Prince.java (579 Bytes)

1 Like