[Вопрос:]Внедрение Axapta 3.0, полученной по параллельному импорту

[Удвой Покуров]

Цитата:

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

P.S. Ну и последний - вполне классический вопрос: Невозможно обеспечить 100% работоспособность любой системы. Соответственно - возникает вопрос, как будет обрабатываться ситуация когда у нас сама Аксапта работает, а микросервисный модуль рассчета налогов, например, на минуту-другую подвис. Будем разносить инвойсы без налогов и потом налоги доначислять ? Или будем вообще разноску инвойсов в аксапте отключать ? А что если у нас таких микросервисов штук 10 и каждый из них в сумме пару минут в день висит?

Кстати, в Технониколе это как раз решили. Кстати, поверх 1С. При масштабировании у них все начало дико тормозить, и они "расшивали" узкие места путем микросервисов, начала с сервиса расчета спецификации, ускорили в 100 раз по сравнению со штатным. Потом еще один сервис написали, потом еще... в итоге получилось наполовину 1С, наполовину - сборник из сотен микросервисов, причем написанных на разных языках программирования. И это как-то живет и поддерживается. Если падает - ищут причину, чинят и думают как сделать так чтобы не повторилось.

[sukhanchik]

Цитата:

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

Ну чисто в рамках интеллектуальной разминки.
Модели в 365 вообще муть какая то не понятная. Скорей для разработчиков, а не для функционала. Хотят может я такой "не проникся"

А здесь надо рассматривать деление с разных сторон, но всегда с позиции MS (если что - всё описанное ниже - это чисто мои предположения).
1. Маркетинг. Чем больше модулей - тем больше видна масштабность системы. Поэтому часть пунктов меню выпилили в отдельные модули (например, Консолидация или Налог)
2. Каждое новое приобретение (сам MS глобально функционал не пишет, а приобретает у партнеров) - это новый модуль. Так технически проще его встроить в систему. Поэтому Управление активами и Аренда актива - это разные модули, а фукнкционал госсектора (Public sector) - хоть и не выделен в меню явно, но технически выделен в отдельный модуль. Тоже самое касается разделения модуля Управление персоналом и Зарплата (которую обещали вырезать)
3. Рабочие места (Workspaces) - это те формы, в которых в основном люди должны работать. Плюс есть поиск по меню. Следовательно - какая разница в какой модуль запихнёт разработчик свой пункт меню?
4. Какие-то блоки, которые можно попытаться отдельно продать (вспомним историю с HRM) - удобно вынести в отдельный модуль как с маркетинговой т.з., так и с технической.
5. Технически удобно, если все доработки партнёров / клиентов будут в их собственных единых модулях
6. Инсталляция модулей сторонних разработчиков должна проходить быстро и легко. Чем больше будет сторонних разработчиков - тем лучше будет держаться "на плаву" система в целом.

Другое дело, что конечным пользователям / консультантам деление неудобно. Но... когда MS думал о них )

[axm2017]

Цитата:

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

А здесь надо рассматривать деление с разных сторон, но всегда с позиции MS (если что - всё описанное ниже - это чисто мои предположения).

Тут надо помнить что в MS в силе облачные инженеры которые и слыхом не слыхивали о каких то Ax. Поэтому решают вопросы чисто инженерно и в духе времени. Единственное что останавливает их - большая история и накопленная масса кода с которой крайне сложно уйти.
Но время работает на них: разрабы на X++ в целом исчезающий вид и если не считать поддержки масса народа в российском MS занималась уже клепанием сервисов либо перехода на них (другой вопрос что кривенько и косенько но это как обычно).

[twilight]

Цитата:

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

Какая из 1С? Бухгалтерия, Управление торговлей, ЗиК/ЗУП, УПП, Консолидация или ERP?

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

[LETTO]

Цитата:

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

А что если у нас таких микросервисов штук 10 и каждый из них в сумме пару минут в день висит?

