Clarity PPM | Six Best GEL Practices

Today we'll go through six best GEL practices our PPM partner IT-ROI Solutions shared in a webinar given by their president, Federico Pena in May 2015.

Federico’s webinar includes walking-through a brilliant slide deck assembled by engineers Sean Harp and Kelly Limberg, who delivered the information at CA World in 2011. 

GEL Scripts | “Can Script” Doesn’t Mean “Should Script”

Naturally, you want to do things with Clarity PPM (CA PPM) that aren’t available out-of-the-box. This is where GEL Scripting comes in.

"That's right, GEL is the necessary evil when it comes to Clarity PPM," says Marc Latreille, Creative Director at IT-ROI. "Poorly written GEL scripts cause all sorts of issues that everyone wants to avoid. Just because you can do anything in GEL, doesn't mean that you should."

“GEL lets you manipulate data any way you want. It’s almost limitless," says Federico Pena. But GEL scripts can cause massive performance problems.

“The larger your GEL scripts, the more stuff you have in memory, the more complicated it is to process data,” says Federico. “So you want to be really careful about how you write your GEL scripts.”

Common GEL Script Problems

One key problem Federico sees all the time is when organizations create a GEL script containing a XOG script.

“You use the custom script parameters inside Clarity PPM to maintain your user name, password, and XOG URL.” So far, that’s fine. Development happens in dev, and then you move to test and production.

Enter Problem #1.

If you haven’t changed the custom script parameter, the URL will point to the previous system. You’ll try to make changes in production, discover they don’t work, open a ticket, and find out the URL is pointing to the test or dev environment. Easily solved.

But Problem #2 is a bear.

Federico sees organizations get excited at the production level, decide “we want that to be our golden source system,” and then they push the database back into lower environments: dev and test.

But the setting for the custom script parameter is stored in your database.

“So then people start doing development and testing inside the dev and test environment,” says Federico, “and they’re actually making all the changes inside the production environment.”

It’s a bad surprise. “So it can be extremely dangerous to utilize the custom script parameter,” says Federico.

Solving Common GEL Problems

You can solve the problem a couple different ways—Federico points to Sean Harp and Kelly Limberg’s slide deck. One solution is to create a custom.properties file with the URL, usernames, and passwords. “You store this outside of the database,” says Federico.

xog.url=https://<servername>/niku/xog

xog.user=<xog username>

xog.pass=<xog password>

Next you add an entry to the JVM arguments to specify the location of the custom.properties file. This removes any location specific information about the file from the database schema.

-Dcustom.properties=d:/niku/clarity/config/custom.properties

“Then you can utilize the gel scripts themselves to actually get the values, using the “invokeStatic class” to grab that data from inside your gel script,” says Federico.

Or you can take the IT-ROI route and read the properties file from your existing environment, inside the NSA, directly. Check out the start-script Federico says they use in every process by watching his webinar.

6 Best Practices for GEL Scripts

A few other practices will make life with GEL easier on your Clarity PPM instance. We'll go into detail on a few, and the rest you can see in the image below.

All SQL and SOAP tags should be wrapped in gel exception handling.

“This is standard, basic coding procedure for anything that you do,” says Federico.

It’s important to be able to catch exceptions and decide if you want the script to fail or continue. You might be sending a XOG file through a loop 50,000 times.

“If it fails on the third time, do you want the whole thing to fail, or do you want it to continue and trap that one exception?”

All debug statements should be controlled via a parameter that is optional when needed.

“This is a real big one,” says Federico. “Whenever you’re logging data inside a gel script, you’re actually using the <gel:log> or the gel out. It writes it to your BPM error table, which can get pretty large because each log item becomes an entry. That table can get huge and cause serious performance problems whenever you’re validating your processes.”

So the first thing IT-ROI does is set the debug_flag to zero.

<core:if test= “$(debug_flag != 0)”>

When you generate a script and put it inside Clarity PPM during the start of a process, the gel parameter gives you an extra tab called Custom Script Parameters with a user name and a debug_flag.

Using the Custom Script Parameters with the user name and the debug_flag is critical “because they’re the only items you can change inside of a validated active process without having to put it on hold to make modifications and re-validate it,” says Federico. “So the logging piece is critical.”

If the GEL script is performing XOG read/write actions in a loop, the XOG login and logout actions must be outside of the loop.

“This is another huge one. What does this mean?” says Federico. You start your gel script, login, get a session ID, write a query, write a loop, and then your loop actually sends the XOG messages one-at-a-time. At the end, you logout.

“You don’t want to login and logout for every iteration of that loop. That causes major overhead,” says Federico. “Every time you login and out, it’s additional work the BG engine has to do. So you want to make sure that all of your session gathering is kept outside of the loop.”