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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.09.2017, 03:35   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
goshoom: Recurring Integrations Scheduler
Источник: 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/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 28.09.2017, 04:26   #2  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
На яммере данную вещь встретили крайне восторженно, но удивляет почему
Вкратце – ребята написали сервис на C#(с собственным планировщиком) который занимается по сути импортом-экспортом файлов из директорий(Inbound, Outbound, Processing, Success, Error), подключаясь к АХ через OData. Т.е. сама задача по сути типичная возникает на каждом втором проекте. Удивляет архитектура решения – "отдельный . NET сервис"
Т.е. обычно она решалась созданием пакетного задания(ий) в АХ и реализации работы с файлами.
Т.е. тут можно было сделать аналогично тем же пакетным заданием, который бы обращался к Azure storage с созданными папками(Azure storage можно замапить как локальный диск в windows, собственно для приложения с которым интегрируемся это будет прозрачно)
Есть у кого-нибудь идеи преимущества подобной архитектуры перед пакетными заданиями?
Т.е. у меня сходу только недостатки: отдельный сервис который нужно администрировать (т.е. отдельное расписание, ошибки нужно будет смотреть в 2 местах), 2 системы – непонятно как реализовывать DR, усложненный мониторинг и т.п.
Старый 28.09.2017, 09:34   #3  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от trud Посмотреть сообщение
Удивляет архитектура решения – "отдельный . NET сервис"
Т.е. обычно она решалась созданием пакетного задания(ий) в АХ и реализации работы с файлами.
Меня удивляет архитектура решения которая требует обмен файлами, а Вас нет ?
Старый 28.09.2017, 10:56   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
Меня удивляет архитектура решения которая требует обмен файлами, а Вас нет ?
Если очень большая рекативность решения не нужна (то есть - задержки в пределах 15-30 минут никого не пугают), то в файлах ничего плохого нету. В случае чего их легко просмотреть в редакторе, подправить данные (если например предудущий пример уже сработал и надо просто сделать то же самое со следующим заказом/журналом и тп). Таким образом - легкость отладки на порядок выше чем при использовании web-service или Azure AppBus какой-нить. Надежность, на самом деле, тоже не так уж плоха. Я, например, видел внедрение, где разработанная где-то во второй половине 90ых система (на C++ Builder кажется), достаточно устойчиво обменивалась файлами с разработанной в середине 80ых системой на AS 400. То есть - в конечном итоге и то и другое было частично заменено на Аксапту, а частично на какой-то CAD/MES. Но сам факт того что файловая интеграция благополучно проработала 20 лет наводит на мысли...
Старый 28.09.2017, 12:27   #5  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от 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 пришлось бы писать самому, а это затратно и не кошерно.
За это сообщение автора поблагодарили: mazzy (2).
Старый 29.09.2017, 04:54   #6  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Но сам факт того что файловая интеграция благополучно проработала 20 лет наводит на мысли...
Люди благополучно использовали счеты сотнями, а может и тысячами лет, но этот факт не наводит меня на мысли использовать их вместо калькулятора... А если сравнить их с AX, одни преимущества: багов нет, поддержка бесплатная, "код" открыт...

Цитата:
Сообщение от fed Посмотреть сообщение
В случае чего их легко просмотреть в редакторе, подправить данные (если например предудущий пример уже сработал и надо просто сделать то же самое со следующим заказом/журналом и тп).
Попахивает временами EDI, когда данные были низкого качества, документы исчислялись штуками и надо было каждый проверять вручную. Как это поможет вам в enterprise реалиях если количество документов исчисляется тысячами или миллионами?

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

Последний раз редактировалось skuull; 29.09.2017 в 04:56.
Старый 29.09.2017, 06:47   #7  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от skuull Посмотреть сообщение
А в чем легкость по сравнению с любой программной очередью, к примеру Azure Queue ? Одно приложение кладёт сообщение в очередь, другое достает. Хотите подебажить - положите сообщение еще раз. Плюсы для меня: не надо писать экспорт данных в файл, не надо хранить файлы, не надо администрировать доступ к файлам и т.д. и т.п.
А как кстати АХ будет работать с этой очередью? путем написания нового пакетного задания которое будет брать сообщения и обрабатывать их?

Последний раз редактировалось trud; 29.09.2017 в 07:15.
Старый 29.09.2017, 09:34   #8  
raz is offline
raz
NavAx
Аватар для raz
NavAx Club
Лучший по профессии 2014
Лучший по профессии 2009
 
1,490 / 1060 (38) ++++++++
Регистрация: 22.07.2003
Адрес: МО
Цитата:
Сообщение от trud Посмотреть сообщение
А как кстати АХ будет работать с этой очередью? путем написания нового пакетного задания которое будет брать сообщения и обрабатывать их?
Ага. У нас так, на продакшене еще не пробовали, но на тесте работает. Очередь хороша тем, что можно последовательно грузить данные, если есть зависимости,то самое оно. У нас это надстройка над DMF для передачи файлов в обе стороны, поддерживается Azure Service Bus, Azure File Storage, Azure Blob Storage, FTP, Local Share (для тестирования).
По скриншотам QuartzAX не понятно как настроить, если надо обмениватся разными типами данных (клиенты, поставщики, заказы и т.д.), надо для каждого типа свой инстанс настраивать/запускать или все можео настроить в одном?

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

