Разработка в кластере АОС

[ravil]

Вопрос такой: как вести разработку в условиях наличия кластера из нескольких АОС. Интересует как работа с непосредственно АОТ, так и с меточными файлами.

Почему спрашиваю, в документах на партнергайде (Deploying application changes in a multi-AOS environment using Navision Axapta 2.5, Handling development in an AOS environment) я вычитал, что вроде можно разработку вести и не перезапуская АОСы, используя класс sysaodflush для обновления кэша, но у меня изменения, сделанные в одном АОС, на другом автоматически не появляются, несмотря на запуск этого класса и перезапуска клиента. (Добавленное в одном АОС поле таблицы в другом АОС показывается с именем UNKNOWN, и обозревателем тадлица не открывается, выдает ошибку SQL).

Не могли бы подсказать, как правильно вводить изменения в АОТ и меточные файлы, по возможности избегая перезапуски АОС.

Настольные книги Developer's Guide и Developer's Best Practices при поиске по слову cluster выдают только про кластерные индексы.

[savel]

У нас работа горганизованна следующим образом.
Есть боевая Аксапта, с 2мя АОСами в кластере. Есть Аксапта для разработки - 1АОС.
Стандартно разработка ведётся в Аксапте для разработки, после принятия решения, что текущие наработки можно переносить - останавливаетс боевая, переносится весь слой, всё синхронизируется, запускаются оба АОСа. (по времени это занимает обычно не больше 15 мин.).
Если же переносить слой нельзя - экспортируется отдельный проект, или элемент. Заходим в Аксату боевую, импортируем этот элемент, компилируем. После необходимо войти в боевую Аксапту со второго АОСа, на необходимом элементе сказать "восстановить" и тоже откомпилировать.
(с меточными файлами не работаем).

[ravil]

Почему-то восстановление работает не так как я ожидал.

Если с таблицы удаляю поле на АОС1, и сохраняю изменения, то на АОС2 после нажатия на восстановление удаленное поле тоже исчезает.

Если добавляю поле на АОС1 (скажем с названием NewField) и сохраняю, на АОС появляется поле с названием UNKNOWN. То же самое, если на АОС1 компилирую и сохраняю, на АОС2 восстанавливаю - название нового поля не появляется правильно.

Пробую компилировать на АОС2 - выдается ошибка
Неправильный 'SysDictField' элемент создан 'NewField' != 'UNKNOWN'. А у вас при компиляции на втором АОС тоже такого рода ошибки выдаются?
Зато при повторном нажатии на восстановление название нового поля уже появляется как надо, NewField.

А как должно быть правильно? Я полагал, что сохранил в одном АОС (пусть с компиляцией), сделал восстановление в другом (без компиляции) - изменения должны быть синхронизированы, и так можно обновлять систему в режиме реального времени. Но такое не наблюдается. Это так и должно быть или глюк какой или я что-то не так делаю?

Использование класса SysFlushAOD на процесс никак не влияет. Тогда зачем он нужен интересно?

[savel]

У меня так же "восстановить" не всегда отрабатывает с первого раза. Для борьбы с этим перед заходом в Аксапты со ворого АОСа, на клиентской машине убиваю *.aoc файлы. И тем не мение, иногда приходится несколько раз нажимать "восстановить".
В любом случае, перед компиляцией визуально проверяю в АОТ произошли ли необходимые изменения элемента.
Считаю, что при переносе не целого слоя а одного элемента компиляцию необходимо проводить на обоих АОСах.
SysFlushAOD отдельно сам никогда не запускал.

[Vadik]

а стремление вести разработку в трехзвенке - оно от любви к экстриму или есть другие причины?

[George Nordic]

У нас в трех-звенке все прексрасно работает. Ну, бывают, конечно, проблемы, когда одинаковые объекты терзает пара программистов. Но и в двухзвенке данные проблемы тоже наблюдались! А вот вести разработку на 2 АОСах.. - это действительно экстрим! Вы часом не на рабочей базе разработки ведете?

С Уважением,
Георгий

[ravil]

Готовлюсь сдавать экзамен по АОС. Если все АОСы остановить, модифицировать в двухзвенке, удалить у всех клиентов файлы кэша, тогда я полагаю проблем не будет.
Но важно знать, как теоретически правильно вносить модификации в кластерном окружении, а не как этого можно достичь практически. Может быть есть варианты без перезапуска АОС, вот что беспокоит. Про меточные файлы я читал однозначное указание на необходимость перезапуска АОС, чтобы изменения вступили в силу. А вот относительно элементов АОТ у меня сомнения. С одной стороны, в документе по версии 2.5 пишут:

One way to update the cache would be to restart the AOS'. However, this would not be a feasible solution, as it would often require multiple users to restart. In certain situations, it is necessary to ship application changes to a running multi-AOS environment, and so a solution is needed.

The AOT contains a class called SysFlushAOD. This class flushes the application objects from the cache on the tier where it is executed. Executing SysFlushAOD on the client will flush the client application object cache, whereas executing the class on the server will flush the shared server application object cache.

To update the servers object cache, follow the procedure below:
1. Create a new Action Menu Item which activates the SysFlushAOD class.
2. Set the menu item's RunOn property to Server.
3. Add the menu item to the Tools\Development menu by adding it to the Menu named DevelopmentTools.

Once changes have been made to the application, it is possible to update the AOS' by connecting to each individual AOS, and activating the menu item. This will cause the server to flush the current application object cache. Some clients might need to be restarted in order to obtain the new, updated application object.

То есть как бы можно вносить изменения не перезапуская АОС. Но на 3.0 sp3 у меня такой фокус не прокатывает. То ли глюк, то ли так и должно быть.

А вот в другом документе читаю: (для какой версии, не указано)

All development must pass the same AOS. This means no 2-tier development and no other AOS running against the same application at the time of modification. Use 3-tier fat client instead of 2-tier when 3-tier thin client is not sufficient for testing or developing.
When Axapta claims that it needs to be restarted in relation to label file creation, note that the AOS needs to be restarted. It is not enough to restart the client.

То есть получается, перезапускать надо все АОСы, кроме того, на котором изменения вносились. А остальные клиенты, которые были подключены к этому АОС, видимо должны перестартовать. А если в ответах такого варианта не будет ...

[savel]

Цитата:

а стремление вести разработку в трехзвенке - оно от любви к экстриму

А причём тут экстримизм? Никаких проблем мешающих разрабатывать не видел.
2George Nordic

Цитата:

Вы часом не на рабочей базе разработки ведете?

Вы наверное не совсем внимательно прочитали....... Разработка идёт на одном АОСе.
При переносе результатов разработки в боевую Аксапту приходится придерживаться вышеописанных правил.

[savel]

Цитата:

а стремление вести разработку в трехзвенке - оно от любви к экстриму

А причём тут экстримизм? Никаких проблем мешающих разрабатывать не видел.
2George Nordic

Цитата:

Вы часом не на рабочей базе разработки ведете?

Вы наверное не совсем внимательно прочитали....... Разработка идёт на одном АОСе.
При переносе результатов разработки в боевую Аксапту приходится придерживаться вышеописанных правил.