Implementation

Estimated reading: 5 minutes 6 views

Object Tree

The main part of the architecture is the Object Tree custom metadata type. This object will store the hierarchy definition in a JSON format. Please check the Object Tree Setup section to find detailed instructions and information about the object.

Initially the hierarchy is defined in JSON format and manually with no Wizzard assistance. In a future, this could be changed, but as far as it is a very technical configuration it shouldn’t be a problem.

ObjectTree Class

The ObjectTree apex class is the most important part as it is in charge of:

  • Loading and parsing the Object Tree definition in an internal in memory structure.
  • Saves the parsed structure in the Organization cache at the Core cache partition for later uses.
  • Process the specified Object Tree for the desired record generating the resulting Map with all the hierarchy data and relationships.

Invoke the Tree Processor

You can process an Object Tree on a record in two different ways:
Specifying the Object Tree Name and the record Id
ObjectTree.loadObject(String objectTreeName, Id recordId)

Specifying the Object Tree Id and the record Id
ObjectTree.loadObject(Id objectTreeId, Id recordId)

Both methods are exactly the same, the difference is that the one that receives the Object Tree name will need to execute an additional SOQL query.

Options

The loadObject method has an optional parameter to specify the options for the process. The options are:

Option Type Description Use Case Example
filters Map<String, Object> A Map with the relationship name and filters to be applied to the query. We want to load the Order Context but only with one order item. So we could set a filter for the Order Item level with the Order Item Id.
stopOnRelationships Set Specify at which relationship the process should stop. The one specified would be processed. We want to Load the Order Context but only up to the Order Items level avoiding to load child order items, attributes, etc.

All these options are intended to both simplify the development and increase performance.

Object Tree Cache Manager

In order to load a hierarchy for the specified record and Object Tree the engine has to:

  • Retrieve the Object Tree record from the database.
  • Parse the JSON to convert it into apex internal classes.
  • Process the resulting definition to facilitate its later application to the specified record.

All these steps are the same for any record using that Object Tree, so there is no need to invest the resources and time on this everythime a record wants to be processed. As the Object Tree Cache Manager stores the result from all these steps in the cache, the next times it’s used, it’s inmediately retrieved from the Cache.

JSON Definition

In order to define your Object Tree structure you need to specify it in the JSON field. In this field you would need to set the object tree definition in JSON format followin the following specifications:

Nodes Hierarchy

The definition will be a hierarchy, with one and only root object. Each node of the hierarchy will have a children array which will hold the child nodes. This way, you can build the tree as you need.

It’s important to note that the JSON definition must:

  • Enclose both property and string between double-quotes “
  • There cannot be any extra comma ‘,’ in the property list.
    Otherwise it will throw an error.
{
    "name": "theRoot",
    // other fields,
    "children": [
        {
            "name": "FirstChild",
            // other fields
            "children": [
                {
                    "name": "GrandChild",
                    // other fields
                }
            ]

        },
         {
            "name": "SecondChild",
            // other fields
            "children": [
                {
                    "name": "GrandChild",
                    // other fields
                }
            ]

        }
    ]
}

The Node

Each object in the JSON tree will be considered a NODE. This is, the JSON definition will only have Nodes, related between them with the children relationship.

Node Definition

Property Type Example Required Description
name String “Account” Y An unique name for the node that will be used by the internal engine and that can be reference for Recursive Templates (see later)
type NodeType “STANDARD” N Three different values are allowed:
-ROOT: To specify the root node. You can omit this.
-STANDARD: For nodes using exiting objects relationships.
-CUSTOM: To speficy a custom relationship that doesn’t exist in the Objects definition.
fields String “Name,LastName,Account.Parent.Name” N Fields to retrieve from the object.
relationshipName String “wattyoordersr” Y* The API name for the relationship from the Parent to this Object. It can be a Lookup (1:1) or a Master-Detail relationship (1:N).
*Only required for STANDARD nodes.
options Options {} N And object with the different options available for the node.

Options Definition

Property Type Example Required Description
renameRelationship String “Products” N Name to override the relationship name in the outcoming map.
isJunction boolean true N If set to true, the node itself will not be rendered / included in the outcoming map. In other words, the children from the node will be attached to the parent skipping the current node.
convertToList boolean true N Force the relationship to be a list even if there is only one record.
recursiveTemplate String “Account” N The name of the node to inherit the children from.

Special Cases

Nested Junction Objects

In case you have several Junction nodes in a row, you will need to set the ‘renameRelationship’ value to the same one for all of them.

Leave a Comment

       
Euphoria, forever till the end of times

Euphoria

Share this Doc

Implementation

Or copy link

CONTENTS