For years, if I wanted to move data through the system, I would export XML, go to the next instance, import the XML, etc. I never really though about it; I thought this was the way to do it and that was it. Then, recently, a colleague showed me something he does:
He uses it to create backout update sets that can just be applied to revert changes. But, all it does is save the XML of the current record. He uses it to make originals of scripts he touches. But, this got me thinking. I could use it to save the XML of data used to support my releases.
var table = current.getTableName();
var sysID = current.sys_id + '';
addToUpdateSet(table, sysID);
function addToUpdateSet(table, recordId)
{
var um;
if (typeof GlideUpdateManager2 != 'undefined'){
um = new GlideUpdateManager2();
}
else{
um = new Packages.com.glide.update.UpdateManager2();
}
var rec = new GlideRecord(table);
rec.get(recordId);
um.saveRecord(rec);
}
So, let's say I am adding a group to support my release:
The Group:
The Update Set:
The Data:
So, now it is just one step. Deploy all your code AND all the data to support it in a single update set.
The only gotchas are the same gotchas that exist with pure XML insert: if you have any other unique columns, it will conflict if it exists in your target instance. But you can go in and manually change the XML in sys_update_xml if that conflict happens.
