Поиск юзал, нужной инфы не нашел, поэтому открываю новую тему.
Извините, если скажу что-нибудь не то - до этого с MDM не сталкивался.

Ситуация.
Есть MDM (v.5.56 SP04), есть SAP-системы. MDM в основной части уже внедрен, настроен, репликация данных между MDM и SAP работает. Во всяком случае, это не наша головная боль.

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

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

Вопрос: как в целом это возможно осуществить?
Из документации по MDM ABAP API не совсем понятно. Например, как устанавливать и контролировать статусы заявок.

Задача 2.
Одним из главных достоинств MDM можно назвать мега-быстрый поиск единиц НСИ - гораздо быстрее, чем в SAP-системах. У клиента родилась идея создать средства поиска для SAP-систем, которые будут искать НСИ не в SAP-системе, а будут обращаются к MDM (например, через IF_MDM_CORE_SERVICES->QUERY).
Подразумевается, что SAP-системы и MDM всегда будут безукоризненно синхронизированы друг с другом (во всяком случае, это не наша головная боль).

Вопрос.
Кто-нибудь пробовал делать что-нибудь подобное? СтОит овчинка выделки? Будет ли существенный выигрыш по быстродействию, не съест ли его взаимодействие через интерфейсы?

Заранее спасибо.

Up

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

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

Возможно, как вариант. Но клиент хочет использовать возможности MDM для проверки этих заявок.

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



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

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


В общем, я с MDM ABAP API дела не имел, использовал Java API, но подозреваю, что проблемы там сходные:
- сам API (не говоря уж о протоколе) меняется с каждым патчем;
- можно сразу забыть о настройках структуры и мэппинга сообщений;
- теряется: очереди, обработка ошибок, мониторинг, конфигурирование, масштабирование и т.д. и т.п. - все, что дает XI.

Технически не вижу никаких препятствий для внесения записей в репозитарий. У нас заявки создаются во внешних системах, переносятся при помощи XI в MDM, где обрабатываются администратором. К сожалению, средства MDM (встроенный язык "проверок") ограничены, поэтому приходится отлавливать изменения записей через Java API и обрабатывать их внешним приложением (проверка ИНН, автоматическое присвоение значений из диапазона по условию и т.д.). Интерфейс для внесения и обработки записей писался, но тоже на Java, и идея там была несколько иная - разместить приложение и MDM-сервер на одном хосте, а с пользовательским интерфейсом обмениваться минимумом данных.

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

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

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

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

Интерфейс уже сделан на АВАРе, никакого вэб-интерфейса не предусмотрено (честно говоря, не представляется целесообразным).
Вот, примерно в таком виде:


Скриншоты не очень актуальны, достаточно старая версия, более актуальные по техническим причинам сейчас не могу сделать.
Явно видны мелкие баги.
Например, по части статусов - не должно быть "зеленых друзей", если под ними сидит хоть один "красненький". По части отображения (например, "ST" вместо "ШТ"). И т.д.
Имена юзеров из колонки "Пользователи" вырезаны специально.

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

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

Слушай - фик знает, самому интересно. Но плотно еще не разбирался, да и продукт закрытый. Видимо, оригинальная модель данных, позволяющая все хорошо проиндексировать.
Наверняка здесь есть гуру, которые могут объяснить.



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

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

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

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

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

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

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

Кстати, первоначально MDM делался на ABAP-платформе самим SAPом. Но потом, намаявшись с ним, купили совсем другой продукт небольшой израильской компании, написаный на Java и скомпилированный в нативный код (видимо, берегут так ноу-хау свои). Предполагаю, что здравый смысл победит, и однажды этот продукт сделают нормальным приложением Java, работающим под SAP Java WAS. Пока же эта нативность дает только кучу проблем и глюков.

Большое спасибо за подробные и дельные советы!
Ответил также в личку.