goshoom: Recurring Integrations Scheduler

[Blog bot]

Источник: http://dev.goshoom.net/en/2017/09/re...ons-scheduler/
==============

You may have heard about QuartzAX, an application for file-based integration with AX 7 (Dynamics 365 for Finance and Operations, Enterprise Edition). Microsoft announced at the last Technical conference that it would be released in a few days, but it didn’t happen and it looked like it wouldn’t ever be made available. But it has changed today.

You can find its source code and documentation on GitHub under the new name: Recurring Integrations Scheduler.



Источник: http://dev.goshoom.net/en/2017/09/re...ons-scheduler/

[trud]

На яммере данную вещь встретили крайне восторженно, но удивляет почему
Вкратце – ребята написали сервис на C#(с собственным планировщиком) который занимается по сути импортом-экспортом файлов из директорий(Inbound, Outbound, Processing, Success, Error), подключаясь к АХ через OData. Т.е. сама задача по сути типичная возникает на каждом втором проекте. Удивляет архитектура решения – "отдельный . NET сервис"
Т.е. обычно она решалась созданием пакетного задания(ий) в АХ и реализации работы с файлами.
Т.е. тут можно было сделать аналогично тем же пакетным заданием, который бы обращался к Azure storage с созданными папками(Azure storage можно замапить как локальный диск в windows, собственно для приложения с которым интегрируемся это будет прозрачно)
Есть у кого-нибудь идеи преимущества подобной архитектуры перед пакетными заданиями?
Т.е. у меня сходу только недостатки: отдельный сервис который нужно администрировать (т.е. отдельное расписание, ошибки нужно будет смотреть в 2 местах), 2 системы – непонятно как реализовывать DR, усложненный мониторинг и т.п.

[skuull]

Цитата:

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

Удивляет архитектура решения – "отдельный . NET сервис"
Т.е. обычно она решалась созданием пакетного задания(ий) в АХ и реализации работы с файлами.

Меня удивляет архитектура решения которая требует обмен файлами, а Вас нет ?

[fed]

Цитата:

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

Меня удивляет архитектура решения которая требует обмен файлами, а Вас нет ?

Если очень большая рекативность решения не нужна (то есть - задержки в пределах 15-30 минут никого не пугают), то в файлах ничего плохого нету. В случае чего их легко просмотреть в редакторе, подправить данные (если например предудущий пример уже сработал и надо просто сделать то же самое со следующим заказом/журналом и тп). Таким образом - легкость отладки на порядок выше чем при использовании web-service или Azure AppBus какой-нить. Надежность, на самом деле, тоже не так уж плоха. Я, например, видел внедрение, где разработанная где-то во второй половине 90ых система (на C++ Builder кажется), достаточно устойчиво обменивалась файлами с разработанной в середине 80ых системой на AS 400. То есть - в конечном итоге и то и другое было частично заменено на Аксапту, а частично на какой-то CAD/MES. Но сам факт того что файловая интеграция благополучно проработала 20 лет наводит на мысли...

[skuull]

Цитата:

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

Но сам факт того что файловая интеграция благополучно проработала 20 лет наводит на мысли...

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

Цитата:

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

В случае чего их легко просмотреть в редакторе, подправить данные (если например предудущий пример уже сработал и надо просто сделать то же самое со следующим заказом/журналом и тп).

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

Цитата:

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

Таким образом - легкость отладки на порядок выше чем при использовании web-service или Azure AppBus какой-нить. Надежность, на самом деле, тоже не так уж плоха.

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

[trud]

Цитата:

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

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

А как кстати АХ будет работать с этой очередью? путем написания нового пакетного задания которое будет брать сообщения и обрабатывать их?

[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

[EVGL]

Цитата:

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

На яммере данную вещь встретили крайне восторженно, но удивляет почему
Вкратце – ребята написали сервис на C#(с собственным планировщиком) который занимается по сути импортом-экспортом файлов из директорий(Inbound, Outbound, Processing, Success, Error), подключаясь к АХ через OData. Т.е. сама задача по сути типичная возникает на каждом втором проекте. Удивляет архитектура решения – "отдельный . NET сервис"
Т.е. обычно она решалась созданием пакетного задания(ий) в АХ и реализации работы с файлами.
Т.е. тут можно было сделать аналогично тем же пакетным заданием, который бы обращался к Azure storage с созданными папками(Azure storage можно замапить как локальный диск в windows, собственно для приложения с которым интегрируемся это будет прозрачно)
Есть у кого-нибудь идеи преимущества подобной архитектуры перед пакетными заданиями?
Т.е. у меня сходу только недостатки: отдельный сервис который нужно администрировать (т.е. отдельное расписание, ошибки нужно будет смотреть в 2 местах), 2 системы – непонятно как реализовывать DR, усложненный мониторинг и т.п.

Томек Мелисса написал эту программу от чистого отчаяния, поскольку год назад никаких Flow или LogicApps-коннекторов еще не было.

Обратите внимание, что задание типа Recurring integration в модуле Data management (DIXF) не открывает папку Azure, а вывешивает отдельный endpoint, в который сторонняя программа за-push-ивает файл в конверте. После этого файл кладется в очередь и разбирается процессом Recurring integration.

Т.е. пакетное задание для чтения папки Azure пришлось бы писать самому, а это затратно и не кошерно.