How to Ace your ACE Report

For those that don’t know, the ACE report is an automatically generated list of best practice violations. Only ServiceNow has the ability to run the report, and it’s often done at the end of a Professional Services project or before a ServiceNow Professional Services sales person meets with a client.

Because the ServiceNow ACE report is a relatively new entry into ServiceNow history, Few techs are aware of the standards, and even fewer initial implementations follow this set of best practices.

My goal here is to list out a very short set of rules to adhere to that will ensure your instance will pass the ACE report if and when it’s run. This is of course by no means intended to be a guarantee, and in fact I’ll leave out a handful of items that you’re unlikely to violate anyhow. That said, I do hope this list will get you off to great start.

Rules to Follow

  1. Integrations / Imports
    1. Coalesce fields in Transform Maps should be indexed.

      In order to prevent performance bottlenecks on tables with large data sets, it’s important to index the columns that are used to identify unique records during import.

    2. “Run business rules” should be disabled on Transform Maps.
    3. LDAP Server should be set to only grab needed attributes.
    4. JDBC Data Sources should use the “Use last run datetime” option.
    5. SOAP getResponse() method is inefficient and should never be used.
    6. onBefore Scripts on Transform Maps shouldn’t insert or update records on other tables.

      Take care of this in onAfter or ASYNC scripts instead.

  2. Client Scripts
    1. Client Scripts should be wrapped in functions.

      Wrapping your scripts in a function helps prevent the global namespace from being polluted, this in turn reduces unpredictable behavior.

    2. All clients script functions should be used in an asynchronous manner.
      1. Look up on the Wiki how to use a callback function with getReference and GlideAjax.
      2. Avoid GlideRecord, even with a callback function. Instead create a Script Include that will return only the very specific information you need, and use GlideAjax to communicate with it.
    3. Do not use DOM manipulation.

      While jQuery, Prototype, gel(), and getElementById are supported, they’re not recommended, and can break during upgrades of ServiceNow.

    4. Client Scripts should always check for g_form.isLoading() and exit the script.
    5. Global client scripts are never to be used. Use a UI Script when absolutely necessary instead.
    6. Client Scripts should not be left with an empty script field.
    7. Client Scripts should not contain hard-coded sys_ids.
  3. Business Rules / Script Includes
    1. Client Scripts and Business Rules should be wrapped in functions.

      Wrapping your scripts in a function helps prevent the global namespace from being polluted, this in turn reduces unpredictable behavior.

    2. Global Business rules are never to be used.

      These cause performance issues doing to always being included. Pretend they don’t exist, and use Script Includes instead.

    3. Never use “gr.getRowCount()”.

      The getRowCount() method is very inefficient. Instead learn how to use GlideAggregate.

    4. Before Business Rules shouldn’t insert or update records on other tables.

      Take care of this in onAfter or ASYNC business rules instead.

    5. Never use eval(). Ever.
    6. Scripts should not use hardcoded sys_ids. Instead use a system property to store the value.
  4. Navigation and UI Properties
    1. Modules to large tables should have a filter.
    2. User Preference for rows per page should be 20 or less.
    3. Rows per page options should be limited to 100 rows at most.
    4. Update on Iterate property should be disabled.

      With this property on, as people use the up/down arrows to navigate through records, it would attempt to update the record every time, regardless of whether any changes were made.

    5. Go To search property should default to something other than “contains”. (Performance reasons.)
  5. Security
    1. High Security Plugin should be turned on.
    2. High Security should be set to Default Deny.
  6. Avoid current.update() in these situations:
    1. onBefore Scripts on Transform Maps
    2. Business Rules
    3. Workflow Script Activities

    In all of these situations, there’s other, better ways to ensure that your information gets saved to the database.

  7. Debug Setup
    1. Console.log() should not be used in client scripts.
    2. Debug statements should be removed before code is pushed to production.
    3. SLA Logging level should be “notice”.
    4. Debug properties should be disabled in production.
    5. Errors occurring in Production instances should be under 10,000 per day.
  8. Domain Separation
    1. Admins should be in TOP domain, not global.


Categories: Developers, Scripting Tips

Tags: , , ,

2 replies

  1. It’s worth noting that some Partners (such as Fruition Partners, do get in touch if you’d like to know more david.field@fruitionpartners.com) also have access to the ACE tool

    Like

Trackbacks

  1. Bite #14: Display Business Rules & g_scratchpad | GarrettNow

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: