| Суть изменения | Техническая реализация | Цель | Область применения (Метод API) |
|
Декрементная сортировка списка операций. Операции возвращаются в порядке убывания даты их последнего изменения (от самых новых к самым старым).
|
Использование поля valueDateTime ПУ обрабатывает ответ от сервера, сортируя полученные операции по значению поля valueDateTime в порядке убывания (DESC).
|
СПУ получает последние измененные операции (например, обновленные статусы) вверху списка, что упрощает валидацию и упрощает отображение в пользовательском интерфейсе.
|
GET /transactions GET /accounts/{accountId}/transactions
|
|
Внедрение инкрементального обмена данными. ПУ возвращает СПУ только операции, измененные или добавленные с момента последнего успешного запроса данного СПУ, вместо полного набора данных.
|
Реализация алгоритма на основе маркерных таблиц: 1. Хранение состояния: ПУ ведет таблицу (маркер), фиксирующую для каждого СПУ и типа запроса "точку синхронизации" (напр., временную метку, хэш или ID последней переданной операции). 2. Фильтрация ответа: При получении запроса от СПУ, ПУ использует сохраненный для этого СПУ маркер, чтобы отфильтровать операции, не изменившиеся с момента последнего запроса. 3. Формирование инкрементального ответа: В ответе передаются только новые или измененные с прошлого раза операции. 4. Обновление маркера: После успешной передачи ответа, ПУ обновляет маркер для данного СПУ на основе переданных данных (напр., максимальная временная метка в ответе). Также должен быть механизм, позволяющий СПУ повторно получить полный набор данных, не учитывающий предыдущие запросы (необходимо проработать).
|
Снижение нагрузки на системы: Уменьшение объема передаваемых данных и обработки на стороне ПУ и СПУ за счет исключения передачи неизмененных операций. Экономия сетевых ресурсов: Сокращение трафика между ПУ и СПУ. Улучшение масштабируемости: Системы лучше выдерживают рост числа клиентов (СПУ) и частоты запросов.
|
GET /transactions GET /accounts/{accountId}/transactions (в перспективе и другие методы, возвращающие исторические/объемные данные) |
|
Рекомендации по доступным действиям для счетов в статусах "Disabled" и "Deleted".
|
На основе опыта участников рынка рекомендуется для счетов со статусом Disabled: -ПУ продолжает возвращать полные данные о счете (реквизиты, детали операций, баланс) в ответах на соответствующие методы API. -ПУ возвращает баланс, актуальный на последний момент доступности счета до его перехода в статус Disabled. - ПУ разрешает вызов методов, связанных с получением информации (чтением данных). Методы, инициирующие действия (списания, переводы) блокируются. Для Deleted: - ПУ не возвращает актуальный баланс (или возвращает 0) в ответ на запросы текущего баланса. Запросы баланса могут возвращать ошибку или пустой/нулевой результат. - ПУ продолжает возвращать исторические данные об операциях по счету (выписки) за периоды, когда счет был активен. - ПУ разрешает вызов только строго определенных методов, предоставляющих исторические данные. Все остальные методы (включая запрос актуального баланса, инициирование действий) блокируются.
|
Снижение рисков несогласованности в работе ПУ и СПУ. | Требуется проработка с участниками. |
Счета ФЛ:
1. Декрементная cортировка операций в GET /transactions и GET /accounts/{accountId}/transactions.
Техническая реализация на стороне ПУ:
2. Алгоритм оптимизации обмена данными с использованием маркерных таблиц.
Техническая реализация на стороне ПУ:
Счета ФЛ и ЮЛ:
3. Рекомендации по доступным действиям для счетов в статусах "Disabled" и "Deleted".
На основе опыта участников рынка рекомендуется для счетов со статусом Disabled:
Для Deleted: