AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.09.2007, 11:33   #21  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Можешь начать отсюда
Начинать лучше здесь, поскольку обсуждение ведется здесь же.
__________________
полезное на axForum, github, vk, coub.
Старый 06.09.2007, 12:07   #22  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
У меня есть почти все 2.1, 2.5, 3.0, 4.0, 5.0. Вес дистрибутивов около 8Гб. Как передать? Буджешь устанавливать и анализировать?
Скажем так, версии 2.1, 2.5 мне сейчас не очень интересны, их исследование думаю оставить на потом - для "полноты картины". Из перечисленных на axaptapedia и на forum.mazzy.ru версий ядра 3-ки и 4-ки мне не хватает 3.0.1951.8, 3.0.1951.18, 3.0.1951.801, 3.0.1951.3733, 4.0.1659.35, 4.0.1581.0. Соответственно, многомегобайтные дистрибутивы мне не нужны (ну разве что 5.0 ), нужны лишь исполняемые файлы клиентов и серверов (ax32.exe, ax32serv.exe).
Цитата:
Сообщение от mazzy Посмотреть сообщение
Можешь подскажешь способ как можно узнать быстрее?
Я, к сожалению, пока сам в этом не до конца разобрался Собственно, если для 4-ки какой-то способ известен, то для 3-ки еще предстоит понять, как выловить эту internal AOCP revision, поскольку тот же анализ трафика тут мало чем поможет: в отличие от RPC, по AOCP никакой (общедоступной) документации нет.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Ок. Это гипотеза. Хорошая гипотеза. Как проверить?
Пока единственное, что приходит в голову, - это проверить непосредственно работоспособность связок клиентов и АОСов разных версий, полазить в меню, позапускать какие-то формы/классы/job'ы. Еще можно заняться анализом fixlist'ов разных версий - как исправления в ядре могли отразиться на взаимодействии клиента и сервера.
Старый 26.09.2008, 03:20   #23  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Утилита для просмотра версии AOCP/RPC-интерфейса бинарника DAX
Ой, подумать только - прошло уже больше года с тех пор, как всплыла эта тема, уже вышла DAX 2009... Хотелось, конечно, предложить данное решение раньше, но, как говорится, «у меня изменились личные обстоятельства» © х/ф. Впрочем, лучше поздно, чем никогда
Во вложении находится утилита, с помощью которой можно-таки без анализа трафика и ковыряния в бинарниках (это утилита сделает сама ) узнать, какую внутреннюю версию AOCP, если речь идет об Axapta 3, либо версию RPC-интерфейса, если речь идет о DAX4/2009, использует та или иная сборка ядра Аксапты. Для этого достаточно скормить утилите исполняемый файл ядра - AOS, клиент либо один из варинтов Business Connector'а (COM/.Net).

