Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Dan Martinez
Tera Expert

Overview

Over the years I haven see customers struggling to export data thinking all they can do is either do it manually or via a web service, but they forget about “Export Sets”, a feature that if I remember correctly was released back in Jakarta. These are, somehow, forgotten so in this article I will show how to configure an “Export Set” to be generated for Closed Incidents.

 

Requirements

Export sets come Out of the Box and require no plugin or application to be installed.

 

Setting up the scene

Everything that has to do with exports sets can be found under “System Export Sets” as shown below:

 

Menu.png

 

Bear in mind Export Sets require the following:

  • Export Definitions
    • What will be exported
  • Export Targets
    • Where the exported data will be stored
  • Scheduled Export
    • When the export will take place

Let’s have a look each of them, why they are required and how to configure them to make it work.

 

Export Definitions

If you go to “System Export Sets > Administration > Export Definitions” you will be able to create yours. Export Definitions define what needs to be exported, not just in terms of the fields required, but also the condition that will apply. You will realise that when you select the Table, a bunch of fields suddenly appear populated. This is because there is an OOB Client Script that retrieves what are the fields in the Default view and pastes them there. You can always modify the fields that appear, either to remove them as to add some that didn’t appear automatically.

 

In the example below I have entered the condition as “Active IS false” as you can see and I have left the default fields as the ones that will be exported:

 

Export Definition.png

 

This is to restrict the incidents we need to export to be the closed ones only. The next step is to define where to leave the content exported. Let’s have a look at the Export Targets then.

 

Export Targets

These records only contain two important fields, the MID Server where the file will be stored and the File Path defining the exact path within the MID Server itself. Bear in mind the path is correct and the MID Server is up and running before scheduling the Export Set. Here is how I configured mine:

 

Export Target.png

 

Export Sets

These records allow us to specify the remaining bits and pieces of the export and will serve as the element that relates the “Export Target” and the “Export Definition” we have just crated. Here’s how I have set it up:

 

parent1.png

 

The first thing we do, apart from giving it a name, is defining the name of the file that will be generated, in our case “incidents.csv”. Then we can tick the “Append timestamp” which will append the timestamp to the file name. This is very useful in case there are several exported files. You can still check the creation date, but this may help with sorting too.

 

Column headers have the following options:

 

Coplumn Headers.png

 

Imagine you have selected the “Short Description” within the fields to be exported. If you select “Use field name” then “short_description” will appear as the header instead of “Short Description” which is what would be displayed if you select “Use field label”

 

Column values have the following options:

Columnvalues.png

 

The best way to describe this would be using references. Imagine we want to export the “Assignment group”. If we selected “Use display value” we would ben exporting the name of the group, say “Service Desk”, whereas if we choose “Use raw value” then the sys_id of the group would be exported instead.

 

In the example above, I selected CSV as the format, but these are the other options you have:

 

fileFormat.png

 

Then we have two tabs, “What to export” where we select the “Export Definition” and under the “Where to export to” we have to select the “Export Target” created before.

All we need now is to define when this export we have configured will take place and for that we will cover the last element type, called “Scheduled Export”

 

Scheduled Export

A Scheduled Export works quite similarly to any other Scheduled job, so I will skip the well-known fields they have in common.

 

In the Scheduled Export we need to select the Export Set we have just created, which in our case was called “Incidents”. After this, there are two tabs underneath, the first one “Delta Exports”, where we have the opportunity to define whether we want the full export of records that satisfy our criteria, or we just want the ones that have been either created or updated since the last execution. For instance, in our case, we could do a full export on day one, and then a monthly delta from that day exporting a handful of incidents that have been closed within the last month.

 

Scheduled Data Export.png

 

To define whether we need the ones that have been created or updated since the last execution, we have the “Delta on or after” field. The “Last export scheduled run” allows us to define a date if our scheduled job has never run before. This is especially useful if we used to have a scheduled Data Export that was removed and we want to continue from the last point we left it, or if we simply want to ignore records created or updated before a certain date.

 

Scheduled Data Export 2.png

 

Last but not least, we have the “Scripts” tab, which allows us to run the export conditionally. For instance, we could set a condition that checks if a given plugin is installed, a system property has a given value or if there have been rows synchronised from an external system, among other examples.

 

The “Execute pre-export script” and “Execute post-export script” allow us to trigger behaviours similar to the ones “Transform Scripts” do in Transform maps.

 

Some use cases I have seen would be validating data before the export happens or triggering a notification to someone to let them know there’s a new export produced on the post-export script.

 

Once this record is set up, all we have to do is wait for the specified date/time of the Scheduled Execution and the file will appear where we told ServiceNow to.

 

Export History

Finally, bear in mind any exports produced out of this "Scheduled Execution" will be listed in the "Export Set" down under the Related lists so you can check how many times it was executed under the  "Export Histories" tab. They look like this and will let you know if it was a delta export, if it was completed, and if so with errors or without.

 

history.png

 

Feedback

Please like 👍 and share 🌍 this article to your colleagues if you found it useful.