We need some help/guidance with one implementation using the CA API Gateway - Policy Manager.
We have a requirement to convert a long(string) variable which stores windows date time (Ex.636703698395512138) and needs to be converted to a proper DateTime format.
We are assuming that we need to use the "Set Context Variable" assertion, but we are not able to get the conversion done successfully.
Can you please help / guide us on this request?
I'm not actually sure if the Set Context Variable assertion will work in this case, because it doesn't automatically convert strings. To be honest, I'm not certain which assertion would do that for you, at least not yet. I will certainly continue to review this though.
Do you mind providing more detail that may help us? I'm thinking it'll be useful if we know the way the message gets generated, or in other words if that long string with the Windows time is present in the body of the message or as a header, for example. Additionally, it'd be good to know if your policy does any manipulation of the data prior to the point in time of the policy where you'd like to do this conversion, and if so, what the request looks like at that point in time. If you're able to provide more information around that part, I think that may help us come up with a flow that could help, if it's possible.
I look forward to hearing from you.
I expect you would have to convert it to a more unix/java style timestamp probably using the following types of calculation:
Convert Windows Timestamp to date using PHP on a Linux Box - Stack Overflow
And should then be able to construct it with the Set-Context with
Data Type : Date/Time
from a Format: of :
That would be what I would start experimenting with.
Cheers - Mark
Just to elaborate a bit - I thought there was another question around in the communities asking to add a constant to a timestamp - but my searches keep coming up with this case - so will expand the method here.
Calculation can be done on time objects via XPath
Here is one I have setup : (not quite the same calculation) but :
You can see we create a dummy xml object, and then here I have two unix timestamp objects :
And then a calculation via XPath to gets the delta time :
You can see that the input values are "String" but are then converted to numbers via XPah.
And I store the limittime.result as the timedelta.
So in your case, I'd expect you can do a similar calculation - as per :
https://stackoverflow.com/questions/10411954/convert-windows-timestamp-to-date-using-php-on-a-linux-boxtUnix = tWindow/(10*1000*1000)-11644473600;
tUnix = tWindow/(10*1000*1000)-11644473600;
From : Convert Windows Timestamp to date using PHP on a Linux Box - Stack Overflow
To give you the unix timestamp from the Microsoft one, and then use the Set Context Variable to get the result value interpreted as a Date/Time field. eg :
PS: If I ever find that original question, about adding an offset to the current time, I will point them here - an offset can be done via the XPath calculation, or it looks an offset can be added in the Set-Context-Variable as well - to add say 600sec for some sort of expiry.
Thanks for the response Dustin.
I will provide some detail steps of what we are doing and what we are expecting.
1. We have an existing web service which returns the windows date time in long format.
2. Our API invokes this web service, converts the SOAP response to XML and then XML to JSON (Response body).
3. We are assigning the Windows Date Time string to a context variable.
We are stuck after this step, where we have to convert the string to a proper date time.
In the worst case, we have to modify our existing Web service code but that we want to consider as the last option. Hence, we are trying out all the options within the Policy Manager.
Please let me know if you need any further information.
It's an interesting use-case. I honestly am not sure if we have a solution to this though, at least not one that is built-in. The Gateway works with the following date/time formats for interpretation and output, based on the documentation:
Does the Windows timestamp being generated on your side end up looking exactly like an EPOCH timestamp by any chance? An EPOCH timestamp is 13 digits long. Ref: https://currentmillis.com/ In your example though, it looks quite a bit longer than 13 digits. If it does look like an EPOCH timestamp, and it is in fact the same thing, then we may have something to work with. But if the Windows timestamp generated is it's own format, then I don't think we can interact with it as the Gateway isn't programmed to recognize that date/time format at this point in time. Out of curiosity, what happens when you set the format to "Auto” on the Set Context Variable assertion with the Date/Time type? Does it recognize it at all?
Ultimately, if the time stamp coming into the Gateway isn't one that it's aware of, then it cannot convert it or do anything with it since it has no knowledge of what that Windows timestamp means in the first place. I think if you need this done, you would need to follow Mark's suggestion above in this thread which was to convert it to a UNIX-like timestamp before it gets to the Gateway, where should be able to then take it from there and convert to a more proper date format. Unless that can happen though, I'm afraid this doesn't appear to be possible in the current version of the Gateway, meaning the conversion would need to be done earlier in the workflow before it gets to the Gateway.
Follow the instructions provided by Mark O'Donohue to convert the windows timestamp to unix timestamp first.
Then follow the KB article below to format the date time output,