Difference between revisions of "Processing Visa Queue using Pega Agents"

From PegaWiki
Jump to navigation Jump to search
(Created a new pattern on Processing Visa Queues using Pega Agents.)
Tag: Visual edit
 
(updated version as of)
Tag: Visual edit
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{New request
+
{{Design pattern|Title=Processing Visa Queue using Pega Agents|Description=Defining the process of handling Visa Batch Queue records using Pega Agents|Version=7.4|Applications=Pega Disputes and Payments Exceptions|Capability Area=Financial Services|Owner=Bharr1}}
|Request to Publish=
 
|Curator Assigned=
 
|Description=Defining the process of handling Visa Batch Queue records using Pega Agents
 
|Applications=Smart Dispute for Issuers & Acquirers
 
|Capability Area=Financial Services
 
|Version=7.48
 
}}
 
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓  '''<big>Please Read Below</big>'''  ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 
  
Enter your content below. Use the basic wiki template that is provided to organize your content.  After making your edits, add a summary comment that briefly describes your work, and then click "SAVE".  To edit your content later, select the page from your "Watchlist" summary.  If you can not find your article, search the design pattern title.
+
==Visa Batch Queue overview==
 +
This topic defines the design used in implementing reading and processing the actions performed on the disputes by the two opposite parties, the issuer, and acquirer, through the VISA association on regular intervals by using Pega agent rules.  
  
When your content is ready for publishing, next to the '''"Request to Publish"''' field above, type '''"Yes"'''. A Curator then reviews and publishes the content, which might take up to 48 hours.  
+
Visa Batch Queues are lists of cases or transactions that a user's organization owns. They are either the cases that require user action or those showing user actions to manage a user's workflow.
  
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ '''<big>The above text will be removed prior to being published</big>''' ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
+
The following are the different types of Batch Queue formats provided by Visa:
 
 
== Visa Batch Queue overview ==
 
This topic defines the design used in implementing the process of reading and processing the actions performed on the disputes by the two opposite parties i.e., the Issuer and Acquirer through the association VISA on regular intervals by using Pega agent rules.
 
  
Visa Batch Queues are lists of cases or transactions that are owned by a user’s organization, either cases requiring action from the user or showing actions by the user and are used to manage a user's workflow.
+
*Queue format T for RFC, collaboration requests and responses, miscellaneous fees, and more
 +
*Queue format R for all rejects
 +
*Queue format S for legacy pre-compliances, pre-arbitrations, and case filings
 +
*Queue format D for all acceptances, awaiting action disputes, and VCR pre-filings
  
The following are the different types of Batch Queue formats provided by Visa:
 
* Queue format T for RFC, collaboration requests and responses, misc. fees, etc.
 
* Queue format R for all rejects
 
* Queue format S for legacy pre-compliances, pre-arbitrations, and case filings
 
* Queue format D for all acceptances, awaiting action disputes, and VCR pre-filings
 
 
(Application rules: CheckIfQueueCanBeProcessedInSD (Issuer) and CheckIfQueueCanBeProcessedInSDForAcquirer (Acquirer) rules can be referred to check the corresponding D Queue, S Queue, T Queue and R Queue items based on the Batch queue type and cases status)
 
(Application rules: CheckIfQueueCanBeProcessedInSD (Issuer) and CheckIfQueueCanBeProcessedInSDForAcquirer (Acquirer) rules can be referred to check the corresponding D Queue, S Queue, T Queue and R Queue items based on the Batch queue type and cases status)
  
== Before you begin ==
+
==Before you begin==
 
'''Issuer:''' The bank or financial institution that issues the credit or debit card to the account or cardholder
 
'''Issuer:''' The bank or financial institution that issues the credit or debit card to the account or cardholder
  
'''Merchant:''' A seller of goods and/or services who accepts credit or debit cards in payment
+
'''Merchant:''' A seller of goods or services who accepts credit or debit card payments
  
'''Acquirer:''' The financial institution that is the merchant’s representative in the transaction and receives a financial transaction's electronic data from a Merchant and places that data into an interchange system
+
'''Acquirer:''' The merchant's representative financial institution in the transaction that receives the financial transaction's electronic data from the merchant and places that data into an interchange system
  
 
'''Dispute:''' A situation in which a customer questions the validity of one or more transactions on a credit or debit card account
 
'''Dispute:''' A situation in which a customer questions the validity of one or more transactions on a credit or debit card account
  
