We are using Oauth authentication type to integrate Informatica Cloud application in ISC Sandbox.
For this integration, I have tested operations in postman, it was working
First we have sent a request in postman by passing necessary values to generate a access token.
To generate session id value, sent a 2nd request With access token value which we got it from 1st request. once it generated, we need to pass this session id value for each operation like account & group aggregation et..
Request 1 for access token:
curl --location ’ Sign in to your account ’
–header ‘Content-Type: application/x-www-form-urlencoded’
–header ‘Cookie: fpc=AsOw71QzYzxAp7KWzbh4Ox0rtSl6AQAAAH-q1uEOAAAA; stsservicecookie=estsfd; x-ms-gateway-slice=estsfd’
–data-urlencode ‘client_id=’
–data-urlencode ‘scope=api://al58M9pGYcwep8w0r6rjMc.dm-us.informaticacloud.com/custom.read’
–data-urlencode ‘client_secret=value I didn’t paste here because it’s confidential’
–data-urlencode ‘username=**********’
–data-urlencode 'password=’
–data-urlencode ‘grant_type=password’
This is a well-known challenge with multistep OAuth flows in ISC Web Services connectors. Let me explain what’s happening and how to fix it.
Why you’re seeing these errors
ISC’s Custom Authentication block supports only a single HTTP operation for token fetch. When you define two custom auth operations, ISC doesn’t know how to chain them hence “Exception occurred while generating access token”. And when you define only one (Request1), the session ID is never fetched, so every operation fails with the managed system error.
The fix:
Custom Auth block — configure only Request. Set the return attribute to access_token so ISC stores it.
Before Operation Rule — write a BeanShell rule that:
1.Reads the stored access_token from the application context
2.Makes an HTTP POST to https://dm-us.informaticacloud.com/ma/api/v2/user/loginOAuth with your orgId and the token
3.Parses the icSessionId from the response
4.Injects it into requestEndPoint.getHeader() as INFA-SESSION-ID
In order to achieve “Custom Authentication” where this Custom Authentication - HTTP Operation will generate an access token and then, this access token, you have to use in subsequent operations such as Aggregation, Create Account, etc. Follow the below steps.
Then, in the subsequent methods of “Account Aggregation”, etc, inside the Headers section, pass the respective Bearer Token as shown below.
The respective operations when they will see the dynamic variable of “Bearer $application.access_token$”, it will call the Custom Authentication method and provide your operation a valid bearer token.
Thank you for your response. But your appraoch won’t suitable for my requirement. I have tried this approach already. Your approach won’t give a session Id that required for remaining operations.
It seems Bapu gogu approach looks good to me but not sure whether it give a results.
Hello Anil, your Postman flow is basically: Azure AD token, then Informatica loginOAuth for the session ID, then that session ID goes into every aggregation call.
So the Azure token alone won’t help you in the aggregation headers. What I would suggest is, keep one Custom Auth operation for the Azure AD token call and map the response to a custom key like custom_oauth_token. Don’t use accesstoken as the key, it’s reserved and will cause issues.
For the second call (Informatica loginOAuth), handle it inside a WebServices Before Operation Rule. The rule would read $application.custom_oauth_token$, call Informatica’s loginOAuth, parse the icSessionId from the response, and inject it into requestEndPoint.getHeader() before Test Connection, Account Aggregation, or Group Aggregation runs.
That way ISC follows the exact same flow you already have working in Postman.
@aphanidapu We have the same requirement to handle rotating refresh tokens. To address this, we use a Before Operation Rule to persist the latest refresh token in parameter storage. During subsequent operations, the stored refresh token is used to request a new access token, which is then passed to downstream API calls.
