Skip navigation

this-is-hot.pngthis-is-hot.pngthis-is-hot.png

Hello ServiceNow developers and partners seeking to redouble your startup's growth, expand your addressable market, and experience lasting fame and fortune!

 

The  CreatorCon Challenge entry deadline is Wednesday, February 15th, at 8:00PM Pacific Time !!!

 

Complete your entry for a shot at $500K in cash investments from ServiceNow Ventures for three startups, and over $300K worth of marketing and business development prizes for up to ten startups! Holy Mackanow!

 

creatorcon_challenge_keynote.jpgThis Could Be You on the CreatorCon Main Stage at Knowledge17 !

 

Mandatory Entry Materials

 

1. Two-minute investor pitch video - why ServiceNow Ventures should consider investing in your company. Guidelines on what to include in your video:

 

a.Your Team/Background
b.Company vision
c.Addressable market size
d.Sustainable competitive advantage/differentiator
e.App pitch (use case, problems solved, value delivered)
f.Use of ServiceNow platform services/technology stack
g.Roadmap highlights
h.Forecast (customers/bookings)

 

2. Five-minute app demo video - on-screen recording with narration demonstrating the user experience for both a ServiceNow admin and an end user

 

3. Your app, resident on your designated developer instance

 

Check out the pitch videos from the ten 2016  CreatorCon Hackathon finalists to get a flavor for how to pitch and demo your app.

 

Your app does not have to be Store, production instance, or even sub-prod instance ready! It only has to be in a demo-ware state by the entry deadline! There is still time!

 

Happy hunting and we hope to see your company and app at the finish line!

 

Team CreatorCon Challenge

Martin Barclay
Director, Product Marketing
App Store and ISVs
ServiceNow
Santa Clara, CA

In this episode, Ankit Khetarpal shares his best practices for keeping your ServiceNow instance at peak performance.

volume_icon.png

Listen

 

 

Subscribe

 

to iTunes

 

This episode covers:

  • Stats page
  • Semaphores
  • Schedule workers
  • Debugger
  • What's new in Istanbul

 

For more information on ServiceNow Express, see:

 

Your feedback helps us better serve you! Did you find this podcast helpful? Leave us a comment to tell us why or why not.

 

LISTEN BELOW

 

 

To catch clips behind the scenes with our podcast guests, and find out what topics we'll be covering next before they are posted, follow @NOWsupport on Twitter. You can also search Twitter using the hashtag #SNtechbytes for all previous podcasts, video clips and pictures.

choices.jpgWith the introduction of Service Portal in Helsinki, those who had spent the last few years knee-deep in CMS development and wrestling with Jelly/iframes rejoiced! Finally, there was a modern solution for elevating the end-user experience.

 

Virtually every customer or partner I have chatted with around Service Portal has asked the same question: Is there a migration plan from CMS? With good reason. With checks still being cut for CMS development, how do you not lose out on all that work you did to get to the new portal?

 

The short and unfortunate answer is: there is no migration path. It’s a completely new technology and runs in a whole different way:

 

  • CMS uses Jelly, Service Portal has AngularJS
  • CMS has layouts for HTML, Service Portal uses Bootstrap
  • CMS requires iframes for forms, Service Portal has built-in widgets for that to render within the page

 

So programmatically it’s all different. That dynamic block that you spent days working on will need to have about 90% of it ripped out and replaced. Why 90%? Well, you can take advantage of some of the server side scripting and styling that you put in place for use within your new widget.

 

Style wise you might be able to salvage some of the work you’ve done if you previously designed for Bootstrap. You can use the same CSS which might save some time.

 

Translations, messages and system properties can be retained, but need to be adjusted at the code level as to how they are used.

 

That’s about it, unfortunately.

 

Menus have to be rebuilt, custom JS or jQuery you have will need to now work within a context of Client Scripts on your new custom widget. Pages are a whole new beast from a layout perspective (no more templated layouts), and even URLs are going to change.

 

