I’ve been a software developer for 20 years or so, and have been recently doing ServiceNow development. ServiceNow is a decent platform for IT Service Management, change control, CMDB services, and all the canned stuff that they provide. This is my rant about the pain points of developing on the platform. I’m interested in hearing about why you think I’m wrong and will publish reasonable responses when I get them - mike.baranski is my address for gmail.
ECMAScript 5 was released in 2009. That’s all we get. This is an “upgrade” in Orlando, too. How do you release software in 2020 and “upgrade” to libraries that are 11 years old and 4 major versions behind everyone else
This is a big deal, not only because we’re missing useful features.
If we’re looking for developers we are trying to recruit people used to Node, React, Angular, Vue and all the other Javascript frameworks that are not 10+ years old. Using legacy (to be kind) tools is going to be a non-starter for lots of developers.
We want to edit a script. We can do it right in the browser, which is not bad at first glance. If we want to edit 2 scripts at the same time (a Business Rule to put some stuff on the scratchpad, and a UI Policy to display those messages on the screen) you need 2 tabs open.
When we save one tab we go back to the most recent list you had open (even if it was in a different tab). So, we might save a Script Include and wind up back at a list of business rules, which is not intuitive at best.
This quickly becomes confusing and causes us to open everything in a new tab in the browser. This is not a great solution for coding, particularly when we are used to using an IDE (more on the lack of an IDE later).
The Javascript editor is a study in frustration and futility. How? Let me count the ways:
There’s an editor with syntax highlighting. Awesome! Let’s write a script that has maybe 50 lines. Cool. Then let’s save the script while we are on line 49. Shit, our cursor is back at the top of the file and we are not where we were editing! No problem, it’s only 50 lines. Now try it with a 200 line file and you are editing in the middle. This sucks
There’s a full screen editor. Sweet! Now let’s save the script we are in the middle of. Wait - now the editor is no longer full screen and our cursor is back at the top of the file! What line was I on? I have to make the thing full screen again? All I did was save the file and I have to re-size my editor and figure out which line I was on again…
CMD-right and CMD-left go to beginning and end of line. Fn-up and Fn-down page up and down. OPT-left
and OPT-right move one word at a time. Cool! How do I:
Can’t do any of that? It’s not very useful for more than basic editing, and even then for scripts that are less than 10 or 15 lines.
Studio is an attempt at giving us an IDE. We get some pretty good improvements over the regular editor:
Multiple tabs for editing (though no way to switch via keyboard shortcut, which is more frustrating than multiple
browser tabs sometimes - at least we can switch browser tabs with CMD-Tab)
A convenient list of file to edit in the project view
“source control” (not really proper source control but the button is there to be excited about)
Looking a little bit deeper, we can see that this is just window dressing (aside from the multiple editor tabs). What are we missing?
Keyboard shortcuts (again…) - how do we switch between tabs without the mouse? (spoiler: we don’t)
The full screen editor still reverts to the small editor when we save
Saving a script in the editor still takes us to the first line in the file
We cannot edit ATF tests in studio. This is a big one, because we’re back to the incredibly frustrating browser interface trying to edit multiple scripts at the same time. We also have the usual back button lottery and a magic-8-ball-like redirect when we save a file.
“Source Control” in SN is a misnomer. It should be called snapshots. Source control should provide us:
SN provides none of this, all it does is stuffs its proprietary XML formatted records into git. We get nothing useful here except being able to branch a project and have snapshots of older versions of our code (which you can’t actually read without reverting to that snapshot on an SN instance because it’s a mess of XML in git).
In continuing the trend of getting excited about a promising headline but being let down by the implementation, we’ll look at what SN gives us with the new VSCode IDE integration. This sounds great, in theory. We’re missing some things that are pretty important, though.
Well, at least there are lots of docs. Sometimes, they are even useful, and mostly they are correct.
They are not, however, complete.
Let’s say you want to create a UI action that shows up on a list page that does something (sets a user preference) without any records selected.
** There’s got to be an option for that, right? ** - Nope - no configuraiton option for it
** There’s got to be a bit in th UI Action documentation for that, right? ** - Nope - nothing in the docs
** It must not be possible then, right? ** Nope - it’s possible (sometimes, not in all cases, of course)
So, get on the Slack channel and ask and someone says search for sysverb - however, sysverb does not
show up in the docs. After hunting around in the community docs, we find a sentence in a reply 4 replies
down from a question that says:
I found that it seems to be an issue that can be resolved by naming the action name the prefix "sysverb" and then anything after that. There must be some hardcoded check to see if sysverb is prefixed in the action name, and if so it will not require selection from the list view.
Well, this is great news. Let’s use it. Of course, it works except for the List Link action type. Then it does not work. Is there something that does work for the link? Who knows? It sure as hell is not documented.
This sucks.
We finally got a File Attachment field type! This is great, because now I can validate that people have provided a document for specific fields (rather than counting attachments and validating those). This is awesome, except it’s implemented in a (now typical) half-assed way that is only partly usable.
Sure, you can attach a file with a file attachment field. That works.
Now, make it mandatory in Studio and try to submit a record. You can’t submit the record because even if you attach
a file to that field, you get the message The following mandatory fields are not filled in: Design document.
That sucks.
OK, now we’ll pretend we wrote a BR to do our validation. That’s a pain in the ass for a “new” feature and should never should have gotten past SN’s QA, but whatever. Now let’s write an ATF test to test this form (remember: we’ll need to attach a file to this required field).
hmmmm, there’s an ATF step to attach a file to a form, but that does not work for the File attachment fields.
That sucks.
Let’s script it.
After several hours of investigating why I can’t set a File attachemnt field value with a script,
it becomes apparent that it’s just a little bit better than useless. When SN creates a File attachment, the file goes
into the sys_attachment (and related) table(s) just like regular attachments and the field gets the ID.
Except the table_name is ZZ_YYtable_name instead of just the table name.
Where is this documented (spoiler: it’s not)?
Add another field, and what will the table name be? I’ll leave that as an exercise for the reader
I feel like somebody promised me the world and sent me to Cleavland.
Another day, another half-day wasted because of a shitty implementation in SN!
Today, we bring you scoped apps and email scripts. Email scripts are simple: we create one that injects some code into an email template, reference it in the template and bingo! Custom
It probably even actually works as documented. Sure it does. Unless we use it in a scoped app.
Then, when we call template.print("ZZZZZ"); it does not work.
There’s no error in the logs. We don’t get any indication of what is wrong.
However - if we do this:
try {
var res = template.print("ZZZZZ");
} catch (e) {
gs.error("EScript threw Exception: " + e);
}
We see that there is an exception because of cross-scope access. Now, having gotten this far into the ServiceNow sucks page, we know all about cross scope access. Why can’t SN print a fucking error message when there is clearly an exception thrown? That’s rhetorical, of course, because it makes no sense at all.