Как стать автором
Обновить
7
0

Пользователь

Вы знаете, обыскал весь LCS портал и не увидел для проектов Dynamics 365 on-premise утилиты Infrastrucure estimator. Оставили только Subscription estimator, куда загружается опросник для клаудных версий.
А Infrastructure estimator вижу только для предыдущей версии AX2012 — это не очень интересно.
Похоже, что для on-premise решений придется руководствоваться только этим гайдом.
Как я уже упоминал, мы не можем управлять сайзингом продуктивной среды, даже если видим неполную утилизацию. Стоимость этих виртуальных машин «включена» в стоимость клиентских лицензий, поэтому смысла менять сайзинг нет.
Вы имеете в виду заявление про то, что мы второй клиент, запустивший клауд, из российских клиентов? Я консультировался в Microsoft, прежде чем публиковать это. А с 2012 мы действительно продолжаем работать, это не секрет.
Если в целом, то проблемы решаем самостоятельно доработками. Именно эту пока еще не решили.
Тестирование на текущий момент делаем вручную.
Обновления регулярно накатываем, и пока процесс нравится. Пользуемся вариантом с объединением package'а обновления с моделью собственных разработок, и единым пакетом деплоим. Тестируем обновленное приложение в SAT environment, затем выкатываем в прод.
Большие ожидания связаны с недавно анонсированной утилитой автоматических регрессионных тестов.
Мониторинг есть. А Вы про какие виртуалки спрашиваете: DevBoxes или продуктивную среду?

Цены только за пользователей.
А результатами оценки сайзинга поделюсь в ближайшее время.

Overlaying больше не работает

Примерно так и делали. Это связано ещё с новой схемой программирования и переноса кастомизаций моделями, хоть модели и были в предыдущих версиях. Например, сначала мы делали разные модели для разных блоков функциональности. Потом пришли к выводу, что проще не множить зависимости между библиотеками (dll), и весь свой код иметь и деплоить одной моделью

Норбит — далеко не единственная консалтинговая компания — партнёр Microsoft, занимающаяся внедрением ERP Microsoft. Но именно клаудную версию D365 мы запустили вторыми.

Прошу прощения, если не совсем точно объяснил. История с чеклистом для клауда работает так, что он не возвращается назад к клиенту, на основании него MS принимает решение, какого масштаба нужна инфраструктура под клиента в облаке, и ее готовит. В итоге мы просто получили по факту тот набор серверов, который я описал.
В случае решения клиента запускать D365 on-premise, насколько я понимаю, этот чек-лист подгружается в утилиту hardware estimator на портале LCS, и клиент получает рекомендации по сайзингу, но решение остаётся окончательно за ним. Кстати, я могу попробовать прогнать наш чек-лист через эту утилиту и поделиться результатом.

Трудности с интеграцией связаны прежде всего с ограничениями стандартного функционала по генерации файлов для интернет-банка по международным и местным платежам, который не позволяет, например, объединять в одну платежку несколько платежей (за несколько инвойсов) с одинаковыми реквизитами, при этом корректно указывая в назначении платежа весь список исходных документов, за которые идет оплата.
Также была чисто техническая проблема с кодировкой создаваемых файлов — D365 генерит их в UFT-8, а интернет банк ожидает только ANSI.
И ещё есть заморочка с факторингом: либо мы не научились его "готовить", либо в немецкой локализации нет этого функционала.

Кстати, MS обещал плагин по работы с персональными данными, если еще не выпустил. Суть плагина состоит в том, чтобы настроенные данные, которые компания считает персональными, сначала складывать на российские сервера, и только потом сохранять в облако Azure. К сожалению, в России датацентров у MS действительно нет.
Облачная версия Dynamics — это чистый SaaS, у клиента нет доступа к продуктивной среде совсем. Даже средств посмотреть сайзинг виртуальных машин нету. Этим управляет вендор на основе показателей производительности и заявленных требований клиента.
Тут нету прямой зависимости между пользователями и нагрузкой. 20 пользователей может нагенерировать достаточно данных для фоновой обработки, как в нашем случае. Если чуть более конкретно, то сайзинг окружения считается, исходя из запускаемых процессов (какая функциональность будет использоваться) и из количества номенклатур, поставщиков, клиентов, количества складских транзакций, количества финансовых транзакций, наличия интеграций и т.д. Это все указывается в опросном шаблоне перед выходом в продакшн.
Если говорить конкретно про 7 наших виртуальных машин, то их роли такие — БД, 4 сервера приложений, 2 сервера отчетности.
Могу ответить про сайзинг виртуальных машин, которые мы используем для разработчиков — это OneVM DevBox в Azure Standard E8 v3 (8 vcpus, 64 GiB memory)
Тут акцент все-таки больше не на инфраструктуру в Германии, а на инфраструктуру как таковую. Даже в России нужно было выделять серверные мощности под виртуальные сервера. Если выделять отдельное железо, то есть риск не утилизировать его полностью. Если использовать виртуализацию на текущем — все равно рано или поздно нужно будет расширяться. Посчитали наши объемы (по сути нагрузку на систему), отправили этот чеклист вендору и получили 7 виртуальных машин только под продакшн. Кроме этого еще приближенный к продуктивному environment для пользовательского тестирования, и чуть более сжатый вариант под сборку приложения. И это все без учета DRP. С учетом небольшого количества пользователей, всего 20 лицензий, вариант с облачным решением подошел идеально.
Конечно, можно. Вот домашняя страница про расширения.
Если вкратце, то для таблицы заказов на покупку нужно создать расширение, добавить в него новое поле (параметр). Дальше все зависит от задачи. Если это отдельная кнопка по пересчету цен, то можно создать свой класс с логикой расчета, для вызова класса создать MenuItem, для формы также сделать Extension, в который положить новый MenuItem. Если есть необходимость вклиниться с новым параметром в существующую логику расчета, то нужно смотреть возможность расширения этих стандартных классов. Можно также сделать делегаты на события, в которые включить нужную логику расчета цен, например, при изменении нашего нового параметра запустить логику расчета цен.
В новой версии Dynamics 365 Microsoft полностью изменил идеологию разработки и кастомизации приложения — теперь все делается через расширения (extensions). При этом расширения доступны далеко не для всех стандартных алгоритмов, что, с одной стороны, добавляет головной боли разработчику, а, с другой стороны, мотивирует подумать над внедряемым процессом и попытаться изменить процесс, а не систему.
Цели вендора тоже понятны — сделать приложения клиентов всегда актуальными с минимальными трудозатратами. Ведь не секрет, что для классической ERP обновление версии зачастую равнозначно новому внедрению.

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность