|
![]() |
#1 |
Участник
|
Цитата:
Сообщение от skuull
![]() А в чем легкость по сравнению с любой программной очередью, к примеру Azure Queue ? Одно приложение кладёт сообщение в очередь, другое достает. Хотите подебажить - положите сообщение еще раз. Плюсы для меня: не надо писать экспорт данных в файл, не надо хранить файлы, не надо администрировать доступ к файлам и т.д. и т.п.
Последний раз редактировалось trud; 29.09.2017 в 07:15. |
|
![]() |
#2 |
NavAx
|
Цитата:
По скриншотам QuartzAX не понятно как настроить, если надо обмениватся разными типами данных (клиенты, поставщики, заказы и т.д.), надо для каждого типа свой инстанс настраивать/запускать или все можео настроить в одном? ЗЫ. На чистом .Net только один статический метод для чтения body из сообщения в Azure Service Bus. Последний раз редактировалось raz; 29.09.2017 в 09:37. |
|
![]() |
#3 |
Banned
|
Все в одном. Один процесс контролирует множественные задания.
|
|
![]() |
#4 |
NavAx
|
Идея такая.
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 интерфейсов. |
|
![]() |
#5 |
Участник
|
Ну т.е. если у вас обычное пакетное задание, читает что-то(в принципе то неважно что, очередь azure или директорию с файлами) и обрабатывает
мне это кажется логичным, но вот EVGL такой подход считает "некошерным" (аналогично кстати отозвались на яммере, используя правда терминологию "не энтерпрайс подход" ![]() собственно в этом и вопрос - зачем для такой задачи нужно отдельное приложение-сервис, с собственным планировщиком и т.п. |
|
![]() |
#6 |
Участник
|
Цитата:
вендору понятно зачем - микросервисы, разделение по командам, независимое планирование/тестирование/приемка, независимое ценообразование. масса преимуществ для вендора. |
|
![]() |
#7 |
Участник
|
Если обратить свой взор на DMFIntegrationBridge то можно найти использование разных интересных библиотек типа Microsoft.Dynamics.Platform.Integration.*, а дальше рефлектор в руки и смотрите как используеться и блоб и очереди и прочие прелести Azure.
|
|
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|