Зачем это нужно
Казалось бы, неписанное правило гласит, что связка клиент-сервер Аксапты всегда должна иметь одинаковый номер сборки, так зачем же ковыряться в каких-то там деталях их взаимодействия?.. Но практика показала, что разные сборки клиента и сервера могут при определенных обстоятельствах прекрасно работать друг с другом, однако, не совсем было ясно, как в общем случае можно подобрать такие пары с разными номерами сборки, чтобы они гарантированно заработали вместе. Совместное использование различных версий ядра системы может иметь смысл при обновлении ядра в условиях, когда новое ядро нужно развернуть на большом числе клиентских машин. В этом случае можно обновить ядро AOS, а затем постепенно обновлять ядро клиентов - при условии, конечно, что клиент старой версии сможет "ужиться" с сервером новой версии. В ходе экспериментов было выяснено, что это зависит от "внутренней ревизии" протокола AOCP (в случае Axapta 3), либо от версии RPC-интерфейса (в случае DAX4 и выше), используемого для взаимодействия клиента и сервера.
Ранее я писал, что, мол, «если верить журналу работы пользователей, AOS получает информацию о точной версии клиента», так вот, это оказалось заблуждением. В журнале работы пользователей, в поле SysUserLog.BuildNum действительно пишется номер сборки ядра, а размещение на соотв. форме этого поля рядом с полем "Тип клиента" может натолкнуть на мысль, что это номер сборки ядра клиента, однако в общем случае это не так. Если посмотреть по перекрестным ссылкам, то можно увидеть, что поля создаваемой записи SysUserLog заполняются не где-нибудь, а непосредственно в табличном методе insert(), при этом значения таких полей, как имя клиентского компьютера и тип клиента, берутся из свойств экземпляра класса xSession, а вот номер сборки ядра - из статического метода класса xInfo::buildNo(), не имеющего явно заданных модификаторов client или server. Дело, напомню, происходит в табличном методе, а табличные переменные в 3-хуровневой конфигурации живут в общем случае на сервере, следовательно, там же будет вызываться и метод xInfo::buildNo(). Стало быть, он в данном случае будет возращать номер сборки ядра сервера, а не клиента, как можно было бы предположить. Собственно, все эти рассуждения легко проверить самостоятельно, запустив в 3-хуровневой конфигурации клиента, чей номер сборки отличается от сервера, - и затем посмотреть, какой именно номер сборки будет записан в журнале работы пользователей для данного подключения.
Итак, с одной стороны, разработчики ядра Аксапты должны были обеспечить надежное взаимодействие клиентской и серверной частей системы, что подразумевает использование ими согласованного протокола взаимодействия, детали которого неизбежно могут изменяться со временем. С другой стороны, на момент подключения сервер не получает от клиента информации о его (клиента) точной версии, включая номер сборки, что было достоверно установлено в ходе анализа сетевого трафика и изучения сервера и клиента методами, о которых отдельно упоминается в лицензионном соглашении. Вместо этого для определения возможности подключения и дальнейшего взаимодействия с тем или иным клиентом сервер полагается на передаваемый им т.н. "внутренний номер ревизии AOCP" (применительно к Axapta3) либо на номер версии RPC-интерфейса (для DAX4 и выше). В последнем случае при запуске сервер указывает подсистеме RPC UUID и версию поддерживаемого им интерфейса; клиент при попытке подключения также указывает UUID RPC-интерфейса сервера приложений и поддерживаемую клиентом версию этого интерфейса. Подсистема RPC сверяет эти данные, и в случае рассогласования версий RPC-интерфейса клиента и сервера попытка клиентского подключения завершается с ошибкой "указанный интерфейс не поддерживается".
Таким образом, чтобы узнать, смогут ли работать вместе произвольные клиент и сервер, достаточно сравнить используемые ими версии AOCP или версии RPC-интерфейсов, в зависимости от того, к какой версии системы относятся эти клиент и сервер.

Вернемся к нашим баранам...
Несколько замечаний по использованию утилиты и ее работе.
  • Утилите кроме названия файла ядра, подлежащего обследованию, можно указать параметр -nosigcheck, отключающий проверку цифровой подписи файла. Проверка цифровой подписи изначально задумывалась для уменьшения возможностей "надурить" утилиту, подсунув ей вместо ядра Аксапты какой-нить левый исполняемый файл, а также для освоения P/Invoke в C# Но потом выяснилось, что некоторые вполне даже "честные" сборки ядра Аксапты почему-то не имеют цифровой подписи - в частности, ядро версии 3.0.1951.17 в полном составе, а также сервер версии 3.0.1951.6710 (KR1).
  • Указав параметр командной строки -debug, можно включить вывод некоторой дополнительной технической информации, в т.ч. в ситуациях, когда определить версию AOCP/RPC не удается.
  • У меня есть почти все сборки ядра Аксапты с 3.0.1951.8 по 5.0.593.0, и можно было бы предположить, что утилита просто смотрит на номер сборки и выдает соответствующую заранее подготовленную информацию, но это не так. В ней реализован "честный" поиск соотв. версии AOCP/RPC, и с выходом новых версий ядра в этом можно будет убедиться.
Вложения
Тип файла: rar dax-aocp-version.rar (14.8 Кб, 83 просмотров)

Последний раз редактировалось gl00mie; 26.09.2008 в 03:24. Причина: typo
За это сообщение автора поблагодарили: mazzy (2), somebody (1), raz (7).
Теги
aos, версии, ax2009, ax3.0

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series Blog bot DAX Blogs 0 06.08.2008 12:05
Upgrade с AX 3.0 SP2 до AX 3.0 SP5 KR2 vallys DAX: Администрирование 14 04.08.2008 11:31
Версия приложение после установки AX 4.0 SP2 FP1 EE IvanOFF DAX: Администрирование 4 04.07.2008 22:45
Arijit Basu: AX 2009 - Quick Overview Blog bot DAX Blogs 4 19.05.2008 14:47
Arijit Basu: Reporting & BI in AX: An Overview [Level 100] Blog bot DAX Blogs 0 07.01.2008 16:01
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:19.