Updated 15-February-2013 -- Chuck Tomasi

(Content has been moved to the TechNow blog.)

I was working on something today and discovered something interesting. You know me, if I find something cool, I want to share it. I was going through some of the standard script includes that come with each instance when I noticed a gs.getMessage() statement with some intriguing characters and a second parameter. When I figured out what it did, I thought "Oh, how I wish I had this a year ago! It would have been so much cleaner than what I did." Hopefully this article will save you the same frustration.

I'm often faced with providing customers solutions for complex requirements. Some of these requirements come at the end of long processes. For example, "in our change workflow, we want you to look up closure approvers from these set of conditions…" I could put 10-20 lines of code in a workflow script activity, but then I'd have to go through 15-20 minutes of filling out a form, moving it through the change process, only to get to the closure to find out if my code worked or not. Read on for a better way.

System properties are a great way to put configurable parameters in your system without having to modify scripts or workflows. Let's say you've been given a requirement to cancel approvals after three reminders, then someone asks you to change it to five reminders. Using a property, you can change this "magic number" from 3 to 5 without modifying any code. If this number appears in multiple places in the system, all are addressed at the same time just be changing the property. The challenge becomes how to present those properties in a nice format like the out-of-box property pages when you've got a collection to maintain. Continue on faithful reader and I'll show you the quick and simple way to make your properties look great.

Let me introduce you to two of my favorite little JavaScript methods join() and split(). They save me lots of time managing arrays and strings. If you aren't familiar with join() and split(), then let's take a closer look at what some people do instead, the issues with it, and how these two methods can make your life so much simpler.

A customer came to me with a rather interesting request. At first it appeared as a simple database view, but they wanted a few extras thrown in that provided me with a learning opportunity I just had to share with you. If you haven't used database views before, they're a cool way to merge information from two (or more) different tables in to one "virtual table", or view. You can then use them just like any other table to generate reports, gauges, etc.

Last week I needed a way to take two lists of comma separated values and determine what the differences were. A customer was looking for a way to do approvals based on values added or removed from a proposed change to a glide_list on a CI. For example, if SOX was added to the glide_list field, they wanted a group approval based on SOX. If PCI was removed, then a different group was required to approve. With a little XML parsing, I was able to get the old and new list values. My script is written to work equally well on any list of comma separated values. I offer to you, free of charge, as-is my GlideListDiffer script include for your use.

Once upon a time I found a workflow activity called Waitfor WF Event and I thought, "Great, now I can have my workflow pause and if someone clicks a UI action, or a business rule meets certain conditions, I can use gs.eventQueue() to tell the workflow it's time to move on." Unfortunately, it didn't work and that's when I learned that there were two different types of events and how to make that workflow advance when I wanted it to for greater process control.

XML fields are a great way to save form content and apply it later. You may already be familiar with this concept from the Propose Changes functionality. If you haven't used this, here's a quick refresher. At some point in the change process, you right click on an a CI listed in the affected CIs related list, make some changes on the form, then click the Save Proposed Changes UI action, and all your changes are saved in an XML field to be applied later when you click "Apply Proposed Changes." Recently, a customer had me build a cancelation process that did something similar. This is what I came up with…

A colleague of mine recently asked for some assistance in managing Glide List (glide_list) fields. I had written some scripts that were fairly task specific so I rewrote them as generic as possible and share them here.