Архитектура импорта файлов: батчем + интеррактивно

[Lankey]

AX2009

Простая задача: Нужно импортировать файлы батчем из папки на сервере и также дать возможность пользователю запустить этот процесс вручную(интеррактивно)

Как избежать того, чтобы два батч процесса или батч+интеррактив не начали одновременно обрабатывать один и тот же файл?
Один из вариантов, как мне кажется: создать табличку, куда писать имя файла и статус (обработан или нет) и, может, какой-то guid для обозначения процесса, который файл обрабатывает. Т.о конкурирующий процесс увидит, что файл уже в процессе обработки, и не будет его трогать.

Другой вариант: можно куда-то перемещать файл сразу для обработки(в другую папку и удалять из текущей), но, наверное, это менее надежный подход

Еще один: как-то лочить сам файл(открывать на запись, но ничего не писать).Тогда другой процесс проверит открыт ли он на запись и не сможет обработать.

Есть ли иные(проверенные) способы?
(Не хочу изобретать велосипед или наступать на грабли). Может, в самой аксапте есть хорошие стандартные примеры?

[Владимир Максимов]

В MS SQL сервере введено понятие "ресурса", который можно заблокировать

sp_getapplock (Transact-SQL)

Физически, "ресурс" - это просто символьная строка. Соответственно, через команды прямого обращения к SQL (Connection+Statement) можно создать и заблокировать "ресурс" и при попытке другого пользователя создать тот же самый ресурс он получит ошибку

Применительно к данной задаче в качестве "ресурса" можно использовать имя обрабатываемого файла

Достоинства этого метода в том, что в случае разрыва соединения блокировка ресурса снимается автоматически. Именно по этой причине лучше использовать именно Connection

PS: вопрос только в том, какая версия MS SQL используется. Не помню, с какой версии эти функции были введены

PPS: в dax2012 есть готовый класс по работе с ресурсами MS SQL. Называется ReqReaderWriterLock. Но был ли он в dax2009 - не в курсе

[axm2017]

Цитата:

Сообщение от Lankey

AX2009
...
Другой вариант: можно куда-то перемещать файл сразу для обработки(в другую папку и удалять из текущей), но, наверное, это менее надежный подход
...

Перемещать проще и надежнее + какая то обработка файлов данных в стандарте уже что-то подобное делает если память не подводит.
Что то типа папка файлов для обработки -> папка с обрабатываемыми файлами ->папка с успешно обработанными/сбойные файлы
(stoneridgesoftware: Automated Data Entity Import Using DIXF in Dynamics AX ?)

[Владимир Максимов]

Кстати, все описанные варианты не взаимоисключающие, а, скорее, взаимодополняющие

1. Перемещение файла упростит анализ того, что вообще надо обрабатывать, а что уже обработано. Все, что в указанной папке - надо обработать. После обработки файл в другой папке

2. Дополнительная таблица - это лог того, что обработали. Удобно для "разбора полетов" в случае каких-то проблем

3. Блокировка по sp_getapplock - ну, это гарантия того, что 2 пользователя не попытаются "одновременно" взять (переместить) файл

[Товарищ ♂uatr]

Добрый вечер.
Смотреть на флаг read-only у целевого файла - стандартный способ для встроенной системы контроля версий в Аксапту.
Однако общепринятой практикой является таблица с логическими флагами или статусами.
Самым простым выглядит, для пользовательского процесса, запускать всё тоже пакетное задание, но в синхронном режиме, с ограничением (batch constrain) на выполнение иного пакетного задания.
Тут всё зависит от контекста. Зачем вообще пользователя подпускать к данному процессу? Он системе как-то помогает? Да вряд ли... Приоритизирует файлы к обработке потому что эти данные нужны здесь и сейчас?

[Lankey]

Цитата:

Сообщение от Товарищ ♂uatr

Зачем вообще пользователя подпускать к данному процессу? Он системе как-то помогает? Да вряд ли... Приоритизирует файлы к обработке потому что эти данные нужны здесь и сейчас?

