Documentation for a newer release is available. View Latest
Esta página no está disponible actualmente en Español. Si lo necesita, póngase en contacto con el servicio de asistencia de Icon (correo electrónico)

Duplicate Check Keys - Single

When invoking checkSingleDuplicate, data elements from the message which are used as duplicate check parameters are mapped into a Duplicate Check Key. This key holds these elements as a list of strings and these keys are saved to the supporting transaction cache service.

A message will be considered a duplicate if more than one entry containing the same keys is present in the transaction cache at the time of checking.

public class DuplicateCheckKey implements Serializable {
    private List<String> data;
    private String transactionCacheEntryType;
}

Duplicate Check Keys - Multiple

To perform multiple duplicate checks in a single invocation (such as performing duplicate checks against all transactions contained within a message) the checkMultipleDuplicate function can be called. A duplicate check will be performed for each entry in the map provided and the responses will be collated into a single response which is sent back to the calling flow. If using this functionality, you should provide a Transaction Cache Entry Type in addition to the Duplicate Check Key Map. If one is not specified, a default of CheckMultipleDuplicate is used, which is taken from the action’s name.

The results of the multiple duplicate check are collected in a map, so consideration should be given to the expected number of entries in the resulting map, as this is stored against the flow aggregate. If there are more than 500 expected entries, an alternate approach to the multiple duplicate check flo-client might be more appropriate 
public class DuplicateCheckMultipleRequest implements Serializable {
    String transactionCacheEntryType;
    Map<String, DuplicateCheckKey> duplicateCheckKeyMap;
}

Duplicate Check Key Multiple Response

If a multiple duplicate check is requested, results will be collated into a Map, which will be returned as business data to the flow. If any duplicates are contained in the result set, the response code returned by the checkMultipleDuplicate call will be CONTAINSDUPLICATES, otherwise the response code returned will be NODUPLICATES

public class DuplicateCheckMultipleResponse implements Serializable {
    Map<String, DuplicateResponse> duplicateCheckResponseMap;
}

Persistence

The transaction cache is provided by a PersistentTransactionCacheService. Refer transaction cache service. for more details on the transaction cache service.

This service is backed by MongoDB, so the necessary data to populate the cache and perform duplicate checks survives a service restart.

TransactionCacheEntryType

By default, entries associated with single duplicate check invocations will have a TransactionCacheEntryType of CheckSingleDuplicate whereas entries associated to the multiple duplicate check will have an entry type of CheckMultipleDuplicate, which is taken from the action’s name. The transaction cache entry type is used at the time of saving and finding within the cache. Even if the same duplicate check key exists as an entry in the transaction cache, it will only be considered a duplicate if the transactionCacheEntryType is the same.

The Client Implementations are able to provide custom transaction cache entry types. This could be useful for when:

  • There are two separate flows carrying out duplicate checks and want to restrict duplicate responses just to keys that flow has seen.

  • There is a requirement to have different duration periods for different function calls. Custom purging schedules can be setup based on the type.

Refer Providing Custom TransactionCacheEntryTypes for more details on how a custom transaction entry type can be defined.

Duplicate Duration

The length of time a Duplicate Check Key entry exists within the cache effectively determines the period of time a message will be considered a duplicate. Duplicate Check Key entries are routinely purged from the supporting transaction cache service.

By default, purging will take place at midnight every day, and will remove all entries older than midnight. Effectively acting to clear the previous day’s transactions. You can provide configuration if this schedule does not meet your needs.

Eager saving

Duplicate Check Keys are eargerly saved to the cache and then verified for any duplicates. If more than one entry is found then at least one previously existed, and the message will be considered a duplicate.

This "eager" save is a preferable alternative to the process of:

  • Read from cache with derived key

  • If there is a result, then flag a duplicate, else save to the cache.

It reduces the window for concurrent duplicates slipping through, at the cost of an extra record being stored.

Supported Message Types

The floclient has the ability to support any message type or message attributes for duplicate checking due to the use of client specific mapping functions for duplicate checking.

The following default mapping functions are provided.

Default Mapping Function Name ISO 20022 Message Type Fields mapped to Duplicate Check Key Description

DuplicateSingleMapFromPain001

pain001

.pmtInf[0].dbtrAcct.id.othr.id .pmtInf[0].cdtTrfTxInf[0].pmtId.endToEndId .pmtInf[0].cdtTrfTxInf[0].amt.instdAmt.value .pmtInf[0].cdtTrfTxInf[0].amt.instdAmt.ccy

Useful for messages containing a single transaction

DuplicateSingleMapFromPacs008

pacs008

.cdtTrfTxInf[0].pmtId.endToEndId .cdtTrfTxInf[0].dbtrAcct.id.othr.id .cdtTrfTxInf[0].intrBkSttlmAmt.value .cdtTrfTxInf[0].intrBkSttlmAmt.ccy

DuplicateMultipleMapFromPain001

pain001

.pmtInf[0].dbtrAcct.id.othr.id .pmtInf[0].cdtTrfTxInf[0].pmtId.endToEndId .pmtInf[0].cdtTrfTxInf[0].amt.instdAmt.value .pmtInf[0].cdtTrfTxInf[0].amt.instdAmt.ccy

Useful for messages which contain many transactions

DuplicateMultipleMapFromPacs008

pacs008

.cdtTrfTxInf[0].pmtId.endToEndId .cdtTrfTxInf[0].dbtrAcct.id.othr.id .cdtTrfTxInf[0].intrBkSttlmAmt.value .cdtTrfTxInf[0].intrBkSttlmAmt.ccy

The Duplicate Check Keys provided by the default mapping functions have no knowledge of the message type. Different messages can share the same field values.

To avoid misidentification of a duplicate between message types, use different transaction cache entry types. Alternatively, if implementing your own mappers, consider including a value within the key that ensures it is unique between message types.