Salesforce BigObjects

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.

2. 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.
2. 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>

Custom Field Metadata 

The following fields are supported in <fields>

Custom Index Metadata 

The following fields are supported in <indexes>

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

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″?>
2. <CustomObject xmlns=”http://soap.sforce.com/2006/04/metadata”>
3.   <deploymentStatus>Deployed</deploymentStatus>
4.   <fields>
5.     <fullName>CanBeMerged__c</fullName>
6.       <label>Can Be Merged</label>
7.       <length>80</length>
8.       <type>Text</type>
9.     </fields>
10.   <fields>
11.   <fullName>CodeReviewDate__c</fullName>
12.     <label>Code Review Date</label>
13.     <type>DateTime</type>
14.     <required>true</required>
15.   </fields>
16.   <fields>
17.     <fullName>Comments__c</fullName>
18.     <label>Comments</label>
19.     <length>255</length>
20.     <type>Text</type>
21.   </fields>
22.   <fields>
23.     <fullName>Employee__c</fullName>
24.     <label>Employee</label>
25.     <referenceTo>Employee__c</referenceTo>
26.     <relationshipName>Employees</relationshipName>
27.     <required>true</required>
28.     <type>Lookup</type>
29.   </fields>
30.   <fields>
31.     <fullName>Score__c</fullName>
32.     <label>Score</label>
33.     <precision>1</precision>
34.     <scale>0</scale>
35.     <type>Number</type>
36.   </fields>
37.   <fields>
38.     <fullName>Story__c</fullName>
39.     <label>Story__c</label>
40.     <referenceTo>Story__c</referenceTo>
41.     <relationshipName>Stories</relationshipName>
42.     <required>true</required>
43.     <type>Lookup</type>
44.   </fields>
45.   <indexes>
46.     <type>PRIMARY</type>
47.     <fullName>Test1CodeReviewPK</fullName>
48.     <fields>
49.       <name>Story__c</name>
50.       <sortDirection>DESC</sortDirection>
51.     </fields>
52.     <fields>
53.       <name>Employee__c</name>
54.       <sortDirection>DESC</sortDirection>
55.     </fields>
56.     <fields>
57.       <name>CodeReviewDate__c</name>
58.       <sortDirection>DESC</sortDirection>
59.     </fields>
60.   </indexes>
61.   <label>Test1 Code Review History</label>
62.   <pluralLabel>Test1 Code Reviews History</pluralLabel>
63. </CustomObject>

package.xml

1. <?xml version=”1.0″ encoding=”UTF-8″?>
2. <Package xmlns=”http://soap.sforce.com/2006/04/metadata”>
3.     <types>
4.         <members>*</members>
5.         <name>CustomObject</name>
6.     </types>
7.     <types>
8.         <members>*</members>
9.         <name>PermissionSet</name>
10.     </types>
11.     <version>39.0</version>
12. </Package>

Test1CodeReview_BigObject.PermissionSet 

1. <?xml version=”1.0″ encoding=”UTF-8″?>
2. <PermissionSet xmlns=”http://soap.sforce.com/2006/04/metadata”>
3.     <fieldPermissions>
4.         <editable>true</editable>
5.         <field>Test1CodeReview__b.CodeReviewDate__c</field>
6.         <readable>true</readable>
7.     </fieldPermissions>
8.     <fieldPermissions>
9.         <editable>true</editable>
10.         <field>Test1CodeReview__b.Employee__c</field>
11.         <readable>true</readable>
12.     </fieldPermissions>
13.     <fieldPermissions>
14.         <editable>true</editable>
15.         <field>Test1CodeReview__b.Story__c</field>
16.         <readable>true</readable>
17.     </fieldPermissions>
18.     <fieldPermissions>
19.         <editable>true</editable>
20.         <field>Test1CodeReview__b.CanBeMerged__c</field>
21.         <readable>true</readable>
22.     </fieldPermissions>
23.     <fieldPermissions>
24.         <editable>true</editable>
25.         <field>Test1CodeReview__b.Score__c</field>
26.         <readable>true</readable>
27.     </fieldPermissions>
28. </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();
2. cr.CanBeMerged__c = ’False’;
3. cr.CodeReviewDate__c = System.today();
4. cr.Comments__c = ’I found a SOQL inside of a loop.’;
5. cr.Employee__c = ’a6j24000000fxSL’;
6. cr.Score__c = 0;
7. cr.Story__c = ’a6k24000000k9bN’;
8. 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: