честно говоря, у меня в голове плохо укладывается REST (stateless) и "по мере обработки...обогащается"

Автор хрень какую-то описывает

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

В любом случае, REST должен возврашать всю иерархию в консистентном состоянии

Х.з. как там SAP запихивает

Каким образом Вы собираетесь что-то осмысленное делать с данными, когда придет

1. Заголовок счета-фактуры. Итого по счету -100 рублей, в том числе НДС -20 рублей
2. А запросами по строкам счета-фактуры:
Услуга N1 (корректировка за пред.период) -100 рублей В том числе НДС -20 рублей
Услуга N2 150 рублей В том числе НДС 30 рублей

Что Вы будете с такими "данными" делать?

Особенно хорошо их будет интегрировать с бухгалтерий. Когда отрицательные счета это совсем и не счита, а авансы. Бухгалтерия обычно доходчиво такие косяки объясняет, без лишних стенснений и без попыток "удержать великий и могучий русский язык за зубами"

Выдвину теорию:

Если информация не консистентна, то это называется не "данные", а "мусор"

В этом случае, значительно эффективнее заранее выполнить оптимизацию программы и просто все REST запросы заменить на вызов локальной ф-ции Random.

Ситуация описываемая автором топика, называется просто - бардак.

"компьютеризация бардака на выходе даст лишь компьютеризированный бардак" ( C )

p.s.
вообще-то, как автор описывает свою задачу 22026892 он ровно и пытается из существующего бардака и мусора возврашаемых по REST хоть как-то в свое хранилище переложить и упорядочить.

НО не нужно забывать:

Второй закон термодинамики Эверитта: Неразбериха в обществе постоянно возрастает. Только очень упорным трудом можно её несколько уменьшить. Однако сама эта попытка приведет к росту совокупной неразберихи .

IMHO & AFAIK


I)
Обычно, все же, из системы в систему данные пытаются передавать, когда они в каком-то "мало редактируемом" состоянии.

Например у заказы в OeBS (Sales Order, Purchase Order), есть понятие "Утверждение заказа". После утверждения, заказ уже (теоретически) меняться не должен

Например, если по в событие "смена статуса" приходит с какого и на какой он меняется, то теоретически, при:
1) "неутвержден -> утвержден" данные можно смело копировать в хранилище т.к. Order Line в OeBS уже меняться не должны.
2) При событие "утвержден -> не утвержден", смело все удалять ))). Т.к. неутвержденный заказ в понятиях OeBS это просто мусор.

note. вроде статус есть даже на отдельных строках заказа, лет 10 назад с OeBS работал, не помню

II)
Если говорить "про хранилище" / BI, то например у нас его заливают ночью, когда с системой никто не работает.

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

Сравнивать данные в текущем периоде, никому и в голову не приходит. И так понятно, что они не совпадают и это нормально.

III)
аналогично в OeBS происходит заливка данных в ERP

запихиваем данные в интерфейсную таблицу
выполняем команду "запустить"
запускается батч процесс, который эти данные в ERP и проводит

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

Бизнес конкретика нужна. Так можно до бесконечности обсуждать.

Привел пример OeBS. На SO (Sales Order) может быть 100500 изменений - но на их, вообще-то, всем глубоко пчихать. Единственное ВАЖНОЕ изменение (с точки зрения системы) - утверждение заказа.

Но после "утверждения заказа" он обычно (могут быть исключения подтверждающие правило) уже НЕ меняется

Т.е. его смело можно вычитывать и отправлять в бухгалтерию. Но вычитывать лучше атомарным и консистентным способом. Например смотрю на Ваш же битрекс и вижу, что товарные позиции определяются так же ОДНИМ запросом (crm.deal.productrows.get)

Т.е., например, как бы я видел более-менее корректную интеграцию с бухгалтерией:
1. изменения сами по себе - глубоко пофиг
2. прошла операция "утверждение заказа" (изменился статус) или аналог - данные передаются
например в бухгалтерии создаем счет
3. прошла операция "отмена утверждения заказа" - данные из бухгалтерии "вычишаются"
например в бухгалтерии для старого счета создаем сторнировочный счет (УЖЕ на основе данных бухгалтерии)

Не знаю Битрекс, но глубоко убежден, что понятия аналогичные "утверждение заказа" у них есть.

Возьмем тот же Ozon. Сколько раз я редактирую свою корзину заказов - в целом глубо пофиг. Важно только, когда я эту корзину превращаю в утвержденный мною заказ - его можно отправлять на склад "скомплектовать заказ, собрать все в посылку". Если же я от заказа отказываюсь, то опять таки, на склад нужно отправлять команду "заказчик сцуко, заставил делать лишнию работу, разкомплектовать посылку обратно и разложить обратно на полки" при этом, знать, что было в заказе уже не нужно. Это информация уже есть на складе.
Но, опять таки, в оформленном заказе, изменять на Ozon'е я уже ничего не могу .

IMHO & AFAIK

Но частая ситуации, что во время операции ОБРАБОТКИ данные уже успели поменяться, это нонсенс

Если есть поле Version, то наверное по полю Version, можно определять, что данные в процессе переноса изменились и просто делать rollback.

Ну и согласен с PetroNotC Sharp какая-то мешанина из ETL и обработки. Может проще задачи разделить? ETL - отдельно; обработка - отдельно, по уже извлеченным данным.