Последний раз редактировалось raz; 29.09.2017 в 09:37.
Старый 29.09.2017, 09:45   #9  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от 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

Последний раз редактировалось fed; 29.09.2017 в 11:14.
За это сообщение автора поблагодарили: EVGL (2), Link (2).
Старый 29.09.2017, 10:01   #10  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от trud Посмотреть сообщение
А как кстати АХ будет работать с этой очередью? путем написания нового пакетного задания которое будет брать сообщения и обрабатывать их?
Если обратить свой взор на DMFIntegrationBridge то можно найти использование разных интересных библиотек типа Microsoft.Dynamics.Platform.Integration.*, а дальше рефлектор в руки и смотрите как используеться и блоб и очереди и прочие прелести Azure.
Старый 29.09.2017, 10:11   #11  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от raz Посмотреть сообщение
По скриншотам QuartzAX не понятно как настроить, если надо обмениватся разными типами данных (клиенты, поставщики, заказы и т.д.), надо для каждого типа свой инстанс настраивать/запускать или все можео настроить в одном?
Все в одном. Один процесс контролирует множественные задания.
Старый 29.09.2017, 10:25   #12  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Это я к тому, что любые рассуждения о прогрессе неплохо бы сопровождать хотя бы примерными обоснованиями финансовой эффективности.
Это экспертное мнение, разве оно должно сопровождаться чем-то ?

Цитата:
Сообщение от fed Посмотреть сообщение
Вообще когда говорится о миллионах сообщений, возникает ощущение что речь идет о каком-то серьезном архитектурном просчете
Один поставщик - 1 ASN, 1000 поставщиков - 1000 ASN. 1 customer order в ритейле - 1 документ, 1000 - 1000, где тут просчеты?

Давайте уйдем от полемики. Кроме возможности прочитать и подправить руками есть еще преимущества?
Старый 29.09.2017, 10:41   #13  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 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.
Старый 29.09.2017, 10:56   #14  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от raz Посмотреть сообщение
Ага.
Ну т.е. если у вас обычное пакетное задание, читает что-то(в принципе то неважно что, очередь azure или директорию с файлами) и обрабатывает
мне это кажется логичным, но вот EVGL такой подход считает "некошерным" (аналогично кстати отозвались на яммере, используя правда терминологию "не энтерпрайс подход" )

собственно в этом и вопрос - зачем для такой задачи нужно отдельное приложение-сервис, с собственным планировщиком и т.п.
Старый 29.09.2017, 11:08   #15  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от trud Посмотреть сообщение
собственно в этом и вопрос - зачем для такой задачи нужно отдельное приложение-сервис, с собственным планировщиком и т.п.
ты щас спрашиваешь с точки зрения потребителя или с точки зрения вендора?

вендору понятно зачем - микросервисы, разделение по командам, независимое планирование/тестирование/приемка, независимое ценообразование.
масса преимуществ для вендора.
__________________
полезное на axForum, github, vk, coub.
Старый 29.09.2017, 11:26   #16  
raz is offline
raz
NavAx
Аватар для raz
NavAx Club
Лучший по профессии 2014
Лучший по профессии 2009
 
1,490 / 1060 (38) ++++++++
Регистрация: 22.07.2003
Адрес: МО
Цитата:
Сообщение от EVGL Посмотреть сообщение
Все в одном. Один процесс контролирует множественные задания.
Идея такая.
1. Есть Interface - связь с DMF проектом и dataentity.
2. Есть Shared resource - связь с тем, где брать/куда класть файлы с данными.
3. Есть звязка между Interface и Shared resource.
4. Есть Interface log, промежуточная таблица, куда попадают данные для экспорта/импорта. Данные - это файлы сгенерированные DMF или для DMF.
5. Обработчик (пакетник) для обработки Shared resource, при запуске нужно указать какой ресурс. Сколько интерфейсов нужно мониторить, столько пактеных заданий запускаем. Для входящих интерфейсов файлы будут браться с ресурса и класться в Interface log со статусом Pending import. Для исходящих данных из Interface log будут браться строки с Pending export и отправляться на/в ресурс.
6. Обработчик для Pending import. Нужно одно пакетное задание.
7. Для экспорта нужны или триггеры, или можно натроить Auto push для dataentity с Incremental push only. Данные попадают в Interface log со статусом Pending export.
8. Обработчик для Pending import. Нужно одно пакетное задание.
9. Обработчик для Auto push интерфейсов.
Миниатюры
Нажмите на изображение для увеличения
Название: ibf1.JPG
Просмотров: 371
Размер:	53.3 Кб
ID:	11668   Нажмите на изображение для увеличения
Название: ibf2.JPG
Просмотров: 481
Размер:	59.0 Кб
ID:	11669  

Нажмите на изображение для увеличения
Название: ibf3.JPG
Просмотров: 409
Размер:	54.2 Кб
ID:	11670   Нажмите на изображение для увеличения
Название: ibf4.JPG
Просмотров: 336
Размер:	69.8 Кб
ID:	11671  

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
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, время: 21:56.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.