It’s a whole new world!

 

However, asking how to move from CMS to Service Portal might be the wrong question.

 

To me, it’s better to think through:

 

  • How do we translate our current functionality (dynamic blocks, lists, etc.) through a lens of Service Portal out-of-box widgets? More than likely you’ll find something that’s close. That will save you some time and will help with future support and upgrades to stay close to OOB.
  • Do you have any customer feedback to incorporate so you can approach this as more of a 2.0 release? If you want a straight swap you might be missing out on a great opportunity to make some improvements.
  • Will you gain by moving? Sure, the new technology is fun and exciting, but what is wrong with what you have now? Identify that before you make any moves so you know when you’ve been successful. That being said, it’s worth your effort to move towards Service Portal. CMS is going to be retired at some point (there are no plans for any development on it for the near future) so instead of moving when you HAVE to move, start thinking through now how to get from here to there.

 

With what you have available to you out-of-box, I bet you’re closer than you think.

Let's connect:

twitter.com/mattmetten
www.mattmetten.com

Anyone who has ever administered a web site or a ServiceNow instance can probably relate to this dilemma. You need to make a tiny change, such as adding a field to a form, or activating a plugin, and you're really pressed for time. Why not just quickly make the change on your production, or PROD, instance? What could happen; it's a minor change, right? In this third installment of our best practices series, we look at why you should never develop in production, and what you should do before making any changes to PROD.

 

Why you should never develop in a production instance

Sometimes it may be tempting to knock out small changes in PROD, but changes that seem minor can have unexpected and far-reaching effects.

 

For example, when you activate the Timeline Visualization plugin, Project Management V3 is automatically activated as a dependency, which could produce unwanted results. Before activating any plugin, make sure you understand which additional plugins get activated automatically, and which features they affect. These are described in the product documentation, like the example shown below.

time_visualization_doc.jpg

Development best practice

Perform all development in a sub-PRODuction instance and thoroughly test everything that’s affected before deploying to PRODuction. This includes even small changes, such as adding a field to a form, or activating a plugin, updating an access control list (ACL) rule, or tweaking a client script.

 

Before making ANY change to your PROD instance:

  • Make the change in a sub-PROD instance.
  • Make sure you understand how the change may affect downstream features, functions, and data.
  • Use small update sets that can be backed out more easily than a large one.
  • Thoroughly test the changed feature and any dependent features or functions.
  • Ideally, have other stakeholders assist with testing because they follow their normal workflow, which an admin may not be familiar with. This helps identify any issues that aren't evident to an admin user but may show up for users with other roles (such as itil). If other stakeholders can’t help with testing, use impersonation.
  • Always have a back-out plan, which includes backing up all records that will be affected by the change.

 

Leave your PROD pristine, and take all your tweaking and testing offline to your sub-PROD instance.

--

 

Behind the scenes here at ServiceNow, the Knowledge Management team works closely with subject matter experts to disseminate critical information to our customers. We’ve found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise.

 

See Annotate scripts and customizations with comments for the first installment on script comments.

See Limit the Number of Users with the Admin Role for the second installment on user roles.

See Where to avoid linking to a reference field when configuring a list for the third installment on list configuration.

 

To access all of the blog posts in this series, search for "nowsupport best practices series."

Via: Code Creative

 

In a troubleshooting conversation with a couple of my teammates, I realized that I take GlideRecord (and its partner GlideAggregate) for granted.  When you make that simple gr.query() call, what happens?  What SQL does it run?  What does the real underlying table structure look like?  Are there indexes?  Are additional queries run when you dot walk?  Does any of this hit a cache?  How does the cache work?  Where are the optimizations under the hood?

 

The truth is, most of us have no idea what happens and most of the time that is really awesome!  If the queries run fast and returns accurate data we usually don't care how ServiceNow made it happen.

 

