Цитата:
Сообщение от
skuull
Один поставщик - 1 ASN, 1000 поставщиков - 1000 ASN. 1 customer order в ритейле - 1 документ, 1000 - 1000, где тут просчеты?
Давайте уйдем от полемики. Кроме возможности прочитать и подправить руками есть еще преимущества?
Ну так желание хранить каждый конкретный заказ из ритейла - это и есть архитектурный просчет. Для этого retail frontend предназначен.
А насчет полемики - так нету плохих и хороших технологий. Есть технологии применимые для каждого конкретного случая с конкретными параметрами.
Я просто пытаюсь представить себе ситуацию на реальном, более или менее разумно спроектированном внедрении Аксапты, при котором файловый обмен дествительно начинает несправляться. Но реального примера у меня придумать не получается. Ситуации с датчиками в производстве или с закачкой всех ритейловых заказов в аксапту - это как раз примеры скверной архитектуры.
Кроме возможности подправить и прочитать, замечу большую легкость администрирования. Расшарить папочку на компе любой пользователь может, а администрировать message queue - это надо учиться. Наконец - хотя написание кода для записи/чтения XML/JSON и занимает время, но текстовый формат обмена легче согласовать между поставщиками, легче верифицировать и тд. То есть - речь идет не только о времени на кодинг, но и о времени на дизайн.
То есть - на мой взгляд - message queue и Enterprise Service Bus - это вещи вполне полезные, но только в том случае, если внедряется не ERP, а best of breed. Вот если у нас CRM, складская система, финансовая система, система бюджетирования, APS, MES, Business Intellignce, система прогнозирования спроса и тд взяты от разных разработчиков и живут частично в облаке, частично on-premise, то использование MQ и ESB вполне оправдано. (просто потому что объем обмена внутри этого хозяйства просто непосилен для файлового обмена). А если нам надо ERP заинтегрировать с 3-4-5 внешними системами, то в большинстве случаев, использование тяжелых интеграционных технологий - это стрельба из пушки по воробьям.