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