== Processing Visa Queues using Pega Agents ==
+
==Processing Visa Queues using Pega Agents==
Pega Smart Dispute provides several advanced agents rules to fetch, save and process the Batch Queue records retrieved from VROL.  
+
Pega Smart Dispute provides several advanced agents rules to fetch, save, and process the Batch Queue records retrieved from VROL.  
 +
'''Note:''' To prevent accidental processing of batch queue records, the application disables all the agent records by default. You should enable them during implementation.
 +
All the agent rules are configured to run the ''VCR_IssuerBQProcessing'' activity for the issuer and ''VCR_AcquirerBQProcessing'' activity for the acquirer with the following parameters:
  
'''Note:''' To prevent inadvertent processing of batch queue records, all the agents are disabled by default and must be enabled during implementation.
+
*''BatchQueueName'' depends on the queue from which Pega Smart Dispute for issuers or acquirers attempts to retrieve the records.
 +
*''ProcessBatchQueue'' determines whether Pega Smart Dispute for issuers or acquirers fetches new records from the Visa Batch Queue or processes the records which have already been inserted into the Batch Queue staging tables when the value is true.
  
All the agent rules are configured to run the ''VCR_IssuerBQProcessing'' activity for Issuer and ''VCR_AcquirerBQProcessing'' activity for Acquirer that takes the following parameters:
 
* ''BatchQueueName'' depends on the queue from which Pega Smart Dispute for Issuers/Acquirers attempts to retrieve the records
 
* ''ProcessBatchQueue'' which determines whether Pega Smart Dispute for Issuers/ Acquirers fetches new records from the Visa Batch Queue or processes the records which have already been inserted into the Batch Queue staging tables when value is ‘true’.
 
 
The ''VCR_BatchQueueProcessing'' activity rule in the PegaCard-Sd-Dispute-Visa- class is the core activity responsible for performing the following actions:
 
The ''VCR_BatchQueueProcessing'' activity rule in the PegaCard-Sd-Dispute-Visa- class is the core activity responsible for performing the following actions:
  
=== '''<big>Fetching and saving queue records</big>''' ===
+
===Fetching and saving queue records===
The below mentioned API’s are provided by Visa to read and mark the queue record as read:
+
VISA provides the following APIs to read and mark the queue record as read:
* ''GetBatchQueueOperation -'' Used to retrieve transactions from an RTSI Batch Queue based on the member role, BatchQueueType and page number sent in the request. Each page contains 400 records, or the number configured by the member in the VROL System.
+
 
* ''MarkBatchQueueItemAsReadOperation -'' Used to mark a transaction as read and remove it from the RTSI Batch Queue using BatchQueueItemSID value to prevent the records from appearing in the queue during next batch queue operation.  
+
*''GetBatchQueueOperation:'' retrieves transactions from an RTSI Batch Queue based on the member role and BatchQueueType and page number sent in the request. Each page contains 400 records or the number configured by the member in the VROL System.
After fetching the records, they are saved to the Smart Dispute batch queue staging tables listed below before marking them as read and processing.  
+
*''MarkBatchQueueItemAsReadOperation:'' Marks a transaction as read and removes it from the RTSI Batch Queue using BatchQueueItemSID value to prevent the records from appearing in the queue during the next batch queue operation.
 +
 
 +
After fetching the records, they are saved to the Smart Dispute batch queue staging tables listed below before marking them as read and processing.
  
If multiple pages exist, only 1 page is processed at once, the retrieved records will be marked as read and removed from the queue. ''GetBatchQueueOperation'' is invoked again to fetch the new set of records.
+
If multiple pages exist, only one page is processed at once, and the retrieved records are marked as read and removed from the queue. ''GetBatchQueueOperation'' is invoked again to fetch the new set of records.
  
 
Each staging table stores records related to a particular queue format:
 
Each staging table stores records related to a particular queue format:
* SD_VCR_DQUEUE table mapped to the PegaCard-Int-Visa-FormatDQueueItemType integration layer class stores records that belong to the D queue format.
+
 
* SD_VCR_TQUEUE table mapped to the PegaCard-Int-Visa- FormatTQueueItemType integration layer class stores records that belong to the T queue format.
+
*SD_VCR_DQUEUE table mapped to the PegaCard-Int-Visa-FormatDQueueItemType integration layer class stores records that belong to the D queue format.
* SD_VCR_RQUEUE table mapped to the ''PegaCard-Int-Visa-FormatRQueueItemType'' integration layer class stores records that belong to the R queue format.
+
*SD_VCR_TQUEUE table mapped to the PegaCard-Int-Visa- FormatTQueueItemType integration layer class stores records that belong to the T queue format.
* SD_VCR_SQUEUE table mapped to the ''PegaCard-Int- Visa-FormatSQueueItemType'' integration layer class stores records that belong to the S queue format.
+
*SD_VCR_RQUEUE table mapped to the ''PegaCard-Int-Visa-FormatRQueueItemType'' integration layer class stores records that belong to the R queue format.
''BatchQueueItemSID'' is the primary key for all the above tables. This attribute uniquely identifies a queue record. Only selected attributes from the queue record are stored in the staging tables.
+
*SD_VCR_SQUEUE table mapped to the ''PegaCard-Int- Visa-FormatSQueueItemType'' integration layer class stores records that belong to the S queue format.
 +
 
 +
''BatchQueueItemSID'' is the primary key for all the above tables, which uniquely identifies a queue record. The application stores only selected attributes from the queue record in the staging tables.
  
 
SD_VCR_OTHER table mapped to ''PegaCard-Int-Visa-OtherQueueType'' integration layer class is an additional staging table that stores:
 
SD_VCR_OTHER table mapped to ''PegaCard-Int-Visa-OtherQueueType'' integration layer class is an additional staging table that stores:
* Records that cannot be processed because either the Visa Case Status is not applicable to Pega Smart Dispute for Issuers / Acquirers or a corresponding entry in another staging table has been processed, and the dispute case already resumed. This duplicate message can be skipped.
+
 
* Records from the other batch queue staging tables that have exceeded the maximum number of retries for processing.
+
*Records that cannot be processed because either the Visa Case Status is not applicable to Pega Smart Dispute for issuers or acquirers, a corresponding entry in another staging table has been processed, or the dispute case already resumed. This duplicate message can be skipped
If the retry count exceeds the specified threshold, the ''VCR_UnProcessedQueueItemFilterForIssuer'' activity moves the batch queue records from the respective staging tables to SD_VCR_OTHER table. The following four agents were configured to filter the staging tables:
+
*Records from the other batch queue staging tables that have exceeded the maximum number of retries for processing.
* Cleanup of Unprocessed cases D Queue
+
 
* Cleanup of Unprocessed cases S Queue  
+
If the retry count exceeds the specified threshold, the ''VCR_UnProcessedQueueItemFilterForIssuer'' activity moves the batch queue records from the respective staging tables to SD_VCR_OTHER table. The following four agent configurations filter the staging tables:
* Cleanup of Unprocessed cases T Queue
+
 
* Cleanup of Unprocessed cases R Queue
+
*Cleanup of Unprocessed cases D Queue
* Cleanup of OtherTable
+
*Cleanup of Unprocessed cases S Queue
 +
*Cleanup of Unprocessed cases T Queue
 +
*Cleanup of Unprocessed cases R Queue
 +
*Cleanup of OtherTable
 +
 
 
The V''CR_CleanUpOtherTable'' activity removes items from the SD_VCR_OTHER staging table based on an interval defined in the ''BQRecordCleanUpInterval'' dynamic system setting.
 
The V''CR_CleanUpOtherTable'' activity removes items from the SD_VCR_OTHER staging table based on an interval defined in the ''BQRecordCleanUpInterval'' dynamic system setting.
  
=== Processing queue records ===
+
===Processing queue records===
Separate Smart Dispute for Issuers and Acquirer agents are responsible for handling records on the Batch Queues and processing them within the application. When the ProcessQueueRecord parameter is set to “true”, records that are already present in the staging table will be processed; otherwise, new records will be fetched from the Visa Batch Queue and stored in the Smart Dispute staging tables.
+
Separate Smart Dispute for issuers and acquirer agents are responsible for handling records on the Batch Queues and processing them within the application. When the ProcessQueueRecord parameter is set to true, the records that are already present in the staging table are processed. Otherwise, new records are fetched from the Visa Batch Queue and stored in the Smart Dispute staging tables.
  
 
In VCR_BatchQueueProcessing activity, the available list of queue records are browsed in the local database for processing.
 
In VCR_BatchQueueProcessing activity, the available list of queue records are browsed in the local database for processing.
* For Acquirers only, for incoming disputes if case does not exist in the system with the VisaCaseNumber, then a case is created. Otherwise, if a dispute exists, processing is done to the existing case.
 
