Integer operations in policy assertion?

[Anon Anon]

I'm writing a new policy assertion that requires integer manipulation. None of my attempts have yielded any success. Here's what I'm trying to do:

 

 

If either assertion 2 or 3 are set to Integer, then I get an error along the lines of "Unable to parse integer string" (I'm assuming because in assertion 2, the gateway.time.millis exceeds Integer.MAX_VALUE)

 

I can have integer values that are smaller, but still can't make integer math work

Assertion 3 still gives me the Unable to parse integer string.

 

So is there a way to get integer math to work in a policy through stock assertions? If so, how?

 

Thanks!

[Doyle_Reece]

Hello chou_abc,

 

That won't work . We have kind of a 'Work Around' that you can use, but with the knowledge that mathematical computations may add load to the host.

 

with that acceptance, you can leverage our response Xpath assertion to do simple mathematical computations.

 

Example

Take this Policy:

 

take a look at the xpath assertion.

Here it is working.

 

hope this helped.

[styganesh]

Hi Doyle_Reece

 

Do you recommend Custom assertion for these type of scenarios and is there an added load of using custom assertion as compared to Xpath or for that matter existing assertions?

 

Regards,

Ganesh Reddy

[Doyle_Reece]

i don't think a custom assertion will give you anymore benefit, I just wanted to mention that some people really 'run away' with doing lots of unnecessary mathematical computations on the gateway, and i would try to limit them if necessary.

[Anon Anon]

Hi Doyle,

   First of all, that answer works and seems like a sneaky use of XPath transform ;-)

The use case here is that I'm generating a web token from the gateway and wanted to compute an expiration. Thus, I get gateway.time.millis and add say 60000 to that in get a one-minute token expiration time. Should this have been done outside of the gateway?

 

One other question, the XPath expression creates a decimal result (e.g. 3.0 instead of 3), I'm using split variable to parse out everything before the decimal, this is expected and the right way to do this? I couldn't get the format-number() Xpath function to work for this.

[Anon Anon]

If all you're looking to do is create a token expiry date you can use the Set Variable assertion with the Date/Time data type: Set Context Variable Assertion - CA API Gateway - 8.4 - CA Technologies Documentation .  There is an offset field that allows you to create a time offset from a specified time.

 

And yes, this is a good use of the Gateway.

[Anon Anon]

Well, that almost feels like cheating it's so easy! Thanks...

[Legacy User]

Hi Julian, 

 

I just developing the same solution. I'm trying to add an offset to the current time. But I'm facing problems during the time conversion to milliseconds. I just added the same assertion with the same offset.  

But in the Debugger I can only see the normal time and not the millisecond time. 

 

I'm using the API Gateway 9.2.

Do you have a hint for me? 

regards

Andreas

[Bill_Peterson]

There is a 'millis' suffix that can be used to get the time in milliseconds ( ${gateway.time.millis} )

Date and Time Variables - CA API Gateway - 9.2 - CA Technologies Documentation 

[Ozgur Anil Demir]

Hello,

I tried xpath assertion as you mentioned, but it is NOT RELIABLE. 

I need to calculate 86400 + ${gateway.time.seconds} for every request.

Let me explain;

Example for successful calculation;
when param1 = 86400 and param2 =1674554585

$param1 + $param2 = 1.674640985E9  --> the result is 1674640985, it works fine for this values
 
Example for wrong calculation;
when param1 = 86400 and param2 = 1674554480
it calculates;
$param1 + $param2  = 1.67464088E9 --> But the result is 1674640880, not 167464088. There is a missing zero.

It is very hard to understand that why are you so insistent about not developing an basic calculator for almost 10 years?