![]() |
#1 |
Участник
|
Здравствуйте! Хотелось бы услышать мнения по следующему вопросу. Есть NAV 4.00 SP2 и NAS, который с периодичностью в 10 минут, запускает соответствующий кодеюнит, где выполняются определенные учетные операции. Зачастую указанного времени достаточно, чтобы выполнить учет всех операции, a иногда и нет... Таким образом, по истечению 10 мин., если все операции не выполнились, снова запускается сессия NAS и происходят не очень хорошие вещи… (т.е. конфликты) Конечно, можно увеличить интервал запуска NAS и не морочить голову, но это не выход… (есть еще другие нюансы)))) Суть вопроса в следующем – возможно ли, каким-то образом, при очередном запуске nas, смотреть, а полностью ли завершилась обработка предыдущего сеанса запуска? Т.е., если предыдущий сеанс еще не завершен, то никаких операций не выполнять, а завершить работу и установить интервал запуска nas, скажем, через 2 минуты (если после 2 минут, предыдущий сеанс обработался, интервал запуска снова необходимо вернуть в 10 мин.). В противном случае, начать обработку.
|
|
![]() |
#2 |
Участник
|
Навскидку такой вариант:
использовать SingleInstance функциональность. Для этого в кодеюните 448 "Job Queue Dispacher" или в собственном отдельном SingleInstance-кодеюните создаёте булевые переменные, которые и включаете TRUE, FALSE по мере надобности, т.е. перед началом работы каждого процесс сам процесс включает булевую переменную типа ProcessComplete=FALSE и потом, если процесс завершён полностью, то ProcessComplete=TRUE. T.e. по идее если по плану следующий процесс стартует через 10 минут, то он первым делом должен обратиться к булевой переменной в SingleInstance-кодеюните и если NOT ProcessComplete, то ждём +10 минут и обращаемся снова. И только если ProcessComplete=TRUE, то стартуем данный процесс. Есть конечно и минус: если по какой-то причине предыдущий процесс вывалился так, что не смог закончить своё пребывание в SingleInstance-кодеюните, то следующий процесс вообще никогда не стартует, так как будет ждать вечно. Но на такой случай можно ждать макс. определённое время и следующий процесс включать принудительно по истечении макс. возможного ожидания. |
|
![]() |
#3 |
Участник
|
Можно попробовать что-то типа:
OnRun() CREATE(QueueTimer); QueueTimer.Interval := 10*60*1000; QueueTimer.Enable; ... QueueTimer::TimerEvent() QueueTimer.Disable; ... QueueTimer.Enable; |
|
![]() |
#4 |
Участник
|
Ребят, спасибо большое за советы – очень помогли и оба варианта работают. Проверял
![]() Единственное, что способ, который предложил RedFox я переделал вот так: OnRun() CREATE(QueueTimer); QueueTimer.Interval := 10*60*1000; QueueTimer.Enabled := TRUE; ... QueueTimer::Timer(MilliSecounds : Integer) QueueTimer.Enabled := FALSE; … QueueTimer.Enabled := TRUE; И тоже все заработало. |
|
![]() |
#5 |
Участник
|
+1 к RedFox. При реализации интеграции я задействовал:
1. Таблицу интервалов интеграции (содержим режим интеграции - запись, чтение, обновление, id объекта интеграции - товар, клиент и т.д., время интеграции, блокировка). 2. Регистр, в который записывается последняя дата и время записи, чтения и обновления. Если NAS перезапускается, это не приводит к повторному сеансу интеграции. Дата и время берутся из регистра. 3. Таймер, который периодически обращается к кодюниту для сверки текущей даты и времени с сеансами интеграции и регистром. |
|
![]() |
#6 |
Участник
|
Вообще не понял зачем запускать и останавливать именно NAS. Пусть NAS работает постоянно, при запуске NAS стартуйте кодъюнит с таймером который и вызывает ваш кодъюнит по таймеру. В этом случае если не завершилось выполнение кодъюнита NAS следующий и не запустит.
__________________
Want to believe... |
|
![]() |
#7 |
Участник
|
Объясню почему. Если в объекты вносятся какие-то правки, то NAS необходимо перезапускать, чтобы он работал с новой версией объекта. Если никуда не записывать последнюю дату и время сеанса интеграции, то после перезапуска сеанс повторится. А это не всегда хорошо (например, если выполняются тяжелые задания, типа коррекции себестоимости).
|
|
![]() |
#8 |
Участник
|
Цитата:
Сообщение от Fly
![]() Объясню почему. Если в объекты вносятся какие-то правки, то NAS необходимо перезапускать, чтобы он работал с новой версией объекта. Если никуда не записывать последнюю дату и время сеанса интеграции, то после перезапуска сеанс повторится. А это не всегда хорошо (например, если выполняются тяжелые задания, типа коррекции себестоимости).
|
|
![]() |
#9 |
Участник
|
Цитата:
Сообщение от AlexB
![]() Цитата:
Сообщение от Fly
![]() Объясню почему. Если в объекты вносятся какие-то правки, то NAS необходимо перезапускать, чтобы он работал с новой версией объекта. Если никуда не записывать последнюю дату и время сеанса интеграции, то после перезапуска сеанс повторится. А это не всегда хорошо (например, если выполняются тяжелые задания, типа коррекции себестоимости).
|
|
![]() |
#10 |
Участник
|
Цитата:
Сообщение от Fly
![]() [Не знал, что можно установить значение 0. Мне не совсем понятно как NAS в этом случае будет работать. Как он будет знать, что необходимо подтянуть новую версию объектов? И если каким-то образом будет знать, хорошее ли это решение при каждом обращении к объекту обновлять его версию?
|
|
![]() |
#11 |
Участник
|
Цитата:
Сообщение от AlexB
![]() Цитата:
Сообщение от Fly
![]() [Не знал, что можно установить значение 0. Мне не совсем понятно как NAS в этом случае будет работать. Как он будет знать, что необходимо подтянуть новую версию объектов? И если каким-то образом будет знать, хорошее ли это решение при каждом обращении к объекту обновлять его версию?
Объясните пожалуйста ![]() |
|
![]() |
#12 |
Участник
|
Цитата:
Сообщение от Fly
![]() Объясню почему. Если в объекты вносятся какие-то правки, то NAS необходимо перезапускать, чтобы он работал с новой версией объекта. Если никуда не записывать последнюю дату и время сеанса интеграции, то после перезапуска сеанс повторится. А это не всегда хорошо (например, если выполняются тяжелые задания, типа коррекции себестоимости).
И проверено на практике, что SELECTLATESTVERSION не помогает в NAS. |
|
![]() |
#13 |
Участник
|
Цитата:
Сообщение от RedFox
![]() Цитата:
Сообщение от Fly
![]() Объясню почему. Если в объекты вносятся какие-то правки, то NAS необходимо перезапускать, чтобы он работал с новой версией объекта. Если никуда не записывать последнюю дату и время сеанса интеграции, то после перезапуска сеанс повторится. А это не всегда хорошо (например, если выполняются тяжелые задания, типа коррекции себестоимости).
И проверено на практике, что SELECTLATESTVERSION не помогает в NAS. |
|
![]() |
#14 |
Участник
|
Цитата:
Сообщение от Fly
![]() Никак не могу понять. Вы говорите - при старте NAS, если cache=0, то NAS работает с актуальной версией объектов. Т.е. объекты цепляются в этот момент, дальше NAS запускает кодюнит с таймером. При срабатывании события "Timer" NAS будет обновлять версию объектов? Или нет? Когда он это будет делать? Я поменял объект в момент времени N. При следующем срабатывании события "Timer" NAS уже будет работать с новой версией объекта?
Объясните пожалуйста ![]() У меня тоже проверено на практике: прекрасно работает |
|
![]() |
#15 |
Участник
|
Цитата:
Сообщение от AlexB
![]() NAS такой же client как и обычный, только невидимый. При нулевом cache NAS (если он постоянно без промежуточных перезапусков работате) заметит то что обьект изменился только в момент обращения к обьекту, если cashe > 0 то будет работать всю дорогу с версией обьектов из cache до тех пор пока служба NAS не будет перезапущена (по идее, в этом и смысл object cache).
Меня вот это интересует. Потому как Ваш способ очень хорошей и я даже плюсую, но вот этот тонкий момент очень важен. |
|
![]() |
#16 |
Участник
|
Именно так, каждый раз в момент обращения к обьекту. Но RedFox тоже прав, NAS рекомендуется периодически перезапускать, т.к на нулевой chache нельзя полагаться 100%, но именно периодически, а не каждые 10 минут, это уже перебор.
|
|
![]() |
#17 |
Участник
|
Как вариант решения, можно и с нулевым cache. Но как по мне, то частое обращение к объектам (фактически при каждом срабатывании события Timer) не есть гуд.
|
|