* In all other cases, the dispute will wait for a response from the opposite party. In such cases, the activity will identify the case which is waiting for the response by using the VisaCaseNumber. After the case is found, the activity will look up the Flow and Flow Action name in the FlowNameLookupForVCRDQueue, FlowNameLookupForVCRSQueue, and FlowNameLookupForVCRRandTQueues decision tables, and then resume the flow.
 
After successful processing, the record is deleted from the database table.
 
  
'''Note:'''  There should be only one dispute with a unique VisaCaseNumber in the application.  
+
* For acquirers only: for incoming disputes for which the case does not exist in the application with the VisaCaseNumber, the appliation creates a case. Otherwise, the existing case goes into processing.
 +
* In all other cases: the dispute waits for a response from the opposite party. In such cases, the activity identifies the case that is waiting for the response by using the VisaCaseNumber. After finding the case, the activity looks up the Flow and Flow Action name in FlowNameLookupForVCRDQueue, FlowNameLookupForVCRSQueue, and the FlowNameLookupForVCRRandTQueues decision tables, and then resume the flow.
  
The queue record will not contain the complete information. For complete information pertaining to the record, either a Hyper search request or any other related service needs to be invoked in the flow that is being resumed.
+
After successful processing, the record gets deleted from the database table.
 +
'''Note:''' There should be only one dispute with a unique VisaCaseNumber in the application.
 +
The queue record doesn't contain the complete information. For complete information about the record, either a Hyper search request or any other related service needs to be invoked in the flow that is being resumed.
  
== '''Configurable rules:''' ==
+
==Configurable rules==
 
The following rules can be overridden during implementation:
 
The following rules can be overridden during implementation:
  
====== The ''VCR_IssuerBQProcessing'' activity rule in the ''PegaCard-Sd-Dispute-Visa-'' class with the following parameters: ======
+
======Activity rule======
* ''WorkPageClass'' Your default work class for Visa international dispute, the class of the work object will later be replaced by class of the work object being resumed.
+
The ''VCR_IssuerBQProcessing'' activity rule in the ''PegaCard-Sd-Dispute-Visa-'' class with the following parameters:
* ''ReportName'' – The name of the Report Definition rule which is used to identify the work object to be resumed.
+
 
 +
* ''WorkPageClass:'' Your default work class for Visa international dispute. The class of the work object is later replaced by the class of the resuming work object.
 +
* ''ReportName'' – The name of the Report Definition rule that is used to identify the work object to be resumed.
 
* ''DTName'' – The data transform rule for initiating the work page.
 
* ''DTName'' – The data transform rule for initiating the work page.
* ''FlowName'' – In case of issuer, if a pre-compliance request is received in the absence of an existing work object, this flow should create a work object and start the pre-compliance flow.
+
* ''FlowName'' – In the issuer case, if a pre-compliance request is received in the absence of an existing work object, this flow creates a work object and starts the pre-compliance flow.
* ''VCR_MaxRecordsForBQProcessing'' – The maximum batch queue records which will be processed when a queue agent runs.
+
* ''VCR_MaxRecordsForBQProcessing'' – The maximum batch queue records that are processed when a queue agent runs.
 +
 
 +
====== Decision tables ======
 +
The following decision tables in ''PegaCard-Sd-Dispute-Visa-'' class:
  
====== The following decision tables in ''PegaCard-Sd-Dispute-Visa-'' class: ======
 
 
* FlowNameLookupForVCRDQueue
 
* FlowNameLookupForVCRDQueue
 
* FlowNameLookupForVCRSQueue
 
* FlowNameLookupForVCRSQueue
 
* FlowNameLookupForVCRRandTQueues
 
* FlowNameLookupForVCRRandTQueues
These rules will set the Flow Name and the Flow Action name to be resumed. These values must be configured based on the queue name being processed and the case status of the queue record, which can be used to identify the record type (Pre-Arb, Pre- Arb response, Pre-Comp, Pre-Comp response, etc.)
+
 
* The ''MapBatchQueueType'' map value rule in the ''PegaCard-Sd-Dispute-Visa-'' class returns the integration class based on the Queue Name. The name of
+
====== Other Rules ======
the integration class is required to retrieve the records saved in a database table. These classes should be replaced by the implementation layer integration classes.
+
These rules will set the Flow Name and the Flow Action name to be resumed. These values must be configured based on the queue name being processed and the queue record's case status to identify the record type (Pre-Arb, Pre- Arb response, Pre-Comp, Pre-Comp response, etc.)
* Customers can extend ''AdditionalExceptionProcessing'' activity rule in the ''PegaCard- Sd-Visa-'' class to handle exceptions caught during the processing of queue records.
+
 
 +
* The ''MapBatchQueueType'' map value rule in the ''PegaCard-Sd-Dispute-Visa-'' class returns the integration class based on the Queue Name. The name of the integration class is required to retrieve the records saved in a database table. The implementation layer integration classes should replace these classes.
 +
* Customers can extend ''the AdditionalExceptionProcessing'' activity rule in the ''PegaCard- Sd-Visa-'' class to handle exceptions caught during queue records processing.
  
 
== Results ==
 
== Results ==
The Issuer or Acquirer will be able to process the Visa batch queues using agents .
+
The Issuer or Acquirer will be able to process the Visa batch queues using agents.

Latest revision as of 19:25, 29 June 2021

Processing Visa Queue using Pega Agents

Description Defining the process of handling Visa Batch Queue records using Pega Agents
Version as of 7.4
Application Pega Disputes and Payments Exceptions
Capability/Industry Area Financial Services



Visa Batch Queue overview[edit]

This topic defines the design used in implementing reading and processing the actions performed on the disputes by the two opposite parties, the issuer, and acquirer, through the VISA association on regular intervals by using Pega agent rules.

Visa Batch Queues are lists of cases or transactions that a user's organization owns. They are either the cases that require user action or those showing user actions to manage a user's workflow.

The following are the different types of Batch Queue formats provided by Visa:

  • Queue format T for RFC, collaboration requests and responses, miscellaneous fees, and more
  • Queue format R for all rejects
  • Queue format S for legacy pre-compliances, pre-arbitrations, and case filings
  • Queue format D for all acceptances, awaiting action disputes, and VCR pre-filings

(Application rules: CheckIfQueueCanBeProcessedInSD (Issuer) and CheckIfQueueCanBeProcessedInSDForAcquirer (Acquirer) rules can be referred to check the corresponding D Queue, S Queue, T Queue and R Queue items based on the Batch queue type and cases status)

Before you begin[edit]

Issuer: The bank or financial institution that issues the credit or debit card to the account or cardholder

Merchant: A seller of goods or services who accepts credit or debit card payments

Acquirer: The merchant's representative financial institution in the transaction that receives the financial transaction's electronic data from the merchant and places that data into an interchange system

Dispute: A situation in which a customer questions the validity of one or more transactions on a credit or debit card account

Processing Visa Queues using Pega Agents[edit]

Pega Smart Dispute provides several advanced agents rules to fetch, save, and process the Batch Queue records retrieved from VROL.

Note: To prevent accidental processing of batch queue records, the application disables all the agent records by default. You should enable them during implementation.

All the agent rules are configured to run the VCR_IssuerBQProcessing activity for the issuer and VCR_AcquirerBQProcessing activity for the acquirer with the following parameters:

  • BatchQueueName depends on the queue from which Pega Smart Dispute for issuers or acquirers attempts to retrieve the records.
  • ProcessBatchQueue determines whether Pega Smart Dispute for issuers or acquirers fetches new records from the Visa Batch Queue or processes the records which have already been inserted into the Batch Queue staging tables when the value is true.

The VCR_BatchQueueProcessing activity rule in the PegaCard-Sd-Dispute-Visa- class is the core activity responsible for performing the following actions:

Fetching and saving queue records[edit]

VISA provides the following APIs to read and mark the queue record as read:

  • GetBatchQueueOperation: retrieves transactions from an RTSI Batch Queue based on the member role and BatchQueueType and page number sent in the request. Each page contains 400 records or the number configured by the member in the VROL System.
  • MarkBatchQueueItemAsReadOperation: Marks a transaction as read and removes it from the RTSI Batch Queue using BatchQueueItemSID value to prevent the records from appearing in the queue during the next batch queue operation.

After fetching the records, they are saved to the Smart Dispute batch queue staging tables listed below before marking them as read and processing.

If multiple pages exist, only one page is processed at once, and the retrieved records are marked as read and removed from the queue. GetBatchQueueOperation is invoked again to fetch the new set of records.

Each staging table stores records related to a particular queue format:

  • SD_VCR_DQUEUE table mapped to the PegaCard-Int-Visa-FormatDQueueItemType integration layer class stores records that belong to the D queue format.
  • SD_VCR_TQUEUE table mapped to the PegaCard-Int-Visa- FormatTQueueItemType integration layer class stores records that belong to the T queue format.
  • SD_VCR_RQUEUE table mapped to the PegaCard-Int-Visa-FormatRQueueItemType integration layer class stores records that belong to the R queue format.
  • SD_VCR_SQUEUE table mapped to the PegaCard-Int- Visa-FormatSQueueItemType integration layer class stores records that belong to the S queue format.

BatchQueueItemSID is the primary key for all the above tables, which uniquely identifies a queue record. The application stores only selected attributes from the queue record in the staging tables.

SD_VCR_OTHER table mapped to PegaCard-Int-Visa-OtherQueueType integration layer class is an additional staging table that stores:

  • Records that cannot be processed because either the Visa Case Status is not applicable to Pega Smart Dispute for issuers or acquirers, a corresponding entry in another staging table has been processed, or the dispute case already resumed. This duplicate message can be skipped
  • Records from the other batch queue staging tables that have exceeded the maximum number of retries for processing.

If the retry count exceeds the specified threshold, the VCR_UnProcessedQueueItemFilterForIssuer activity moves the batch queue records from the respective staging tables to SD_VCR_OTHER table. The following four agent configurations filter the staging tables:

  • Cleanup of Unprocessed cases D Queue
  • Cleanup of Unprocessed cases S Queue
  • Cleanup of Unprocessed cases T Queue
  • Cleanup of Unprocessed cases R Queue
  • Cleanup of OtherTable

The VCR_CleanUpOtherTable activity removes items from the SD_VCR_OTHER staging table based on an interval defined in the BQRecordCleanUpInterval dynamic system setting.

Processing queue records[edit]

Separate Smart Dispute for issuers and acquirer agents are responsible for handling records on the Batch Queues and processing them within the application. When the ProcessQueueRecord parameter is set to true, the records that are already present in the staging table are processed. Otherwise, new records are fetched from the Visa Batch Queue and stored in the Smart Dispute staging tables.

In VCR_BatchQueueProcessing activity, the available list of queue records are browsed in the local database for processing.

  • For acquirers only: for incoming disputes for which the case does not exist in the application with the VisaCaseNumber, the appliation creates a case. Otherwise, the existing case goes into processing.
  • In all other cases: the dispute waits for a response from the opposite party. In such cases, the activity identifies the case that is waiting for the response by using the VisaCaseNumber. After finding the case, the activity looks up the Flow and Flow Action name in FlowNameLookupForVCRDQueue, FlowNameLookupForVCRSQueue, and the FlowNameLookupForVCRRandTQueues decision tables, and then resume the flow.

After successful processing, the record gets deleted from the database table.

Note: There should be only one dispute with a unique VisaCaseNumber in the application.

The queue record doesn't contain the complete information. For complete information about the record, either a Hyper search request or any other related service needs to be invoked in the flow that is being resumed.

Configurable rules[edit]

The following rules can be overridden during implementation:

Activity rule[edit]

The VCR_IssuerBQProcessing activity rule in the PegaCard-Sd-Dispute-Visa- class with the following parameters:

  • WorkPageClass: Your default work class for Visa international dispute. The class of the work object is later replaced by the class of the resuming work object.
  • ReportName – The name of the Report Definition rule that is used to identify the work object to be resumed.
  • DTName – The data transform rule for initiating the work page.
  • FlowName – In the issuer case, if a pre-compliance request is received in the absence of an existing work object, this flow creates a work object and starts the pre-compliance flow.
  • VCR_MaxRecordsForBQProcessing – The maximum batch queue records that are processed when a queue agent runs.
Decision tables[edit]

The following decision tables in PegaCard-Sd-Dispute-Visa- class:

  • FlowNameLookupForVCRDQueue
  • FlowNameLookupForVCRSQueue
  • FlowNameLookupForVCRRandTQueues
Other Rules[edit]

These rules will set the Flow Name and the Flow Action name to be resumed. These values must be configured based on the queue name being processed and the queue record's case status to identify the record type (Pre-Arb, Pre- Arb response, Pre-Comp, Pre-Comp response, etc.)

  • The MapBatchQueueType map value rule in the PegaCard-Sd-Dispute-Visa- class returns the integration class based on the Queue Name. The name of the integration class is required to retrieve the records saved in a database table. The implementation layer integration classes should replace these classes.
  • Customers can extend the AdditionalExceptionProcessing activity rule in the PegaCard- Sd-Visa- class to handle exceptions caught during queue records processing.

Results[edit]

The Issuer or Acquirer will be able to process the Visa batch queues using agents.