AX 2012. Стратегии установки плагина для AX.

[saygon]

Всем привет.
Исходная задача:
Разрабатываем плагин для AX 2012, к-ый подменяет некоторую функциональность системы (подсчёт надога - sales tax) для некоторого типа транзакций.
Плагин состоит из изменений в X++ коде и .Net библиотек с исходным кодом (основная бизнес логика и взаимодействие с третьесторонними веб-сервисами). Код на X++ используют классы с .Net сборок. X++ кастомизация ложится в модель, модель в проект, и импортируется проект в .axmodel файл. Итого имеем .net сборки и axmodel файл.
Плагин будет поставляться разным клиентам (т.е. установка должна быть как можно более универсальной и простой).

Не могли ли бы Вы подсказать возможные стратегии установки плагина, а также их недостатки и преимущества. Исправления и добавления приветствуются. На данный момент я вижу две стратегии (на данный момент используется первая):

1. При установке сначала в AOT импортятся (добавляются в AOT References) .net библиотеки, к-е лежат отдельно, затем импортится axmodel файл с X++ кастомизацией и AX компилится.
Недостатки - для добавление в AOT References возможно потребуется developer license, к-ой у клиента может не быть.

2. Исходный код .net сборок добавляется в AOT, и при импорте model->AX project-> .axmodel файл, туда мы добавляем.net проекты. Итого мы имеем единственный .axmodel файл, к-ый импортируется клиентом в AOT, AX компилируется как и на предыдущем шаге.
По сравнению с предыдущим методом, мы можем полность импортить axmodel файл без developer license (исользую только AXutil.exe).
Недостатки Клиент получает сходный код .net сборок (небольшая проблема на самом деле) + размер axmodel файла, к-ый включает и исходники и бинарники, может быть довольно большим.

Какие способы ещё есть (универсальные - подходящие для разных клиентов и без developer license)?

[plumbum]

Добрый день, saygon

А зачем Вам именно проекты добалять в дерево? Добавьте ссылки (AOT\References) на нужные библиотеки!

.NET сборки еще надо будет зарегистрировать на машине AOSа, насколько я понимаю, иначе Reference на них из AOT выдаст ошибку.
Может есть смысл написать Setup Project для .NET, который бы прописывал библиотеки и в заключении вызывал axUtil из коммандной строки, тогда имортировалась бы ваша модель с последующей компиляцией.

[saygon]

Здраствуйте, plumbum.

1. "А зачем Вам именно проекты добалять в дерево? Добавьте ссылки (AOT\References) на нужные библиотеки!" - Первый метод это и подразумевает (добавление в AOT\References). Но для того чтобы добавить cборки туда, нужно открыть среду разработки, а среда разработки доступна только если у кастомера есть дев лицензия (к-ой может и не быть).

2. "NET сборки еще надо будет зарегистрировать на машине AOSа, насколько я понимаю, иначе Reference на них из AOT выдаст ошибку." - да, это я не описал). Тут 2 варианта (регистрировать в GAC при установке, или ложить в папку клиента AX на сервере (у меня это C:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin) чтобы AX нормально заимпортил). С этим вроде бы всё понятно, я для простоты это опустил.

3. "Может есть смысл написать Setup Project для .NET, который бы прописывал библиотеки и в заключении вызывал axUtil из коммандной строки, тогда имортировалась бы ваша модель с последующей компиляцией." . Рассматривается способ 1, я так понимаю? (т.к. для способа 2 регистрировать dll не требуется - они и так в исходниках в импортируемом файле лежат).
Как я понял последовательность следующая:
1. Регистрация dll в GAС-e
2. Добавление их в References
3. Импорт модели, компиляция.

У меня вопрос - есть ли средства в AX для автоматического добавления сборок в References?
Потому как если этот шаг делается вручную, то и все дальнешие шаги (импорт модели, компиляция) тоже необходимо вручную делать.

[plumbum]

Цитата:

Сообщение от saygon

Здраствуйте, plumbum.
У меня вопрос - есть ли средства в AX для автоматического добавления сборок в References?
Потому как если этот шаг делается вручную, то и все дальнешие шаги (импорт модели, компиляция) тоже необходимо вручную делать.

Ну а если эти сборки в Вашей модели? Вы созадли при разработке проект, куда включили все объекты и ссылки (References), эти ссылки и объекты вы добавили в Вашу модель.

Вы можете потом сразу всю модель залить через axUtil, а на вызов этой утилиты права у администратора, устанавливающего плагин, должны быть. Данный способ развертывания не предусматривает открытия окна клиента. Потом надо будет с помощью этой же утилиты прокомпилировать дерево.

[saygon]

Спасибо за быстрый ответ.

Вы имеете ввиду добавить Reference на сборку, добавить её в модель и при импорте модели акс включит саму сборку (бинарник) в импортируемый текстовый файл?
Только что добавил NLog.dll в References, добавил её в модель и импортнул - в .axmodel файле метаинформация о этой сборке, но без бинарников сборки.

Или же Вы подразумеваете другой сценарий: добавление в Reference в моём дев окружении -> импорт в модель -> установка на сервере клиента этой модели + установка в GAC моих сборок. И сборки будут доступны по Referenc-aм, т.к они есть в GAC-е?

[plumbum]

Цитата:

Или же Вы подразумеваете другой сценарий: добавление в Reference в моём дев окружении -> импорт в модель -> установка на сервере клиента этой модели + установка в GAC моих сборок. И сборки будут доступны по Referenc-aм, т.к они есть в GAC-е?

Именно, не нужно держать сборки в AOT, сразу в GAC их

[saygon]

Как круто Вы со сборками-то

Супер, спасибо.

И последний вопрос - будут ли клиентские машины автоматом загружать сборки с сервера?
Т.е. посоле установки плагина на сервере, при перезапуске клиентской части, клиент будет видеть что есть новая сборка - он будет эту сборку тянуть в Common\..\VsAsemblies\ с GAC-a напрямую, или через серверную директорию bin? Потому как есть некоторая вероятность того, что сборки на клиентской части AX-а потребуется, и этот момент для меня пока не ясен - будет ли он нормально всё стягивать с сервера в Вашем варианте?

[plumbum]

Цитата:

И последний вопрос - будут ли клиентские машины автоматом загружать сборки с сервера?

А вот тут не все так просто
По идее клиенты не имеют доступа в GAC сервера. Это легко проверить: если на клиентской машине открыть среду разработки, то сборки не будут компилироваться. Такая проблема обычно решается установкой сборок на терминальном сервере, к которому коннектиться клиент (если конечно используется терминальный сервер)

[belugin]

Теоретически можно использовать SysFileDeployer но тогда надо клиенту давать права на добавление файлов рядом с бинарниками аксаптовского клиента.

Я бы поискал способы вне Dynamics Ax типа всяких политик Active Directory - хороший админ должен знать несколько таких инструментов.

[saygon]

"По идее клиенты не имеют доступа в GAC сервера. Это легко проверить: если на клиентской машине открыть среду разработки, то сборки не будут компилироваться. Такая проблема обычно решается установкой сборок на терминальном сервере, к которому коннектиться клиент (если конечно используется терминальный сервер)".

В этом и проблема в использовании GAC. Как я понял из нескольких источников, и в частности отсюда , можно положить dll в Server\bin\ и каким либо способом добавить их в References (вручную или импорт модели с Referenc-ами). И когда какой-либо клиент коннектиться к серверу, он видит новые сборки и копирует их с server\bib себе в %Common%\...\VsAssemblies\ - и сборки доступны к использованию! Проверил - да, при рестарте клиента он копирует сборки в локальную папку юзера. Вот поэтому пока планируем ложить сборки в bin\server - для доступности в случае необходимости на клиенте. Доступность сборок с GAC-а сервера под вопросом.

"терминальном сервере" - не уверен, что понял Вас в контексте AX - мы используем AX сервер и устанавливаем AX клиент на машинах юзеров. Вы имеете ввиду сервер и клиент на одной машине, к к-ому юзеры коннектятся по какому-либо протоколу (RDP, etc.)? Такого способа использования Акса мы не планируем .

SysFileDeployer - посмотрю, спасибо, хотя выставления разрешений пока настораживает.
политики Active Directory - хотелось бы использовать внутренние способы разворачивания сборок в AX-е, раз уж они есть и покрывают потребности, и вроде бы - так здорово упрощается установка, в случае с Active Directory необходимы дополнительные шаги и возникает возможность потенциальных ошибок при установке, связанных с политиками безопасностями, настройками сети, и т.д.

Спасибо за ответы plumbum и belugin. По сравнению с забугорными форумами, коммьюнити с этого оказалось наиболее отзывчивым и полезным.

[plumbum]

Цитата:

"терминальном сервере" - не уверен, что понял Вас в контексте AX - мы используем AX сервер и устанавливаем AX клиент на машинах юзеров. Вы имеете ввиду сервер и клиент на одной машине, к к-ому юзеры коннектятся по какому-либо протоколу (RDP, etc.)? Такого способа использования Акса мы не планируем .

Да, именно RDP (ну или через Citrix), таким образом удобно работать с GAC. Не обязательно делать AOS терминальным сервером, лучше настроить один - два терминальных сервера отдельно, установить на них клиета, оффис и все такое, а юзерам давать возможность подключаться к нему. ИМХО намного дешевле и надежнее выходит

Цитата:

Спасибо за ответы plumbum и belugin. По сравнению с забугорными форумами, коммьюнити с этого оказалось наиболее отзывчивым и полезным.

даже буржуи признают этот форум лучшим по AX

[saygon]

Цитата:

Да, именно RDP (ну или через Citrix), таким образом удобно работать с GAC. Не обязательно делать AOS терминальным сервером, лучше настроить один - два терминальных сервера отдельно, установить на них клиета, оффис и все такое, а юзерам давать возможность подключаться к нему. ИМХО намного дешевле и надежнее выходит

Может быть. Просто у нас должен получиться универсальный плагин, к-ый должен работать на большинстве конфигураций. Дефолтная конфигурация для Акса, как я знаю- сервер и клиентские машины с установленным клиентским Аксом. Первый способ будет по идее с обеими конфигурациями работать (сервер+клиенты / терминальный сервер).

Пока будем ориентироваться на метод - dll-ки в server\bin папке на сервере и импорт References из модели (клиенты AX-a скачивают данные сборки при первом логиине автоматически), т.к. минимум лишних действий + поддержка AX-ом данного метода. С возможной регисрацией сборок в GAC-е надо будет поиграться как-нибудь, посмотреть, как клиент Аксовский реагирует. О результатах надеюсь не забыть отписаться.

Всем спасибо за полезные ответы.

[macklakov]

Цитата:

Сообщение от saygon

клиентские машины автоматом загружать сборки с сервера?

А этот плагин точно нужен на клиентских машинах? Налог, по идее, AOS должен считать. Он пусть и пользует сборки. А пользователь к AOS пусть чем хочет, тем и прицепляется. Вдруг пользователь не захочет/не сможет стандартный клиент ставить? А захочет через тот же EP налоги себе посчитать...

[saygon]

Да, всё верно, налог должен и будет считаться на сервере. Но у нас будет AX форма с настройками плагина, и там нужна будет валидация данных средствами сборок. Поправьте меня, если я ошибаюсь, но для использования .net сборок в коде форм нам нужна сборка на клиенте.
Хотя это можно обойти вызвовом серверного X++ кода, к-ый и вызывает код со сборки.

Кстати, по поводу ответа plumbum:

Цитата:

А вот тут не все так просто
По идее клиенты не имеют доступа в GAC сервера. Это легко проверить: если на клиентской машине открыть среду разработки, то сборки не будут компилироваться. Такая проблема обычно решается установкой сборок на терминальном сервере, к которому коннектиться клиент (если конечно используется терминальный сервер)

Вот нашёл пост, когда человек загружает сборки на клиент с GAC-а. Но у него проблема с тем, что одна сборка с GAC -а сервер на клиент загружается, другая - нет.

[fed]

Извиняюсь за неуместное любопытство, но мне страшно интересно - зачем считать налог в Net-библиотеках ? Ну то есть -налоги обычно по простым формулам считаются, какой-то сложной арифметики и очень больших объемов памяти для налогов - тоже не надо. Вроде бы встроенной в Аксапту логики рассчета налогов (возможно с небольшими дополнениями) должно хватать по производительности.
Может это какой-то странный региональный налог для странных налоговых юрисдикций ?
Я вот слышал, что в Бразилии есть что-то типа счетов-фактур, и прежде чем ее напечатать ты через какой-то странный API (web-сервис вероятно) должен зарегистрировать эту фактуру и получить ее номер. Таким образом государство отслеживает все товародвижения ( по крайней мере - по суммам и группам товаров). Может это что-то похожее ?

[saygon]

Не стоит извиняться, любопытство - хорошая штука .

1. Это налог (sales tax) для Штатов. Там куча всяких налогов чуть-ли ни у каждого городка (+штат, округ, и .т.д.). Ставки для этих налогов очень часто обновляются (кроме того, существуют разные временные налоги по конктретным типам товаров - к примеру, допустим детское питание в штате Иллинойс с 1 января по 1 декабря облагается не 2% а 5% налогом, и т.д.). Для того чтобы нормально отслеживать эти изменения нужно отдельный штат, к-ый будет смотреть за этими изменениями и вносить в систему. Наш заказчик за деньги предоставляет веб-сервис, к-ый это всё считает и возвращает на основание всех данных сумму налога.

2. На клиенте должны присутствовать некая функциональность (валидация, разные бизнес правила, взаимодействие с сервером), к-ые у нас есть в виде .net сборок. По моему опыту c X++, реализовать это на X++ - долгое и муторное дело. Поэтому интеграция на X++, оттуда - вызов .net сборок -> вызов сервисов.

[belugin]

Если сами сборки не содержат особого ноухау (они ж не работают без вебсервиса), почему бы их не положить в АОТ? Тем более, что X++ отвергнут потому, что муторно, а не потому, что открыты исходники. Это и есть сейчас рекомендованный способ интеграции внешних сервисов - обертка на С# в AOT

А еще интересно насколько широко и глубоко вы интегрируетесь в AX - есть же куча мест где налоги рассчитываются в разных комбинациях и используются

[saygon]

Цитата:

Если сами сборки не содержат особого ноухау (они ж не работают без вебсервиса), почему бы их не положить в АОТ? Тем более, что X++ отвергнут потому, что муторно, а не потому, что открыты исходники. Это и есть сейчас рекомендованный способ интеграции внешних сервисов - обертка на С# в AOT

.
Тут всё от заказчика зависит - согласится ли поставлять исходники .net сборок клиенту - мало ли, вдруг не захочет. Данный способ рассматривался нами (см. второй способ в самом верху), может быть его и будем использовать.

Цитата:

А еще интересно насколько широко и глубоко вы интегрируетесь в AX - есть же куча мест где налоги рассчитываются в разных комбинациях и используются

Мы интегрируемся с некоторыми типами транзакций (не со всеми) - Sales Orders, Quotes, etc. Неподдерживаемые типы транзакций мы отдаём на откуп стандартному механизму. По по поводу способов подсчёта налога - мы выбрали настройки tax кода (там и указывается способ подсчёта налога) к-ые мы можем в эффективной мере поддерживать и всегда возвращаем их когда AX достаёт такс коды для продукта, если транзакция нужного нам типа. Соответственно, интегрируемся в стандартные классы там, где этот метод подсчёта такса используется и подменяем его поведение для определённого типа транзакций. Все остальные специфичные настройки (исключения для налога, и т.д.) клиенты производят на стороне заказчика.

[belugin]

Я сам так не пробовал, но теоретически можно запихать скомпиленную DLL куда-нибудь в ресурсы проекта и кастомной командой копировать ее при сборке проекта в target. То есть, чтобы "компилятором" была соманда copy

[saygon]

1. Спасибо belugin за совет, но если есть уже готовые пути поставлять .net либы, то использовать воркэраунды не есть хорошо как по мне. Но за подсказку спасибо конечно, такой вариант я даже не рассматривал, буду знать.

2. Что в итоге получилось (юзал способ от plumbum-а):
Есть инсталлер, к-ый ложит подписанные .net сборки в GAC (References на эти сборки лежат в модели). Инсталлер ложит файл с моделью куда-то в папку. Админ должен зайти туда, скопировать путь к файлу и с помощью axutil импортнуть модели. Будет делать это вручную, т.к. на этапе импорта нужно потверждение в консоли набрать и возможные ошибки/конфликты пишутся в консоль - админ должен это всё видеть. Затем всё стандартно - админ перезапускает AOS, компилирует X++, компилирует в CIL - в общем, идёт по чеклисту или выбирает Compile&Synchronize, к-ый высвечивается после импорта модели и перезапускa AOS . На чистой ВМ проверял - вроде всё работает.

Ещё раз всем спасибо за советы - они мне очень помогли. Если у кого-то есть какие-то вопросы или трудности с этой темой - помогу чем смогу .