AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 29.09.2017, 10:41   #1  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от 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 внешними системами, то в большинстве случаев, использование тяжелых интеграционных технологий - это стрельба из пушки по воробьям.

Последний раз редактировалось fed; 29.09.2017 в 11:13.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: Recurring Integrations in Dynamics 365 for Operations Blog bot DAX Blogs 0 14.07.2017 02:21
goshoom: Code snippets in AX 7 – The Problem Blog bot DAX Blogs 0 30.06.2016 12:11
Microsoft Dynamics CRM Team Blog: Exploring Recurring appointment and Linked fields Blog bot Dynamics CRM: Blogs 0 29.04.2011 00:11
Microsoft Dynamics CRM Team Blog: Demystifying Recurring Appointment update recurrence logic: How history of past instances is saved in CRM Blog bot Dynamics CRM: Blogs 0 25.04.2011 19:11
Microsoft Dynamics CRM Team Blog: Demystifying the Recurring Appointment series expansion in Microsoft Dynamics CRM 2011 Blog bot Dynamics CRM: Blogs 0 09.12.2010 02:13

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 20:11.