Teach Me Salesforce

A community approach to learning salesforce.com

Salesforce DX Monoliths: Chipping Away at the Metadata

leave a comment »

Yesterday I started preparations to build a package from actual production metadata after experimenting with 2GP in a Trial DX Org first. My goal is quite modest: a package with the 4-5 fields and matching Permission Set necessary for one of our integrations.

The preparations followed a predictable pattern:

  1. Authorize a new DevHub (I’ve got 35 orgs, I hope my DevHub aliasing convention works for the other 32 yet to be DXed!)
  2. Clone the git repo where our metadata is backed up daily by Copado (fast easy way to do this).
    1. Create a new branch for DX-related manipulations.
  3. Create a new DX project (finally understood the difference between –outputdir and –defaultpackagedir. I mistook outputdir as the location that new metadata files would go into eventually. But it’s simply the location that the sfdx-project.json, config/scratch-project-def.json, .forceignore and the readme.MD)

Then began the process of getting just the metadata I wanted in the package. I saw a couple approaches:

  1. Create and populate the files manually (maybe just cutting and pasting from actual metadata).
  2. Retrieve the actual metadata and remove what I don’t want in the package.

The first would probably have been faster and what I would do in the future but I thought it would be a good exercise to remind myself of all the metadata that is there and be sure I kept all the dependencies intact.

So for a couple hours I used git rm -r to remove all the unnecessary metadata from the branch. This was tedious, especially when I had to leave one file like a Permission Set but delete all the other files in a folder.

After getting down to just the two Objects with fields I want plus the Profile and Permission Set that will be used for the integration user, I attempted my first $sfdx force:mdapi:convert -r ../src/ -d force-app/
and I got an errorI had deleted my package.xml and had to restore it and strip out all the unnecessary references.

After I restored the package.xml, the convert worked although I got an apparently non-critical fatalError message because I left a ” </recordTypeVisibilities>” tag in the profile file. I think I also had a missing end tag in the package.xml.

[xmldom fatalError] end tag name: recordTypeVisibilities is not match the current start tagName:Profile
[xmldom error] element parse error: end tag name: recordTypeVisibilities is not match the current start tagName:Profile
[xmldom fatalError] end tag name: Profile is not match the current start tagName:undefined
[xmldom error] element parse error: end tag name: Profile is not match the current start tagName:undefined

But the convert worked anyway. I had decided to leave the two Object files intact rather than remove all the additional metadata in them. So I ended up with extra folders I’ll have to delete:

  • fieldSets
  • listViews
  • recordTypes
  • validationRules
  • webLinks
  • Plus the Account.object-meta.xml with ActionOverrides and other metadata I won’t need.

When I ran sfdx force:source:push -f I left <trackHistory>true</trackHistory> in the field definition files but had deleted the object-metadata.xml file that contained the <enableHistory>true</enableHistory> so I got errors like:

N/A                      The entity: Account does not have history tracking enabled (3:13)
N/A                      The entity: Lead does not have history tracking enabled (3:13)

And I had a couple of custom picklist values in the Lead businessProcess and the Account recordType files that I had to remove from the XML.

───────────────────────────────────────────────────────────N/A                      Picklist value: New not found (48:24)
N/A                      Picklist value: inboundcounselor in picklist: AccountSource not found (37:18)

But, one of those picklist values was the default, so I got a very tricky error:

───────────────────────────────────────────────────────────N/A                     No default value specified (48:24)

And I could only figure that one out by noticing that the 48:24 reference matched a previous error so at least I could look in the correct file for the problem.

At this point I recognized that I should have left the StandardValueSet in place so that the businessProcess file can refer to the picklist values for Lead.Status. I was expecting that other dependencies were waiting for me so I decided I should just start over. git reset –hard ffc1b. Glad I was committing frequently as I made small changes!



Written by Always Thinkin

January 14, 2018 at 5:16 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: