|
25.08.2023, 12:02 | #1 |
Участник
|
Если речь про данные, то п.1 делает ядро, правда, глючно. Периодически этот механизм синхронизации кешей аосов ломается и его чинят (аосы периодически пишут данные в SysLastValue - сообщения друг другу о необходимости сброса кеша). Можно другое ядро- неглючное подобрать.
Если класс аксапты кеширует данные, например как с курсами валют то мне больше всего нравится вот это вариант О сломанных шестеренках в большом моторе Если речь об исполнимом коде, то есть способ (первый раз увидел его в сообщении Maximin). После того как проект по живой накатили, запускаем специальную процедуру, она перебирает все аосы, подключается к каждому аосу (запускает клиента аксапты с параметром - имя проекта) и на каждом аосе перебирает узлы проекта и каждый узел компилирует и делает refresh + restore дважды (именно дважды). Это прочищает кеш исполнимого кода аоса. |
|
25.08.2023, 18:22 | #2 |
Участник
|
Цитата:
Сообщение от Logger
После того как проект по живой накатили, запускаем специальную процедуру, она перебирает все аосы, подключается к каждому аосу (запускает клиента аксапты с параметром - имя проекта) и на каждом аосе перебирает узлы проекта и каждый узел компилирует и делает refresh + restore дважды (именно дважды). Это прочищает кеш исполнимого кода аоса.
Ну и "запускает клиента аксапты" я уже видел - при нескольких АОСах это мультипликация на экране пользователя, который это запустил. Уж лучше, если Акса до 2009 включительно, то "втихую" powershell с использованием NET-Connectir. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
25.08.2023, 21:51 | #3 |
Участник
|
Цитата:
У вас работает ? А с 2012-й не прокатывает ? Мы в 12-ке тоже такой подходи применяем, но модифицировали. Вместо компиляции с восстановлением, делаем импорт xpo на каждом аосе. Нужного эффекта достигаем. За исключением вот этой проблемы Ax 2012 R2. Поле "не извлечено" Но мы все неинтерактивные аосы (пакеты, web-сервисы) запускаем с опцией -INTERNAL=NOCURSORREUSE Последний раз редактировалось Logger; 25.08.2023 в 22:02. |
|
28.08.2023, 11:50 | #4 |
Участник
|
Привет.
Хотел выбрать простое и стабильное решение. Сложилось впечатление, что Pipe сюда идеально подходит. Плюсом является нативная возможность его работы в асинхронном режиме. Есть встроенный EventDrillDownPoller, обертка над PipeServer, который можно было слегка переработать для достижения целевого результата. Вопрос остается только в отправке трафика (если бы) - для этих целей, по идее, подходит PipeClient. Соответственно создаём pipeServer, pipeClient - отправляем трафик серверу и...ничего. Читаем документацию по клиенту и поражаемся тем, насколько MS удалось придерживаться концепций "чистого кода": https://learn.microsoft.com/en-us/do...-finops-dotnet) Когда код настолько описывает себя, что даже и документация не нужна. Самое полезное, что было в документации - имя сборки содержащей данный объект "Microsoft.Dynamics.AX.Xpp.Support.dll" (это помогло совершенно в ином вопросе). Ну и не нашел ничего похожего в данной библиотеке, поэтому сделал необоснованный вывод, что PipeClient и PipeServer ничто иное как обертка над System.IO.Pipes.NamedPipeClientStream и System.IO.Pipes.NamedPipeServerStream соответственно. Открываем тоже самое по серверу и видим чуть больше информации: https://learn.microsoft.com/en-us/do...-finops-dotnet Ну и получается, что MS ограничили возможность коммуникации на инкапсулированном от программиста уровне инициализации объекта. Никто не запрещает подключить сборку System.Code.dll и отказаться от использования PipeServer и Client Аксапты в пользу аналогов из .Net и они работают - но речь уже не идёт о простом решении, чистов воды кастомизация. |
|