Have you ever struggled with moving complicated data structures between instances? Do you wonder if it is possible to define custom XML exports? If you are curious about advanced XML exports and its usage, this article is right for you.
ServiceNow offers the export of any item to XML. It is commonly used to move data, which are not tracked in update sets, between instances. This happens quite often as customers commonly have multiple instances. Real data are in the production/test instances and sometimes it is important for the developer to work with relevant data and the whole instance clone procedure is not possible.
Exporting data from one table is quite straightforward, we can configure a filter and export an XML file and then import it. But it gets tricky when we need to export items containing related items. Then we need to configure multiple filters with a correct filter showing items related to the parent record and it will be stored in the multiple XML files.
ServiceNow offers this possibility, but it has to be developed/configured for particular cases. Here are some examples implemented directly by ServiceNow in the platform: exporting update sets with related update actions, projects with project tasks and dependencies or ROTA schedules.
To achieve this you have to create a UI action, which is redirecting the user to the custom Processor. As an example, you can check OOB UI action Export to XML for the table pm_project and related processor ExportProject (System Definition -> Processors). These processors are using OOB Script Include ExportWithRelatedLists.
One of the use cases of this solution is exporting Service Offerings with related Service Commitments and relations between them and I will showcase this solution. There are also other related items to the Service Offering, which are not shown in the script for simplicity.
This is what a custom processor looks like. Name is not important, but Type is a script, so you can write your own javascript code. You have to specify a path by which it will be called from a UI Action.
And here is the code of the custom processor:
The constructor of the ExportWithRelatedLists accepts the table name and Sys id of the parent record. One item has to be specified as a parent, which is then used in the other functions of the same export run. Also, all fields for this record are stored in the XML file.
Function addQuerySet will include records from any table. You just have to specify the table name and encoded query and during the export, this script will include all items from the query. We have prepared this query by GlideRecord with another filter.
Another function that can be used is adding a related list. It is used for exporting tables that are connected to the parent record via a reference field. It has parameter table name and field name of the reference field, by which it is connected to the parent record. In our case, we have m2m table service_offering_commitment which has field service_offering, that is a reference field to service_offering table. API will then automatically insert sys id of the parent record here so it will return all items from service_offering_commitment table, where field service_offering is equal to sys_id of the exported record (parent record from the constructor).
We can also decide if the export should include attachments to the XML. All you need to do is call the function setAttachments with the parameter “true”. Just be aware that attachments are included only for one parent record.
After calling function export records API will write the XML file into an HTTP response and the XML file will be downloaded by the user. The filename will always be a combination of the parent table name and the sys_id.
Then we just have to create a simple UI action for the Service Offering table:
And one line in the code:
action.setRedirectURL(“export_service_offering.do?sysparm_sys_id=” + current.getUniqueValue());
This script can also be adjusted to accept a list of sys ids. It allows a user to select multiple service offerings directly from the list view via check-boxes. But then one service offering has to be specified as parent items and others have to be included by function addQuerySet. The downside is, that filename can’t be changed and attachments are included only for the parent item.
First, we tried to use export sets, but when we needed to move just particular items, export sets had to be configured each time and also not all fields were included automatically.
This solution takes just a few minutes to set up and then you can export any hierarchy from ServiceNow. It saved us a lot of time moving Service Offering between instances. It is a really useful tool in ServiceNow, which can decrease the amount of manual work during development and testing.
The presented approach could also be used in Project management or Agile plugin for exporting hierarchies. As groups and role assignments are not stored in update sets, this case can also be used. Or even for the exporting of Catalog items with all variables, variable sets, UI policies, and client scripts at once.
Custom XML export API of ServiceNow is not well documented, but it is already used in many places in the platform, so I hope this article will clarify its usage and help you speed up the development process.
