Apex Code Development You need to sign in to do that
Don't have an account?
Andrew Weinstein "Cannot deserialize instance of complexvalue from null value null" - metadata field with CLI and tooling API
as part of a scratch org setup script, i'm trying to create and/or modify records through the tooling API - things like remote site settings, outbound messages, etc. these objects all have required "Metadata" fields.
using a remote site setting as an example: if i do this through the restforce gem for ruby, it works fine. i can execute:
Anyone else encounter a similar problem or find a workaround? In what format am I supposed to provide the metadata for a request like this?
using a remote site setting as an example: if i do this through the restforce gem for ruby, it works fine. i can execute:
resp = sf.create!('RemoteProxy', Metadata: {disableProtocolSecurity: false, isActive: true, url: 'https://www.my-site.com', urls: nil, description: nil}, FullName: 'test_remote_site')
and it creates the site correctly. if i try to do this through the CLI, though:
sfdx force:data:record:create -t -s RemoteProxy -v "FullName='test_remote_site' Metadata='{"disableProtocolSecurity":false,"isActive":true,"url":"https://www.my-site.com","urls":null,"description":null}'"
it fails with error: "Cannot deserialize instance of complexvalue from null value null or request may be missing a required field." I get the same result if I serialize the JSON. The data I'm providing is the same, so the problem isn't with the data or the API itself; it seems like either I'm not using the correct format, or something in the CLI is not serializing the JSON and/or building the request correctly.Anyone else encounter a similar problem or find a workaround? In what format am I supposed to provide the metadata for a request like this?
I'm trying to accomplish the same thing and I'm running into the same error. Were you able to find a resolution for this?
Thanks,
Michael
Kind of. I didn't find a way to create/modify these records, but I did figure out more or less how to achieve the configuration I wanted.
I think that, when I posted this, I hadn't quite figured out the flexibility of the SFDX project directory structure. If you haven't looked at the Falcon Project Template (https://github.com/sfdx-isv/sfdx-falcon-template), I'd start there. Your actual package should be in force-app/, but you can create other parallel directories in your project, which can be forceignored or gitignored as you wish. So basically, my solution was something like this:
- leave the packaged remote site settings/workflows/etc. alone and keep them in the force-app (default) directory
- create an unpackaged/ directory, which contains metadata that will be checked into source control and pushed to/pulled from scratch orgs, but NOT included in the actual package
- create an untracked/ directory, the contents of which are gitignored, that contains developer-specific files created by a scratch org setup script
- include a remote site setting in the unpackaged directory with a path like "http://SUBDOMAIN.my-site.com," and forceignore this metadata file so it doesn't get pushed to the scratch org
- have the scratch org setup script copy that unpackaged, forceignored remote site setting into the untracked directory and replace (use sed or whatever) SUBDOMAIN with an env var set by each developer
if that's all set up correctly, the unpackaged version of the remote site setting will get included in your repo as a template, but the customized version generated by your script will get pushed each time someone creates a scratch org.Hope that helps!
Andrew
We do follow a similar approach for our scratch org specific configurations. I guess my problem is a little different though, as I'm trying to create a script that will dynamically change the Remote Site Settings after a Developer Sandbox refresh.
Maybe I'll reach out to the DX Trailblazer group to see what the actual format of the metadata fields needs to be for the CLI, or if it's even a supported feature. The examples in the CLI reference are pretty trivial.
Thanks,
Michael
I'll watch for answers in that group as well.