A job runs to process batches which use API Dynamic Switch where incoming data goes automatically to be processed as synchronous, batch or bulk. All processed batches are managed on the batch control board.
What is the Batch Control Board?
Batch Control Board is a dashboard where we can monitor Inbound Processing, Interfaces, Queues, and Schedulers. Each tab holds a different function. The board offers us to facilely monitor the batch processing. This document will guide us How to use Batch Control board in details. Batch Control Board is utilized for mass data which is more than 5000.
Batch Control Board is located at the ‘Detail’ tab of Integration and exists in the ‘Custom Links’ section. We use the Batch Control Board to store data temporarily.
In order to search the Batch Control Board follow the given steps :
- Login to Salesforce and select Integration tab then click on Integration Detail page as per screenshot shown below:
Monitoring Batch Control Board #
When you open the Batch Control board we will find four tabs available which are Inbound Processing, Interfaces, Queues, and Scheduler. Each tabs have different functions and display things relatable with Batch processing. The following steps will show you how to monitor each tab:
Inbound Processing #
Inbound Processing is a tab which stores baskets that have inbound direction. There are three sections available in this tab. That section includes Filter, Working Baskets and History Basket. All the incoming basket will store in Working Basket until you set the schedule to run or manually process them. When the baskets are done processing they will move to History Basket section automatically.
Filter #
The filter is a screen where we can search the baskets. We can filter the baskets based on:
- Created Date
- Modified Date.
- The result will reflect as below:-
Status: #
| Status | Description |
| Init | Basket is created. |
| Worker | Basket is pass to the worker. |
| Processing | Basket currently processes by the worker. |
| Completed | The Basket has been successfully processed. |
| Failed | Basket processing gets failed. |
| Canceled | The Basket was canceled by the Administrator. |
Status Init
This is the first status when the attachment is created. When a message is sent utilizing batch mode an affixment gets engendered in the working basket and the status is set to “Init”. The Annexation Processing Scheduler will only cull ingresses to be processed which has this status. From this status, the affixment can become the status “Worker”.
Status Worker
The Affixment Process Scheduler will fetch annexation with status “Init” and pass these affixments to the soi-disant Annexation “Worker”. The Annexation Worker is an internal Skyvva component who will process the annexation e.g. deserialize and post the message resulting from the affixment. The Annexation Worker transmute the status from “Worker” to “Processing”.
Status Processing
The Annexation Worker set this status when it processes the affixment. When the Affixment Worker can process the annexation prosperously it will abstract this affixment from the working basket and move this annexation to history basket. If the Annexation Worker can not process the affixment it will set the status to “Failed” and the annexation is kept in the annexation basket and not moved into the history basket.
Status Failed
The Affixment Worker set this status when it gets an error while processing the annexation. The annexation remains in the working basket and will not move into the history basket. All affixments with this status will be pickup by the Annexation Reprocess Scheduler.
Status Cancelled
This status can be set manually by a utilizer. A utilizer can abrogate the affixment from the working basket before it gets processed.
Interface #
List of all interfaces which are processing on batch control board. This tab exhibit the interfaces that store in an Integration. You can facilely check or monitor them. If you land on Batch Control board, just simply click on the interface tab then you will visually perceive all the interfaces. However, this tab is not editable like Interface tab in Integration detail page.
Interface Group: #
Interface group is a unit to the group where logical interfaces come together. For example, you can group interfaces which 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
:- Technical group
We can apply this filter to probe data referring to concrete interface group.
Working Baskets #
Working Baskets section is a place where all the inbound processing baskets gets store here and wait to process. This section contains some buttons such are Select All, Deselect All, Delete, Delete All, Cancel, Delete All Cancelled, Reprocess and Refresh. Likewise, this section withal exhibits the different status of affixments which is very facile for us to monitor the processing of the annexations.
History Basket #
History Basket section is a location to store the processed baskets which are peregrinated from Working Baskets. If you opt to emaculate all the history baskets you can click on Delete or Delete All buttons. You can additionally use ‘Do maintenance’ (Scheduler) to perform the emaculate operation.
Queues #
This tab is utilized to check ‘How the queues work?’. You can filter queues base on Interface Group, Interface Name, and Status.
Filter by Interface Group, Interface Name, and Status.
Queue inherit the priority from their interface group and thus a Queue will be a Prio-High, Prio-Medium or Prio-Low Queue.
Queue Status:
Status Worker
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. Refer to chapter “11 Task disunion between Scheduler and Worker” to understand the task between scheduler and worker.
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”.
Status 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.
Status Failed
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 of 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.
Status Hold
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 a 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 circumstance, 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. Other 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 resource for processing other queues than queue X.
Scheduler #
There are two schedulers available in the Scheduler tab which are ‘Attachment Process’ and ‘Attachment Reprocess ‘(reprocess the fail annexation). These schedules are for categorical integration. You can set the time and commence the schedule or refresh it.