Спасибо
Батч будет каждую неделю. Пользователи будут корректировать файлы, что не импортировались вследствие ошибок в данных, и тут же ре-импортировать

[Lankey]

Цитата:

Сообщение от Владимир Максимов

1. Перемещение файла упростит анализ того, что вообще надо обрабатывать, а что уже обработано. Все, что в указанной папке - надо обработать. После обработки файл в другой папке

Спасибо.
После обработки он будет в другой папке.
Я тут писала про "промежуточную папку" (как axm2017 описывает выше) , где файл будет, пока не закончена его обработка. Можно, действительно, без нее: если процесс прервался с ошибкой по какой-то причине перемещать его обратно папку-источник в catch блоке. Хотя, если вообще прервана связь с сервером, это не поможет.

[Lankey]

Цитата:

Сообщение от Владимир Максимов

2. Дополнительная таблица - это лог того, что обработали. Удобно для "разбора полетов" в случае каких-то проблем

3. Блокировка по sp_getapplock - ну, это гарантия того, что 2 пользователя не попытаются "одновременно" взять (переместить) файл

Поясните, пожалуйста, зачем (3), если сделать (2), то есть, уже по таблице,вроде, можно понять, заблокирован файл или нет.

[Lankey]

Цитата:

Сообщение от Товарищ ♂uatr

Добрый вечер.
Самым простым выглядит, для пользовательского процесса, запускать всё тоже пакетное задание, но в синхронном режиме, с ограничением (batch constrain) на выполнение иного пакетного задания.

Спасибо. Синхнонное выполнение батча - интересная идея, но, мне кажется, редко используется. Почему? Тк ошибки пользователю не показываются в таком режиме. то есть, менее user-friendly, чем интеррактивный режим? Или есть какие-то еще подводные камни?

[Владимир Максимов]

Цитата:

Сообщение от Lankey

Поясните, пожалуйста, зачем (3), если сделать (2), то есть, уже по таблице,вроде, можно понять, заблокирован файл или нет.

Запись в лог - это история. Что БЫЛО сделано. Инструментом контроля, в общем случае, служить не может

1. Первый пользователь выбрал файл
2. Второй пользователь выбрал файл
3. Первый пользователь сделал запись в лог
4. Что помешает второму пользователю также сделать запись в лог?

Т.е. просто будут 2 записи в логе и 2 пользователя "одновременно" попытаются обработать файл

В случае же блокировки ресурса, первое, что делает пользователь после выбора - пытается заблокировать ресурс. Удалось? Можешь продолжать. Нет? Этот файл взял другой пользователь

[Lankey]

Цитата:

Сообщение от Владимир Максимов

4. Что помешает второму пользователю также сделать запись в лог?

"Мешает" проверка на то, что файл с таким именем уже есть в логе, и его статус != Обработан

То есть, такой лог , в моем понимании, альтернативен Вашему предложению использовать sp_getapplock . Только лог дополнительно полезен тем, что потом можно его анализировать потом, а sp_getapplock - нет

[Владимир Максимов]

Цитата:

Сообщение от Lankey

"Мешает" проверка на то, что файл с таким именем уже есть в логе, и его статус != Обработан

Я так понимаю, что Вы предполагаете перед записью в лог выполнять поиск.

1. Первый пользователь ищет запись. Не нашел
2. Второй пользователь ищет запись. Не нашел
3. Первый пользователь создает запись
4. Второй пользователь создает запись

Уникальный индекс по имени файла? А если в разное время приходили файлы с одинаковым именем? По каким критериям выполнять поиск?

Вы не контролируете то, что получаете из-вне системы. Статусы могут контролировать только записи таблицы. Но что именно записано в эти таблицы?

При работе с данными, которые приходят из вне системы, использование таблицы блокировок для контроля - крайне не надежный инструмент.

[Lankey]

Цитата:

Сообщение от Владимир Максимов

Уникальный индекс по имени файла? А если в разное время приходили файлы с одинаковым именем?

Спасибо. Согласна, так менее надежно
Не очень ясно, почему ,как я понимаю, в стандарте не используется sp_getapplock