JhaoDa Получается, что каждый JobA должен следить за всеми своими соседями по группе:
1) при событии before должен записать (допустим в Redis), что он часть обработки конкретного XML
2) при событии after удалить эту запись и проверить есть ли еще другие и если никого нет, то запустить обработку отчета
Плюс возможна такая ситуация, что парсинг XML и запихивание в очередь этих задач JobA будет медленнее чем, выполнение самой этой микрозадачи JobA. И тогда запустится создание отчета, хотя на самом деле еще не все задачи были положены в очередь.
Получается этот "глупый" микротаск JobA начинает отвечать за то, что даже не видит полностью. Тут явно нужен сторонний наблюдатель, который видит всю группу задач.
JhaoDa спасибо за ссылку, прочитал еще раз. И знал и использовал этот функционал раньше. Давайте только придумаем вместе как это решит конкретно эту задачу. У меня пока нет идей.
Я знаком с концепцией Dispatch Groups, но не вижу им применения конкретно в данном случае.
Если бы я бы инициатором всех задач, которые мне надо скоординировать, тут бы группы сгодились.
Но уведомление от Apple Health приходит в независящий от меня момент.
Как бы вы посоветовали применить Dispatch Groups в этом случае?
Радмир, спасибо за наводку на RetailCRM. Понравился сервис, только API у них корявый, не гибкий и не логичный. Можно извернуться и сделать как хочется, но с издержками.
Спасибо за рекомендацию, часто вижу упоминания о них, видно они давно в отрасли, и видно где-то в 90-х остановились в развитии. Инстинктивно не доверяю компаниям, которые присылают пароль от личного кабинета в открытом в виде на почту. И интеграции через API не получилось найти у них в документации.
