12.06.2024, 19:03 | #1 |
Участник
|
Архитектура импорта файлов: батчем + интеррактивно
AX2009
Простая задача: Нужно импортировать файлы батчем из папки на сервере и также дать возможность пользователю запустить этот процесс вручную(интеррактивно) Как избежать того, чтобы два батч процесса или батч+интеррактив не начали одновременно обрабатывать один и тот же файл? Один из вариантов, как мне кажется: создать табличку, куда писать имя файла и статус (обработан или нет) и, может, какой-то guid для обозначения процесса, который файл обрабатывает. Т.о конкурирующий процесс увидит, что файл уже в процессе обработки, и не будет его трогать. Другой вариант: можно куда-то перемещать файл сразу для обработки(в другую папку и удалять из текущей), но, наверное, это менее надежный подход Еще один: как-то лочить сам файл(открывать на запись, но ничего не писать).Тогда другой процесс проверит открыт ли он на запись и не сможет обработать. Есть ли иные(проверенные) способы? (Не хочу изобретать велосипед или наступать на грабли). Может, в самой аксапте есть хорошие стандартные примеры? Последний раз редактировалось Lankey; 12.06.2024 в 19:08. |
|
12.06.2024, 20:48 | #2 |
Участник
|
В MS SQL сервере введено понятие "ресурса", который можно заблокировать
sp_getapplock (Transact-SQL) Физически, "ресурс" - это просто символьная строка. Соответственно, через команды прямого обращения к SQL (Connection+Statement) можно создать и заблокировать "ресурс" и при попытке другого пользователя создать тот же самый ресурс он получит ошибку Применительно к данной задаче в качестве "ресурса" можно использовать имя обрабатываемого файла Достоинства этого метода в том, что в случае разрыва соединения блокировка ресурса снимается автоматически. Именно по этой причине лучше использовать именно Connection PS: вопрос только в том, какая версия MS SQL используется. Не помню, с какой версии эти функции были введены PPS: в dax2012 есть готовый класс по работе с ресурсами MS SQL. Называется ReqReaderWriterLock. Но был ли он в dax2009 - не в курсе
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... Последний раз редактировалось Владимир Максимов; 12.06.2024 в 21:06. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (5), Lankey (1). |
12.06.2024, 21:08 | #3 |
Участник
|
Цитата:
Что то типа папка файлов для обработки -> папка с обрабатываемыми файлами ->папка с успешно обработанными/сбойные файлы (stoneridgesoftware: Automated Data Entity Import Using DIXF in Dynamics AX ?) Последний раз редактировалось axm2017; 12.06.2024 в 21:11. |
|
12.06.2024, 21:21 | #4 |
Участник
|
Кстати, все описанные варианты не взаимоисключающие, а, скорее, взаимодополняющие
1. Перемещение файла упростит анализ того, что вообще надо обрабатывать, а что уже обработано. Все, что в указанной папке - надо обработать. После обработки файл в другой папке 2. Дополнительная таблица - это лог того, что обработали. Удобно для "разбора полетов" в случае каких-то проблем 3. Блокировка по sp_getapplock - ну, это гарантия того, что 2 пользователя не попытаются "одновременно" взять (переместить) файл
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
12.06.2024, 23:39 | #5 |
Участник
|
Добрый вечер.
Смотреть на флаг read-only у целевого файла - стандартный способ для встроенной системы контроля версий в Аксапту. Однако общепринятой практикой является таблица с логическими флагами или статусами. Самым простым выглядит, для пользовательского процесса, запускать всё тоже пакетное задание, но в синхронном режиме, с ограничением (batch constrain) на выполнение иного пакетного задания. Тут всё зависит от контекста. Зачем вообще пользователя подпускать к данному процессу? Он системе как-то помогает? Да вряд ли... Приоритизирует файлы к обработке потому что эти данные нужны здесь и сейчас? |
|
13.06.2024, 08:17 | #6 |
Участник
|
Цитата:
Батч будет каждую неделю. Пользователи будут корректировать файлы, что не импортировались вследствие ошибок в данных, и тут же ре-импортировать Последний раз редактировалось Lankey; 13.06.2024 в 08:29. |
|
13.06.2024, 08:28 | #7 |
Участник
|
Цитата:
После обработки он будет в другой папке. Я тут писала про "промежуточную папку" (как axm2017 описывает выше) , где файл будет, пока не закончена его обработка. Можно, действительно, без нее: если процесс прервался с ошибкой по какой-то причине перемещать его обратно папку-источник в catch блоке. Хотя, если вообще прервана связь с сервером, это не поможет. Последний раз редактировалось Lankey; 13.06.2024 в 08:33. |
|
13.06.2024, 08:31 | #8 |
Участник
|
Поясните, пожалуйста, зачем (3), если сделать (2), то есть, уже по таблице,вроде, можно понять, заблокирован файл или нет.
|
|
13.06.2024, 08:39 | #9 |
Участник
|
Спасибо. Синхнонное выполнение батча - интересная идея, но, мне кажется, редко используется. Почему? Тк ошибки пользователю не показываются в таком режиме. то есть, менее user-friendly, чем интеррактивный режим? Или есть какие-то еще подводные камни?
|
|
13.06.2024, 10:58 | #10 |
Участник
|
Цитата:
1. Первый пользователь выбрал файл 2. Второй пользователь выбрал файл 3. Первый пользователь сделал запись в лог 4. Что помешает второму пользователю также сделать запись в лог? Т.е. просто будут 2 записи в логе и 2 пользователя "одновременно" попытаются обработать файл В случае же блокировки ресурса, первое, что делает пользователь после выбора - пытается заблокировать ресурс. Удалось? Можешь продолжать. Нет? Этот файл взял другой пользователь
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
13.06.2024, 17:46 | #11 |
Участник
|
Цитата:
То есть, такой лог , в моем понимании, альтернативен Вашему предложению использовать sp_getapplock . Только лог дополнительно полезен тем, что потом можно его анализировать потом, а sp_getapplock - нет Последний раз редактировалось Lankey; 13.06.2024 в 17:53. |
|
13.06.2024, 23:40 | #12 |
Участник
|
Цитата:
1. Первый пользователь ищет запись. Не нашел 2. Второй пользователь ищет запись. Не нашел 3. Первый пользователь создает запись 4. Второй пользователь создает запись Уникальный индекс по имени файла? А если в разное время приходили файлы с одинаковым именем? По каким критериям выполнять поиск? Вы не контролируете то, что получаете из-вне системы. Статусы могут контролировать только записи таблицы. Но что именно записано в эти таблицы? При работе с данными, которые приходят из вне системы, использование таблицы блокировок для контроля - крайне не надежный инструмент.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
17.06.2024, 09:23 | #13 |
Участник
|
|
|
Теги |
ax2009 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|