goshoom: Recurring Integrations 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 ? Одно приложение кладёт сообщение в очередь, другое достает. Хотите подебажить - положите сообщение еще раз. Плюсы для меня: не надо писать экспорт данных в файл, не надо хранить файлы, не надо администрировать доступ к файлам и т.д. и т.п.

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

[raz]

Цитата:

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

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

Ага. У нас так, на продакшене еще не пробовали, но на тесте работает. Очередь хороша тем, что можно последовательно грузить данные, если есть зависимости,то самое оно. У нас это надстройка над DMF для передачи файлов в обе стороны, поддерживается Azure Service Bus, Azure File Storage, Azure Blob Storage, FTP, Local Share (для тестирования).
По скриншотам QuartzAX не понятно как настроить, если надо обмениватся разными типами данных (клиенты, поставщики, заказы и т.д.), надо для каждого типа свой инстанс настраивать/запускать или все можео настроить в одном?

ЗЫ. На чистом .Net только один статический метод для чтения body из сообщения в Azure Service Bus.

[EVGL]

Цитата:

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

По скриншотам QuartzAX не понятно как настроить, если надо обмениватся разными типами данных (клиенты, поставщики, заказы и т.д.), надо для каждого типа свой инстанс настраивать/запускать или все можео настроить в одном?

Все в одном. Один процесс контролирует множественные задания.

[trud]

Цитата:

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

Ага.

Ну т.е. если у вас обычное пакетное задание, читает что-то(в принципе то неважно что, очередь azure или директорию с файлами) и обрабатывает
мне это кажется логичным, но вот EVGL такой подход считает "некошерным" (аналогично кстати отозвались на яммере, используя правда терминологию "не энтерпрайс подход" )

собственно в этом и вопрос - зачем для такой задачи нужно отдельное приложение-сервис, с собственным планировщиком и т.п.

[skuull]

Цитата:

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

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

Если обратить свой взор на DMFIntegrationBridge то можно найти использование разных интересных библиотек типа Microsoft.Dynamics.Platform.Integration.*, а дальше рефлектор в руки и смотрите как используеться и блоб и очереди и прочие прелести Azure.

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

[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 пришлось бы писать самому, а это затратно и не кошерно.