Коллеги из веба давно уже все придумали. Там сотни тысяч запросов обрабатываются в секунду. Асинхронное обслуживание, логирование. Уж думаю с разноской каких то заказов справились бы сервисы. По сути несколько параллельных запросов в сервис ГК, склад, налоги, ОС. Сами заявки отправляются мгновенно. Ответ приходит в течении 10-20 миллисекунд (но даже это не надо ждать - всё асинхронно). Плюс сервисы масштабироваться легко могут. Много накладных - быстро поднимаем доп. сервисы. Красота же. А не этот ужас - на пустой базе система зависает на 1-3 секунды с одной строкой в заказе.

К тоже же сервис можно поднимать на любой системе. Хоть Unix с реал таймом. И писать сервисы можно на любом подходящем языке. Плюс проблема с узким местом - единой БД - уходит.

Расширять сервисы - в json предусмотреть вложенную ветку с данными под расширение (стандартное обновление чтоб его не трогало никогда). Для сервисов pre- post- операции. Доп. проверка - в pre-. Доп. разноски в post-.

ЗЫ Размечтался я что то...

[fed]

Цитата:

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

Коллеги из веба давно уже все придумали.

Люди из веба владеют собственным кодом и могут делать все что им угодно. В ERP кодом частично владеет внедривший партнер и сам клиент, для которых эти сервисы являются черным ящиком, содержимое которого им не известно. Соответственно ЛЮБЫЕ изменения интерфейсов этих черных ящиков - максимально болезненны для всех участников.
В общем - <известный мем с Gustavo Fring из Breaking bad>

[LETTO]

Цитата:

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

В ERP кодом частично владеет внедривший партнер и сам клиент, для которых эти сервисы являются черным ящиком, содержимое которого им не известно.

Да и не должно быть известно. В сервисах есть открытый контракт. Все что внутри - не должен туда лезть никто, кроме владельца. Для клиента должны быть точка расширения. Как в 365 сейчас (но плохо что это расширения в том же монолите). Пусть пишет расширения клиент и сам за них отвечает.

Та же пресловутая разноска заказа на продажу. Там контракт и не менялся практически с версии 2.5. Клиент, Договор, Налоги. Строки - номенклатура, кол-во-цена. Все остальные приблуды для стран/клиентов должны идти как расширения к сервису с неизменным базовым контрактом.

[LETTO]

Отчеты те же. В Аксапте сложный отчет вешают всю систему. В парадигме сервисов - это просто параллельный асинхронный запрос к сервисам, которые для отчета можно поднять дополнительно в любом количестве. И обращаться они должны не к базе сервиса, а к своей копии базы с режимом только для чтения. Как собственно BI сейчас делает в Аксапте.

[fed]

Цитата:

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

Да и не должно быть известно. В сервисах есть открытый контракт. Все что внутри - не должен туда лезть никто, кроме владельца. Для клиента должны быть точка расширения. Как в 365 сейчас (но плохо что это расширения в том же монолите). Пусть пишет расширения клиент и сам за них отвечает.

Та же пресловутая разноска заказа на продажу. Там контракт и не менялся практически с версии 2.5. Клиент, Договор, Налоги. Строки - номенклатура, кол-во-цена. Все остальные приблуды для стран/клиентов должны идти как расширения к сервису с неизменным базовым контрактом.

У нас сейчас на реальном проекте настроена синхронизация (штатными средствами) таблицы клиентов в D365FO и D365CE. Если поменять ОДНО синхронизируемое поле, то синхронизация через стандартный веб-сервис требует примерно 2 секунд. (Юзеры жалуются в общем). Если какая-то из компонент системы холодная - синхронизация может до 7-8 секунд длиться.

Теперь представим себе расширение облачного MRP. Допустим мне, по требованиям бизнеса, нужно приделать расширение, которое при сопоставлении чистых потребностей проверяет - подходит ли этот плановый приход к этому плановому расходу по каким-то дополнительным требованиям (специфичным для клиента). Это значит, после поиска каждого кандидата на сопоставление, микросервис должен вызвать другой микросервис (уже не микрософтом, а мной написаный). И это потребует 2 секунды. Типичное число чистых потребностей для при планировании (для средней руки производственного предприятия) - это где-то 100-200K. Множим 2*150000 = 300000 секунд, то есть - порядка 85 часов на одну сессию планирования. В старом X++овском коде времен DAX2012 обработка этой дополнительной проверки занимала порядка 50-100ms (пара запросов в БД + еще какая-то логика) и планирование для всех этих 200000 чистых потребностей отрабатывало в параллельном режиме часа за 2-3.

