You are using an older browser that might negatively affect how this site is displayed. Please update to a modern browser to have a better experience. Sorry for the inconvenience!

Salesforce BigObjects


By: Venkata

BigObject: 

BigObject is a new type of object that allows us to store and manage large amounts of data on the Salesforce platform. The most important thing is that they do not count against the storage limit.

Types of BigObject: 

There are two types of BigObject: 

  1. Standard BigObjects: 

By Default, they are included in Salesforce like FieldHistoryArchive BigObject, which stores data as part of Field Audit Trail product.

  1. Custom BigObjects: 

These objects are created by users to store information unique to the organization. They just extend the functionality that Force.com provides.

Define and Deploy Custom BigObjects: 

We cannot create BigObjects in a declarative way but can define BigObject using Metadata API and then deploy them through command(cmd) or a Workbench. Define a custom BigObject by creating XML files that contain the definition, fields, and composite primary key (index) for the BigObject.

Consider the following before creating a BigObject: 

  1. Indexes are required and are available only from API 39.0 onwards.
  1. After a BigObject is deployed, any modification like add a field type, change label, etc. cannot be performed. However small changes like the label and API name can be done in a declarative way.

Naming Conventions for Custom BigObjects: 

The API names of custom BigObjects are identified by a suffix of two underscores immediately followed by a lowercase “b” (__b). For example, Code Review History is a BigObject, then its API name will be “Code_Review_History__b”.

Create Metadata Files for Deployment: 

While custom BigObjects use the “CustomObject” metadata type, some parameters are unique to BigObjects and others are not supported. The specific metadata parameters that are supported for BigObjects are outlined as follows:

Custom Object Metadata 

The following fields are supported in <CustomObject>

Field Name Field Type Description

 

deploymentStatus enumeration of type string Custom BigObject’s deployment status (Deployed for all BigObjects)
fields CustomField[] Definition of a field in the object
fullName string Unique API name of a field
indexes Index[] Definition of the index
label string Object’s name as displayed in the UI
pluralLabel string Field plural name as displayed in the UI

Custom Field Metadata 

The following fields are supported in <fields>

Field Name Field Type Description

 

fullName string Unique API name of a field.
label string Field name as displayed in the UI.
length int Length of a field in characters (text fields only)
pluralLabel string Field plural name as displayed in the UI.
precision int Number of digits for a number value. For example, the number 256.99 has a precision of 5 (number fields only).
referenceTo string Related object type for a lookup field (lookup fields only).
relationshipName string Name of a relationship as displayed in the UI (lookup fields only).
required boolean Specifies whether the field is required. All fields that are part of the index must be marked as required.
scale int Number of digits to the right of the decimal point for a number value. For example, the number 256.99 has a scale of 2 (number fields only).
type FieldType Field type. Supports DateTime, Lookup, Number, Text, and LongTextArea.

Custom Index Metadata 

The following fields are supported in <indexes>

Field Name Field Type Description

 

fields string Definition of a field in the index
fullName string Unique API name of a field
label string Field name as displayed in the UI
pluralLabel string Field plural name as displayed in the UI
type string Defines the type of key (supports only the PRIMARY value)

Custom Index Field Metadata 

The following fields are supported in <fields> under the <indexes>. Use the following tags to define the fields in the custom BigObject’s composite primary key (index). Each custom BigObject requires a defined index to determine the custom BigObject’s identity and queryability. The order in which the fields are defined are reflected in the index. It’s recommended that you design your key with the most frequently used filter parameter as the first element of the index

Field Name Field Type Description

 

name string API name for the field that’s part of the index. This value must match the value of the fullName value for the field in the fields section and be marked as required.
sortDirection string Sort direction of the field in the index. Allowed values are ASC for ascending order and DESC for descending order.

The following XML’s create metadata files that can be used to deploy BigObject as a package:

Test1CodeReview__b.object 

  1. <?xml version=”1.0″ encoding=”UTF-8″?>
  1. <CustomObject xmlns=”http://soap.sforce.com/2006/04/metadata”>
  1.   <deploymentStatus>Deployed</deploymentStatus>
  1.   <fields>
  1.     <fullName>CanBeMerged__c</fullName>
  1.       <label>Can Be Merged</label>
  1.       <length>80</length>
  1.       <type>Text</type>
  1.     </fields>
  1.   <fields>
  1.   <fullName>CodeReviewDate__c</fullName>
  1.     <label>Code Review Date</label>
  1.     <type>DateTime</type>
  1.     <required>true</required>
  1.   </fields>
  1.   <fields>
  1.     <fullName>Comments__c</fullName>
  1.     <label>Comments</label>
  1.     <length>255</length>
  1.     <type>Text</type>
  1.   </fields>
  1.   <fields>
  1.     <fullName>Employee__c</fullName>
  1.     <label>Employee</label>
  1.     <referenceTo>Employee__c</referenceTo>
  1.     <relationshipName>Employees</relationshipName>
  1.     <required>true</required>
  1.     <type>Lookup</type>
  1.   </fields>
  1.   <fields>
  1.     <fullName>Score__c</fullName>
  1.     <label>Score</label>
  1.     <precision>1</precision>
  1.     <scale>0</scale>
  1.     <type>Number</type>
  1.   </fields>
  1.   <fields>
  1.     <fullName>Story__c</fullName>
  1.     <label>Story__c</label>
  1.     <referenceTo>Story__c</referenceTo>
  1.     <relationshipName>Stories</relationshipName>
  1.     <required>true</required>
  1.     <type>Lookup</type>
  1.   </fields>
  1.   <indexes>
  1.     <type>PRIMARY</type>
  1.     <fullName>Test1CodeReviewPK</fullName>
  1.     <fields>
  1.       <name>Story__c</name>
  1.       <sortDirection>DESC</sortDirection>
  1.     </fields>
  1.     <fields>
  1.       <name>Employee__c</name>
  1.       <sortDirection>DESC</sortDirection>
  1.     </fields>
  1.     <fields>
  1.       <name>CodeReviewDate__c</name>
  1.       <sortDirection>DESC</sortDirection>
  1.     </fields>
  1.   </indexes>
  1.   <label>Test1 Code Review History</label>
  1.   <pluralLabel>Test1 Code Reviews History</pluralLabel>
  1. </CustomObject>

package.xml

  1. <?xml version=”1.0″ encoding=”UTF-8″?>
  1. <Package xmlns=”http://soap.sforce.com/2006/04/metadata”>
  1.     <types>
  1.         <members>*</members>
  1.         <name>CustomObject</name>
  1.     </types>
  1.     <types>
  1.         <members>*</members>
  1.         <name>PermissionSet</name>
  1.     </types>
  1.     <version>39.0</version>
  1. </Package>

Test1CodeReview_BigObject.PermissionSet 

  1. <?xml version=”1.0″ encoding=”UTF-8″?>
  1. <PermissionSet xmlns=”http://soap.sforce.com/2006/04/metadata”>
  1.     <fieldPermissions>
  1.         <editable>true</editable>
  1.         <field>Test1CodeReview__b.CodeReviewDate__c</field>
  1.         <readable>true</readable>
  1.     </fieldPermissions>
  1.     <fieldPermissions>
  1.         <editable>true</editable>
  1.         <field>Test1CodeReview__b.Employee__c</field>
  1.         <readable>true</readable>
  1.     </fieldPermissions>
  1.     <fieldPermissions>
  1.         <editable>true</editable>
  1.         <field>Test1CodeReview__b.Story__c</field>
  1.         <readable>true</readable>
  1.     </fieldPermissions>
  1.     <fieldPermissions>
  1.         <editable>true</editable>
  1.         <field>Test1CodeReview__b.CanBeMerged__c</field>
  1.         <readable>true</readable>
  1.     </fieldPermissions>
  1.     <fieldPermissions>
  1.         <editable>true</editable>
  1.         <field>Test1CodeReview__b.Score__c</field>
  1.         <readable>true</readable>
  1.     </fieldPermissions>
  1. </PermissionSet>

Deploy Custom BigObjects as a Metadata Package: 

By using the above Metadata API, we can deploy a custom BigObject. Use Workbench or the Ant Migration Tool to deploy.

Deploying using Workbench:

For this, we need to compress all those files as a zip file. Go to https://workbench.developerforce.com and login with the org credentials.

Select Migration [Symbol] Deploy [Symbol] Choose File and choose your zip file which contains the compressed components.

Select Check Only Checkbox and click next and click deploy.

View a Custom BigObject in Setup: 

We can access BigObjects in Setup [Symbol] BigObjects in the Quick Find box.

There will be no edit or del links in the action column, since BigObjects can’t be modified. Similarly, there is no new BigObject or Schema Builder buttons. To see the fields and relationships just click on the name of the BigObject.

Creating records for BigObject:

We can load data into custom BigObject by using a CSV file via Bulk API. Similarly, we can update existing records by providing the same composite primary key in the CSV file. We can also use apex to populate a BigObject record as follows:

  1. Test1CodeReview__b cr = new Test1CodeReview__b();
  1. cr.CanBeMerged__c = ’False’;
  1. cr.CodeReviewDate__c = System.today();
  1. cr.Comments__c = ’I found a SOQL inside of a loop.’;
  1. cr.Employee__c = ’a6j24000000fxSL’;
  1. cr.Score__c = 0;
  1. cr.Story__c = ’a6k24000000k9bN’;
  1. database.insertImmediate(cr);

Considerations for implementing BigObjects: 

  • BigObjects are only available to selected customers through a pilot program that requires agreement to specific terms and conditions.
  • Some features like triggers are not supported on BigObjects.
  • BigObjects support only object and field permissions.
  • We must use Metadata API to define BigObject from sandbox and then deploy it to production environment.
  • BigObjects don’t have state as “In Development”.
  • BigObjects supports Custom Lightning and Visualforce components rather than standard UI elements like home pages, detail pages, list views, etc.
  • SOQL relationship queries from a BigObject to a standard or custom object are based on lookup fields.
  • We can create up to 100 BigObjects per Salesforce org. The limitations for BigObject fields are similar to that of custom objects in Salesforce and depend on your org’s license type.
  • BigObjects appears in the Setup UI only when they are deployed.
  • BigObjects not supported in Salesforce1.

References: 

https://resources.docs.salesforce.com/sfdc/pdf/big_objects_guide.pdf

https://agarciaodeian.com/2017/07/17/salesforce-big-objects/