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