But when performance issues start to pile up on that scripted REST endpoint and all you're doing is generating JSON from GlideRecords... well, what you don't know could be killing your instance.  The Nested GlideRecord silently drags down your app's response times, killing usability and the first step to fix it is to learn how to identify it.

 

The Basic Pattern

 

A Nested GlideRecord is when you run a GlideRecord query within the while loop of another GlideRecord query, like this:

 

var gr1 = new GlideRecord('any_table');
gr1.query();
while (gr1.next()) {
  var gr2 = new GlideRecord('any_table');
  gr2.query();
  while (gr2.next()) {
   // Do something here
  }
}

 

Now, take a look at that script.  How many times does that script query the database?  The correct answer:  I have no idea and neither do you.  We don't know how GlideRecord works exactly.  What we do know is that in the worst case it will run one query for gr1.query() and an additional query for each record in gr1 (gr2.query() inside the while loop).

 

The defining feature of this performance killer is using many smaller queries when one larger query could retrieve the same data.

 

A Crude Scenario

 

So lets take a look at a somewhat real world script to get an idea of why this is such a problem.  Lets try to find and output a list of duplicate user records.  We'll keep it simple and assume the first record found is the original.  To do this, we need to:

 

  1. Get a list of usernames with a count greater than 0
  2. Find all user records with those usernames
  3. Update all but the first with a duplicate flag

 

For this test, I will compare 2 approaches:  Nested GlideRecord and an Array Flattened GlideRecord.

Here is a crude Nested GlideRecord approach:

 

var count = new GlideAggregate('sys_user');
count.addQuery('email', '!=', '');
count.groupBy('email');
count.addAggregate('COUNT');
count.query();
while (count.next()) {
  if ((count.getAggregate('COUNT') * 1) > 0) {
   var user = new GlideRecord('sys_user');
  user.addQuery('email', count.email + '');
  user.query();
  user.next(); // skip the first
   while (user.next()) {
  gs.print(user.sys_id);
   }
  }
}

 

And the Array Flattened GlideRecord:

 

var users = [];

var count = new GlideAggregate('sys_user');
count.addQuery('email', '!=', '');
count.groupBy('email');
count.addAggregate('COUNT');
count.query();
while (count.next()) {
  if ((count.getAggregate('COUNT') * 1) > 0) {
  users.push(count.email + '');
  }
}

var user = new GlideRecord('sys_user');
var prevUser = '';
user.addQuery('email', 'IN', users.join(','));
user.orderBy('email');
user.query();
while (user.next()) {
  if (prevUser == user.email + '') {
  gs.print(user.email);
  }
  // Else, skip the original user
  prevUser = user.email + '';
}

 

Running these two scripts in the background, I was able to achieve some poor man's stats after a few manual runs with 1144 user records and 572 duplicates:

 

  • Nested GlideRecord: ~0.795 seconds to execute
  • Array Flattened GlideRecord: ~0.145 seconds to execute

 

Now this is a pretty extreme example that will more likely be executed as background script or scheduled job rather than a user facing transaction.  But that performance difference between the nested and flattened scripts starts to add up when multiplied by the number of users hitting your site and the depth and frequency of nested GlideRecords in your scripts.  Pretty soon, you might find your database running a query every 60 seconds (yep, that actually happened on a different client).

 

Dot Walking Has The Same Results

 

The scary part about this pattern is that it easily hides itself.  Dot walking, for example, works like magic to retrieve related data.  Under the hood, it runs a query at least once to retrieve the reference (I assume the reference is cached for subsequent calls in a given script if not the entire transaction but I'm not sure).

 

So the following script could inadvertently cause the same issue as the previous example (and in the originally mentioned REST script, I believe this was a contributing factor):

 

var gr = new GlideRecord('sys_user');
gr.query();
while (gr.next()) {
  var department = gr.department.name; // Reference Field!
}

 

That Department is a reference field, so ServiceNow has to run a separate GlideRecord query behind the scenes to retrieve the data for that department.  All magic comes at a price, deary!

 

Or How About ACL's

 

Running a GlideRecord query in an ACL yields the same effect.  In this case, its subtle but still there.  If you run a query on the incident table for example, an ACL will be applied to (and the script run for) each record in the resulting set.  For each and every record in your resulting set, a narrowly defined GlideRecord query will execute to find out if the user can see the record!  (This by the way was one of the primary causes behind the 60 second queries).

 

Bottom Line

 

Here's the too long didn't read:  Avoid using 20 narrowly defined GlideRecords when with a little work you can combine it into a single broader GlideRecord.  Watch out for the same pattern in ACLs, dot walking, and other ServiceNow scripts.  This pattern likes to hide itself.  Another time, we'll take a look at some strategies to fix this.

For more of my content checkout: https://codecreative.io

ServiceNow has developed a utility called “code search” which helps to search a code both within and outside of your application. This is helpful whenever you’re troubleshooting or just trying to understand how something works. Code search is built into the ServiceNow Studio IDE interface to make developers life easier. Search can be easily applied without navigating to the platform UI by applying additional filters using Code Search. Code search is offered in the Geneva release onwards. I will walk you through an example of how to find a particular line of script/fields and where it is being used in the system

 

Example of how to use code search

Let’s assume as part of my troubleshooting, I want to investigate what all scripts are triggered against a field for ex: close_notes which set the field to be mandatory. Here are the steps to be followed.

  1. On your instance navigate to System Applications>Studio
  2. Click on open Studio tab.

    Studio servicenow.jpg

  3. Now select one of the applications from the list (for example, Now application)

    code search application.jpg

  4. Now on upper right corner, you will see the “Code search” button.

    code search servicenow.png

  5. Click on Code Search.
  6. Enter the search for ex: close_notes.
  7. Now you have the option to either select a table to search from or search in all application.
  8. Select one of those options and hit search button.
  9. The output result will be the name of the script(hyperlink) with code line number in case a match is found.

    output result.jpg

As you can see, we have all of the scripts which are triggered against the field close_notes. In this particular case, it's most likely a client script/UI action/UI Policy which is responsible for the mandatory operation. Now I can go through all the scripts found to understand the behavior further.

 

Tables included in code search scanning:

Below is the list of tables on which scan is performed whenever a user enters a keyword to search for. For ex: In the above case we have searched for a field "close_notes".

  • Access Control
  • Business Rule
  • Client Script
  • Email Template
  • Inbound Email Action
  • Map Page
  • Notification
  • Processor
  • Relationship
  • Scheduled Script Execution
  • Script Action
  • Script Include
  • Style
  • Table Transform Map
  • UI Action
  • UI Macro
  • UI Page
  • UI Policy
  • UI Script

 

Please note the scan will be across global and scoped applications.

 

Code Search presents a powerful tool to developers. This is really helpful to find a particular script during active development in their instance. This allows the developer to search scripts across the platform, rather than doing the limited search on the individual table by applying a filter i.e business rules, client script, UI scripts, etc.

 

For more information on code search see:

Is there a way to make Studio's Code Search into a favorite or module?

What's New in Geneva for Developers?

- Pradeep Sharma (@sharma_pradeep)
ServiceNow

PS: Hit like, Helpful or Correct depending on the impact of the response

iceburg.jpgFor the past six months or so I’ve been gallivanting around the world with a crew of folks teaching, evangelizing, discussing the new Service Portal application that came out in Helsinki. Without a real solid training program out yet (though it’s coming soon!) we basically created our own to help the internal folks, partners and customers get up to speed on Service Portal.

 

There is so much that I’m loving about Service Portal:

  • No iframes. I could just stop there.
  • No Jelly coding. While it has meant I have a learn AngularJS, I’m glad for the community to not be restricted by such an obscure programming language.
  • Pixel-perfect sites. I can get a portal to look EXACTLY as I want it to be. I’m not sure there’s another enterprise UX tool out there with so much flexibility.
  • If I can dream it, I can build it. Angular opens so many doors to interactive and modern experiences. You marry that with the power of the platform and you have something pretty exceptional.

 

Sure, there are some bugs and things that are being worked out, as I would expect with any recently released product. If I compare what we had (CMS) with what is there now, no contest.

 

That being said, the solution for all your enterprise service management (ESM) woes is not Service Portal (SP). By that I mean, SP is just an application within a much larger and powerful platform. It’s the vehicle that is going to take your ESM to a whole new level. You are not just going to magically fix all your problems because there are some great out-of-box widgets to use.

 

Once you have your strategy in place, SP gives you the opportunity to make some real magic. But at the end of the day, if you have a form with 100 fields that are all mandatory to be filled out before a Catalog Item can be submitted, that’s not a SP issue.  If your site looks beautiful and responsible and branded you have definitely accomplished something great, but if people can’t get to what they are looking for when they search or have to click through seven levels to find that one service, you’ve missed the mark.

 

Much like an iceberg, the true challenge of launching an enterprise portal lies beneath the surface of interface. Sure, learn the new technology and become incredibly proficient at deploying widgets and spinning up beautiful portals. But you also have to consider a few things if you want to truly transform the customer experience:

  • Why do your users come to your site? What are they hoping to achieve/accomplish/find?
  • To the business, what value is a great portal? What is the cost to one that under-performs? How will you know?
  • How come the portal is the way it is now?
  • Do you have a baseline of who is using the portal now? Which pages are they going to? Which articles are they reading? Do they give up somewhere along the way?

 

Service Portal does allow you to seriously improve the impression your portal will give your end users. Take the time as you move towards that 2.0 release and make sure you are not just swapping out one mediocre experience for another that just happens to look a bit better.

Let's connect:

twitter.com/mattmetten
www.mattmetten.com

EDIT: *The UI Page "CodeSearchExampleUse" mention below doesn't work in Istanbul release, there you need atm. go through the studio*

 

I have been supposed to write this post for months now, and finally I got the time to do it.

 

I doubt I'm the only one being in the position where I forgot where I wrote a specific piece of code or that you can see that something is changing the data, but you can't figure out how/where.

 

Lucky for us, ServiceNow has a solution for us, you just need to search a bit to find it. The solution is named "Code Search". This been around for a while and it pretty much lets you easy search for a piece of code in a lot of places. After read what I could find in the docs, I would guess this is made primary for the ServiceNow Studio and I'll come back to that in the end of this post.

 

so, here is how to find it:

 

Code Search itself is an application and you can find it by going to "System Applications->Applications" in the navigator.

 

Then you need to click on "downloads" and there it appears in the list. You can click on it to get some more information about it.

 

Looking around in the records it has, you can see that it got a UI page called "CodeSearchExampleUse", let's look at it.

 

 

 

You can see its got a endpoint, so lets click on it and see how it looks like.

 

Just check the box "Search All Applications" and fill in what you looking for and tada, it gives you the result.

Here you can see that for example there is 2 client scripts having "setValue" within them. It also give us the client script name and even at which row it can be found.

 

Atm. I can see that it searches through:

  • Approval Steps
  • Inbound Email Actions
  • Style
  • Installation Exists
  • Client Script
  • Validation Script
  • Scheduled Script Execution
  • Relationship
  • Macro
  • UI Page
  • AJAX Script
  • Transform Script
  • Notification
  • MID Server Script Include
  • Access Control
  • Map Page
  • Workflow Activity Definition
  • Knowledge Nav-ons
  • Schedule Item
  • Table Transform Map
  • UI Script
  • Business Rule
  • Dynamic Content
  • Email Template
  • BSM Map Actions
  • Processor
  • Script Include
  • UI Action
  • UI Policy
  • Widget
  • Script Action

 

So it's quite the list and a real nice help to find stuff.

 

But it's some clicks to get to the search page and sadly there isn't an application with modules done for this. But you can make your own.

 

This is what I have done:

I've made my own application with modules that I use often and I put CodeSearch as one module. The module looks like this:

 

And just to show you what I meant with it exists in studio, this is where you will find it:

 

 

So there you go. I hope this will help you in the search of code as it has done for me.

 

Take care,

Göran

 

Symfoni Logo Color Box.jpgadvocate.jpg

//Göran

ServiceNow Witch Doctor and MVP
-----------------------------------
For all my blog posts: http://bit.ly/2fCzj1g

Description

 

Mimeo copies hierarchical data between tables while preserving sys_ids on reference fields all without scripting! This is great for moving data from a global app to a scoped app, or updating data on a secondary table for reporting or limited access use cases. Using familiar tools such as the auto mapping feature and mapping assist borrowed from import set transform maps, you can quickly constructed a map of tables and fields to copy. Mimeo identifies the reference fields that need new sys_ids and updates them to point to new records in the target tables.

 

Mimeo also allows you to quickly debug and retest your maps. These maps can be captured in update sets to easily migrate them to other instances for additional testing and production.

 

Common use cases

  • Migrate data from a global app's table structure to a scoped app's tables
  • Replicate (all or part of) data from one set of tables to another for reporting or users with separate ACL structure

 

Download

 

Compatibility

  • January 3, 2017: Tested with Geneva, Helsinki (P7), and Istanbul (P0)

 

Explanation/Demonstration Video

** NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, SYMFONI ESM**

 

When the Helsinki release arrived we all saw Service Portal and what it can do. All our focus was on how it would help us move from the old CMS application to a brand new world with Service Portal. Giving us the widgets, AngularJS and other fun stuff. Which would make our life both easier and funnier.

 

After a while the mind started to wander away on what other functionality that could be possible with Service Portal and its pages. Lately I have noticed that I haven’t been alone going in this direction when similar thinking has been popping up at the community. Some of the questions has been on what you can do with those pages and if it’s possible to display them inside the normal UI of ServiceNow. And of course this is something you can do it and you can do it pretty easy as well.

 

Before I had time to look into this any deeper Istanbul release came and now we are really starting to see the true power of Service Portal and what you can do with it.

 

 

 

The whole CAB Workbench is built within a Service Portal and I think it’s just the beginning. I think we will see more and more applications being build this way and beside the having it built as a own UI, I bet we will see more and more pages being displayed inside he normal UI, like this example I quickly made:

 

 

This is easy created with a Service Portal and a module with an URL link.

 

Looking at what ServiceNow has on it road map and what the rumors says, they are moving more and more into widgets and Service Portal. And it’s the right way in my opinion. Going away from UI Pages, means going away from Jelly. And neither we (users) nor ServiceNow is really happy about Jelly and seeing a road ahead which means less Jelly, I think we all will love to go down that road.

 

So in the future when I get to a requirement that in the past would have been a UI Page, I will first look if it’s possible to do as a Widget/Service Portal. If not, perhaps there would be another solution and a UI Page as a last solution.

 

The only place I can see there is a need for a UI Page is where you using the GlideDialogWindow. Here I can’t see any solution to replace it with something from the Service Portal, besides perhaps building the whole thing within the portal and that might be overdoing it and one of the places it isn’t worth the effort.

 

So to answer my question in the subject. I think that UI Pages will still exists for a few more releases, but we will see less and less of them. I hope this little article has gotten your ideas a new perspective and hopefully we will see some real creative solutions in the future with Service Portal.

 

 

//Göran

 

advocate.jpgSymfoni-Logo-Color (1).png

//Göran

ServiceNow Witch Doctor and MVP
-----------------------------------
For all my blog posts: http://bit.ly/2fCzj1g

Filter Blog

By date: By tag: