Service Now - Service Now Sucks

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.

Rhino and ECMAScript 5

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.

Editing/working in multiple tabs

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).

Javascript Editor

The Javascript editor is a study in frustration and futility. How? Let me count the ways:

1. 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

2. 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…

3. 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:

   • Save a script with a keyboard shortcut?
   • Switch to full-screen editing with a keyboard shortcut?
   • Jump to a matching brace?
   • Jump to the next/previous warning/error line?
   • Navigate to the definition of a function/variable that the cursor is on?
   • Get autocomplete for anything but the most basic objects?
   • Use typescript to keep my scripts sane?
   • Jump to the unit test for the script I’m writing
     

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

Studio is an attempt at giving us an IDE. We get some pretty good improvements over the regular editor:

1. 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)

2. A convenient list of file to edit in the project view

3. “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?

1. Keyboard shortcuts (again…) - how do we switch between tabs without the mouse? (spoiler: we don’t)

2. The full screen editor still reverts to the small editor when we save

3. Saving a script in the editor still takes us to the first line in the file

4. 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.

5. “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 and pull requests
   • file editing with the tool(s) of our choice
   • 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 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).

VSCode Integration

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.

1. We cannot edit ATF tests is VSCode. This is a major pain. ATF is great because it lets us use Jasmine for unit tests. However, we are stuck with the almost-mediocre web-based editor. This is probably my biggest complaint. Dangle a real IDE in front of us and then give us a half-baked integration with it.
2. No true git integration, no support for Typescript, no help for the IDE’s autocomplete. This is marginally better than copying/pasting between an IDE and the browser. That’s pretty much it.

File Attachment field type

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.