Хранение данных обработки между сеансами
Добрый вечер!
Написал обработку, которая периодически шлет заявки на доставку (Заказ клиента, Возврат, Реализация и т.п.) на внешний сервис. Часть заявок может быть отменена, а чтобы удалить их в сервисе необходимо конкретно их выгрузить отдельным методом.
С учетом того, отмененная заявка и заявка, которая попала в Задание на перевозку одинаково невидима для алгоритмов обработки, вижу решением создавать некий список выгруженных документов при выгрузке, а при следующей выгрузке новый список сравнивать со старым и по каждой отсутсвующей заявке выяснять - она закрыта или нет - если да, то именно ее отправить на удаление из внешнего сервиса.
Так вот, встал вопрос - А где, собственно, хранить эти межсеансовые списки документов внешней обработки?
Написал обработку, которая периодически шлет заявки на доставку (Заказ клиента, Возврат, Реализация и т.п.) на внешний сервис. Часть заявок может быть отменена, а чтобы удалить их в сервисе необходимо конкретно их выгрузить отдельным методом.
С учетом того, отмененная заявка и заявка, которая попала в Задание на перевозку одинаково невидима для алгоритмов обработки, вижу решением создавать некий список выгруженных документов при выгрузке, а при следующей выгрузке новый список сравнивать со старым и по каждой отсутсвующей заявке выяснять - она закрыта или нет - если да, то именно ее отправить на удаление из внешнего сервиса.
Так вот, встал вопрос - А где, собственно, хранить эти межсеансовые списки документов внешней обработки?
По теме из базы знаний
- Железнодорожная накладная ГУ 27 (для состава)
- ЖД Накладная ГУ-27 для одного вагона
- "Внешний" справочник или Хранение данных между сеансами работы внешних обработок
- Передача данных между сеансами и Повторное использование значений между сеансами
- Как сделать обмен данными через универсальный формат быстрее? Реализация многопоточного обмена данными
Найденные решения
Пришел к выводу, что сохранение списка последних отправленных документов в каком бы то ни было виде ,с последующим сравнением с новым списком, не гарантирует выявление сторнированных заявок, т.к. список ранее выгруженных документов уже может не содержать сторнированные заказы из-за вариаций предполагаемых пользовательских настроек обработки.
Думаю, что лучшим решением будет запрос в API сервиса с получением выгруженных заказов и сравнение с текущим списком обработки
Думаю, что лучшим решением будет запрос в API сервиса с получением выгруженных заказов и сравнение с текущим списком обработки
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Для этого в идеале надо статусную модель документам - Не отправлен, Отправлен, К отмене, Отменен и тд.
Статусы для документов логично хранить в регистре сведений и соответственно менять при определенных действиях. Одной обработки для нормального обмена тут не достаточно.
Статусы для документов логично хранить в регистре сведений и соответственно менять при определенных действиях. Одной обработки для нормального обмена тут не достаточно.
(6)Тут проблема в отсутствии единой архитектуры "API" для подсистемы доставки в УТ11 (КА, ЕРП) и, скорее всего, всю подсистему сделали чисто для галочки. Потому, где-то есть статусная модель, где-то ее нет, а есть вообще документ Поручение экспедитору, который на фиг ломает всю логику, как программную, так и человеческую
(8) К сожалению, обработка не предполагает столь масштабного перекроения УТ. На самом деле есть способ узнать отменен заказ или нет - если его не видит алгоритм обработки и его нет в Задании на перевозку, значит доставка отменена и если этот заказ уже был выгружен, значит для надо отправить отдельный POST запрос на удаление.
И вот ключевой момент тут - если этот заказ уже был выгружен.
Первое, что на ум приходит - сохранять в Хранилище Соответствие с парой ТипДокумента-УИДдокумента(по-моему, нельзя сохранять ссылки на документы(мутабельные значения) в Хранилище) для выгружаемых документов, а в следующей сессии сравнить новый список со старым и отсутствующие проверить на сторно
Плюсы - не трогается конфигурация, нет такого непредсказуемого фактора, как файловая система
Минусы - Если заказов будет реально много, то процесс сравнения будет сильно грузить систему, т.к. потребует поиска доков по ГУИДАМ
Второе - использовать штатный механизм дополнительных реквизитов в документах вместо статусов.
Плюсы - не трогается конфигурация, нет такого непредсказуемого фактора, как файловая система и я не очень доверяю Хранилищу(ибо это такая "черная коробочка")
Минусы - для доп рек придется немало продумать и написать кода для "защиты от дурака", каждый выгружаемый документ придется перезаписывать, потенциально тяжеленные запросы для выборки всех отправленных документов
И вот ключевой момент тут - если этот заказ уже был выгружен.
Первое, что на ум приходит - сохранять в Хранилище Соответствие с парой ТипДокумента-УИДдокумента(по-моему, нельзя сохранять ссылки на документы(мутабельные значения) в Хранилище) для выгружаемых документов, а в следующей сессии сравнить новый список со старым и отсутствующие проверить на сторно
Плюсы - не трогается конфигурация, нет такого непредсказуемого фактора, как файловая система
Минусы - Если заказов будет реально много, то процесс сравнения будет сильно грузить систему, т.к. потребует поиска доков по ГУИДАМ
Второе - использовать штатный механизм дополнительных реквизитов в документах вместо статусов.
Плюсы - не трогается конфигурация, нет такого непредсказуемого фактора, как файловая система и я не очень доверяю Хранилищу(ибо это такая "черная коробочка")
Минусы - для доп рек придется немало продумать и написать кода для "защиты от дурака", каждый выгружаемый документ придется перезаписывать, потенциально тяжеленные запросы для выборки всех отправленных документов
(9)
Хотя, можно сначала сравнить строковые ГУИДЫ, вычленить отсутствующие ГУИДЫ и уже по ним вывести документы для проверки. А пару делать УИДдокумента = ТипДокумента.
Это существенно снизит нагрузку.
Есть ли у кого более оптимальное решение?
Первое, что на ум приходит - сохранять в Хранилище Соответствие с парой ТипДокумента-УИДдокумента(по-моему, нельзя сохранять ссылки на документы(мутабельные значения) в Хранилище) для выгружаемых документов, а в следующей сессии сравнить новый список со старым и отсутствующие проверить на сторно
Хотя, можно сначала сравнить строковые ГУИДЫ, вычленить отсутствующие ГУИДЫ и уже по ним вывести документы для проверки. А пару делать УИДдокумента = ТипДокумента.
Это существенно снизит нагрузку.
Есть ли у кого более оптимальное решение?
Пришел к выводу, что сохранение списка последних отправленных документов в каком бы то ни было виде ,с последующим сравнением с новым списком, не гарантирует выявление сторнированных заявок, т.к. список ранее выгруженных документов уже может не содержать сторнированные заказы из-за вариаций предполагаемых пользовательских настроек обработки.
Думаю, что лучшим решением будет запрос в API сервиса с получением выгруженных заказов и сравнение с текущим списком обработки
Думаю, что лучшим решением будет запрос в API сервиса с получением выгруженных заказов и сравнение с текущим списком обработки
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот