Skip navigation

Thank you to the 2,646 developers that responded to the survey that was conducted in January.  We appreciate the time, feedback and the insights you provided us.  This information will play a vital role in continuing to shape the Developer Program around your needs.

 

Below is an infographic of the results followed by a more detailed explanation of each section.  Please give us your comments and thoughts below as well.  We are considering running this survey twice a year due to the valuable information the developer community provided us.

Infographic.png

Respondents

 

The 2,646 respondents to the survey represent 11% of the total number of registered developers in the program in mid January that was nearly 25,000 individuals.  We really appreciate the incredible response rate and thank those of you that responded.  Your participation and the data the survey generated is motivating and inspiring to the Developer Program team.

 

We asked five questions in order to understand the respondent’s development background, and along with insights on what training they completed, we were able to break down the respondents into the three groups: developers, admins and users.  Based on feedback and emails we receive, this appears to be very representative of the current registered developer population.  Although the program is designed for developers and technically savvy admins, we are happy that users from ServiceNow customers are leveraging the program to understand some of the base applications on the ServiceNow platform.

Respondents.png

Experience.png

ServiceNow Experience

 

The survey asked a few questions on ServiceNow development experience and what elements of the platform the respondent felt comfortable doing.

 

The developer community has an average of 2.3 years of experience with 6 folks responding that they had more than 10 years of experience on the ServiceNow Platform.  This makes these developers the earliest on the platform in 2004 and 2005.

 

We asked respondents what aspect of the platform they felt the comfortable or proficient, and to choose everything that applied.  The provided options ranged from creating forms and lists that 87% of respondents felt comfortable doing to Orchestration and Performance Analytics where just above 10% of surveyed developers were proficient.

 

Of concern to the program team is that only 24% of the developer community is confident building and deploying scoped applications.  Every training on the site guides developers in building and extending scoped applications as the preferred way to build applications.  The Developer Program team will work on this opportunity to help the developer community to improve confidence in the new application model.  Look for more content in the coming months.

Certifications and Training

 

We finished the section on ServiceNow Experience with a couple of questions on what training and certifications the registered developers have completed, and which training and certifications they want to take.

 

Almost half of the respondents have one or more of the three available certifications: Certified System Administrator, Certified Implementation Specialist and/or Certified Application Developer.  Currently, only 8% of the developer community are certified application developers, but 50% want to become Certified Application Developers.

 

Only 31% of respondents haven’t taken some form of in-person or virtual training, but 33% want to attend the Scripting course, and 29% wanted to attend the Application Creation class provided by ServiceNow Education Services team.  Scripting was the most desired course that respondents wanted to take.

 

Look for an upcoming promotion that will make taking in-person training and achieving certifications easier.

Certification and Training.png

 

Art or Science.png

Developing Applications: Art or Science?

 

Between each section of the survey, we asked more lighthearted questions that made the survey easier to complete.  Consequentially, these questions also provided us with some great insights about our developer community.

 

This question is one that I asked routinely while interviewing developers.  Is developing applications an art or a science?  The survey only provided the responses "Yes", "No" and "Other" with the ability to write in your own response to "Other".  Interestingly, about 30% of the respondents wrote in with some form of both.

 

The answer to this question is subjective, and I was more interested in the rationale behind the answer verses the answer itself.  Since I have a Computer Science Engineering degree, my education makes me lean towards a science, but my experience has led me to believe that it is also an art to make supportable applications that withstand the test of time.

Developer Site Features

 

We asked what was the most important aspect or feature of the site.  Not surprisingly, the highest ranked feature was the free Personal Developer Instance ranked 4.7 out of a possible 10.  Developer documentation, training and the API reference all came in relatively tied at 3.6 to 3.7.

 

The survey proceeded to ask about the features on the developer site, specifically, what is considered a priority to be improved first?  Four features were ranked at the top.  The API reference was ranked the highest with associated feedback on both the survey and on the Developers Site wanting it to be a complete reference for all ServiceNow API information.  We listened, and today you will find both scoped and legacy server-side API information as well as client-side API information.  Soon we will be publishing a comprehensive REST API section to round out the API reference on the site.  At this point, the Developer Site is the definitive source for ServiceNow API reference information.

 

Training was the next highest priority for improvement followed by instance availability and inactivity time.  The Platform Business Unit has invested in more instances assigned to the Developer Program that almost doubled capacity. There are now currently plenty of available instances on the Developers Site.

Dev Site Features.png

Training Improvements.png

Developer Training

 

The survey dived into specifically how we could improve the current developer training on the site.  Respondents were asked to pick their top three areas (which is why the percentages add up to over a 100%).

 

In our top band, 59% wanted to have more advanced courses than what is currently on the site.  Once again, we have made progress on this feedback.  We have courses on Orchestration and Performance Analytics that will be published to the site soon.  We have Service Mapping and Discovery in plan for later in the year.  With the Helsinki release, we will also be expanding our content on AngularJS and single page apps.

 

In the next highest band, the developer community wanted embedded videos, more courses in general and quizzes to validate they picked up the concepts.  Look to see progress on these priorities throughout the year.

Marvel vs DC

 

Our second lighthearted question revolved around the all-important preferred super hero universe: Marvel or DC.  This question had additional answer options of “Other” and “What is a Super Hero Universe”, which explains why the two percentages do not add up to 100%.

 

Younger audiences tend to prefer Marvel characters, and older audiences lean towards DC, so this gives us an idea about who is in our developer community.  With a number of respondents not knowing what a super hero universe was, it seems we have a fairly large number of international respondents.

 

Unfortunately the results are bad news for poor Wonder Woman who is weeping.  Perhaps if we ask this question in the second half of the year after the Batman vs. Superman movie comes out, we might see a shift since most of the recent big movies are from the Marvel universe.

Marvel vs DC.png

Results.png

Developer Program Impact on My Company and Me

 

The survey then asked a series of questions on results of the platform and the Developer Site for the respondent and the respondent’s company.

 

Since the current developer ecosystem is comprised of customers and partners, having almost 90% of the respondent’s company’s primarily using the ServiceNow platform is expected.  As we push the platform and program beyond the current ecosystem, this question becomes more interesting.

 

Another interesting piece of information for the program team was how the Developer Site helps the individual developer.  The respondents had a wide range of possible answers, and they were given the option to select all that applied.  33% of the respondents reported they would recommend the platform based on the Developer Site, which is very encouraging for us.  Even more inspiring is 13% indicated that they were able to get a better job and 10% actually got a job from using the Developers Site.

 

We are looking to spotlight some of these stories on the site and at developer events.  We measure our success based on your success so it is really wonderful to hear about how we are making a difference in the developer community.

Number of Applications in Production

 

The primary objective of the Developer Program is to encourage folks to create applications on the ServiceNow Platform.  With 50% of the respondents saying that they have 3 or more custom applications in production, we now have a baseline that we will attempt to increase over time.

Apps in prod.png

Life beyond earth.png

Intelligent Life Beyond Earth

 

The most important question we asked was whether or not the respondent believed in intelligent life beyond Earth.  12% of the respondents wrote in with the "Other" option that the question was basically moot since there was no intelligent life on Earth.  We have a very optimistic developer community

I thought I would share this as something of importance.  I know as ServiceNow software developers we do not build what could be termed necessarily as life-critical-systems (failure of which could cause loss-of-life); that I am aware of, but we do build software that if done poorly could result in loss of money. 

 

For several years now ACM (Association for Computing Machinery) has been tracking Software Risks-to-the-Public via the Software Engineering Special Interest Group (SIGSOFT).  I received my copy once-a-month for several years, and it made me a believer.  No matter how small the system you work on; always keep in mind risks to the user base, and failure recovery. 

 

The link below is for a cumulative article published as of early last year, by Peter Neumann of SRI International (Stanford U.) in Menlo Park.  It is in essence everything from the ACM publications, but also covers hardware problems.  Take special notice of the Descriptor Symbols section.  Then read on.  It is amazing what is listed.

 

Build it solid.  Unit test everything.  Be responsible for your code!

 

Illustrative Risks to the Public

 

Steven Bell

Articles List to Date

 

If you find this article helps you, don't forget to log in and "like" it and Share it!

 

CS_logo.jpgMVP-logo.jpeg

Please Share, Like, Comment this blog if you've found it helpful or insightful.

One of the new features in Geneva is the ability to write Scripted REST APIs. These take the place where Processors were used previously but have a richer feature set and more flexibility.

 

Scripted Rest API basics

 

When you create a new API inside the Studio environment, you define a name for it and an API ID (which will default to the name but can vary independently). Based on your currently selected application scope, it will automatically choose that application and namespace which corresponds to your scope identifier. Finally, you can set a protection policy to use no protection, make it read-only or protected.

 

After saving or submitting, you will see the Base API path that was created for you. This will be /api/<APPLICATION_SCOPE>/<API_ID>/ . That will be the prefix for all the individual resources you create, so if you create resource “foo”, your fully qualified URL would be:

https://instancename.service-now.com/api/<APPLICATION_SCOPE>/<API_ID>/foo

 

Screen Shot 2016-02-24 at 11.04.28.png

 

Upon creating a new resource, you will be asked for the name of the resource, the HTTP method or verb used to access it, and the relative path.  The relative path can be arbitrarily complex and as in this screenshot, can contain multiple levels of path. You are not limited to a single level.

 

In addition, you can define path parameters as part of this relative path. Any parameter defined as part of the path as in the example will then be available to the scripting environment. The bracketed text will become a variable that is available from the request.pathParams object. More on this later.

 

 

Screen Shot 2016-02-24 at 10.21.40.png

 

Verbs

 

As you would expect in any modern API, you can support any of the HTTP verbs for any resource you define. This allows you to use the style of a single endpoint with multiple verbs where

 

GET /item/{id}

 

would be used to get the read view for a single data item while

 

PUT /item/{id}

 

would be used to update it and

 

DELETE /item/{id}

 

would then remove the item from the database. This allows you to create a simple externally facing interface that conforms to the style that other systems expect.

Scripting

 

Associated with every resource is a scripting window. This is where the work of Scripted REST APIs really happens. The context of the script window provides a request and response object. As part of the Geneva enhancements you will be able to see all the methods available on these objects using the autocomplete functionality.

 

The main functionality provided by the request object is the hashes for pathParams and queryParams. In the example above where the resource is defined with an {id} template for the path parameter, that is accessed in scripting by

 

     var id = request.pathParams.id;

or alternately (both syntaxes work)

    var id = request.pathParams['id'];

 

The same thing can be done for query parameters, so that if the resource was called with a query string of “?maxRecords=30”, it would be available to the script by

 

    var id = request.queryParams.maxRecords;

 

The response object allows for low level control of the return, including manipulating headers, status codes, and the stream writer of the response itself. It is not necessary to use it, if a JSON object is returned by the process(request, response) function then that will be the output, defined as “results” similarly to the default behavior of GlideAjax.

 

Inside this scripting environment, you have full control over the system up to the limits of the scope, with access to GlideRecord, GlideSystem and the functionality you would expect in a scripting environment. This allows you to within a scoped application expose any functionality that the scope can access through the system. For example, it would be possible to create a scoped application called “IncidentPlus” that provided a full logical API for interacting with Incident records on the core system. Although the scoped application would own the REST API endpoints, the functionality can be anything allowed in that scope and does not need to be confined to records within that scope.

 

Screen Shot 2016-02-24 at 22.20.35.png

 

 

Rest API Explorer

 

Once the endpoints are defined, the REST API Explorer on your instance can be used to interact with and test your API. It works exactly the same for your custom defined endpoints as it does for system provided APIs like the Table API. You will be presented with an interface to pick the Namespace, the API, the version and which resource to access. If the endpoint has path parameters defined there will be fields to enter those, and also the ability to add arbitrary query parameters to the request. Additionally, you can manipulate the headers such as the request and response data formats, and as well can add arbitrary headers if you desire.

 

Screen Shot 2016-02-24 at 10.39.43.png

 

Sending the request will then display the return value. If you did everything correctly, you will see a status of 200 and the data you expected. If debugging, you might commonly experience a 500 error and some error messaging. You can use the REST API Explorer as a debugging tool to exercise your API until you get the logic correctly working.

 

Screen Shot 2016-02-24 at 10.44.24.png

Versioning

 

Versioning was briefly mentioned above. Scripted REST APIs support versioning, which is also a best practice of using them. This allows for adding, deprecating or altering behavior of the API in a subsequent version while leaving the original API with original behavior operational as a previous version. This way current users of the API can be protected from changes. If your request uses a version qualified endpoint, then it will not accidentally be using functionality that was not intended.

 

This implies that when publishing an API version that behavior be held consistent within that version. Any change that would break the logic of consumers of the API should always be contained in a subsequent version to minimize disruption to any deployed accessors to your API. When publishing your APIs, publishing the versioned form of it allows consumer to "pin" their implementation to your version of the API, again isolating the consumer from any future changes.

 

 

Summary

 

Scripted REST APIs present a powerful tool to developers. They allow users to define logical level APIS, with little or no implementation details required to use them and arbitrary scripting to deliver the resources. This enables more robust, less brittle integrations with external systems and less time spent maintaining this connection.

 

If you have interesting idea  for (or even deployed) REST APIs, please leave them as a comment on this post. These are an exciting addition to the toolkit that really have no upper limit to the value they can enable. I am personally looking very forward to seeing the work that happens out in the world with Scripted REST APIs so let me know how you are using them.

 

For more information you can look at the Documentation site and also watch the episode of TechNow in which I did a demonstration of some of the capabilities of Scripted REST APIs. Happy exploring!

Dave Slusher | Developer Advocate | @DaveSlusherNow | Get started at https://developer.servicenow.com

In my last blog post 5 Ways to Troubleshoot your Instance Performance I have shared a few tips which enable administrators to diagnose performance issues. As a performance engineer, homepage performance is one of the most commonly diagnosed problem areas we assist customers with. Heavy home pages can lead to overall instance performance degradation.

 

Inefficient homepages lead to poor end user experiences e.g:

- Slower logins

- Poorer instance performance at peak login times

- Poor performance on form submission (where redirect to home.do occurs)

- Homepage auto-refresh functionality (https://docs.servicenow.com/use/homepages/reference/r_RefreshTheHomepage.html) can compound the problem where inefficient home pages are concerned

 

While designing home pages, ask yourself which information do you need to rendered as a part of home page loading and which one is not?

 

How to identify if your instance performance is suffering due to a heavy homepage

Hefty home pages can result in slow load times, which may lead you to think there's something wrong with your overall instance. Administrators can review the transaction logs and look for URL starts with "/home.do" and check through the response times. Sort the response times z > a and look for the usernames with highest response time.

identify instance performance.jpg

 

This will help to pinpoint the users with heavy home pages. If the  response times of multiple "home.do" transactions is high ( > 8-10  seconds), that could be impacting the overall instance and causing a load on the database as well.

 

Homepage best practices to improve performance time

  1. Avoid having too many gauges in one dashboard, especially from big tables. Aim for no more than 4 gauges per page - split onto other pages if more needed.

        A dashboard should be designed with gauges that show focussed and pertinent items of data that should invite a user to drill down further if needed.

   2.  As an admin user, make use of debug options  by enabling "Debug home page rendering."                                                                                                                                                       

    1. Impersonate one of the users with a heavy homepage. It will display the time each widget is taking. Remove heavy widgets and run it as a report, or see if there are ways to optimize the performance of those reports by adding additional filters.

  3.   Avoid frequent homepage refresh.

    1. Setting auto refresh for every 5-10 seconds could result in session synch waits. Doing the frequent refresh by multiple users can lead to massive database workload.  Refresh option can be entirely disabled by creating the "glide.home.refresh_disabled" property and refresh intervals can be customized using "glide.home.refresh_intervals" property.

  4.   Make use of multi threaded homepage rendering, see Parallel Homepage Rendering Explained for more details.

  5.   Design and set a default system homepage preference so that users who haven't selected a specific home page will land on a lightweight default homepage.

  6.   Always report on current (active=1) data - gauges that show trending on historical or inactive data should be moved to "Reports" wherever possible

    1. For example, try the Incident > Resolved, then try it again after adding active=true to the filter. For more tips, refer Improve performance by displaying "just enough" data

  7.   Think carefully about allowing non-admin users to create their own custom home pages - if this is allowed ensure users have a good understanding on how to design good home pages

  8.   Do not put slow gauges on the same page as fast gauges - defeats advantage of multi-threading which the platform supports

 

 

For additional information on homepage performance see:

Homepage caching

Change the parameter for parallel homepage rendering

Configure homepage cache properties

Troubleshoot reports on a homepage for performance

How do you enhance Homepage performance in case of gauges ? i) Increase the number of gauges ii) decrease refresh time of gauges iii) Off Refresh button/delete groups

How to improve the performance of home page

In this final Workflow Control Pattern article we will be using what we learned with Variable and Property control and building a hybrid that uses both.  This has a bit of twist to it, and thus the reason for this particular pattern.  BTW, this pattern is the one I use the most when dealing with Service Catalog items.

 

The other articles in this series:

 

  1. Pragmatic Patterns: Workflows - Using Data to Adjust the Flow
  2. Mini-Lab: Workflow Control Via Variable Input (Intermediate Skill Level)
  3. Mini-Lab: Workflow Control Via Property Input (Advanced Skill Level)

 

 

Prerequisites:

 

  • Intermediate to Advanced experience with ServiceNow will smooth over places in the labs where I don’t spell out exactly what should be done.  Consider this an Advanced Skill Level article.

 

  • You are going to want to work through the Property Input article (#3) first.  We will be expanding on the Service Catalog and Workflow we constructed there.

 

  • Also, if you have not done so, you might want to run through my other lab on how to do advanced work with the If Activity; as we will be using the techniques describe there in this series of labs:

 

Mini-Lab: Workflows - Playing With the If Activity

 

 

Requirements

 

  1. Create a Service Catalog Item / Workflow combination where properties changed by an application owner will affect what occurs in the workflow.
  2. Place this Service catalog Item under the Can We Help You? Service Catalog Category.
  3. The name of the Service Catalog Item will be: Workflow Control via Property Input
  4. The Service Catalog item will contain a single variable: State.
  5. State can have four choices: New, Active, Open, and Closed.  The underlying values of these will be 0,1,2,3 respectively.
  6. Only the Order Now button will appear on the Service Catalog Item.
  7. There will be a new application named: Workflow Patterns
  8. There will be a section under Workflow Patterns labeled: Administration.
  9. In the Administration section there will be a module that will contain a properties page named: Properties.
  10. There will be three properties:
    1. Property 1 will be labeled: React on Active?, and will be a checkbox.  Default will be checked.
    2. Property 2 will be labeled: React on Open?, and will be a checkbox.  Default will be checked.
    3. Property 3 will be labeled: Possible Choices (New, Closed, Monkeys)
  11. The workflow will print a message in the log that indicates a particular state was chosen.
  12. The workflow will check to see if the React on Active is checked.  If it is it will place a log statement saying so in the System Log.
  13. The workflow will check to see if the React on Open is checked.  If it is it will place a log statement saying so in the System Log.
  14. The workflow will check to see if the New and/or Closed are listed.  If either is it will place a log statement saying so in the System Log.
  15. If nothing is chosen or an unknown value is present then an unknown message will be printed in the log.
  16. If Monkeys is listed in the Possible Choices field then the Active, Closed, and Unknown log messages will change to reflect that Monkeys was chosen.

 

Design

 

1. Create a Service Catalog Item (Req #1)

    1. Name: Workflow Control via Property Input (Req #1,3)
    2. Category: How Can We Help You? (Req #2)
    3. Deactivate every shopping cart feature except Order Now. (Req #6)

 

2. Catalog Item Variables: (Req #4,5)

    1. Name: State
    2. Choice List
    3. Choices: New, Active, Open, Closed
    4. Values will be the strings: 0, 1, 2, 3
    5. Choices will be entered into the Choices table

 

3. Create a new Application (Req #7,8)

    1. Name: Workflow Patterns
    2. Create a section in the new application labeled: Administration.

 

4. Create three System Properties (Req #10)

a. Name: workflow.react_on_active

    • Description: React on Active?
    • Type: true/false
    • Associated to Workflow Patterns -> Properties page

b. Name: workflow.react_on_active

    • Description: React on Active?
    • Type: true/false
    • Associated to Workflow Patterns -> Properties page

c. Name: workflow:possible_choices

    • Possible Choices (New,Closed)
    • Type: String
    • Associated to Workflow Patterns -> Properties page

 

5. Create a new System Property Category

    1. Name: Workflow Patterns
    2. Title: Workflow Patterns
    3. Associate this to the two system properties in Design#4.

 

6. Create a new Module under Workflow Patterns (Req #9)

    1. Name: Properties
    2. Type: Properties page.
    3. Link: Workflow Patterns System Property Category.

 

7. Workflow design will be as follows: (Req #1, 11,12,13,14,15,16)


 

 

Development

 

Our requirements and design are finished. Let us now create the solution!

 

We will be building off of our solution from the previous article.  So, same properties; we will be adding one new one.  Same properties page, and application.  Same Service Catalog.  However, we will be copying our previous workflow and expanding on it.

 

 

Lab 1.1: Adding Possible Choices to the Properties Page

 

1. In the navigation filter type sys_properties.list and press enter.  This will open up the System Properties list view.

 

2. Click on the New button to open the New properties form.

 

3. Fill in the form with the following:

    1. Name: workflow.possible_choices
    2. Description (this will act as the question in the properties page): Possible Choices (New, Closed):
    3. Type: String
    4. Value: New,  Monkeys
    5. Right-Click on the form header to display the form context menu, and choose Save to save your work.
    6. Scroll to the bottom of the form to view the System Property Category list view.  Note that it is now empty.
    7. Click on the Edit button.  This will display a Select List of System Property Categories.
    8. Filter for Workflow Patterns, and select this category. 
    9. Click on Save to save your work.  This will display the workflow.possible_choices property form. Scroll to the bottom to verify that the property is now associated to the Workflow Patterns System Property Category.
    10. Click on the Workflow Patterns link in the System Property Categories related list.  This will display the Workflow Patterns System Property Categories form.
    11. Scroll to the bottom of the form.  You will see the associated System Properties list view. Note the ordering.
    12. Make the workflow.possible_choices order to be 300.
    13. Click on the Update button to make sure you save your work.  To make sure you have saved your work. This will return you to the workflow.possible_choices form. 
    14. Click on the Update button to make sure to save your work.  Just to make sure your work is saved.  This will return you to the System Properties list view.

 

 

Lab 1.2: Creating the Workflow

 

1. Navigate to Workflow -> Workflow Editor.  A new tab will open in your browser and the Workflow Editor will be displayed.

 

2. From the Workflows tab scroll down until you find the Workflow Control Via Property Input, which you created in the previous article.  Open the workflow.

 

3. Click on the “hamburger” (Workflow Form Context) button in the upper left to display the Context menu.

 

4. Click on the Copy menu item.  This will display the Workflow Name form

 

 

5. Fill out the form with the following:

    1. Name: Workflow Control Via Variable Examination
    2. Click on the OK Button to create the new workflow.

 

Snap 2016-02-16 at 08.15.56.png

 

6. Right-Click on the Check Properties If Activity header to display the Activity Context menu, and choose Add Condition (be patient, for whatever reason this can take several seconds to display!).  The new Condition Properties form will appear.

 

 

7. Fill out the form with the following:

    1. Name: isOpen
    2. Condition Type: standard
    3. Skip during generate: checked
    4. Condition: workflow.scratchpad.result.open == true
    5. Click on the Submit button to save your work.

 

8. Repeat the procedure.  Fill out the form with the following:

    1. Name: isClosed
    2. Condition Type: standard
    3. Skip during generate: checked
    4. Condition: workflow.scratchpad.result.closed == true
    5. Click on the Submit button to save your work.

 

9. Open the Check Properties If Activity

 

a. Name: Check Properties (just making sure)

b. Change the Script to be the following:

 

var identifier = context.name + '.' + activity.name;

workflow.scratchpad.result = ifScript();

function ifScript() {
            var result = {new1:false, active:false, open:false, closed:false, monkeys:false, unknown:false};       
            
            result.new1 = (workflow.variables.state == 0 && workflow.scratchpad.new1);
            result.active = (workflow.variables.state == 1 && workflow.scratchpad.active);
            result.open = (workflow.variables.state == 2 && workflow.scratchpad.open);
            result.closed = (workflow.variables.state == 3 && workflow.scratchpad.closed);
            result.monkeys = workflow.scratchpad.monkeys;
            
            // Debug
            //gs.info('---> [WF:{0}] {1} - {2} - {3} - {4}', identifier, result.new1, result.active, result.open, result.monkeys);
            
            // make sure you have a catch all
            result.unknown = (
                        !(result.new1
                          || result.active 
                          || result.open
                          || result.closed)
            );
                                                              
            return result;
}

 

c. Click Save to save your work.

 

 

10. Your If Activity should look like this:

 

11. Open the Initialize Run Script Activity.

 

  1. Replace the Script with the following:

 

var identifier = context.name + '.' + activity.name;

workflow.scratchpad.active = gs.getProperty('workflow.react_on_active') == 'true';
workflow.scratchpad.open = gs.getProperty('workflow.react_on_open') == 'true';

// separating these out into individual ifs allows for parallel execution in the
// workflow.  Be careful with this.  It could introduce problems if you don't do
// it correctly.
workflow.scratchpad.possibleChoices = gs.getProperty('workflow.possible_choices').toLowerCase();

workflow.scratchpad.new1 = (workflow.scratchpad.possibleChoices.indexOf('new') > -1);
workflow.scratchpad.closed = (workflow.scratchpad.possibleChoices.indexOf('closed') > -1);
workflow.scratchpad.monkeys = (workflow.scratchpad.possibleChoices.indexOf('monkeys') > -1);

// Debug
//gs.info('---> [wf:{0}] {1} - {2} - {3}', identifier, workflow.scratchpad.new1, workflow.scratchpad.closed, workflow.scratchpad.monkeys);


 

b.    Click on the Update button to save your work.

 

12. From the Core tab on the editor navigate to Utilities and drag a Run Script Activity onto the form.  The Activity Properties form will appear.

 

13. Fill out the form with the following:

a. Name: Log Open

b. Script:

 

 

var identifier = context.name + '.' + activity.name;

gs.info('---> [WF:{0}] Open triggered!', identifier);

 

c. Click the Submit button to save your work.

 

 

14. From the Core tab on the editor navigate to Utilities and drag a Run Script Activity onto the form.  The Activity Properties form will appear.

 

15. Fill out the form with the following (Req #16):

a. Name: Log Closed

b. Script:

 

 

var identifier = context.name + '.' + activity.name;

if (workflow.scratchpad.result.monkeys) {
      gs.warn('---> [WF:{0}] There were monkeys present at closing!', identifier);
}
else {
      gs.info('---> [WF:{0}] Closed triggered!', identifier);
}

 

c. Click the Submit button to save your work.

 

16. Open the Log Active Run Script and change the Script to the following (Req #16):

 

 

var identifier = context.name + '.' + activity.name;

if (workflow.scratchpad.result.monkeys) {
            gs.warn('---> [WF:{0}] Monkeys were present when Active was triggered!', identifier);
}
else {
            gs.info('---> [WF:{0}] Active triggered!', identifier);
}

 

 

17. Open the Log Failure Run Script and change the Script to the following (Req #16):

 

var identifier = context.name + '.' + activity.name;

if (workflow.scratchpad.result.monkeys) {
            gs.error('---> [WF:{0}] Something bad happened probably due to monkeys!', identifier);
}
else {
            gs.info('---> [WF:{0}] Nothing triggered!', identifier);
}

 

18. Wire up your workflow to look like the following diagram:

 

 

At this point you may want to Publish your workflow to save it down.  However, that is not really necessary as you will be the only one testing it.

 

 

 

Lab 1.3: Building the Service Catalog Item

 

Now we are ready to create the user interface (UI).

 

1. Navigate to Service Catalog -> Catalog Definitions -> Maintain Items.  The Catalog Items list view will be displayed.

 

2. Click the New button.  The New Catalog Item form will be displayed.

 

3. Fill out the form with the following:

    1. Name: Workflow Control Via Variable Examination
    2. Active: checked
    3. Availability: Desktop Only
    4. Catalogs:  Service Catalog
    5. Category: Can We Help You?
    6. Workflow:  Workflow Control Via Variable Examination
    7. Short Description: Workflow Control Via Variable Examination
    8. Use Cart Layout: not checked
    9. Omit price in cart: checked
    10. No quantity: checked
    11. No proceed checkout: checked
    12. No cart: checked
    13. Right-click on the form header to bring up the context menu.
    14. Choose Save to save your work and remain on the form.

 

 

4. Scroll to the bottom of the Item form.  You will see the tabs for the related lists.

 

5. Choose Variables, and click the New button.  The New Variable Form will be displayed.

 

6. Fill out the form with the following:

    1. Type: Select Box
    2. Click on the Question tab.
    3. Question: State
    4. Name: state
    5. Click on the Type Specifications tab.
    6. Include None: checked
    7. Right-click at the top of the Variable form to display the context menu.
    8. Choose Save to save your work and remain on the form.

 

 

7. Scroll to the bottom of the Variable form.  You will see the Question Choices related list displayed.

 

8. Click on the New button.  The New Question Choice form will be displayed.

 

9. Fill in the form with the following:

    1. Text: New
    2. Value: 0

 

10. Right-click on the Question Choice form header to bring up the context menu.

 

11. Click on Save to save your work and remain on the form.

 

12. Change the form to the following:

    1. Name: Active
    2. Value: 1

 

13. Right-Click on the Question Choices form header and choose Insert and Stay.  This will write down a new record with the new values, and keep you in the form.

 

14. Change the form to the following:

    1. Name: Open
    2. Value: 2

 

15. Right-Click on the Question Choices form header and choose Insert and Stay.  This will write down a new record with the new values, and keep you in the form.

 

16. Change the form to the following:

    1. Name: Closed
    2. Value: 3

 

17. Right-Click on the Question Choices form header and choose Insert.  This will write down a third choice record, and will then return you to the Item form.

 

18. Set the order of your choices from the list view.  The Question Choices list view should now look something like this:

 

 

 

Unit Test

 

There are so many options with this design that unit testing has to be approached differently than in the previous two articles. So we will go through the exercise of listing out the various tests that need to be created, then creating a couple to demonstrate that things are actually working.

 

Unit Tests that need creating:

 

  1. Check that new Possible Choices property is available in the Properties page.
  2. Test if New property checked and New picked on Service Catalog that is New path is activated in the workflow.
  3. Test if Active property checked and Active picked on the Service Catalog that is Active path is activated in the workflow
  4. Test if Open listed in Possible Choices property and Open picked in the Service Catalog that is Open path is active in the workflow.
  5. Test if Closed listed in Possible Choices property and Closed picked in the Service Catalog that is Closed path is active in the workflow.
  6. Test if Closed and Monkeys listed in Possible Choices property and Closed picked in the Service Catalog that is Closed path is active and the “Monkeys” log message is placed in the System Log.
  7. Test if Monkeys and Hello listed in Possible Choices property and any value is chosen in the Service Catalog that is Unknown path is active and “Monkeys” log message is placed in the System Log.
  8. ...And…well, you get the idea.  You need to be thorough when it comes to unit testing!

 

So let’s test a couple of these to see if things really do work!

 

1. Navigate to Workflow Patterns -> Administration -> Properties.  The Workflow Properties page will be displayed.

 

2. Validate that the three properties are present. Change the values to be the following:

 

  1. Active is checked
  2. Open is unchecked
  3. Possible Choices has the following: New, Monkeys.
  4. Click the Save button to save your changes.

 

 

3. Navigate to Self-Service -> Service Catalog. The Service Catalog home page will be displayed.

 

 

4. Click on the Can We Help You? Service Catalog item. The list of Help Service Catalog items will be displayed.

 

 

5. Scroll down until you find the Service Catalog Item labeled: Workflow Control Via Variable Examination, and click that link.  The Workflow Control Via Variable Examination page will be displayed and should look something like this:

 

 

6. Choose the State value of Active, and click the Order Now button.  The Order Status form will be displayed.

 

 

7. Click on the RITM number.  The Requested Item form will be displayed.

 

8. From the Requested Item Form scroll down to related links.

 

 

9. Click on the Show Workflow link.  This will display the current workflow.

 

10. The workflow should show that the Active path was executed.

 

 

11. Close the workflow browser tab.

 

12. Navigate to Self-Service -> Service Catalog. The Service Catalog home page will be displayed.

 

13. Click on the Can We Help You? Service Catalog item. The list of Help Service Catalog items will be displayed.

 

14. Scroll back down until you find the Service Catalog Item labeled: Workflow Control Via Variable Examination, and click that link. The Workflow Control Via Variable Examination page will be displayed.

 

15. Choose the State value of Closed, and click the Order Now button.  The Order Status form will be displayed.

 

16. Click on the RITM number.  The Requested Item form will be displayed.

 

17. From the Requested Item Form scroll down to related links.

 

18. Click on the Show Workflow link.  This will display the current workflow.

 

19. The workflow should show that the Unknown path was executed.  This is because Closed was not listed in the Possible Choices property and therefore the default fired.

 

 

20. Close the workflow browser tab.

 

21. Navigate to System Logs -> System Log -> All. The System Log list view will be displayed.

 

22. Filter for Message starts with “---> [“. This will display the list of messages written by the workflow.

 

23. Note that the first entry should be for the Active branch of the workflow firing.  The second should be for the Unknown branch of the workflow firing.  Because we had Monkeys listed in the Possible Choices property we also were able to trigger the code that checked for Monkeys.

 

 

24. You should go ahead and now test the other possibilities.  Ahhh, make-work, gotta love it!

 

 

The demonstration of this pattern was to show that it is possible to use a variety of variable and property combinations to control any workflow.  This flexibility allows for a lot of complexity. 

 

That concludes the third data controlled workflow pattern example.

 

If you have read my previous three articles on workflow patterns you are probably getting pretty much tired of workflows! Hang in there!  This is the last one…um, for a bit.  I actually have three or four more planned dealing with Orchestration Framework workflows! 

 

Steven Bell

 

 

If you find this article helps you, don't forget to log in and "like" it!

 

Also, if you are not already, I would like to encourage you to become a member of our blog!

Whenever I get a question about Jelly I start to sweat nervously. Then you throw in a question about phase 1 and phase 2 idiosyncrasies and I start to mumble like a crazy person.  So, here’s a little story I’ve got to tell - </end-beastie-boy-impression>

 

Stephan Nolan, an employee working with me at RMIT, asked the question:

"We have a dynamic content block with the following:

 

<?xml version="1.0" encoding="utf-8" ?>
<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">
     <h1>Hello World</h1>

     <script id="template" type="text/x-handlebars-template">
         <![CDATA[
             <label>
                 <input
                     name="example"
                     type="radio"
                     value="1"
                     {{#if blah}}checked="checked"{{/if}}
               />
                 <span>Radio button</span>
             </label>
         ]]>
     </script>
</j:jelly>

 

 

 

Which works fine when two phase is turned off.  However when we turn it on, the <![CDATA[]]> tags are being ignored and the following error is thrown

Element type "input" must be followed by either attribute specifications, ">" or "/>".: org.xml.sax.SAXParseException: Element type "input" must be followed by either attribute specifications, ">" or "/>".:

 

We need two phase turned on to enable HTML escaping.  Currently our only solution is to replace the '<' of the input with &lt; to bypass jelly parsing."

 

I couldn’t figure out a nice an simple answer for him on this, but much to my delight he figured out a nice solution later on and shared the fact that if you have this requirement, wrap your script in a UI Macro and use an inline template. Example <g2:inline template="uimacro.xml".  It looks like the first phase eats up the CDATA tags and when we go into phase two we get the above error.  If we inline in the second phase we get to keep the CDATA tag and there is no need to escape all those pesky < > brackets.  Thanks Stephen for the tip.  I hope it helps someone else out there in Jelly ****, I mean land. 

 

Extensions to Jelly Syntax - ServiceNow Wiki

The next workflow pattern I will give an example of is the Workflow Control via Property Input pattern.  As a side-note; for this article the title of Mini-Lab is a misnomer. This is a full-lab!  Fair warning. 

 

To see more about workflow patterns read my article:

 

Pragmatic Patterns: Workflows - Using Data to Adjust the Flow

 

Similar to my previous mini-lab article (Mini-Lab: Workflow Control Via Variable Input ) we will be going through the steps to build a very simple Service Catalog driven workflow. This one, however, will be configured by properties in the System Properties table.  We will be looking at how changing the properties activates/deactivates parts of the workflow.  The idea is to give greater control to the owner of an application without having to make code changes.

 

 

Prerequisites:

 

  • Some familiarity with the workflow editor.  I will be using the Geneva version of ServiceNow for my examples.

 

  • Also, if you have not done so, you might want to run through my other lab on how to do advanced work with the If Activity; as we will be using this in those techniques in this and the next mini-lab article:

 

Mini-Lab: Workflows - Playing With the If Activity

 

 

Requirements

 

  1. Create a Service Catalog Item / Workflow combination where properties changed by an application owner will affect what occurs in the workflow.
  2. Place this Service catalog Item under the Can We Help You? Service Catalog Category.
  3. The name of the Service Catalog Item will be: Workflow Control via Property Input
  4. The Service Catalog item will contain a single variable: State.
  5. State can have four choices: New, Active, Open, and Closed.  The underlying values of these will be 0,1,2,3 respectively.
  6. Only the Order Now button will appear on the Service Catalog Item.
  7. There will be a new application named: Workflow Patterns
  8. There will be a section under Workflow Patterns labeled: Administration.
  9. In the Administration section there will be a module that will contain a properties page named: Properties.
  10. There will be two properties:
    1. Property 1 will be labeled: React on Active?, and will be a checkbox.  Default will be checked.
    2. Property 2 will be labeled: React on Open?, and will be a checkbox.  Default will be checked.
  11. The workflow will print a message in the log that indicates a particular state was chosen and the appropriate property is active.
  12. The workflow will check to see if the React on Active is checked.  If it is it will place a log statement saying so in the System Log.
  13. The workflow will check to see if the React on Open is checked.  If it is it will place a log statement saying so in the System Log.
  14. If either is not checked, but is chosen in the Service Catalog Item then an unknown message will be printed in the log.

 

Design

 

1. Create a Service Catalog Item (Req #1)

    1. Name: Workflow Control via Property Input (Req #1,3)
    2. Category: How Can We Help You? (Req #2)
    3. Deactivate every shopping cart feature except Order Now. (Req #6)

 

2. Catalog Item Variables: (Req #4,5)

    1. Name: State
    2. Choice List
    3. Choices: New, Active, Open, Closed
    4. Values will be the strings: 0, 1, 2, 3
    5. Choices will be entered into the Choices table

 

3. Create a new Application (Req #7,8)

    1. Name: Workflow Patterns
    2. Create a section in the new application labeled: Administration.

 

4. Create two System Properties (Req #10)

    1. Name: workflow.react_on_active
      • Description: React on Active?
      • Type: true/false
      • Associated to Workflow Patterns -> Properties page
    2. Name: workflow.react_on_active
      • Description: React on Active?
      • Type: true/false
      • Associated to Workflow Patterns -> Properties page

 

5. Create a new System Property Category

    1. Name: Workflow Patterns
    2. Title: Workflow Patterns
    3. Associate this to the two system properties in Design#4.

 

6. Create a new Module under Workflow Patterns (Req #9)

    1. Name: Properties
    2. Type: Properties page.
    3. Link: Workflow Patterns System Property Category.

 

7. Workflow design will be as follows: (Req #1, 11,12,13,14)

 

 

Development

 

Our requirements and design are now completed. Let us see about implementation!

 

We will do our construction bottom up.  We will start with the properties, then move to the workflow, then create the Application/Module/Properties page, and finally create our Service Catalog Item to kick the whole thing off.

 

 

Lab 1.1: Setting up the Properties Page

 

1. In the navigation filter type sys_properties.list and press enter.  This will open up the System Properties list view.

 

2. Click on the New button to open the New properties form.

 

3. Fill in the form with the following (Req #10):

    1. Name: workflow.react_on_active
    2. Description (this will act as the question in the properties page): React on Active?
    3. Type: true | false
    4. Value: true
    5. Right-Click on the form header to display the form context menu, and choose Save to save your work.

 

System Propety - Active.png

4. Scroll to the bottom of the form and note the System Property Category related list.  Click on the New button.  The new System Property Category list view will be displayed. (Design #5)

    1. Fill in the form with the following:
    2. Name: Workflow Patterns
    3. Title: Workflow Patterns
    4. Copy the link that is displayed.  This will be used when creating the Workflow Patterns property module later.
    5. Click the Submit button to save your work. This will display the workflow.react_on_active properties form.

 

 

f. Note that the workflow.react_on_active property now has a related list link to the new Workflow Patterns System Property Category.

g. Right-Click on the form header to display the form context menu, and choose Save just to make sure you save everything.

 

 

5. In the Navigation filter type in the following: sys_properties_category_m2m.list.  This will display the System Properties Category list.

 

NOTE: Not sure why sys_properties and sys_properties_category_m2m are not links in the System Admin application.  Mystery.

 

6. Filter for "Workflow Patterns". 

 

7. Change property display order so that Active is 100, and Open is 200.

 

 

NOTE: This affects the order that the properties appear in the displayed properties page.

 

8. Now change the property name to: workflow.react_on_open

         Note: (Req #10)

    1. Right-Click on the form header to display the form context menu, and choose Insert and Stay.  This will create a new property named workflow.react_on_open.
    2. Scroll to the bottom of the form to view the System Property Category list view.  Note that it is now empty.
    3. Click on the Edit button.  This will display a Select List of System Property Categories. Filter for Workflow Patterns, and select this category. 
    4. Click on Save to save your work.  This will display the workflow.react_on_open property form.  Scroll to the bottom to verify that the property is now associated to the Workflow Patterns System Property Category.
    5. Click on the Update button to make sure to save your work.

 

System Property - Open.png

 

 

9. Navigate to System Definition -> Application Menus. The Application Menus list view will be displayed.

 

10. Click on the New button.  The New Application Menu form will be displayed.

 

11. Fill out the form with the following (Req #7,8,9):

    1. Name: Workflow Patterns
    2. Active: Checked
    3. Category: Custom Applications
    4. Right-Click on the form header to display the form context menu and select Save to save your work.

 

Application Menu.png

12. Scroll to the bottom of the Application Menu form. You will see the Modules related list. It will be empty.

 

13. Click the New button.  The New Module form will be displayed.

 

14. Fill out the form with the following:

    1. Title: Administration
    2. Order: 9000
    3. Click the Link Type tab.
    4. Link Type: Separator
    5. Click the Submit button. You will be returned to the Application Menu form.

 

15. Click the New button again.  The New Module form will be displayed.

 

16. Fill out the form with the following (Req #10):

    1. Title: Properties
    2. Order: 9100
    3. Click the Link Type tab.
    4. Link Type: URL (from Arguments: )
    5. Arguments: system_properties_ui.do?sysparm_title=Workflow%20Patterns&sysparm_category=Workflow%20Patterns

 

NOTE: This is the link you copied in step 4b.  I shortened it a bit as everything to the sys_properties_ui.do is implied and automatically filled in for you during runtime.

 

Module Properties.png

 

f. Click the Submit button. You will be returned to the Application Menu form.

g. The Modules list on the Application Menu form should look like this:

 

Modules List View.png

 

17. Click the Update button to make sure you save all of your work

 

 

 

Lab 1.2: Building the Workflow

 

1. Navigate to Workflow -> Workflow Editor.  A new tab will open in your browser and the Workflow Editor will be displayed.

 

2. Click the plus “+” symbol in the upper right of the editor to create a new workflow.  The New Workflow form will be displayed.

 

3. Fill out the form with the following:

    1. Name: Workflow Control Via Property Input
    2. Table: Global
    3. Description: Workflow control via property input
    4. Click the Submit button to save your work.

 

4. From the Core tab on the editor navigate to Utilities and drag a Scripting Activity onto the form.  The Activity Properties form will appear.

 

5. Fill out the form with the following:

    1. Name: Initialize
    2. Script:

 

// it is a good practice to assign your properties to scratchpad variables
workflow.scratchpad.active = gs.getProperty('workflow.react_on_active');
workflow.scratchpad.open = gs.getProperty('workflow.react_on_open');

 

Note: This will pull in our properties and feed them into the workflow stream.  BTW, this is my best practice, others feel just using the gs.getProperty where needed is sufficient.  I feel that if you call the getProperty for the same property more than once it becomes an efficiency issue.  Keep the number of record retrievals to a minimum in your workflow for maximum performance.

 

6. From the Core tab on the editor navigate to Conditions and drag an If Activity onto the form.  The Activity Properties form will appear.

 

7. Fill out the form with the following:

    1. Name: Check Properties
    2. Advanced: Checked
    3. Script:

 

// in a modified if we can store our results in a scratchpad object variable for
// examination
workflow.scratchpad.result = ifScript();

function ifScript() {
            
            // build a result object that will contain all possible results
            var result = {active:false, open:false, unknown:false};  
            
            result.active = workflow.scratchpad.active == "true";
            result.open = workflow.variables.open == "true";

            // make sure you have a catch all
            result.unknown = !(result.active || result.open);
                                                              
            return result;
}

 

d. Click the Submit button to save your work.

 

8. Right-Click and Delete the two conditions of the Check Properties If Activity.

 

9. Right-Click on the Check Properties If Activity header to display the Activity Context menu, and choose Add Condition (be patient, for whatever reason this can take several seconds to display!).  The new Condition Properties form will appear.

 

10. Fill out the form with the following (Req #12):

    1. Name: isActive
    2. Condition Type: standard
    3. Skip during generate: checked
    4. Condition: workflow.scratchpad.result.active == true
    5. Click on the Submit button to save your work.

 

11. Repeat the procedure.  Fill out the form with the following (Req #13):

    1. Name: isOpen
    2. Condition Type: standard
    3. Skip during generate: checked
    4. Condition: workflow.scratchpad.result.open == true
    5. Click on the Submit button to save your work.

 

12. Repeat the procedure one last time.  Fill out the form with the following (Req #14):

    1. Name: isUnknown
    2. Condition Type: standard
    3. Skip during generate: checked
    4. Condition: workflow.scratchpad.result.unknown == true
    5. Click on the Submit button to save your work.

 

13. Your If Activity should look like this:

 

 

14. From the Core tab on the editor navigate to Utilities and drag a Run Script Activity onto the form.  The Activity Properties form will appear.

 

15. Fill out the form with the following (Req #11):

a. Name: Log New

b. Script:

 

var identifier = context.name + '.' + activity.name;

gs.info('---> [{0}] New triggered!', identifier);

 

c. Click the Submit button to save your work.

 

NOTE:  The context.name will automatically fill in the workflow name, and the activity.name will automatically fill in the, uh, activity name.  BTW, this is really useful for labeling your log entries! Remember that a best practice is: NO MYSTERY LOG ENTRIES in the System Log!  This has been a real problem at a lot of my clients that use Workflows.

 

16. From the Core tab on the editor navigate to Utilities and drag a Run Script Activity onto the form.  The Activity Properties form will appear.

 

17. Fill out the form with the following (Req #11):

a. Name: Log Active

b. Script:

 

var identifier = context.name + '.' + activity.name;

gs.info('---> [{0}] Active triggered!', identifier);

 

c. Click the Submit button to save your work.

 

18. From the Core tab on the editor navigate to Utilities and drag a Run Script Activity onto the form.  The Activity Properties form will appear.

 

19. Fill out the form with the following (Req #11):

a. Name: Log Failure

b. Script:

 

var identifier = context.name + '.' + activity.name;

gs.info('---> [{0}] Nothing triggered!', identifier);

 

c. Click the Submit button to save your work.

 

20. Wire up your workflow to look like the following diagram:

 

 

At this point you may want to Publish your workflow to save it down.  However, that is not really necessary as you will be the only one testing it.

 

 

 

 

Lab 1.3: Building Service Catalog Item

 

Now we are ready to create the user interface (UI).

 

1. Navigate to Service Catalog -> Catalog Definitions -> Maintain Items.  The Catalog Items list view will be displayed.

 

2. Click the New button.  The New Catalog Item form will be displayed.

 

3. Fill out the form with the following (Req #1,2,3,6):

    1. Name: Workflow Control Via Property Input
    2. Active: checked
    3. Availability: Desktop Only
    4. Catalogs:  Service Catalog
    5. Category: Can We Help You?
    6. Workflow:  Workflow Control Via Property Input
    7. Short Description: Workflow Control Via Property Input
    8. Use Cart Layout: not checked
    9. Omit price in cart: checked
    10. No quantity: checked
    11. No proceed checkout: checked
    12. No cart: checked
    13. Right-click on the form header to bring up the context menu.
    14. Choose Save to save your work and remain on the form.

 

NOTE: Some of these values may not be visible on the form and you may need to modify the form to include them.

 

Catalog Item - Property Input.png

4. Scroll to the bottom of the Item form.  You will see the tabs for the related lists.

 

5. Choose Variables, and click the New button.  The New Variable Form will be displayed.

 

6. Fill out the form with the following (Req #4,5):

    1. Type: Select Box
    2. Click on the Question tab.
    3. Question: State
    4. Name: state
    5. Click on the Type Specifications tab.
    6. Include None: checked
    7. Right-click at the top of the Variable form to display the context menu.
    8. Choose Save to save your work and remain on the form.

 

NOTE:  The Name field is where we make sure our variable name is consistent with what we programmed into our workflow.

 

Variable Form.png

Type Spceification - Include None.png

 

7. Scroll to the bottom of the Variable form.  You will see the Question Choices related list displayed.

 

8. Click on the New button.  The New Question Choice form will be displayed.

 

9. Fill in the form with the following:

    1. Text: New
    2. Value: 0

 

10. Right-click on the Question Choice form header to bring up the context menu.

 

11. Click on Save to save your work and remain on the form.

 

Question Choice Form - New.png

 

12. Change the form to the following:

    1. Name: Active
    2. Value: 1

 

13. Right-Click on the Question Choices form header and choose Insert and Stay.  This will write down a new record with the new values, and keep you in the form.

 

14. Change the form to the following:

    1. Name: Open
    2. Value: 2

 

15. Right-Click on the Question Choices form header and choose Insert and Stay.  This will write down a new record with the new values, and keep you in the form.

 

16. Change the form to the following:

    1. Name: Closed
    2. Value: 3

 

17. Right-Click on the Question Choices form header and choose Insert.  This will write down a third choice record, and will then return you to the Item form.

 

18. The Question Choices list view should now look something like this:

 

Question Choices.png

 

 

Unit Test

 

Now we are ready to do our testing.  First we will test with all of the defaults.  Our first test will involve choosing State equals Active, and verify that the properties don’t interfere with the normal working of the workflow.  Next we will turn off the Active property, and retest to see that Active is now an Unknown choice in the workflow.  This will demonstrate control of the workflow via the properties.

 

1. First let’s verify that our Properties page displays, and that the two options are present, and defaulted checked.

 

2. Navigate to Workflow Patterns -> Administration -> Properties.  The Workflow Properties page will be displayed.

 

3. Validate that the two properties are present, and that they are both checked.  Cool huh?!

 

System Property Page - Active True.png

 

4. Navigate to Self-Service -> Service Catalog. The Service Catalog home page will be displayed.

 

Service Cat - Can we help you.png

5. Click on the Can We Help You? Service Catalog item. The list of Help Service Catalog items will be displayed.

 

6. Scroll down until you find the Service Catalog Item labeled: Workflow Control Via Property Input, and click that link. 

 

 

7. The Workflow Control Via Property Input Catalog Item will be displayed and should look something like this:

 

 

8. Choose the State value of Active, and click the Order Now button.  The Order Status form will be displayed.

 

Order Status.png

9. Click on the RITM number.  The Requested Item form will be displayed.

 

10. From the Requested Item Form scroll down to related links.

 

Related Links.png

 

11. Click on the Show Workflow link.  This will display the current workflow.

 

12. The workflow should show that the Active path was executed.

 

Workflow Run - Active.png

 

13. Close the workflow browser tab.

 

14. Navigate back to Workflow Patterns -> Administration -> Properties.  The Properties page will be displayed.

 

15. Uncheck React on Active? And click the Save button to save your work.

 

Properties Page - Active False.png

 

16. Navigate to Self-Service -> Service Catalog. The Service Catalog home page will be displayed.

 

17. Click on the Can We Help You? Service Catalog item. The list of Help Service Catalog items will be displayed.

 

18. Scroll back down until you find the Service Catalog Item labeled: Workflow Control Via Property Input, and click that link.  The Workflow Control Via Property Input page will be displayed.

 

19. Choose the State value of Active, and click the Order Now button.  The Order Status form will be displayed.

 

20. Click on the RITM number.  The Requested Item form will be displayed.

 

21. From the Requested Item Form scroll down to related links.

 

22. Click on the Show Workflow link.  This will display the current workflow.

 

23. The workflow should show that the Active path was not executed, but instead you should see that the Unknown path was executed.  This validates that the Active property controlled the flow.

 

Workflow Run - Unknown.png

24. Close the workflow browser tab.

 

25. Navigate to System Logs -> System Log -> All. The System Log list view will be displayed.

 

26. Filter for Message starts with “---> [“. This will display the list of messages written by the workflow.

 

27. Note that the first entry should be for the Active branch of the workflow firing.  The second should be for the Unknown branch of the workflow firing.

 

Log Messages.png

 

28. You should go ahead and now test the other two possibilities:

 

  1. Open property unchecked, Active property checked, and Open chosen on the Service Catalog item.
  2. Open property unchecked, Active property unchecked, and anything chosen on the Service Catalog item.

 

 

 

And there you have it!  A method of controlling a workflow via properties; complete with interface!  This makes it possible to give the user control over what is executed in the workflow.

 

This concludes the second pattern example.  In my next article I will show how you can use variables and System Properties in concert to control your workflow (pattern 3).

 

Steven Bell

 

CS_logo.jpgMVP-logo.jpeg

Please Share, Like, Comment this blog if you've found it helpful or insightful.

 


for Click for More Expert Blogs and also Find Expert Events!


With recent introduction of both Team Development and Applications as fairly new tools in your ServiceNow development toolkit, many customers continue to struggle with how best to utilize these new tools alongside the existing ones like Update Sets. I will discuss how each of these tools were designed to be used, and where best to use them in conjunction with each other, to best achieve your internal development and deployment process goals.

 

Differences between Development and Deployment

In development we have individuals and/or teams managing multiple work streams to achieve a project goal within a specific deadline:

  • Development is conformable to parallel team based processes as they construct the next unit of development. It is within this phase that customers can engineer quality and assure its achievement.
  • Deployment is the phase that follows development, where the now completed development units are deployed, tested, validated and ultimately moved into your live production environments. It is within this phase that we see the execution of your change management process at work, and where quality is confirmed by stakeholders and ultimately end users.

 

Perhaps you are familiar with some of the development tools that exist outside of the ServiceNow platform such as Git, Perforce, or Jenkins. Much like these external tools, the internal tools provided within ServiceNow are designed to help you achieve your goals of fast development and deployment, with no production downtime. All of these tools are; however, just that, tools. How each customer uses them will be determined by their internal processes and best practices, along with the scale of their individual instance architecture. Lets take a look at each of these tools a little more in-depth to understand where best to utilize each one within your individual organizations.

 

Team Development vs. Update Sets

It is important to know the difference between a version, and update, when looking at Team Development and Update Sets:

  • A version (sys_update_version) tracks changes to a file. Team Development works by comparing the differences in versions between two instances.
  • An update (sys_update_xml) enables adding, updating, or deleting another file on a target instance; and also prevents upgrades from changing customer customized files.
  • An Update Set is a package designed to hold an arbitrary collection of updates in the form of XML payloads, which can be retrieved and committed to target instances.

 

Team Development allows for collaboration between instances using a Parent and one or more Child instances, and is a version control system similar to Git. Team Development compares the current versions of records within the sys_update_version table to locate and tag local and remote changes between instances.

Screen Shot 2016-01-31 at 10.19.14 AM.JPG

Team development should be used for the development process only, and not for the deployment of changes; update sets will continue to be used to deploy changes to Test and Production instances regardless of whether you choose to utilize Team Development or not. Additionally, Team Development is not a 'one size fits all' feature and should only be utilized by customers that have multiple development teams working in multiple development environments with complex development timelines.

team dev servicenow.JPG

As we can see from the illustration above, Team Development and Update Sets work hand-in-hand to develop and then deploy your customizations through your instance pipeline. Team Development should not be used to deploy changes to any Test, UAT, or Production environments, as this falls outside the design and scope of this feature, and doing so can cause undesired results to occur which can be problematic to recover from.

 

Update Sets remain an integral part of the deployment pipeline, and Team Development is not meant nor is it designed to replace Update Sets. You will continue to utilize them regardless of whether you use Team Development, or not. Update Sets are essential for customizing both Out-of-box applications and applications purchased from the App Store. Where Update Sets shine is by letting you apply changes in bulk and helping you to force an instance to load the file versions you need, additionally they are very useful for:

  • Keeping track of why a change was made.
  • Exporting work-in-progress ahead of a clone.
  • Associating changes to SDLC artifacts.

 

Applications and Update Sets

Applications are not entirely new to the ServiceNow platform, but how they are used in the Fuji and Geneva releases has change somewhat to how they were used and deployed previously. Prior to Fuji, applications were deployed through the use of Update Sets. Since Fuji however, through the introduction of the App Store and Company Repository, applications can now be uploaded into the company repository and then subsequently downloaded and installed (much like a plugin is installed) to the target instance without ever needing to utilize an Update Set in the deployment process.

application repository.JPG

Update Sets can still be used to deploy an application, should the user desire it, by utilizing the Publish to Update Set UI Action, from the Application form. This will in turn package the application, in its entirety, into a new complete update set, allowing you to retrieve and commit it to your target instance of choice. You should choose to utilize either the Company Repository OR Update Sets to deploy your applications, but never both. Once you begin to deploy your applications through update sets, it becomes very difficult to switch back to using the Company Repository going forward.

 

In the case of Applications that have been purchased from the App Store or Out-of-Box System Applications, this is where you will need to use Update Sets exclusively to customize the application to your needs, and deploy these changes through your instance pipeline.

application update sets.JPG

 

Conclusions:

  • Team Development adds to the development side of the instance pipeline and should not be used for testing or deployment.
  • Deploying Store and Internal applications is easy, and you retain the ability to customize.
  • You will continue to use Update Sets regardless of whether you use Team Development or Applications.

---------------
Lane Roberts
Business Operations Analyst
ServiceNow | Work at Lightspeed

Herbert Uhl  explains how ServiceNow customers are realizing significant OPEX savings and gaining operational efficiencies with MobiChord’s Mobile Expense and Asset Management app.

 

volume_icon.png

Listen

 

 

Subscribe

 

to iTunes

I learned something very interesting from my Australian brothers Steve Farrar and Zac Murray today.  Quick shout out to these Technical Consultants - they are geniuses and I thank them for imparting their wisdom with me.

 

If you happen to get the following "Upload Failed" "YourAppName" could not be uploaded due to the following error: User name or password invalid, DONT panic - all you need to do is make sure you DO NOT publish your application with an equal or less version than you have already published previously.  Change the version and you will be right as rain.

 

The error below is seen when trying to publish a version of an application ("Make App available on other instances") without increasing the version number.  The error you get is a bit misleading.

 

errorpublish.png

 

Some other community post addressing the same issue:

Error in making application available to other instances

Why am I seeing "upload failed" after I try to Make my app available on other instances?

If you've ever run into trouble creating any client side scripts in your ServiceNow instance (Client Scripts/UI Policies etc.) you may find the following tool very useful. It's known as the Javascript Executor and is one of the ServiceNow support team's first points of call when investigating any client side issues or questions that our customers may raise.

 

It's important to note that this will only work for Client Side scripting; any server side code will not execute and must be executed in "Scripts - Background." This module is only available to users elevated to security admin level.

 

There is a Javascript executor built into your browsers, but the benefits of using the ServiceNow Javascript Executor is that the last executed code is still in the window so it can be modified to correct errors and test again immediately. Also, the Javascript Editor works on the main content frame, so for forms within iFrames (ie navpage.do) the console javascript editor works on the top frame so it cannot interact with iframe forms resulting in errors like "g_form.field is undefined."

 

If you have a large client script that is not working correctly, you can segment it into parts and test each portion in the Javascript Executor to find where the error in logic is.

 

There are two modes to the Javascript Executor:

1. The Javascript Executor

2. The environment variable browser

 

 

The Javascript Executor

To open the Javascript Executor you must be an administrator and simultaneously press "Alt+Ctrl+Shift+j" in a window within your ServiceNow instance to see the popup below:

javascript executor.jpg

 

Example of opening the Javascript executor on your ServiceNow instance:

1. Open an Incident form

2. Press "Alt+Ctrl+Shift+j" to open the Javascript Executor

3. Paste the following code in place of the "Type JavaScript here" text:

var id = '62826bf03710200044e0bfc8bcbe5df1';
var name = 'Abel Tutorer';
g_form.setValue('assigned_to', id, name);

4. Click "Run my code"

 

You will see that the assignee on the Incident form has become "Abel Tutorer" - I have deliberately used a bogus sys_id and username to prevent the form being accidentally submitted with the wrong user details.

 

If the code you execute in the Javascript Executor does not work, you can use the developer tools console as a back up. The Javascript Executor tests client side scripts on the fly with immediate results when combined with the developer tools of the browser of your choice in real time. Open the developer tools console to see if errors appear and you can debug as necessary to ensure your code works as desired. You can use the ServiceNow debug console ( Using the JavaScript debug window ) or the browser's javascript console to display all client side errors.

 

 

Using the Variable Browser

To access the Variable Browser you must be an admin user and have the Javascript Executor window open. In the Javascript Executor window, click the dropdown menu on the bottom left to select "Browse vars".

browser vars.jpg

 

"Browse vars" shows all available browser environment variables on the current form and their current value if it has been set. For example, I found the title attribute via "Browse vars." It was set to "ServiceNow" and the element was "document['title']." If I want to change this on a page, using a client script,  I could test the following javascript in the "Javascript Executor" to change this on the fly before implementing the code in my script:

 

document.title = "ServiceNow Rocks!!";
alert(document['title']);

 

Now, when I use browse vars after running that code you can see the updated page title variable. The beauty of running this in the Javascript Executor is that no change is permanent, so refreshing the page will return the title value to the original value. A simple example purely to illustrate the types of variables you can interact within your client side scripts and how you can test snippets to ensure they work before applying to larger client scripts.

 

If there is any error in the code, using the browsers developer tools console you will see something similar to the below:

Uncaught ReferenceError: title is not defined

The above error was from my trying to update the title variable as below (which is incorrect):

document['title'].value="This will produce an error";

 

 

While my examples above are trivial fiddles, this is a very powerful tool and is invaluable for quickly creating and debugging your client side code. We always recommend to test in sub prod environments and this is no exception as with all client scripts within ServiceNow you have an interface that can cause plenty of trouble which is why it is locked down to administrators. Please feel free to ask any further questions here about this great little tool and I will be happy to assist.

 

For more debugging and troubleshooting information see:

Using Chrome to Debug Client Side Errors

Debugging the Mobile UI from your Desktop

Strategies to isolate and debug an issue

Debugging SAML in ServiceNow and ADFS 2.0

 

Cheers,

Jordan

In this lab I would like to give an example of the Workflow Control via Variable Input pattern I mentioned in my previous article:

 

Pragmatic Patterns: Workflows - Using Data to Adjust the Flow

 

We will be going through the steps to build a very simple Service Catalog driven workflow that will be configured by choices made on the Catalog Item form.  We will be looking at how removing one of the choices deactivates part of the workflow.

 

We will be using this lab as a foundation to build the other two examples in later articles.  This lab will be longer than most as I am taking the time to show you how to do these things from scratch (lots of pictures! ).

 

 

Prerequisites:

 

  • Some familiarity with the workflow editor.  I will be using the Geneva version of ServiceNow for my examples.
  • Some familiarity with creating Service Catalog items, variables, and choices, but I will be listing the steps anyway.
  • Also, if you have not done so, you might want to run through my other lab on how to do advanced work with the If Activity; as we will be using those techniques in this, and the next two articles:

 

Mini-Lab: Workflows - Playing With the If Activity

 

 

Requirements

 

  1. Create a Service Catalog Item / Workflow combination where choices added or removed from the form will affect what occurs in the workflow.
  2. Place this Service catalog Item under the Can We Help You? Service Catalog Category.
  3. The name of the Service Catalog Item will be: Workflow Control via Input
  4. The choices for the form can be in the Choice or custom choice table.
  5. The Service Catalog item that contains a single variable: State.
  6. State can have three choices initially: New, Active, Closed (0, 1, 2)
  7. The workflow will print a message in the log that indicates a particular state was chosen.
  8. Only the Order Now button will appear on the Service Catalog Item.
  9. Removal of a choice will deactivate that portion of the workflow.

 

 

Design

 

1. Create a Service Catalog Item (Req #1)

    1. Name: Workflow Control via Input (Req #3)
    2. Category: How Can We Help You? (Req #2)
    3. Deactivate every shopping cart feature except Order Now. (Req #8)

 

2. Catalog Item Variables: (Req #4,5,6, 9 - implied)

    1. Name: State
    2. Choice List
    3. Choices: New, Active, Closed
    4. Values: 0, 1, 2
    5. Choices will be entered into the Choices table

 

3. Workflow design will be as follows: (Req #1, 7)

 

23.Design.png

 

Development

 

So we have our Requirements, and we have our Design, let’s get to work!

 

We will start at the bottom and work up.  The workflow will get built first, and then the Service Catalog Item.  We won’t have all of the pieces yet, but we can prepare for it.

 

The Workflow (Req #1)

 

1. Navigate to Workflow -> Workflow Editor.  A new tab will open in your browser and the Workflow Editor will be displayed.

 

2. Click the plus “+” symbol in the upper right of the editor to create a new workflow.  The New Workflow form will be displayed.

 

3. Fill out the form with the following:

    1. Name: Workflow Control Via Variable Input
    2. Table: Global
    3. Description: Workflow control via variable input
    4. Click the Submit button to save your work.

1.New Workflow.png

 

4. From the Core tab on the editor navigate to Conditions and drag an If Activity onto the form.  The Activity Properties form will appear.

 

5. Fill out the form with the following:

    1. Name: Check If New
    2. Advanced: Checked
    3. Script:

 

answer = ifScript();

function ifScript() {
            if (workflow.variables.state == 0) {
                        return 'yes';
            }
            return 'no';
}

 

       d. Click the Submit button to save your work.

 

NOTE: Here we are making an assumption: The Service Catalog variable being passed in will be named “state”.  When we build our Service Catalog Item variable we will need to make the name is consistent.

 

For more information on using Service Catalog variables in a workflow see Section 3 in the following wiki article: Using Variables in a Workflow

 

3.If script 1.png

 

6. From the Core tab on the editor navigate to Conditions and drag another If Activity onto the form.  The Activity Properties form will appear.

 

7. Fill out the form with the following:

    1. Name: Check If Active
    2. Advanced: Checked
    3. Script:
answer = ifScript();

function ifScript() {
            if (workflow.variables.state == 1) {
                        return 'yes';
            }
            return 'no';
}

 

       d. Click the Submit button to save your work.

 

4.If script 2.png

 

8. From the Core tab on the editor navigate to Utilities and drag a Run Script Activity onto the form.  The Activity Properties form will appear.

 

9. Fill out the form with the following (Req #7):

a. Name: Log New

b. Script:

 

var identifier = context.name + '.' + activity.name;

gs.info('---> [{0}] New triggered!', identifier);

 

c. Click the Submit button to save your work.

 

NOTE:  The context.name will automatically fill in the workflow name, and the activity.name will automatically fill in the, uh, activity name.  BTW, this is really useful for labeling your log entries!  Remember that a best practice is:  NO MYSTERY LOG ENTRIES in the System Log!  This has been a real problem at a lot of my clients that use Workflows.

 

5.Log new.png

 

10. From the Core tab on the editor navigate to Utilities and drag a Run Script Activity onto the form.  The Activity Properties form will appear.

 

11. Fill out the form with the following (Req #7):

a. Name: Log Active

b. Script:

 

var identifier = context.name + '.' + activity.name;

gs.info('---> [{0}] Active triggered!', identifier);

 

c. Click the Submit button to save your work.

 

12. From the Core tab on the editor navigate to Utilities and drag a Run Script Activity onto the form.  The Activity Properties form will appear.

 

13. Fill out the form with the following (Req #7):

a. Name: Log Failure

b. Script:

 

var identifier = context.name + '.' + activity.name;

gs.info('---> [{0}] Nothing triggered!', identifier);

 

c. Click the Submit button to save your work.

 

14. Wire up your workflow to look like the following diagram:

 

2.Workflow.png

 

At this point you may want to Publish your workflow to save it down.  However, that is not really necessary as you will be the only one testing it.

 

 

The Service Catalog Item (Req #1)

 

Now we are ready to create the user interface (UI).

 

1. Navigate to Service Catalog -> Catalog Definitions -> Maintain Items.  The Catalog Items list view will be displayed.

 

2. Click the New button.  The New Catalog Item form will be displayed.

 

3. Fill out the form with the following:

    1. Name: Workflow Control Via Variable Input (Req #3)
    2. Active: checked
    3. Availability: Desktop Only
    4. Catalogs:  Service Catalog
    5. Category: Can We Help You? (Req #2)
    6. Workflow:  Workflow Control Via Variable Input
    7. Short Description: Workflow Control Via Variable Input
    8. Use Cart Layout: not checked (Req #8)
    9. Omit price in cart: checked (Req #8)
    10. No quantity: checked (Req #8)
    11. No proceed checkout: checked (Req #8)
    12. No cart: checked (Req #8)
    13. Right-click on the form header to bring up the context menu.
    14. Choose Save to save your work and remain on the form.

 

NOTE: Some of these values may not be visible on the form and you may need to modify the form to include them.

 

8.Service Catalog Item.png

 

4. Scroll to the bottom of the Item form.  You will see the tabs for the related lists.

 

5. Choose the Variables tab, and click the New button.  The New Variable Form will be displayed.

 

9.Service Catalog Item Variables.png

 

6. Fill out the form with the following (Req #5):

    1. Type: Select Box
    2. Click on the Question tab.
    3. Question: State
    4. Name: state
    5. Click on the Type Specifications tab.
    6. Include None: checked
    7. Right-click at the top of the Variable form to display the context menu.
    8. Choose Save to save your work and remain on the form.

 

NOTE:  The Name field is where we make sure our variable name is consistent with what we programmed into our workflow.

 

10.Service Catalog Item Variable 1.png

11.Service Catalog Item Variable 2.png

 

7. Scroll to the bottom of the Variable form.  You will see the Question Choices related list displayed.

 

8. Click on the New button.  The New Question Choice form will be displayed.

 

24.choices list view.png

9. Fill in the form with the following:

    1. Text: New
    2. Value: 0

12.Service Catalog Item Variable Question Choice.png

 

10. Right-click on the Question Choice form header to bring up the context menu.

 

11. Click on Save to save your work and remain on the form.

 

12. Change the form to the following:

    1. Name: Active
    2. Value: 1

 

13. Right-Click on the Question Choices form header and choose Insert and Stay.  This will write down a new record with the new values, and keep you in the form.

 

14. Change the form to the following:

    1. Name: Closed
    2. Value: 2

 

15. Right-Click on the Question Choices form header and choose Insert.  This will write down a third choice record, and will then return you to the Item form.

 

16. The Question Choices list view should now look something like this (Req #4, 6):

 

13.Service Catalog Item Variable 3_choices.png

 

 

Unit Test

 

Now we are ready to do our testing.  First we will test it with the values we have entered. Then we will remove the Active choice from the State field and note that this effectively deactivates that part of the workflow (no choice – no way to run the code – simple).

 

1. At the top upper-right of the Item form click on the Try It button.  This will display our new Catalog Item form.

 

14.try it.png

 

2. Click on the State field.  You will see our three new choices displayed.  Note that the shopping cart has been reduced to just the Order Now button.

 

3. Choose Active from the State field, and click the Order Now button (Req #5, 6).  After a moment the Order Status form will be displayed.  Note that the Order Now button is the only thing displayed in the Shopping Cart (Req #8).

 

15.Form - Run-Time.png

 

4. Click on the RITM number.  This will display the Requested Item Form.

 

16.result.png

 

5. From the Requested Item Form scroll down to related links.

 

17.requested item 1.png

 

6. Click on the Show Workflow link.  This will display the current workflow.

 

18.related links.png

 

7. The workflow should show that the Active path was executed.

 

25.active workflow context.png

 

8. Navigate to System Logs -> System Log -> All. The System Log list view will be displayed.

 

9. Search for all messages beginning with --->. Observe that there is an entry for Active (Req #7).

 

NOTE:  It is always a good idea to test all available cases.

 

 

10. Navigate to Service Catalog -> Catalog Definitions -> Maintain Items.  The Catalog Items list view will be displayed.

 

11. Open the Workflow Control Via Variable Input Catalog Item

 

12. Scroll to the bottom of the form and click on the Related List Variables tab.  You will see your one variable there.

 

13. Click on the Select Box variable.  The Variable form will be displayed.

 

14. Scroll to the bottom of the form to see the three choices (Req #4).

 

15. Open the Active choice, and delete it.

 

16. You should now only have two choices listed (New, Closed).

 

21.remaining choices.png

 

17. Navigate to Service Catalog -> Catalogs.  The catalogs home page will be displayed.

 

18. Click on Service Catalog.  The Service Catalog home page will be displayed.

 

19. Click on Can We Help You?  The “Can We Help You?”  page will be displayed. (Req #2)

 

26.can we help you.png

 

20. Scroll down through the various items and find Workflow Control Via Variable Input (Req #3).  Click on this item.  This will open our Item form.

 

22.choice disabled.png

 

21. Click on the State field and note that the Active value is now missing; effectively deactivating the Active portion of the workflow.  (Req #3, 9)

 

 

The point of all of this was to show that by removing a value from the State list we can effectively control what is executed in our workflow.

 

Note that I included requirements traceability in my listing of the Design, Development, and Unit Testing stages.  The process and the traceability are both best practices to ensure that I met the original requirements.

 

That concludes the first pattern example.  In my next article I will show how you can use System Properties to control your workflows (pattern 2).

 

Steven Bell

If you find this article helps you, don't forget to log in and "like" it!  I would also like to encourage you to become a member of our blog!

CS_logo.jpgMVP-logo.jpeg

Please Share, Like, Comment this blog if you've found it helpful or insightful.

 


for Click for More Expert Blogs and also Find Expert Events!


Email has three chances to recognize a reply email arranged over subject, header and email body. The last chance an email has to recognize a reply is related to the subject of having a reply prefix and the record <number>. This method is popular because it does not requires a previous email from the instance to use it; however, its power is limited. I can see that using watermarks is more efficient. Nevertheless, here are my findings.

 

Incoming emails are classified following an algorithm as New, Reply or Forward. Inbound email actions enable an administrator to define the actions ServiceNow takes when receiving those emails. Reply emails can be identified by several methods. The most complex of methods to identify reply emails is: subject with a reply prefix that contain the record number and no watermarks.

 

incoming_emails.png

 

Recognizing the reply by the subject record number

Based on my tests, to classify the email using the Subject as reply, the text needs to be as follow:

  1. The first characters need to match the reply prefix and it is not case sensitive.
  2. The record number needs to be ONE word. Only spaces or ‘:’ are accepted before and/or after.
  3. The record number prefix needs to exist on the sys_number table.
  4. The number needs to be within the first 160 characters (including the number itself)
  5. The user that sent the email needs to have access to the record refered by the number

 

Based on that, you can see it can be consider as temperamental. Well, maybe.

 

The first characters need to match the reply prefix.

This is usually done by your email client. Nothing to worry except spaces before the prefix or other languages. Just ensure the subject line is starting with a recognized reply prefix. Just avoid spaces (or invisible spaces - e.g. MS word justifications paragraph markers) before the prefix.

 

The record number needs to be ONE word. Only spaces or ‘:’ are accepted before and/or after.

The record <number> is the field called 'number' on the target table. The record <number> has to be one word (e.g. INC00001) and with a valid record number that matches an existing record.

Yes, <number> needs to be ONE WORD (no symbols or characters around them) with spaces around it (e.g. MM-INC0001 is wrong).

The record number 'prefix' needs to exist on the sys_number table

The number "prefix" needs to EXIST and ideally be unique (or first found) on the Number Maintanance (sys_number table).

 

e.g. INCxxxx record will INC match on sys_number table, and it will provide the 'incident' target table.

 

Another example is TASKxxx record. It will match TASK, which points to two target tables. Use with caution. It will match the first table found causing inconsistency. Prefixes are stored on Number Maintanance, and there are TWO "TASK" prefixes. On my testings, it was matching TASK prefix from the task table, instead of TASK from sc_task table.

 

To validate the prefixes, check

<instance>/sys_number_list.do?sysparm_query=prefix!%3DNULL

Here is the how it looks:

02-Number_maintenance.jpg

 

The number needs to be within the first 160 characters (including the number itself) of the subject

There is a limit of 160 characters on the sys_email subject. When creating the subject, ensure the <number> is on the first 160 characters. To validate if the subject was  correct, after the instance process the email, the incoming email logs will show:

Received id=<Message-ID> Classified as reply to '<number>' found in subject

If the subject is incorrect, the incoming emails will get classified as New.

Received id=<Message-ID> Classified as new

 

Here are the results of my testings with different subjects. INC0001 is a valid incident number.

Working subjects:

Reason

Re:INC0001 

Reply prefix + number

re: Review INC0001

Reply prefix + anything + “space” + number

RE: Review:INC0001:

Reply prefix + anything + “colon” + number + “colon”

rE:INC0001 Review

Reply prefix + number  + space + anything

 

You can see the reply prefixes are not case sensitive. Space and colon are acceptable.

 

Not working subjects:

Reason

Re:Review-INC0001

Minus is not acceptable. Space and colon are fine.

Re:Review -INC0001

Minus touching the number is not acceptable.

Re:Review TEST0001

TEST is not a valid sys_number prefix.

Even if the number=TEST0001 exist.

This could happen on manually created numbers

Re:TASK0001

Acceptable but it may pick the wrong target table. from sys_number. There are two TASK prefixes.

Re: XX…(160+chars) INC0001

The subject will get truncated leaving the number out. Place the number on the first 160 characters.

     Re:INC0001

Space before the prefix is not acceptable.

 

As you can see, the character - before the number  is not acceptable. Also, the number needs to exist on the target table. Also, if the number was created without following the prefix (e.g. TEST instead of INC), it will not match.

 

Here are the results on the sys_email table:

01-identified-email.jpg

 

If you are using subjects for reply emails without watermarks, ensure you are using the email prefix, then <number> separated with spaces and the rest of the subject. Then all should be as easy as drinking a glass of water.

 

I have tested with Chrome as browser on Fuji. Emails were written on Outlook 2011.

 

More information here:

Since workflows execute on the server there are a couple of questions that often arise from my clients:

 

  1. How do I control the features I want the workflow to execute?
  2. How do I do this without having to modify the workflow?
  3. Or better: From a ServiceNow Admin: How do I give the user control of the workflow without giving them Admin rights?

 

These workflow requirements arise so often that I have created patterns to describe them.

 

What are patterns?  These are software development descriptions that quantify often repeated designs, and are a software engineering best practice.

 

 

The Patterns

 

1. Workflow Control Via Variable Input

 

This pattern describes control via a Service Catalog variable or variables.  The User Interface (UI) would consist of choices presented to the user in a Service Catalog Request, or UI Page.  These choices would represent variable values that configure how the workflow will react.

 

The choices could be:

 

  • Added at a later time to activate portions of the workflow.
  • Removed at a later time to de-activate portions of the workflow.

 

The down-side to this pattern is that the Application Owner must request addition or removal of variable values from the ServiceNow Admin team.  However, how often would the App Owner actually want to turn things on or off?  Not often I should imagine.

 

Here is a visual diagram of the pattern:

 

 

Now to demonstrate how this works consider the following diagram:

 

 

Let us suppose that a State field in a Service Catalog form had several values.  Two of these values: Active and New would be used to trigger special behavior in a workflow.

 

If we remove the Active value from the State field choice list we will be effectively deactivating the section of the workflow that would be normally available.  No code was changed, and if the Application Owner ever wanted to reactivate that feature then they would simply request re-adding it to the dropdown.  On or off.  Simple.

 

So that is the first of the two patterns.  I almost never use this myself, but I present it here as a form of “building-block” for the next pattern.

 

 

2. Workflow Control Via Property Input

 

This pattern provides control through a configuration property.  This property could be administrator accessible only, but more likely it would be available to the Application Owner through a Module and a Properties Page (user interface). This would allow for security to be easily implemented.  The Application Owner could then make features available/unavailable

 

Here is a visual diagram of the pattern:

 

 

Because of the ability to easily create property UI this provides a slick way to integrate this method into the SeviceNow application.  You could create an “Admin” module for the Application Owner that would be visible only to them.

 

Another nice feature is that the properties are not limited to “on/off”. They can also be string or number values.

 

The following diagram describes a possible use-case:

 

 

As a ServiceNow Administrator I prefer this pattern.  Since it puts control into the Application Owner’s hands.  I don’t have to maintain that portion of it through requests.  One less thing on my massive to-do list to schedule into my busy day!

 

 

3. Workflow Control Via Variable Examination

 

The final pattern, I want to show, provides control through a set of coded rules that examine the inbound variables and trigger flags according to what is found.

 

 

With this pattern the control would be in the rules.  This could be a check for a value or combination of values which would then set a Workflow Scratchpad variable that in-turn would be used in determining the flow.

 

The following diagram presents a possible use-case:

 

 

To make this work you would have to use my enhanced If Activity, but you get the idea.  The “rules” are in the code, and develop true/false values based on the inbound variable combinations.  This is a bit of a twist on the first pattern, and can be combined with the second to provide some flexibility.

 

Obviously you can mix and match all three patterns, but I wanted to show them in their simplest form.  Patterns provide a reusable and thoughtful approach to architecting a solution to fit your needs.  Remember: reusability and maintainability should be primary best practices!

 

In my next couple of articles I will be giving working examples of these patterns.

 

Steven Bell

 

 

If you find this article helps you, don't forget to log in and "like" it!

 

Also, if you are not already, I would like to encourage you to become a member of our blog!

 

Filter Blog

By date: By tag: