What are Virtual Data Resources?
Virtual data resources provide a common API wrapper around multiple vendor endpoints that represent the same class of data: for example /Contacts. Virtual data resources provide a one-to-many coding experience for developers. You code against a common API, and we take care of the plumbing of routing and mapping your requests to a number of different REST, SOAP, SDK and DB driven endpoints.
Virtual data resources put your data models at the center of your application ecosystem and enable you to manage the data you care about in the structure that is best for your application or business.
Virtual data resources provide a canonicalized view of your data objects while eliminating the need for point-to-point mapping of data to each and every new application. Our Virtual data resources leverage enriched API models to make it easier to map from your defined resources, to the endpoints you require.
In the illustration below, /myCompany is a RESTful resource containing fields that are mapped to similar fields at each element. Instead of mapping point-to-point, you just map to the single Virtual data resource. In some cases, you don't have to map fields at all by using one of our prebuilt resources.
After mapping the virtual data resource to elements, we'll transform the element resources to a consistent request and response payload. You can also transform payload types and values. For example, one system may use High, Medium and Low while another uses 1, 2 or 3 to denote severity level.
Types of Virtual Data Resources
You'll encounter two types of Virtual data resources: templated resources and resources that you have either built yourself or customized based on a prebuilt resource. Prebuilt resources provide a template for common mappings to elements. You can clone the prebuilt resources to customize them for your needs, adding or removing , fields, and mappings. Templated resources include:
- /contacts mapped to HubSpot CRM, Hubspot Marketing, Netsuite CRM 2016 Release 1, Bullhorn, SugarCRM, Salesforce Sales Cloud, and Oracle Eloqua
- /leads mapped to Salesforce Sales Cloud, Marketo, HubSpot CRM, and SugarCRM
- /companies mapped to HubSpot CRM, Salesforce Sales Cloud, Oracle Eloqua, Microsoft Dynamics CRM, Hubspot Marketing, and SugarCRM
Understanding Levels
You define and map fields in virtual data resource within a hierarchy that includes four levels: system, organization, account, and instance. Only prebuilt resources have fields and mappings at the system level. When you clone a prebuilt resource, the fields become mapped at the account level. Only users at the organization level or account level can create or clone virtual data resources, while users at other levels can configure the virtual data resource for specific transformations.
- The system level is the highest level and reserved for prebuilt resources.
- The organization is the highest level available to users. A virtual data resource built at this level creates default mappings for all accounts within your organization.
- The account is the next highest level. Accounts typically represent your customers. Transformations at the account level are shared by all users associated with a specific account.
- The instance is the most granular level. Transformations that you or other users create at this level apply only to a specific element instance.
Definitions
To help you understand VDRs, review the definitions in this section.
- virtual data resource
A custom object, such as a contact, employee, or product that represents the source of truth for how your company views data about that object. Fields within the object are mapped to similar objects at API providers, enabling you to create integrations to the custom object.
- normalize
- Relates to transforming information from vendors to a common language within Cloud Elements. In relation to VDRs, normalization is the transformation of related fields and objects in multiple element resources to a single definition of the field or object within a VDR.
- field
- Data within a resource. Fields mapped between a VDR and an element instance result in a transformation of the element fields.
- map
- The process of associating objects within a vendor's resource to objects in a VDR so the vendor objects can be transformed.
- resource
- An object or entity that can be accessed via a URI request. Similar resources, such as Accounts, Contacts, and Customers appear in multiple APIs. VDRs at Cloud Elements normalize these varied resources.
- transformation
- The result of mapping an API provider resource to a VDR.
- element instance resource
- The resources available to the element instance through its API. You map the data from the element instance resources to the data in your VDR to create a transformation.
