Good news!
xMatters integration scripts have been upgraded to use JDK 11 - meaning integration designers and scripting aficionados have access to a better, faster, stronger scripting engine.
The bad news is that some custom integration scripts may not be fully JavaScript compliant, and you may see some issues or error messages.
Why are we doing this?
We're always looking to upgrade our technologies to deliver the best possible features and functionality, including security updates, performance enhancements, and compatibility improvements. (Just as a quick example, this change lets us support modern JavaScript features like arrow functions and default parameters.)
Switching to JDK 11 (and the AdoptOpenJDK suite) can help provide all these things.
What's changed?
Among other things, one of the big differences between JDK 8 (the old version) and JDK 11 (the version we're moving to) is the deprecation of support for the Nashorn JavaScript Engine. Nashorn had something of a quirk in that it accepted some Java functions - meaning that it would accept scripts that were not pure JavaScript, and thus not technically valid.
One other note: JDK version 8 required ECMAScript 5.1 compliance, whereas JDK version 11 requires ECMAScript 6+. What this means is that if you're running an integration on the cloud, your scripts must be ECMAScript 6+.
What do you need to do?
While this won't affect the majority of integrations, it does mean that non-compliant scripts may encounter some issues after we've made the switch.
For example, here are some Java String methods that could previously be used in custom integrations, along with the appropriate JavaScript replacement:
| Java method | JavaScript |
equalsIgnoreCase |
str1.toLowerCase() === str2.toLowerCase() |
equals |
str1 === str2 |
contains |
str1.includes(str2) |
To help prevent any problems from arising, we've added handling for the above functions - and provided some helpful error messages to the Activity Stream to point them out - so leaving them in won't break your integrations.
There are some other things that might not be backwards compatible. For example, the following function (along with its working equivalent) isn't supported in ECMAScript 6+:
| Unsupported function | JavaScript |
for each (var element in array1) |
array1.forEach(function(element) (...)) |
Luckily, it doesn't appear anyone is using this function anyway. For calls such as this, the only solution is to edit the integration code to use the correct JavaScript.
Ultimately, the best prevention is simply to make sure that your integration scripts are fully JavaScript and ECMAScript 6+ compliant - something that the more recent versions of the JDK require anyway.
Comments
7 commentsPlease sign in to leave a comment.
Was this announced previously and I just missed it? 2 business days notice is hardly a notice especially for those of us that do need to make changes.
Hi Clayton
Our engineers have already added handlers for all of the potential issues that they could identify, so even integration scripts that do have those invalid Java methods will continue to function. As long as your integration scripts are fully JavaScript compliant, you shouldn't have to actually change anything.
So if we leave the invalid method equalsIgnoreCase as in a inbound integration script for triggering an event, the event will still go through?
Hi Clayton - yes, that's correct. The Integration Builder logs will flag it to make it easier for you to find (and eventually update) those methods, but the scripts will continue to execute and your events will still go through.
I am currently trying to integrate with Stackdriver using the workflow template(converted to custom workflow) provided. I had the Stackdriver admin send me a sample POST message and received the following error:
Script failed with message: TypeError: data.version.toLowerCase is not a function
Here's the message body JIC:
{ "incident": { "incident_id": "f2e08c333dc64cb09f75eaab355393bz", "resource_id": "i-4a266a2d", "resource_name": "webserver-85", "state": "open", "started_at": 1385085727, "ended_at": null, "policy_name": "Webserver Health", "condition_name": "CPU usage", "url": "https://app.google.stackdriver.com/incidents/f333dc64z", "summary": "CPU for webserver-85 is above the threshold of 1% with a value of 28.5%" }, "version": 1.1 }
Please advise.
Thank you.
Two follow-up questions:
1. Is it safe to assume that your JavaScript includes the parentheses? e.g. data.version.toLowerCase()
2. Is data.version a string? (toLowerCase is only for strings)
Sean,
Silly me. Sin in haste...
Thanks for pointing out my oversight (point #2).
I appreciate the prompt response!
Dave