daxmusings: ISV Licenses in Packages

[imir]

Ключи это реально овершит.. учитывая что они платные и протухают, хотели позаботиться о защите от взлома/модификации кода, но не такими же методами.. хотя - а какими еще?

Установка на dev-box реально делается через cmd, а для uat и прод, если лень разбираться в конвеерах, есть лайфхак, открываешь обозревателем таблицу SysConfig на devbox (https://****.cloudax.dynamics.com/?m...Name=SysConfig), смотришь там значение и такую же строку создаешь в проде так же через обозреватель или джобом, для ажура, кто чем осилит короче - и весь импорт. Но объяснить клиенту такие пляски конечно непросто)

Если ключ установлен, то протухание сертификата уже не влияет на работу, система смотрит только на запись в SysConfig. Другое дело если лицензия срочная - то при импорте нового ключа сертификат должен быть тоже свежий. Даннеы не грохаются в любом случае.

[mazzy]

Цитата:

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

Даннеы не грохаются в любом случае.

О! У нас остались оптимисты!

https://coub.com/view/1uhbhz

[EVGL]

Цитата:

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

и такую же строку создаешь в проде так же через обозреватель или джобом, для ажура

В xxx.operations.dynamics.com и xxx.sandbox.operations.dynamics.com нет обозревателя. И доступа к Azure SQL тоже.

[imir]

Цитата:

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

В xxx.operations.dynamics.com и xxx.sandbox.operations.dynamics.com нет обозревателя. И доступа к Azure SQL тоже.

Обозреватель есть (на UAT точно), но в ажуре - read only. Универсальнее, наверное, написать свой класс-диалог, куда вбивается значение, взятое с dev-Box и кодом вставлять запись. Эдакий олд-скул импорт без плясок )

По поводу платных-протухающих ключей - МС, кстати, мне кажется, могла бы и сама стать центром сертификации/валидации, а не посылать ISV покупать эти ключи у третих фирм. И выдавать их автоматом при регистрации решения бессрочно. И аннулировать, если решение снято с регистрации автоматом. Но думаю им недосук )

Если лицензия кончается по сроку - вырубается конф-ключ, но вырубание ключей в 365-й не приводит к удалению таблиц или данных. Но это такое - срочные лицензии в основном для триалов.

[Vadik]

Цитата:

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

В xxx.operations.dynamics.com и xxx.sandbox.operations.dynamics.com нет обозревателя. И доступа к Azure SQL тоже.

в sandbox есть JIT

[trud]

Цитата:

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

Если ключ установлен, то протухание сертификата уже не влияет на работу, система смотрит только на запись в SysConfig. Другое дело если лицензия срочная - то при импорте нового ключа сертификат должен быть тоже свежий. Даннеы не грохаются в любом случае.

Он же предлагает его добавить в билд пайплайн, т.е. ключ будет устанавливаться каждый раз при билде. Будет ли он при этом затирать уже имеющееся значение в SysConfig это вопрос, но я думаю что вполне может быть так. Т.е. в 2012 если вы импортили неправильный ключ, то он затирался. Если отключится ключ на рабочей системе то мало не покажется, какие-нибудь ветки алгоритмов могут пойти не туда, не сработать нужные евент хендлеры, если решение как-то завязано на стандартные таблицы, то по сути будет логическая порча данных

[Vadik]

Цитата:

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

Он же предлагает его добавить в билд пайплайн

это нормально. если не нравится, берем шаблонный SDP, добавляем в него лицензию руками, деплоим - вуаля!

Цитата:

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

Чтобы что-то отключилось в продуктиве в D365 теперь надо
а) обновить лицензию в DevOps на "неправильную" в DEV/MAIN/UAT или как там у нас бранчинг настроен
б) смерджить эти изменения в UAT/PRERELEASE/что-у нас-там
в) задеплоить в UAT/PRERELEASE
г) оттестировать все, дать sign off на установку в продуктив и не заметить что целый модуль потерялся

В 2012 достаточно было просто выбрать "неправильный" файл. Оверинжиниринг ? Не думаю

Friends don't let friends right-click publish

[trud]

Цитата:

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

Чтобы что-то отключилось в продуктиве в D365 теперь надо
а) обновить лицензию в DevOps на "неправильную" в DEV/MAIN/UAT или как там у нас бранчинг настроен
б) смерджить эти изменения в UAT/PRERELEASE/что-у нас-там
в) задеплоить в UAT/PRERELEASE
г) оттестировать все, дать sign off на установку в продуктив и не заметить что целый модуль потерялся

Не надо ничего обновлять в этом то и дело. Загрузка лицензии привязана к публичному ключу ISV, который имеет срок действия.
Ну т.е. типичная ситуация - клиент настраивает то что написано в этом блоге, забывает об этом
- Через 1-3 года делается новый билд(допустим с небольшими доработками), он успешно деплоится в UAT/PRERELEASE, тестируется там к примеру 3 дня, делается sign off
- Наступает час Х, когда публичный ключ истекает
- Клиент загружает этот же самый пекедж в PROD, он перезатирает ключ на невалидный(плохой сценарий) или падает(это хороший сценарий). Т.е. это надо проверить как они обрабатывают ошибки в лицензиях

[Vadik]

Цитата:

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

Через 1-3 года делается новый билд..

Я не эксперт в части лицензирования, но должен спросить - эти три года наш сферический ISV находится в анабиозе, не выпускает новых версий (но при этом его решение остается совместимым с One version), не выставляет клиенту инвойсов, не получает оплату и не присылает новых лицензий ?
Если все условия выполнились, то таки да, похоже у клиента могут быть проблемы

P.S. могу добавить что работаю с другими партнерами которые реализуют свои "неклассические" лицензии самостоятельно. Такие варианты тоже есть