goshoom: Recurring Integrations Scheduler

[fed]

Цитата:

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

Люди благополучно использовали счеты сотнями, а может и тысячами лет, но этот факт не наводит меня на мысли использовать их вместо калькулятора... А если сравнить их с AX, одни преимущества: багов нет, поддержка бесплатная, "код" открыт...

Во первых замечу, что счеты были заменены на калькуляторы (по крайней мере в СССР) только тогда, когда стоимость стандартного бухгалтерского калькулятора примерно сравнялась со стоимостью одного рабочего дня низового бухгалтера.
Это я к тому, что любые рассуждения о прогрессе неплохо бы сопровождать хотя бы примерными обоснованиями финансовой эффективности.

Цитата:

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

Попахивает временами EDI, когда данные были низкого качества, документы исчислялись штуками и надо было каждый проверять вручную. Как это поможет вам в enterprise реалиях если количество документов исчисляется тысячами или миллионами?

Судя по полемическому задору и употреблению термина "попахивает", текст взят из какого-то рекламного проспекта. Не очень понятно как вообще использование EDI связано с низким качеством данных? Если у поставщика данных баги в коде, то ошибки будут в сообщениях, независимо от того какой носитель сообщения используется - тупая папочка на диске или очередь в Azure.
Во вторых - далеко не всегда в Enterprise реалиях количество документов исчисляется тысячами и миллионами. Если у нас интеграция, например, с внешним рассчетом зарплаты, то там документ только один в месяц - итоговый платежный табель. Вообще когда говорится о миллионах сообщений, возникает ощущение что речь идет о каком-то серьезном архитектурном просчете. Наверное, можно таких размеров обмена достичь, если попытаться написать внутри Аксапты свою MES и собирать в нее данные с датчиков. Но все-таки правильнее держать MES где-то во внешнем приложении, а в аксапту ежедневно импортировать данные о нескольких сотнях активных производственных заказах и их потреблении/выпуске. А это - задача вполне посильная файловому обмену.

Цитата:

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

А в чем легкость по сравнению с любой программной очередью, к примеру Azure Queue ? Одно приложение кладёт сообщение в очередь, другое достает. Хотите подебажить - положите сообщение еще раз. Плюсы для меня: не надо писать экспорт данных в файл, не надо хранить файлы, не надо администрировать доступ к файлам и т.д. и т.п.

Работу с очередью относительно легко отлаживать только тогда, когда и приложение-источник и приложение-приемник разрабатывает один и тот же разработчик. А вот если разработчики работают а разных фирмах, используют разные подходы к разработке и вообще имеют несколько разное виденье интеграции - то вот это самое "положите сообщение еще раз" становится уже очень непростым. Так что при использовании message queue время на отладку на порядок больше - это факт.
В принципе - я согласен что при использовании стандартных Message Queue экономится немного времени на огранизацию очередей, логирования и тп. Но на аксапте это порядка 3-4 экранов кода - экономия не гигантская. Формировать XML или JSON тебе все равно надо в обоих случаях - и при очереди и при примитивной папочке на диске.
Единственное реальное преимущество Message Queue (причем гигантское) - это их интеграция с менеджерами транзакций. То есть - можно гарантировать, что сообщения пропадут из очереди ТОЛЬКО при успешном завершении текущей транзакции. (Чего при файловом доступе добится нельзя ни при каких условиях).
Однако, Аксапта не поддерживает работу с менеджерами транзакций и преимущество это может сработать только при разработке на голом C#/Java

[skuull]

Цитата:

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

Это я к тому, что любые рассуждения о прогрессе неплохо бы сопровождать хотя бы примерными обоснованиями финансовой эффективности.

Это экспертное мнение, разве оно должно сопровождаться чем-то ?

Цитата:

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

Вообще когда говорится о миллионах сообщений, возникает ощущение что речь идет о каком-то серьезном архитектурном просчете

Один поставщик - 1 ASN, 1000 поставщиков - 1000 ASN. 1 customer order в ритейле - 1 документ, 1000 - 1000, где тут просчеты?

Давайте уйдем от полемики. Кроме возможности прочитать и подправить руками есть еще преимущества?

[fed]

Цитата:

Сообщение от 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 внешними системами, то в большинстве случаев, использование тяжелых интеграционных технологий - это стрельба из пушки по воробьям.