Коллеги, добрый день.

Система SAP ERP ECC 6.0 EHp2 + Oracle 10.2.0.5.0. на HP-UX IA64
Наблюдается странная картина:

- есть некоторые пользователи, которым присваиваю роль в системе, затем иду выравнивать, и в списке пользователей роли нет нужного юзера,
жду некоторое время, снова проверяю нет, ради эксперимента присваиваю эту же роль другим случайным пользователям и вуаля они почти сразу появляются в списке юзеров роли(PFCG). Кроме того периодически происходят глюки, некорректно выполняется проверка полномочий, а именно, пользователь начинает жаловаться, что у него нет полномочий на то, что он всегда делал, я начинаю смотреть выяснять и вижу что эти полномочия есть и соответствующие роли с этими полномочиями у него также есть. Пока разбираюсь, пользователь мне говорит, все ок, снова все есть. Подобные случаи со всевозможными вариациями постоянно повторяются. Я предполагаю, что в этом механизме участвуют RFC и сетевые подключения(тоже распределение изменений пользователей по системам через CUA). Но я с таким ни разу не сталкивался и никаких ошибок в системном журнале, при выравнивании, при изменение данных юзеров нет. Я даже не знаю с какой стороны подойти, как работает логика данного механизма и где можно посмотреть, куда копать, помогите.

Скорее всего CUA айдоки не своевременно обрабатываются.
Подобные лаги возникают когда в систему поступает большое количество idoc.
Посмотреть очередь на обработку и статус можно в транзакции BD87.

Так, нашел в idoc проблемного юзера, с ним оказалось что из-за того что я сидел в этой роли в целевой системе, idoc на его изменение висел со статусом что я заблокировал роль, с этим я справился все ок, но вопрос, если вот так запрос не прошел или с ошибкой то пока руками сам не исправишь так и будет, правильно я понимаю? Даже несмотря на то, что в центральной системе CUA в данных юзера у меня в списке ролей она есть в целевой системе?

И очередь просмотреть в BD87 "Перейти" - "Транзакционный RFC" - "Просмотреть IDoc - записи очередь в tRFC - очереди" - это оно?
Только не очень понимаю а как очередь из idoc связана с тем, что у пользователя периодически глюки с полномочиями? Проверка полномочий тоже выполняется через запросы idoc?

на стороне CUA, тр. SCUL Вам в помощь.

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

Благодарю за развернутый ответ.
С этим я уже разобрался и причину нашел. Но вот остался 2ой вопрос, а именно - это то, что периодически отваливаются полномочия, а потом сами появляются. При этом, как я писал выше, когда проверяю их(полномочия) на наличие у конкретного юзера, они есть и все в порядке. Хотелось бы понять механизм и логику работы проверки полномочий.

Добавлю ещё момент, если один из IDOC встал с ошибкой, вы сгенерировали другие, они прошли внесли изменения, а потом перезапустили ошибочный IDOC, то пользователь откатиться на версию прав содержащихся в нём.

Глюки с полномочиями могут быть связанны с тем, что у вас есть фон который перезапускает ошибочные IDOC, тем самым затирая ваши изменения.

проверить логи фоновых заданий: нет ли "перекрытий" (с бэкапом, например), правильность задания манданта и юзера исполнения:
контрольный список примерно таков:
RSETESTD
RHALEINI
RBDAPP01
RHPROFL0
RHAUTUPD_NEW

По RBDAPP01 нашел задания, пользователь RFC_CUA, мандант правильный. Не уверен что понимаю, что Вы имели ввиду под "перекрытиями", задания эти выполнялись в среднем по 10-15 секунд, практически без задержек. Но вот в логах некоторых из них я увидел массу(100 и более) записей типа:
"Запрошенный объект сейчас блокирован пользователем RFC_CUA."
Полагаю, что из предыдущих заданий этого же типа, которые не завершились и вносили изменения в те же объекты. Но я пока все равно не улавливаю связи с отваливающимися полномочиями, которые были присвоены более недели назад и даже раньше.

Это конечно вероятно, ибо система досталась мне после 2 летней самостоятельной жизни и отсутствием какой либо документации. А каким образом можно выяснить, найти фон который перезапускает idoc, я с таким не сталкивался. Тот список, что привел Skif ниже из ABAP программ, из него я нашел только RBDAPP01 и то они были не запланированы, а выполнялись в фоне после моих действий по изменению юзеров.

нельзя смешивать ручное и HR-ORG присвоение. RHPROFl0 будет обрывать ручные присвоения. PFUD будет "дообрывать" вложенные в композитные single-роли. Конечно, можно это отрегулировать настройками запуска программ.
Кстати, роли у вас присваиваются локально или из CUA? Если из CUA, то может быть неконсистентность оргструктуры в HR и CUA. Обязательно, перед работой CUA надо RHALEINI-ть оргструктуру. Необходимо правильно распределить, что где ведётся и не использовать "и там и там". Например, роли, параметры и лицензии необходимо вести локально (потому как эти параметры в разных системах для одного пользователя могут отличаться)

Вот список программ для обработки IDOC вручную:

Тут немного подробнее: How to Reprocess the IDOC in Both Inbound & Outbound

CUA отлично разруливает разные роли и лицензии с привязкой к конкретным системам централизованно, что очень удобно, надо пользоваться. А вот, насчёт параметров, соглашусь, разделения по системам нет.

может быть давно делал и сейчас не вспомню почему принял такое распределение, но возился долго. у меня реализоваy "полный автомат", т.е. нет админа юзеров-полномочий. Роли пришлось сделать все композитные, и в CUA идут "пустышки", чтобы только была связка AG-S - из имени роли в CUA считывается система и мандант создания юзера (для центральной RHPROFL0). В рабочих реальные роли (с single-наполнителем) присваиваются в допиленной локальной RHPROFL0. Лицензии задаются в параметрах её запуска - в разных системах получается своя. Под финал выравниваются композит и сингл. И так каждую ночь. Утром операдмин смотрит почту - "создан, блокирован, присвоено, отнято" и закрывает заявки.

Да, у меня CUA и оно глобально по всем параметрам. Ручное я понимаю что за присвоение, а что такое HR-ORG? А можно по простому, как обычно делают, я например, веду вручную роли, имею ввиду присвоение, затем если нужно юзеру прямо сейчас полномочия, выравниваю их в целевой системе через PFCG. Если не срочно, то фоновое задание PFCG_TIME_DEPENDENCY каждый день крутится. С CUA я не работал, на прежнем месте у нас его не было, планировали ввести, но не успели. "надо RHALEINI-ть оргструктуру" - это я так понимаю выполнить отчет RHALEINI и если да, то в какой системе? Или я не правильно понял?

Кратенько и просто, для ландшафта D-Q-P + solman.
Роли делаем в D, тащим транспортом в P.
Всё в CUA глобально, кроме разблокировки пользователей и параметров.
Всем остальным управляем через солюшен.