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.
We want to edit a script. We can do it right in the browser, which is not bad the first few times. 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 log messages.
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 that later, of course).
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-down page up and down.
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
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 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 useful diffs, the ability to do code reviews via pull requests, file editing with the tool(s) of our choice, and CI pipeline support. 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 nominally branch a project and have snapshots of older versions of our code.
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.
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.
OK, now we’ll pretend we wrote a BR to do our validation and we have that working. That’s a pain in the ass for something that never should have gotten past SN’s QA, but whatever. Now let’s write an ATF test to test this form (hint: 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.
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.
table_name is ZZ_YYtable_name instead of just the table name.
Add another field, and what will the table name be? I’ll leave that as an exercie for the reader.
It’s pretty clear that this feature is not implemented well in SN.
It’s a shitty answer to the requirement of having named fields for attachments in SN.