Batch queue processing

The Pega Smart Dispute Agentic Automation uses Job Scheduler to fetch or read the batch queue records from Visa's queue and save them in the Pega Smart Dispute database.

A new case type, Visa BatchQ, is created to fetch the batch queue records from Visa's queue and queue them to the queue processor once the records are saved to the database.

By default, the Visa case type reads multiple queue types in its batch queues for both Issuers and Acquirers at various stages of dispute processing. During dispute processing, the corresponding queue records and dispute responses are available in the AWAITING_ACTION_BQ_DISPUTE batch queue on both the Issuer and Acquirer sides.

Due to the presence of multiple queue types, Smart Dispute Agentic Automation creates individual job schedulers for each queue type for both Issuers and Acquirers.

Each job scheduler execution creates a Visa BatchQ case in the Smart Dispute application. The Visa BatchQ case belongs to the work class PegaFSPE-Work-BatchQ-Visa. Below is a snapshot of the Visa BatchQ case that the system creates for every job scheduler execution.

This case provides statistical information about the records present per page and is displayed under the Execution Details tab of the case.

Based on the total page count of the batch queue, execution details per page can be found here, which helps in tracking the batch queue records.

Consider the following scenario: The system expects a dispute response from the Acquirer for a Consumer Dispute – Cancelled Recurring transaction category.

The job scheduler uses the following process:

1. The system executes a VisaBatchQReadDisputeResponses job scheduler for dispute responses, which takes the AWAITING_ACTION_BQ_DISPUTE queue type parameter.
2. The job scheduler runs every four hours on a production system and uses a separate access group, SDIssuers:BatchQ, for its runtime context. The role of the job schedulers in batch queue processing for Visa is to fetch the Visa queue records, save them to the Smart Dispute Agentic Automation database, and input the queue records to the queue processors.
3. After the system triggers the job scheduler with the queue type parameter, it calls the activity VisaBatchQReadIssuerItems, which in turn creates a new Visa BatchQ case in the application.
4. Each job scheduler execution creates a Visa BatchQ case in the Smart Dispute application.

Steps in Visa BatchQ case

1. The system invokes the flow FetchBatchQRecords for queue processing.
2. The system first calls the GetBatchQueueOperation to retrieve the total number of pages in the AWAITING_ACTION_BQ_DISPUTE queue.
3. Once the total page count is received, the activity VisaBatchQReadItemsPerPage is invoked for further processing.
4. The data transform SetBatchQReadPageNumberSequence is invoked to set the batch queue read page number sequence. This data transform defines two parameters: Param.FirstPageNumber and Param.LastPageNumber. Param.FirstPageNumber is always set to 1, and Param.LastPageNumber is set to the total page count received from the batch queue.
   By default, batch queue items are read per page from page number 1 to the last page number present for the given queue.
5. The activity VisaBatchQReadItemsPerPage runs in a loop from Param.FirstPageNumber to Param.LastPageNumber, incrementing by 1, and invokes the GetBatchQueueOperation service per page. It then calls the SaveVisaQueueItems activity to save the queue records to the corresponding batch queue type database tables.
6. The activity SaveQueueItems validates the batch queue record according to the decision tables ValidateQueueItemForSDProcessing and ValidateQueueItemForMultipleQueueAvailability. Based on the outcomes of these decision tables, records are saved to the database table with the ExecutionStatus column value set to New.
   This activity also sets the batch queue counter values and prepares a TotalBatchQueueItemSID list string to store the batch queue item IDs being stored per page. The system reads all the batch queue record items present from the first page to the last page (the total batch queue page count) and saves them to the database tables.
7. Once all batch queue items are read and saved, the activity VisaBatchQMarkAsReadQueueRecords is invoked in a loop from the first page to the last page, marking the batch queue items present on each page as read. The TotalBatchQueueItemSID list holds all queue items in CSV string format for each page. For every page, the MarkBatchQueueItemAsRead service is invoked to mark the batch queue item as read. Based on the response from the MarkBatchQueueItemAsRead service, the MarkedAsRead column in the database table for that record is updated with the following values:

   Value	Description
   Yes	Mark as read service invocation passed
   No	Mark as read service not yet invoked
   Failed	Mark as read service invocation error

8. Once all pages have completed the process of invoking the mark as read service, and the service response for each batch queue item has been stored in the database table, the activity VisaBatchQ_QueueRecordsToQP is invoked. This activity is responsible for queuing the records to individual queue processors for further processing.
9. As part of the VisaBatchQ_QueueRecordsToQP activity, the system queues records to the queue processor only under the following conditions:
   1. The record has been successfully stored in the database table.
   2. The mark as read service invocation was successful for that batch queue table.

Only when both conditions are met, the system will queue the record to the queue processor for further processing.

Once all records from each page have been successfully queued to the queue processor, the system concludes the job scheduler's processing.