Composite Graph API

 The Composite Graph API is a huge leap forward when you need to perform CRUD operations on a large number of related sObjects.

Not only does it increase the subrequest limit from 25 to 500, it also provides a number of optimizations that ensure records are processed efficiently and operations are rolled back if any steps are not completed.

Organize subrequests inside within a graph :

The body of a Composite Graph API request consists of a number of graphs, each of which may contain multiple composite subrequests. You can think of each graph as its own grouping of related sObject records.

Syntax : 

{

    "graphs": [

        {

            "graphId": "graphId1",

            "compositeRequest": [

                compositeSubrequest1, 

                compositeSubrequest2, 

                ...]

        },

        {

            "graphId": "graphId2",

            "compositeRequest": [

                compositeSubrequest3, 

                compositeSubrequest4, 

                ...]

        }

    ]

}

Grouping collections of sObjects into graphs enables you to get much more done with a single API call. One big advantage of this is no longer having to manage the orchestration of the deeper, more intricate relationships that are inherent to more complex graphs.

As with the Composite API, each subrequest contains a referenceId that can be used to relate records that follow the subrequest.In the example below, the Account record is upserted and the referenceId is set to Account. In the subrequest that follows, an order record is inserted and the Account__c field value is set to @{Account.Id} , which references the account that was just inserted.

{

  "graphId": "graph1",

  "compositeRequest": [

    {

      "method": "PATCH",

      "url": "/services/data/v49.0/sobjects/Account/ExternalAcctId__c/ID12345",

      // Reference Id used to relate records to the account

      "referenceId": "Account",

      "body": {

        "Name": "Trailblazers",

        "Website": "TrailblazerOutfiters.com"

      }

    },

    {

      "method": "POST",

      "url": "/services/data/v49.0/sobjects/Order__c",

      "referenceId": "newOrder",

      "body": {

        // Reference Id used to relate records to the order

        "Account__c": "@{Account.id}"

      }

    },

    {

      "method": "POST",

      "url": "/services/data/v49.0/sobjects/OrderItem__c",

      "referenceId": "newProduct",

      "body": {

        "Order__c": "@{newOrder.id}",

        "Product__c": {

          "External_Id__c": "EB1213"

        },

        "Qty_L__c": "1",

        "Price__c": "500"

      }

    }

  ]

}

set own created date for the inserted salesforce test records in test class

 How to set created date for a test method in test class in salesforce?

System.Test allows you to set the created date/time of a record.

This is super helpful when inserting test data and you want some of it to appear to the older.

// Sets CreatedDate for a test-context sObject.

 syntax : setCreatedDate(recordId,createdDatetime)

 

 ex :

   @isTest   

 private class SetCreatedDateTest {  

   static testMethod void testSetCreatedDate() {  

     Account a = new Account(name='Test Account');  

     insert a;  

     Test.setCreatedDate(a.Id, DateTime.newInstance(2012,12,12));  

     Test.startTest();  

     Account myAccount = [SELECT Id, Name, CreatedDate FROM Account   

                WHERE Name ='Test Account' limit 1];  

     System.assertEquals(myAccount.CreatedDate, DateTime.newInstance(2012,12,12));  

     Test.stopTest();  

   }  

 }  

 

Key points:

1.All database changes are rolled back at the end of a test. You can’t use this method on records that existed before your test executed.

2.You also can’t use setCreatedDate in methods annotated with @isTest(SeeAllData=true), because those methods have access to all data in your org.

3.This method takes two parameters—an sObject ID and a Datetime value—neither of which can be null.