Duplicate Check Keys - Single
Al invocar checkSingleDuplicate, los elementos de datos del mensaje que se utilizan como parámetros de duplicate check se mapean a un Duplicate Check Key. Esta clave contiene estos elementos como una lista de strings y estas claves se guardan en el transaction cache service de soporte.
Un mensaje se considerará un duplicado si, en el momento de la verificación, hay más de una entrada que contenga las mismas claves en el transaction cache.
public class DuplicateCheckKey implements Serializable {
private List<String> data;
private String transactionCacheEntryType;
}Duplicate Check Keys - Multiple
Para realizar multiple duplicate checks en una sola invocación (como realizar verificaciones contra todas las transacciones contenidas en un mensaje) se puede llamar a la función checkMultipleDuplicate.
Se realizará un duplicate check por cada entrada del mapa proporcionado y las respuestas se recopilarán en una sola respuesta que se envía de vuelta al flow que invoca. Si utilizas esta funcionalidad, debes proporcionar un Transaction Cache Entry Type además del Duplicate Check Key Map. Si no se especifica,
se usará un valor predeterminado de CheckMultipleDuplicate, que se toma del nombre de la action.
| Los resultados del multiple duplicate check se recopilan en un map, por lo que se debe considerar el número esperado de entradas en el mapa resultante, ya que esto se almacena en el flow aggregate. Si se esperan más de 500 entradas, puede ser más apropiado un enfoque alternativo al multiple duplicate check flo-client. |
public class DuplicateCheckMultipleRequest implements Serializable {
String transactionCacheEntryType;
Map<String, DuplicateCheckKey> duplicateCheckKeyMap;
}Duplicate Check Key Multiple Response
Si se solicita un multiple duplicate check, los resultados se recopilarán en un Map, que se devolverá como business data al flow. Si el conjunto de resultados contiene duplicados, el código de respuesta devuelto por la llamada checkMultipleDuplicate será CONTAINSDUPLICATES; en caso contrario,
será NODUPLICATES.
public class DuplicateCheckMultipleResponse implements Serializable {
Map<String, DuplicateResponse> duplicateCheckResponseMap;
}Persistence
El transaction cache es proporcionado por un PersistentTransactionCacheService. Consulta transaction cache service para más detalles sobre el servicio de transaction cache.
Este servicio se basa en MongoDB, por lo que los datos necesarios para poblar el cache y realizar duplicate checks sobreviven a un reinicio del servicio.
TransactionCacheEntryType
De forma predeterminada, las entradas asociadas con invocaciones de single duplicate check tendrán un TransactionCacheEntryType de CheckSingleDuplicate, mientras que las entradas asociadas al multiple duplicate check tendrán un tipo de entrada de CheckMultipleDuplicate (tomado del nombre de la action). El transaction cache entry type se utiliza en el momento de guardar y buscar dentro del cache. Incluso si la misma duplicate check key existe como entrada en el transaction cache, solo se considerará un duplicado si el transactionCacheEntryType es el mismo.
Las Client Implementations pueden proporcionar transaction cache entry types personalizados. Esto podría ser útil cuando:
-
Hay dos flows separados realizando duplicate checks y se desea restringir las respuestas de duplicado únicamente a las claves que ese flow ha visto.
-
Existe el requisito de tener diferentes periodos de duración para distintas llamadas a funciones. Se pueden configurar purgas personalizadas basadas en el tipo.
Consulta Providing Custom TransactionCacheEntryTypes para más detalles sobre cómo se puede definir un transaction entry type personalizado.
Duplicate Duration
La duración de tiempo que una entrada de Duplicate Check Key permanece en el cache determina efectivamente el periodo durante el cual un mensaje será considerado duplicado. Las entradas de Duplicate Check Key se purgan de forma rutinaria del transaction cache service de soporte.
De forma predeterminada, la purga se realiza a medianoche todos los días y eliminará todas las entradas anteriores a esa medianoche. En la práctica, esto limpia las transacciones del día anterior. Puedes proporcionar configuración si este calendario no satisface tus necesidades.
Eager saving
Las Duplicate Check Keys se guardan de forma eager en el cache y luego se verifican en busca de duplicados. Si se encuentra más de una entrada, entonces al menos una ya existía, y el mensaje se considerará un duplicado.
Este guardado "eager" es una alternativa preferible al proceso de:
-
Leer del cache con la clave derivada
-
Si hay un resultado, marcar duplicado; de lo contrario, guardar en el cache.
Reduce la ventana en la que se podrían colar duplicados concurrentes, a costa de almacenar un registro adicional.
Supported Message Types
El floclient tiene la capacidad de admitir cualquier tipo de mensaje o atributos de mensaje para duplicate checking gracias al uso de mapping functions específicos del cliente para el duplicate checking.
Se proporcionan las siguientes mapping functions predeterminadas.
| Default Mapping Function Name | ISO 20022 Message Type | Fields mapped to Duplicate Check Key | Description |
|---|---|---|---|
DuplicateSingleMapFromPain001 |
pain001 |
|
Útil para mensajes que contienen una sola transacción |
DuplicateSingleMapFromPacs008 |
pacs008 |
|
|
DuplicateMultipleMapFromPain001 |
pain001 |
|
Útil para mensajes que contienen muchas transacciones |
DuplicateMultipleMapFromPacs008 |
pacs008 |
|
Las Duplicate Check Keys proporcionadas por las mapping functions predeterminadas no conocen el tipo de mensaje. Mensajes diferentes pueden compartir los mismos valores de campo.
| Para evitar la identificación incorrecta de un duplicado entre tipos de mensaje, usa transaction cache entry types diferentes. Alternativamente, si implementas tus propios mappers, considera incluir en la clave un valor que asegure que sea única entre tipos de mensaje. |