Tweet |
Exporting Metadata with the Salesforce CLI
Introduction
Regular readers of this blog are all too aware that I’m a big fan of the Salesforce CLI. I rarely use anything else to interact with Salesforce orgs, outside of the main UI. Prior to this I used the Force.com CLI, which is another excellent tool, though didn’t give me quite enough information about operations to switch to it exclusively.
One area where the Force.com CLI still beats the default functionality of the Salesforce CLI is the export command, which pull back most of the metadata from an org (except reports, dashboards, and email templates, where you have to jump through a few hoops to get folder names first). Switching back to the Force.com CLI to take a backup of an org started to get a bit repetitive, so I decided to write something to replicate the functionality using the Salesforce CLI.
To Plugin or Not to Plugin
After some consideration, I decided not to plugin. I need to do some work and then execute a deployment via the Salesforce CLI, and there’s currently no way to execute a command from a plugin. I could shell out of the plugin and execute the CLI as a new child process, but that seemed a bit clunky. Plus where does it end? We’d end up with plugins creating child sfdx commands that were plugins that created child sfdx commands - a house of cards made of processes and just as fragile. I’d also seen Dave Carroll call this approach an anti-pattern on twitter and I didn’t want him mad at me, so I went with a node script that wraps everything up into a single command from the users point of view.
The Node Code
As I plan to do more of this sort of thing, rather than having loads of different scripts to execute I went with one script that offers subcommands. Kind of like a CLI all of it’s own, but very lightweight.
In order to support subcommands I used the commander module - I’ve used this a few times in the past and it’s really straightforward. I just configure it with the subcommands and their options and it figures out which one to execute and parses the arguments for me:
var exportCmd=program.command('export') .option("-u, --sfdx-user [which]", "Salesforce CLI username") .option("-d, --directory [which]", "Output directory") .action(function(options) {new ExportCommand(options).execute()}); program.parse(process.argv);
The export command is responsible for generating a package.xml manifest file containing details of all the metadata to retrieve and then executing a metadata API retrieve.
It contains a list of the names metadata components to extract:
const allMetadata=[ "AccountSettings", "ActivitiesSettings", "AddressSettings", "AnalyticSnapshot", "AuraDefinitionBundle", ...
“CustomObject”,
... "ValidationRule", "Workflow" ];
The one wrinkle here is the standard objects. If I wildcard the CustomObject metadata type, this will just retrieve my custom objects. To include the standard objects, I have to explicitly name each of them. Luckily the Salesforce CLI provides a way for me to extract these - force:schema:sobject:list, so I can pull these back and turn them into a list of names:
var standardObjectsObj=child_process.execFileSync('sfdx', ['force:schema:sobject:list', '-u', this.options.sfdxUser, '-c', 'standard']); var standardObjectsString=standardObjectsObj.toString(); standardObjects=standardObjectsString.split('\n'); for (var idx=standardObjects.length-1; idx>=0; idx--) { if ( (standardObjects[idx].endsWith('__Tag')) || (standardObjects[idx].endsWith('__History')) || (standardObjects[idx].endsWith('__Tags')) ) { standardObjects.splice(idx, 1); } }
Then I can generate the package.xml by iterating the list of metadata names and adding a wildcard entry for each of them, and append the standard objects when the metadata name is CustomObject:
for (var idx=0; idx<allMetadata.length; idx++) { var mdName=allMetadata[idx]; this.startTypeInPackage(); if (mdName=='CustomObject') { for (var soIdx=0; soIdx<standardObjects.length; soIdx++) { this.addPackageMember(standardObjects[soIdx]); } } this.addPackageMember('*'); this.endTypeInPackage(mdName); }
Once the package.xml is written, I can then execute a force:mdapi:retrieve to pull back all of the available metadata:
child_process.execFileSync('sfdx', ['force:mdapi:retrieve', '-u', this.options.sfdxUser, '-r', this.options.directory, '-k', this.packageFilePath]);
Export all the Metadata!
(The full source code is available at the Github repo. If you want to try this out yourself, clone the repo, change into the directory containing the clone and run npm install to pull down the dependencies.)
To export the metadata I execute:
node index.js export -u keir.bowden@train.bb -d output
Where -u specifies the username that I’ve previously authorised with the Salesforce CLI (I’m using the client dev org for my training system), and -d is the directory where the package.xml will be created and the metadata extracted to. If this directory doesn’t exist it will be created.
The output is just a couple of lines telling me it succeeded:
Exporting metadata
Metadata written to output/unpackaged.zip
The contents of the output subdirectory shows the package.xml and zip file retrieved from Salesforce:
$ ls -lrt
total 928
-rw-r--r-- 1 kbowden staff 20110 7 Jul 12:49 package.xml
-rw-r--r-- 1 kbowden staff 453236 7 Jul 12:50 unpackaged.zip
unzipping the unpackaged.zip file creates an unpackaged directory containing the retrieved metadata:
$ unzip unpackaged.zip
Archive: unpackaged.zip
inflating: unpackaged/labels/CustomLabels.labels
…
$ cd unpackaged
$ ls -l
total 48
drwxr-xr-x 16 kbowden staff 512 7 Jul 12:52 applications
drwxr-xr-x 4 kbowden staff 128 7 Jul 12:52 assignmentRules
…
drwxr-xr-x 7 kbowden staff 224 7 Jul 12:52 tabs
drwxr-xr-x 4 kbowden staff 128 7 Jul 12:52 triggers
and hey presto, my org is exported without having to revert back to the Force.com CLI.
Related Posts
- SFDX and the Metadata API Part 4 - VS Code Integration
- SFDX and the Metadata API Part 3 - Destructive Changes
- SFDX and the Metadata API Part 2 - Scripting
- SFDX and the Metadata API
- Force CLI Part 5 - Node Wrapper
- Force CLI Part 4 - Deploying Metadata
- Force CLI Part 3 - Accessing Data
- Force CLI Part 2 - Extracting Metadata
- Force CLI Part 1 - Getting Started
This comment has been removed by a blog administrator.
ReplyDeleteHi Bob! great post and very clear
ReplyDeleteSince you wrote it, in 2018, I am wondering if there is an alternative method to fully export the whole metadata of the ORG
Hi Jaime,
DeleteNot that I'm aware of - you still need your own package.xml that covers everything.
Thanks!
Delete