Learning Objectives :-
After completing this unit, you’ll be able to:
- Explain the CDC feature.
- Comfortably use the CDC control board.
This tutorial will exhibit how can we utilize Change Data Control (CDC) for handling data vicissitudes in Salesforce. We can customize the data changes of any sObject and sent out The client. It fortifies an asynchronous mode to accumulate transmuted data which we call the change pointer and sent out to the client. The main difference to the streaming API of Salesforce is that data can be bulk as astronomically immense data. Furthermore, customers can liberatingly schedule when the data will be sent e.g. every 5 minutes, 30 minutes, etc… With this feature, the customer doesn’t require to develop such an app to amass data change and sent out to the client. Just use SKYVVA CDC.
What is CDC Control Board?
CDC Control Board is a dashboard where we can monitor Change Pointer, Interfaces and Scheduler. Each tab holds different functionality. Change Pointer is a table that stores change pointer records. So we can facilely monitor them on Change Pointer table in CDC Control Board rather than on the Integration Admin tab. This withal applies for Interfaces and Schedulers tab.
How to use CDC Control Board
CDC Control Board monitor the CDC processing result. It located in Integration page detail and exist in the Custom links section. Follow the given steps to use the CDC control board.
Step1: Create an Adapter.
Step2: Create Integration.
Step3: Create Outbound Interface
Step4: Configure CDC.
Refer to this tutorial to configure CDC What is CDC and how to configure it?
Step5: Go to CDC Control Board by CDC Control board custom link.
Click on Link. It will navigate to the following screen.
Step6: Monitoring CDC Control Board
When you open the CDC Control board you will find three tabs available which are Change Pointer, Interfaces and Scheduler. Each tab has different functions and displays things relatable with CDC. The following steps will show you how to monitor each tab:
Change Pointer is a table that stores change pointer records. It is written every time a transaction modifies certain fields. The records are created by CDD. The records will store here until you set the scheduler (CDT) to transfer them to the external system. To monitor Change Pointer, just simply:
- Go to Change Pointer tab
- Filter the Integration Name, Interface Name and the status of the record you want to display
- Click on the “Search” button. The result will display according to the status you set
We can Apply filters :
|Interface Name||Outbound Interface on which CDC configured.|
|Status||Two type status. New and|
|Max Number of Record||Filter on the number of records.|
|Application Id||Application Id is the Sobject Id.|
|Date||Filter on created or modified date|
|Sort by & Order by||Sort by creation date. Filter on Ascending or descending.|
This tab displays the interfaces that store in an Integration. You can easily check or monitor them. If you land on CDC Control board, just simply click on interface tab then you will see all the interfaces. However, this tab is not editable like the Interface tab in the Integration detail page.
An interface group is a unit to the group where logical interfaces come together. For example, you can group interfaces that are cognate to each other e.g. Account and Contact to one interface group.
There is two kinds of interface group:
=>Business related logical group
We can apply this filter to probe data referring to a concrete interface group.
Queue inherit the priority from their interface group and thus a Queue will be a Prio-High, Prio-Medium or Prio-Low Queue.
This status is a temporary status set by the scheduler. Customarily most of the status is set by the worker because the worker is the one who does the job of processing the data package/queue passed from the scheduler.
This status is a helpful token that the scheduler has passed the data package/queue to the worker. When the worker starts to process the data package/queue it will transmute the status from “Worker” to “Running”.
This status is set by the worker. When a data package/queue is passed from the scheduler to the worker the status of this queue is “Worker”. Then the worker transmutes the status from “Worker” to “Running”.
The following change from status “Running” can be transpired.
If the queue is processed prosperously then the status will set to “Ready”. This is valid for both queue type e.g. for EO- and EOIO-Queue.
If an error occurred for whatever reason then the status is set to “Failed” for an EO-Queue and to “Hold” for an EOIO-Queue.
This status is set when processing a data package/queue got failed. This status is only utilized for the EO-Queue. For the EOIO-Queue the status can be used is “Hold” and not failed. If the processing of the EO-Queue is not ceased plenarily this status reflect an ephemeral status and can be set for example to “Ready” when next time the processing is prosperous.
Processing an EO-Queue is not blocked if error encountered for EOIO-Queue. Because the nature of EO-Queue is overtaken of data which can be transpired and that we already understood when defining interface group/queue with the type EO.
This status is set when processing a data package/queue got failed. This status is only utilized for the EOIO-Queue. For the EO-Queue the status can be used is “Failed” not hold. If the status is set to “Hold” then the processing of this queue is ceased because we can create an overtaken of data.
There is a reprocess mechanism of the affixment by the affixment reprocess scheduler. Refer to chapter “10 Variant of scheduler” for understanding the variant of the scheduler.
For some error, the reprocess can resolve the error and ergo will reset the status of the queue to “Ready”. Then the blocking of the queue will be relinquished. In some circumstances, because the error cannot be resolved automatically we will require the administrator to resolve the error situation and reset the queue status manually.
Stop by Admin
This status results from an admin action. An admin may want to stop the queue because of maintenance work. Another reason could be that we don’t opt that the queue X should be processed and ergo we intentionally stop this queue. This is for example because we opt to have more resources for processing other queues than queue X.
This alert tab is used for monitoring the CDC table. If the threshold from the alert tab is smaller than the CDC table value, a notify email will be sent to the assigned alert channels.
We have a different type of alerting rules on the integration & interface level
- Send Email SFDC User
- CreateTask for User
- Send Email External Mails
- Chatter group Name
There are some schedulers available in the Scheduler tab which are Change Data Detection (CDD) for Integration, Change Data Transfer (CDT) for Integration and Change Data Transfer SKYWWA DefaultIG Outbound for Interface Group. You can set the time and start the schedule or refresh it.
Note: If you manually create more Interface Group then they will display in the Scheduler tab.