1.) Конечный пользователь создает в SAP-системе заявку на изменение единиц НСИ . После создания, выставляет статус "Отправлено на рассмотрение".
2.) Далее, заявка поступает на рассмотрение Админу НСИ. Он ее одобряет, дополняет значениями для тех или иных полей, и производит физические изменения соответствующих НСИ в системе.
3.) Либо отклоняет, пишет комментарии - заявка возвращается обратно юзеру на доработку. И т.д. по кругу, пока единицы НСИ, содержащиеся в заявке, не будут изменены либо пока заявка не будет отменена юзером.
4.) Все это реализовано с помощью своей статусной модели. Обработка идет через Workflow. + 1 Z-транзакция + 2 Z-таблицы + стандартная система классификации SAP (для настройки структуры ракурсов и состава заполняемых полей).

Возникла необходимость интеграции этого решения с MDM. Т.е. НСИ будут заводиться Админом НСИ в MDM, а не в SAP-системе (юзеры будут, понятно, в SAP-системе работать).

...

Мотивация: например, для того, чтобы не забивать голову конечным юзерам еще и MDM-ом.

Не понял идеи. А чем плоха обработка заявок в ERP? Зачем непроверенные заявки писать в репозитарий?

Получается, вы хотите выкинуть XI и заменить на MDM ABAP API? И гонять заявки на стадии доработки между ABAP-сервером и MDM?

2.) Она улетает в MDM (ессно, в формате MDM).

Но XI не выкидывается совсем, он по-прежнему будет использоваться для репликации данных между системами (для синхронизации НСИ, уже имеющихся в системах). MDM ABAP API будет использоваться только для заявок.

Вот тут она напрямую пишется в репозитарий? И структуры преобразовываются программно?

Виктор, а Вы интерфейс для ввода планируете делать на абапе в одной из сап систем или на вэб-динпро ?

Насчет MDM - изначально про интеграцию с MDM-ом вообще речи не шло, это был продукт чисто под SAP.

чисто в двух словах - чем обусловлено быстродействие выборок в MDM?

- это какой-то внешнеплатформенный продукт, типа очередное "благоприобретение" SAP AG?

Дык, не знаю :roll: .
Вопрос как раз в том, как сделать так, чтобы сначала положить данные как бы понарошку, в неком черновом статусе, а потом, в случае правильности данных, завести их уже "по-взрослому".
И тут есть свои нюансы.

Например, ID материала - его номер. Присваивается он только при окончательном создании материала. Даже если нумерация внешняя - все равно, очевидно, номер материалу должен присваиваться админом НСИ в самую последнюю очередь, при создании материала в системе.
До этого момента единственный способо его идентифицировать - по номеру заявки+номеру позиции заявки. Можно, конечно, сначала присваивать материалу игрушечный номер, соответствующий этому сочетанию (номер заявки+номер позиции), а потом его менять на всамделишний. Но тут появляются свои нюансы, из-за изменения ключевых полей.

Не совсем понятно, как в MDM решаются подобные вопросы.

Да :). Оно не на SAP-платформе, сделано кем-то со стороны и куплено SAP-ом.

А зачем внешний код (номер заявки или ID во внешней системе) заменять на код центрального справочника? Сделайте два разных поля, первое позволит контролировать прохождение этапов обработки и связь с дополнительными структурами (например, классификации, если речь идет о материалах), а второе проапдейтится только перед публикацией.

У нас обрабатывается одномоментно заявка только из одной системы, то есть делается либо создание записи в центральном справочнике (сущность не найдена в ЦС), либо merging двух записей - центрального справочника и заявочной (сущность ранее заведена в ЦС). В этом случае в "слитой" записи присутствует номер последней заявки. Кроме того, в многозначное поле "Системы" центрального справочника добавляется система, приславшая заявку.

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

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

Идентификатор центрального справочника у нас присваивается автоматически в момент назначения администратором статуса "ОК" (это делает программа-listener, которая ловит события в репозитарии - вроде внешнего триггера). Синдикатор публикует все записи со статусом отличным от "не обработана". В XI делается ветвление на основании многозначного поля "Системы" и сообщения уходят тем системам, которые ранее присылали заявки на данную сущность.

До тех пор, пока у записи статус "не обработана", она болтается в репозитарии, но не отдается внешним системам.