Many Salesforce developers and system administrators use Metadata API to manage the modification and release process for complex organizations. This blog covers guide about Salesforce Metadata API.
Understanding Metadata API
Metadata API is used to assist developers in retrieving, creating, deploying, updating, or deleting the customized information. This can be such a thing that is done using custom object definitions and page layouts for the organizations. The Salesforce Metadata is meant to be used for management to make customizations and build tools to assist management at the mode of metadata.
The easiest and simplest way to access the functionality in Metadata API is to use the IDE of Force.com or Ant Migration Tool. To simplify the work with Metadata API, both tools are built on top of Metadata API and use Ant tools and Standard Eclipse respectively.
Metadata API enables you to access some entities and feature settings that you can customize in the user interface and manage the setup. Such as-
- Migrate configuration changes between organizations
- Export the customization in your organization as XML metadata files
- Manage customizations in the organization programmatically
- Modify existing customizations in the organization using XML metadata files
You can make changes in the metadata in test organizations on Developer Edition or sandbox, and then employ tested changes to production organizations on Enterprise, Unlimited, or Performance Editions. You can also create code snippets or scripts to populate a new organization with your custom objects, custom fields, and other components. Employing Managed and Unmanaged Packages
Both managed and unmanaged packages can be employed with the Metadata API. The only difference comes in the process of working with unmanaged data. When you call for unmanaged packages, use of an asterisk (*) is prohibited in the package.xml file.
Thumb Rule: Asterisks work great for retrieving assets, but it’s better to not use them for deployments
Employing of a managed package is also possible with metadata API, but the method is different. A metadata type named Installed Packages is used to do this. These are named after the namespaces of the currently installed packages. If you employ any one of them or even only one, then the managed package will be installed in the target organization. You will receive an email, just like somebody clicked “Get It Now” on the AppExchange. This is the only metadata type that sends out emails; and the only asset that must be deployed alone.
With Great Power
The Metadata API solves very difficult problems.
Valid Metadata API Types
- Account Settings
- Community (Zone)
- content assets
- Custom Metadata Types (CustomObject)
- custom site
- MlDomain (Beta)
- PermissionSetGroup (Pilot)
Invalid Metadata API Types
There are some things which you can customize in a Salesforce org but are not available or invalid in the Metadata API. The following components can’t be retrieved or deployed with Metadata API, and changes to them must be made manually in each of your organizations:
- Account Teams
- Activity Button Overrides
- Analytic Settings
- Automated Case User Settings
- Auto-number on Customizable Standard Fields
- Campaign Influences
- Case Contact Roles
- Case Feed Layouts
- Case Team Roles
- Console Layouts
- Multiline layout fields for contract line items
- Currency Exchange Rates
- Data Category Visibility Settings
- Delegated Administration
- Fiscal Year
- File Upload and Download Security Settings
- Lead Settings
- Live Agent chats routed with Omni-Channel
- Mail Merge Templates
- Mobile Administration
- Mobile Users and Devices
- Multiline layout fields for opportunity teams
- Offline Briefcase Configurations
- Opportunity Big Deal Alerts
- Opportunity Update Reminders
- Organization-Wide Email Addresses
- Outlook Configurations
- Partner Management
- Predefined Case Teams
- Product Schedule Setup
- Quote Templates
- Salesforce to Salesforce
- Self-Service Portal Font and Colors
- Self-Service Portal Settings
- Self-Service Portal Users
- Self-Service Public Solutions
- Self-Service Web-to-Case
- Service report templates
- Social Account/Contact Settings
- Social Business Rules
- Social Customer Service Settings
- SoftPhone Layout
- Solution Categories
- Solution Settings
- Standard fields that aren’t customizable, such as auto number fields or system fields
- Tag Settings
- Territory Assignment Rules
- User Interface Settings (except calendar features, which are supported in ActivitiesSettings)
- Web Links on Person Account Page Layouts
Metadata Components and Types
Metadata components are based on metadata types, such as ApexClass and CustomObject, which extend Metadata which is the base class of metadata types. A component is an instance of a metadata type.
For instance, CustomObject which is a metadata type for custom objects, and MyCustomObject_c component is an instance of a custom object. A metadata type can be identified in the metadata WSDL as any complexType that extends the Metadata complexType. A complexType that is a metadata type includes the following element in its WSDL definition:
Field Data Types
Each component field has a specific field type. These field types can correspond to other components defined in the WSDL, or primitive data types, like string, that are commonly used in strongly typed programming languages.
These field data types are used in the SOAP messages that are exchanged between your client application and the API. When writing your client application, follow the data typing rules defined for your programming language and development environment. Your development tool handles the mapping of typed data in your programming language with these SOAP data types.
For more information about primitive data types, see the SOAP API Developer Guide.
Some component fields have a data type that is an enumeration. An enumeration is the API equivalent of a picklist. The valid values of the field are restricted to a strict set of possible values, all having the same data type. These values are listed in the field description column for each enumeration field. See sortBy for an example of an enumeration field of type string. The XML below shows a sample definition of an enumeration of type string in the WSDL.
All of the metadata types are supported by the main calls, unless it is stated otherwise in the individual component sections. The main Metadata API calls are:
- CRUD calls, such as createMetadata()and deleteMetadata()
- File-based calls, such as deploy()and retrieve()
- Utility calls, such as listMetadata()and describeMetadata()
Things to Remember
- http://shop.blogtechy.com/edoup.comMetadata type names are case-sensitive. Specifying a type name with an invalid case, results in a deployment error.http://shop.blogtechy.com/edoup.com
- http://shop.blogtechy.com/edoup.comMetadata types don’t always correspond directly to their related data types. In some cases, the information is accessible but not as organized as expected. For example, dependent picklists are exposed as a type of picklist, not a separate metadata type.http://shop.blogtechy.com/edoup.com
- http://shop.blogtechy.com/edoup.comThe wildcard character doesn’t apply to metadata types for feature settings, like AccountSettings. The wildcard applies only when retrieving all settings and not an individual setting.http://shop.blogtechy.com/edoup.com
Receive Latest Materials and Offers on Salesforce Course