|
27.02.2023, 11:57 | #1 |
Moderator
|
Я просто напомню, что первый микросервис (MRP) микрософт запустил кажется в 2018ом году. То что у них сейчас сделано закрывает далеко не всю старую функциональность модуля MRP, поэтому клиенты не особо торопятся на него переходить. Кроме того - возможности расширения там весьма ограничены, даже по сравнению с D365FO с отключенным overlayering'ом. Кроме того, не было никаких анонсов о том, как планируется поддерживать новый микросервис для тех, кто купил версию On Premises. Ну и наконец - когда этот микросервис запустили, анонсировалось что он работает в сотни раз быстрее чем старый MRP; После того как туда приделали производственное планирование (по ресурсам) сотни раз сократились до десятков. Не уверен что после покрытия 100% старой функциональности, десятки раз не преврятятся в 200-300%
Кроме того - не понятно, как поддерживать переход на новые версии микросервиса. Для основной версии D365FO сейчас можно заранее установить новую версию и ее эдак месяца 2-3 потестить в Sandbox. Насчет микросервисов были какие-то анонсы, но я не уверен что там реально дают время потестироваться в sandbox... Так что есть шансы, что микросервисы будут работать также как интеграция Ax и CRM (ой простите - D365FO и D365CE). Ее, помнится, первый раз анонсировали в момент выхода Dynamics Ax 4.0, ее уже раз 5 переносили на новую технологическую платформу, а она как была тормозным и нестабильным глюкалом - так и осталась. (Хотя с момента анонса прошло уже 16 лет примерно). P.S. Ну и последний - вполне классический вопрос: Невозможно обеспечить 100% работоспособность любой системы. Соответственно - возникает вопрос, как будет обрабатываться ситуация когда у нас сама Аксапта работает, а микросервисный модуль рассчета налогов, например, на минуту-другую подвис. Будем разносить инвойсы без налогов и потом налоги доначислять ? Или будем вообще разноску инвойсов в аксапте отключать ? А что если у нас таких микросервисов штук 10 и каждый из них в сумме пару минут в день висит? Последний раз редактировалось fed; 27.02.2023 в 12:01. |
|
|
За это сообщение автора поблагодарили: LETTO (1), twilight (1). |
27.02.2023, 16:29 | #2 |
Участник
|
Цитата:
Сообщение от fed
P.S. Ну и последний - вполне классический вопрос: Невозможно обеспечить 100% работоспособность любой системы. Соответственно - возникает вопрос, как будет обрабатываться ситуация когда у нас сама Аксапта работает, а микросервисный модуль рассчета налогов, например, на минуту-другую подвис. Будем разносить инвойсы без налогов и потом налоги доначислять ? Или будем вообще разноску инвойсов в аксапте отключать ? А что если у нас таких микросервисов штук 10 и каждый из них в сумме пару минут в день висит?
|
|
28.02.2023, 09:37 | #3 |
Участник
|
Цитата:
К тоже же сервис можно поднимать на любой системе. Хоть Unix с реал таймом. И писать сервисы можно на любом подходящем языке. Плюс проблема с узким местом - единой БД - уходит. Расширять сервисы - в json предусмотреть вложенную ветку с данными под расширение (стандартное обновление чтоб его не трогало никогда). Для сервисов pre- post- операции. Доп. проверка - в pre-. Доп. разноски в post-. ЗЫ Размечтался я что то... Последний раз редактировалось LETTO; 28.02.2023 в 09:56. |
|
28.02.2023, 10:06 | #4 |
Moderator
|
Люди из веба владеют собственным кодом и могут делать все что им угодно. В ERP кодом частично владеет внедривший партнер и сам клиент, для которых эти сервисы являются черным ящиком, содержимое которого им не известно. Соответственно ЛЮБЫЕ изменения интерфейсов этих черных ящиков - максимально болезненны для всех участников.
В общем - <известный мем с Gustavo Fring из Breaking bad> |
|
28.02.2023, 10:17 | #5 |
Участник
|
Цитата:
Та же пресловутая разноска заказа на продажу. Там контракт и не менялся практически с версии 2.5. Клиент, Договор, Налоги. Строки - номенклатура, кол-во-цена. Все остальные приблуды для стран/клиентов должны идти как расширения к сервису с неизменным базовым контрактом. Последний раз редактировалось LETTO; 28.02.2023 в 10:21. |
|
28.02.2023, 10:29 | #6 |
Moderator
|
Цитата:
Сообщение от LETTO
Да и не должно быть известно. В сервисах есть открытый контракт. Все что внутри - не должен туда лезть никто, кроме владельца. Для клиента должны быть точка расширения. Как в 365 сейчас (но плохо что это расширения в том же монолите). Пусть пишет расширения клиент и сам за них отвечает.
Та же пресловутая разноска заказа на продажу. Там контракт и не менялся практически с версии 2.5. Клиент, Договор, Налоги. Строки - номенклатура, кол-во-цена. Все остальные приблуды для стран/клиентов должны идти как расширения к сервису с неизменным базовым контрактом. Теперь представим себе расширение облачного MRP. Допустим мне, по требованиям бизнеса, нужно приделать расширение, которое при сопоставлении чистых потребностей проверяет - подходит ли этот плановый приход к этому плановому расходу по каким-то дополнительным требованиям (специфичным для клиента). Это значит, после поиска каждого кандидата на сопоставление, микросервис должен вызвать другой микросервис (уже не микрософтом, а мной написаный). И это потребует 2 секунды. Типичное число чистых потребностей для при планировании (для средней руки производственного предприятия) - это где-то 100-200K. Множим 2*150000 = 300000 секунд, то есть - порядка 85 часов на одну сессию планирования. В старом X++овском коде времен DAX2012 обработка этой дополнительной проверки занимала порядка 50-100ms (пара запросов в БД + еще какая-то логика) и планирование для всех этих 200000 чистых потребностей отрабатывало в параллельном режиме часа за 2-3. |
|
28.02.2023, 10:33 | #7 |
Участник
|
Цитата:
Сообщение от fed
У нас сейчас на реальном проекте настроена синхронизация (штатными средствами) таблицы клиентов в D365FO и D365CE. Если поменять ОДНО синхронизируемое поле, то синхронизация через стандартный веб-сервис требует примерно 2 секунд. (Юзеры жалуются в общем). Если какая-то из компонент системы холодная - синхронизация может до 7-8 секунд длиться.
Амазон миллионы пользователей и поставщиков обслуживает по всему миру. Думаете они бы могли это сделать, если бы у них сервисы отвечали по 2 секунды? Сервисы яндекса те же. Они ж мгновенно отвечают. а не через 2 часа. Не думаю что у них там под капотом проще расчеты, чем расчет потребностей. Наглость Майкрософт оттого, что выбора особо не было до определенного времени. Раньше виндовс правил. Но теперь правит веб. Да и опенсоурс силы набрал. Стыдно как то уже на таких примитивных вещах шишки набивать. Но Майкрософт с грацией слона продолжает это делать снова и снова. Последний раз редактировалось LETTO; 28.02.2023 в 11:05. |
|
28.02.2023, 10:36 | #8 |
Участник
|
Цитата:
У меня по работе часто запросы - "форма медленно открывается". Смотришь - а там такой стандартный код, что кулаки сжимаются. А вы про планирование.... Если бы я писал ЕРП я бы не брал НИКАКИЕ продукты от майкрософт. только Юникс и только опенсоурсы. А они сейчас оооочень хороши. Последний раз редактировалось LETTO; 28.02.2023 в 10:40. |
|
28.02.2023, 11:31 | #9 |
Аманд
|
Ни одна из соображающих компаний не будет использовать опенсорсы по многим соображениям, в том числе из-за безопасности и лицензионной политики. А если использует, то сопровождение кода также стоит нормальных денег на специализированный софт и людей.
__________________
- Видеобиблиотека Dynamics AX на YouTube . - наше отраслевое решение для Портов, Судовладельцев, Контейнерных терминалов и Транспортных компаний - Checkmarx - аудит исходного кода программ на безопасность Dynamics AX внедрение ERP и BI Последний раз редактировалось Vals; 28.02.2023 в 11:45. |
|
28.02.2023, 12:14 | #10 |
Moderator
|
Цитата:
Сообщение от LETTO
Да вот это и бесит. Коллеги уже в биг дата с дата сайенс миллионы обработок в секунду, а мы с этим майкрософт не можем нормально простейшую операцию выполнить в приемлимое время.
У меня по работе часто запросы - "форма медленно открывается". Смотришь - а там такой стандартный код, что кулаки сжимаются. А вы про планирование.... Это естественное ограничение бизнес-задачи, которое никакими opensource и unix не преодолеть... |
|
28.02.2023, 10:55 | #11 |
Участник
|
Цитата:
Проектировать надо нормально. Зачем на каждый чих вызывать сервис, если, например, сразу можно все данные забрать за 10ms. |
|
|
|