Metadata API calls were modified or added in version 34.0.
Updated Metadata Calls
The following Metadata API calls changed.
- createMetadata(), updateMetadata(), upsertMetadata(), and deleteMetadata()
- The default behavior for creating and updating sets of metadata components changed. In API version 33.0 and earlier, the createMetadata(), updateMetadata(), and upsertMetadata() calls saved all records only when there are no failures in any record in the call. Starting in API version 34.0, the default behavior allows saving a partial set of records for records that have no errors. The deleteMetadata() call allows saving a partial set of records in all API versions.
- Also, createMetadata(), updateMetadata(), upsertMetadata(), and deleteMetadata() now support a new header, AllOrNoneHeader. This header enables the rollback of all metadata changes when some of the records in a call result in failures. When this header is set to true, changes are saved only when all records are processed successfully.
- createMetadata(), readMetadata(), updateMetadata(), and deleteMetadata()
- For custom metadata types only, the metadata argument now has a limit of 200.
- The checkRetrieveStatus(ID id, boolean includeZip) call now accepts a second boolean parameter. Use this parameter to indicate whether to retrieve the zip file. This optional parameter enables you to retrieve the zip file in a background service. By default, checkRetrieveStatus() returns the zip file on the last call when the retrieval is completed (RetrieveResult.isDone() == true) and deletes the file from the server. Subsequent calls to checkRetrieveStatus() for the same retrieve operation can’t retrieve the zip file after it has been deleted. By using the includeZip parameter, you can retrieve the zip file in a separate process after the retrieval operation is completed. After the zip file is retrieved by passing true to the boolean parameter, it is deleted from the server. For example, a background file transfer service can call checkRetrieveStatus(id, true) to retrieve the zip file. This service is separate from another process that polls the retrieval status by calling checkRetrieveStatus(id, false) in a loop.
- describeValueType() (ValueTypeField)
- ValueTypeField contains the new field valueRequired. This field indicates whether the described value type field must have a value (true) or can be null (false). ValueTypeField is contained within DescribeValueTypeResult, which is the result that describeValueType() returns.
- A new deployment option, testLevel, has been added. This option enables
you to specify which tests to run in the deploy() call. The values of
the TestLevel enumeration
- NoTestRun—No tests are run. This test level applies only to deployments to development environments, such as sandbox, Developer Edition, or trial organizations. This test level is the default for development environments.
- RunSpecifiedTests—Only the tests that you specify in the runTests option are run. Code coverage requirements differ from the default coverage requirements when using this test level. Each class and trigger in the deployment package must be covered by the executed tests for a minimum of 75% code coverage. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.
- RunLocalTests—All tests in your organization are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers.
- RunAllTestsInOrg—All tests are run. The tests include all tests in your organization, including tests of managed packages.
- The runAllTests deployment option in the DeployOptions object has been removed and is replaced by testLevel.