[LETTO]

Цитата:

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

У нас сейчас на реальном проекте настроена синхронизация (штатными средствами) таблицы клиентов в D365FO и D365CE. Если поменять ОДНО синхронизируемое поле, то синхронизация через стандартный веб-сервис требует примерно 2 секунд. (Юзеры жалуются в общем). Если какая-то из компонент системы холодная - синхронизация может до 7-8 секунд длиться.

Это говорит только о кривости кода Майкрософт. Вечная история в общем. Майкрософт вообще нельзя брать за отправную точку в айти технологиях.
Амазон миллионы пользователей и поставщиков обслуживает по всему миру. Думаете они бы могли это сделать, если бы у них сервисы отвечали по 2 секунды?

Сервисы яндекса те же. Они ж мгновенно отвечают. а не через 2 часа. Не думаю что у них там под капотом проще расчеты, чем расчет потребностей.
Наглость Майкрософт оттого, что выбора особо не было до определенного времени. Раньше виндовс правил. Но теперь правит веб. Да и опенсоурс силы набрал. Стыдно как то уже на таких примитивных вещах шишки набивать. Но Майкрософт с грацией слона продолжает это делать снова и снова.

[LETTO]

Цитата:

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

Типичное число чистых потребностей для при планировании (для средней руки производственного предприятия) - это где-то 100-200K. Множим 2*150000 = 300000 секунд, то есть - порядка 85 часов на одну сессию планирования.

Да вот это и бесит. Коллеги уже в биг дата с дата сайенс миллионы обработок в секунду, а мы с этим майкрософт не можем нормально простейшую операцию выполнить в приемлимое время.
У меня по работе часто запросы - "форма медленно открывается". Смотришь - а там такой стандартный код, что кулаки сжимаются. А вы про планирование....

Если бы я писал ЕРП я бы не брал НИКАКИЕ продукты от майкрософт. только Юникс и только опенсоурсы. А они сейчас оооочень хороши.

[LETTO]

Цитата:

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

это где-то 100-200K. Множим 2*150000 = 300000 секунд, то есть - порядка 85 часов на одну сессию планирования.

Я не настолько силен в планировании. Что именно там происходит. Но вы ж понимаете, что такое время просто не нормально для современных технологий. Такого не должно быть просто.

Цитата:

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

Это значит, после поиска каждого кандидата на сопоставление, микросервис должен вызвать другой микросервис (уже не микрософтом, а мной написаный). И это потребует 2 секунды.

Проектировать надо нормально. Зачем на каждый чих вызывать сервис, если, например, сразу можно все данные забрать за 10ms.

[Vals]

Цитата:

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

только опенсоурсы. А они сейчас оооочень хороши.

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

[LETTO]

Цитата:

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

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

Может я что то не понимаю. Кучу народу пишет на этих системах. Где они все работают, если никто не использует опен соурс? Весь веб на оперсоурсе.

Цитата:

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

А если использует, то сопровождение кода также стоит нормальных денег на специализированный софт и людей.

Почему специализированных? Сейчас спецов по этих технологиям как раз таки массы. Обычные джависты в основном. Вчера вот про Кафку читал. В куче контор используют. Я уж молчу про юниксы и sql всякие.
Таки Аксапта это специализированная. Оперсоурсы проекты у всех на виду и они известны. Написаны на общеизвестных языках и имеют хорошую документацию.

Заявление директора по распространению технологий Яндекса Григория Бакунова, которое отражает позицию всей компании.
Таким же предметом общей гордости российского опенсорс-сообщества является Nginx — проект Игоря Сысоева. Сегодня Nginx используется более чем на тридцати процентах веб-страниц и почти во всех крупных интернет-компаниях.

[fed]

Цитата:

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

Да вот это и бесит. Коллеги уже в биг дата с дата сайенс миллионы обработок в секунду, а мы с этим майкрософт не можем нормально простейшую операцию выполнить в приемлимое время.
У меня по работе часто запросы - "форма медленно открывается". Смотришь - а там такой стандартный код, что кулаки сжимаются. А вы про планирование....

Биг дата в общем и в целом оперирует отчетностью. Просто в режиме read-only читается большой объем данных (причем обработка, скорее всего, по самой сути задачи хорошо распараллеливается). В сводном планировании идет планирование конкуренции за ресурсы (складские запасы и рабочие ресурсы). Обсчет очередного шага решения не может, в общем случае, быть распараллелен, потому что иначе может оказаться что у нас два производственных заказа решили один и тот же рабочий центр использовать или один и тот же запас номенклатуры. При этом выхода только два - либо просто в явном виде блокировать все ресурсы взятые в рассчет варианта (конфликтов точно нет, но параллелизм так себе), либо просчитывать, грубо говоря, оба производственных заказа, а потом в конце один из рассчетов откатывать, потому что ресурсы ушли под тот заказ, который раньше закончили обсчитывать. (А это означает неэффективное использование вычислительных ресурсов).
Это естественное ограничение бизнес-задачи, которое никакими opensource и unix не преодолеть...

[Удвой Покуров]

Цитата:

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

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

Вот тут ты не прав, Валер. Много Opensourse ERP есть и используется. Даже в топовые рейтинги попадает - хотя многие исследования игнорируют решения с открытым исходным кодом, потому что не могут правильно оценть устойчивость (выручка за лиценззи = 0) и ability to execute. Пожалуй, Oddo - самая популярная и распространенная на данный момент. Комьюнити, локализация, куча партнерских решений и расширений. Даже в рейтинги попадает. Компания-разработчик зарабатывает на платной поддержке.

[LETTO]

Цитата:

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

Это естественное ограничение бизнес-задачи, которое никакими opensource и unix не преодолеть...

Ну если все как вы говорите, то задача сама по себе алгоритмически трудозатратная. Тут уж вопрос не к сервисам или оперсоурсу.

[Vals]

Цитата:

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

Кучу народу пишет на этих системах. Где они все работают, если никто не использует опен соурс? Весь веб на оперсоурсе.

Условно говоря - как только вы добавите в ваше решение условный опен сорс календарик, вы должны решить (по желанию конечно) два вопроса:
1. Лицензия. А Опенсорс до определённого момента открытый. А так как лицензия может измениться - то отслеживать все изменения лицензии.
2. Безопасность кода этого календарика. А так как календарик периодически апдейтится, то безопасность каждого апдейта.

Ради науки - готов на примере 200К+ LOC исходника и показать уязвимости Отрезвляет

[LETTO]

Цитата:

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

Условно говоря - как только вы добавите в ваше решение условный опен сорс календарик, вы должны решить (по желанию конечно) два вопроса:
1. Лицензия. А Опенсорс до определённого момента открытый. А так как лицензия может измениться - то отслеживать все изменения лицензии.
2. Безопасность кода этого календарика. А так как календарик периодически апдейтится, то безопасность каждого апдейта.

Так тоже вы должны делать с лицензионном ПО. А теперь с облаками прайс меняется еще чаще. И обновления постоянно выходят.

Цитата:

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

Ради науки - готов на примере 200К+ LOC исходника и показать уязвимости Отрезвляет

Я вам тоже могу накидать дыр в лицензионном ПО. Если вы не видите уязвимость, это ж не значит, что ее нет.

Плюс не забываем что опенсоурс обкатывает на 1000 компаний. И там дыры находят быстро в коде сами же занудые коллеги.
Уязвимость Виндовс и Юникс вполне можете сравнить. Юникс используется у наших военных с открытым кодом. Виндовс - нет.

Мы ж с ЕРП работаем. Майкрософт когда нибудь парился за дыры в системе? Как вам помогал в этом? В опен соурсах реагируют сразу. И код проверен миллионами разработчиков.

[Vals]

Цитата:

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

Плюс не забываем что опенсоурс обкатывает на 1000 компаний. И там дыры находят быстро в коде сами же занудые коллеги.

Ну да, конечно https://logging.apache.org/log4j/2.x/ - он использовался наверно в 99% проектов
Но это пример. Эксплуатация той или иной уязвимости и её место в векторе атаки зависит в том числе и от использующего кода.

По нашей теме - о чём спор то?