Knowing that ‘application’ is an input to these two rules, is it possible to call certain methods to set connector attributes from within the rule?
For instance, I might want to store a temp token for use in pagination activities, and I call application.setAttribute("myToken","myValue"); and later retrieve it with application.getStringAttributeValue("myToken");
Is this possible from a connector rule or any rule for that matter?
Hi Sushant,
You can set the attributes related to pagination in transientValues map on application object. These values are accessible on both Webservice Before and after operation rules.
You should be able to store myToken attribute to transientValues Map or you can store it as searchAfter parameter in transientValues to access it later in the rule.
Below documentation also can be helpful to you:
But apart from saving the attributes temporarily in transientValues, i do not think we can save other attributes on application object permanently, since unlike IIQ we cannot save the context modified object.
Let me know in case of any questions.
Regards,
Uday Kilambi
Thanks @uday_kilambiCTS
Do you know how many times the before operation and after operation rules get invoked when pagination is set? Say an aggregation has 10 pages to complete the full aggregation, does it mean both rules if applicable execute 10 times, i.e. once per page?
Before Operation and After Operation rules are invoked once. ie BO before the first page call and AO after the last page call.
Thanks @iamnithesh
Is there any way we can update the headers of an aggregation API call to include a cookie generated in before operation rule in all subsequent pages? Right now, my cookie helps authenticate the first page, but I can’t seem to send it on the next page API calls because maybe the before operation rule like you mentioned, does not get invoked the second time onwards.
Note: I am using the paging tab configuration for paginating. My pagination involves incrementing a URL parameter by 50 until the last page says “no more users”.
How is this cookie passed to the first call?
Hi @sushant1 ,
As per my understanding the rules are executed multiple times as you said 10 times until you make hasMore to false. Webservice operation rules should be executed as many times as API call is executed.
This is because for each iteration the searchAfter value needs to be updated to transientValues again and accordingly hasMore value logic should be updated. Until your logic ends the loop by updated hasMore to false, the execution continues.
Regards,
Uday Kilambi
Cookies can be updated to headers of requestEndPoint in the before operation rule. In the cases that I faced such API requirement, I made an explicit call to the API which provides the cookies in response header. Capture the cookie from response header and added it to the requestEndPoint header such that the current API executes with the cookie for authentication.
Hi Sushant,
Did you try using the paging configuration for the aggregation endpoint to achieve pagination? ISC provides ways to fetch values from the response (from Header or Body) and add the value to the header or body for the next call.
Can you expand on where the value is coming from(header/body) and where you want to pass (header/body)?
This link also talks about the paging configurations.
Hi @uday_kilambiCTS
This is exactly what I did, but even then the next page API calls do not authenticate. I am not sure why this is happening, because when testing on Postman, I can see that it works. I also see it execute the before operation rule for the second time, and fetch the cookie from the transientValues (where I stored it first time). It still fails…
Edit: I checked by printing the requestEndpoint to confirm the cookie being passed in the header, and it is being passed. The same cookie which worked in the first call, failed in the second one.
@sushant1 based on your authentication type you can write a generate token method to use it whenever you want to call an API inside the rule. Please use this code block as a reference:
public String getNewToken() throws GeneralException
{
log.debug("Entering Example_BeforeOperation_Rule: getNewToken method");
OkHttpClient client = null;
Response response = null;
String newToken = null;
try
{
String baseUrl = (String) application.getAttributeValue("genericWebServiceBaseUrl");
String loginUrl = "/authentication/Login";
String finalUrl = baseUrl + loginUrl;
String bodyContent = "{\r\n \"username\": \""+ application.getAttributeValue("username") +"\",\r\n \"password\": \""+ application.getAttributeValue("password") +"\"\r\n}";
client = new OkHttpClient().newBuilder().build();
MediaType mediaType = MediaType.parse("application/x-www-form-urlencoded");
RequestBody body = RequestBody.create(mediaType, bodyContent);
Request request = new Request.Builder().url(finalUrl).method("POST", body).addHeader("Content-Type", "application/x-www-form-urlencoded").build();
response = client.newCall(request).execute();
if (!response.isSuccessful())
{
throw new IOException("Unexpected code in getNewToken()" + response + " || " + response.body().string());
}
// Get response body
log.debug("Retrieving new toekn fromt he response...");
String res = response.body().string();
JSONObject jObject = new JSONObject(res);
newToken = jObject.getString("sessionId");
}
catch (Exception e)
{
log.error("Error while generating new token...." + e.getMessage());
throw new GeneralException("Error while generating new token...." + e.getMessage());
}
finally
{
if (null != response)
{
response.body().close();
}
}
log.debug("Exiting Example_BeforeOperation_Rule : getNewToken method");
return newToken;
}
Regards,
Shekhar Das
Thanks for sample code to get new token value.
Hi everyone,
I wanted to share an update on this thread: Although I can’t seem to identify the cause for the subsequent API calls in the pagination not authenticating as expected, I had to work around the problem by implementing my own pagination in the after operation rule.
The cause of the cookie based authentication failing when we use paging configurations is still unknown.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.