Ведение пользовательских настроек в кластерах ракурсов

office-configuration-tool

Очень часто в процессе разработки необходимо предоставить гибкость программного решения, в зависимости от каких-либо требований, определенными теми или иными настройками. Подобная гибкость в SAP системах традиционно решается путём определения пользовательских настроек в транзакции SPRO.  В статье будет рассмотрен способ определения своих настроек на базе ведения многоуровневого кластера ракурсов и создание ссылки на него в SPRO.

Транзакция SPRO открывает заранее определенную иерархическую структуру, в которой настройки разделены относительно функциональности:

1

Большинство настроек в SPRO представляют собой ссылки на переход к ведению данных в простом ракурсе ссылающемся на какую-либо таблицу, однако встречаются и кластеры ракурсов – набор ракурсов объединенных либо в иерархическую структуру, либо сгруппированных вместе. В качестве примера можете перейти по следующему адресу:

2

Как видно из рисунка, настройка представляет собой кластер ракурсов (набор ракурсов) объединенных для ведения в рамках одной настройки:

3

В кластере присутствует 5 вложенных ракурсов: часовые пояса, правила для часовых поясов, правила для летнего времени и др. Кластеры не связаны друг с другом иерархией, они не зависимы друг от друга.

Встречаются и такие кластеры ракурсов, где один ракурс, может быть зависимым от другого ракурса, в таком случае, чтобы перейти в ведение зависимого, потребуется выбрать запись из ракурса на уровне выше, пример:

4

Для того чтобы перейти на изменение в «Присвоение логический путь – физический путь» необходимо выбрать запись в ракурсе «Определение логических путей к файлу»:

5

Определение кластера ракурсов

В качестве простого примера создадим кластер ракурсов, состоящий из трёх ракурсов, первые два будут зависимыми, третий будет сам по себе.

Предположим у нас есть система, в которой относительно одного логина могут работать сразу несколько человек, каждый из которых может быть пользователем определенного типа (администратор или рядовой пользователь) и нам необходимо настроить ведение людей относительно логина. Кроме того, нужно иметь возможность в рамках одного кластера ракурсов хранить настройку e-mail’ов для типа пользователя.

Первым шагом идет определение Z таблиц (тр. SE11).

Для всех таблиц проставим следующие параметры поставки:

6

Таблица ZCUST_LOGINS:

7

Определим домен ZCUSD_LOGIN_TYPE:

8

Для домена зададим диапазон значений:

9

Определим элемент на базе домена:

10

Таблица ZCUST_LOGIN_INFO:

11

Таблица ZCUST_ROLE_MAILS:

12

После создания таблиц и элементов данных необходимо подготовить ракурсы ведения для каждой из таблицы (тр. SE11). Но перед этим создадим группу функций, отвечающую за хранение сгенерированных к ракурсам ФМ по обновлению данных и экранов. Назовем её ZFG_UCONF. Создать группу функций можно в транзакции SE80.

Ракурс ZCUST_V_LOG:

13

Ракурс ZCUST_V_INF:

14

Для данного ракурса поля LOGIN и MANDT будет образовывать подмножество, т.е. перед тем как начать ведение ракурса необходимо будет задать ограничение по этим полям (можете попробовать нажать просмотр данных), необходимо проставить флаг «S».

В кластере ракурсов ракурс ZCUST_V_INF будет зависимым от ракурса ZCUST_V_LOG, таким образом, поля LOGIN и MANDT через настройку зависимости будут автоматически заполняться по выбранной записи выше по иерархии.

Ракурс ZCUST_V_MAILS:

16

Далее для всех ракурсов будем генерировать ракурс ведения, Меню -> Утилиты -> Генератор ведения таблиц:

17

Так как группа функций у нас будет одна, экраны должны иметь разные названия для каждого ракурса: 101 – для ZCUST_V_LOG, 102 – ZCUST_V_INF и т.д. Если наши настройки должны автоматически попадать в запрос на перенос, для этого необходимо проставить галочку – «Стандартная программа записи» (после генерации экрана).

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

После определения всех ракурсов необходимо объединить их в кластере. Создание кластера ракурсов происходит в транзакции SE54 -> Обработка кластера ракурсов. Назовем наш кластер ZCUST_VC_CONF:

18

Обработка иерархической операции ведения может принимать следующие значения:

Показывать диалоговое окно. Если вы меняете запись в ракурсе, от которой зависят другие записи в зависимом ракурсе, будет появляться диалоговое окно, в котором необходимо будет выбрать решение того, что делать с зависимыми записями:

19

Без диалога с изменением зависимых записей. В этом случае все зависимые записи будут так же удалены (изменены).

Без диалога и без изменения зависимых записей (ограничение на один уровень). Зависимые записи не будут затронуты.

Вид считывания отвечает за то, как будут считываться записи из БД. Если стоит первый вариант, все данные для всех кластеров будут считаны сразу. Если второй вариант, данные будут считаны только для первого ракурса и зависимых от него. Остальные будут считываться по мере необходимости. Обычно второй вариант выставляется для оптимизации при большом кол-ве данных в ракурсах.

Перейдем в структуру объекта. В структуре кластера прописываются все ракурсы, из которых он состоит:

20

Кроме того указывается зависимость ракурсов, в нашем случае ракурс ZCUST_V_INF зависим от предыдущего ZCUST_V_LOG, а ракурс ZCUST_V_MAILS ни от кого не зависит. Зависимость может иметь несколько типов:

  • R – Без зависимостей
  • S – Зависимость от одной записи в главном ракурсе.
  • M – Зависимость от нескольких записей в главном ракурсе. Этот тип применим тогда, когда относительно нескольких записей в главном ракурсе, необходимо редактировать все от них зависимые в зависимом ракурсе. Пример такого ракурса: T804.

Для настройки зависимостей необходимо выделить строку с ракурсом ZCUST_V_INF и перейти в настройку зависимости и прописать зависимые поля (если будут прописаны внешние ключи в таблицах и на предыдущем экране нажать на кнопку «зависимость поля», выделив зависимый ракурс, система пропишет зависимость за вас):

21

После настройки кластера ракурса, его необходимо активировать, делается это по кнопке в определении заголовка (первый экран ведения ракурса). После активации можно выйти на предыдущий экран и протестировать наш кластер:

22

В итоге мы можем завести учётные данные (логины):

23

Относительно каждой учётной записи завести людей, которые ими пользуются и к какому типу они принадлежат:

24

Относительно типа пользователя определить в настройке почтовый адрес:

25

Создание ветки в SPRO

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

Обычно создание своих веток происходит через транзакцию SIMGH, но в нашем случае мы будем расширять стандарт (транзакция SPRO отображает определенную заранее IMG структуру), поэтому воспользуемся транзакцией S_IMG_EXTENSION:

Первым делом выбираем стандартную IMG структуру:

26

Далее необходимо создать ID расширений:

27

28

После создания ID расширения, выбираем его и нажимаем кнопку «Расширить структуру», в итоге попадаем на экран ведения стандартной структуры SPRO.

Создадим узел на том же уровне:

29

Далее вставим новую операцию, при создании операции желательно документировать её, создав документ описания:

30

Созданный документ можно будет просмотреть в описании к настройке:

31

На закладке объекты ведения необходимо прописать наш кластер:

32

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

33

Дополнительная информация

Если вдруг возникает желание проверить, каким образом сконфигурировано действие в IMG структуре, сделать это можно перейдя по меню к технической информации:

34

35

Одноуровневые ракурсы ведения отображают для редактирования экранную таблицу, но при большом количестве полей требуется прокручивать таблицу, так как таблица не растягивается на весь экран:

36

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

После создания кластера может потребоваться создание транзакции к его ведению, сделать это можно через создание транзакции с параметрами к SM34:

1

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

Официальная документация по кластерам и генератору ведения доступна по ссылке.

  • Timofey Valetskiy

    Михаил, спасибо. Я создавал ранее кл. ракурса, но детали подзабыл. У тебя все нашел. Удачи.

    • Пожалуйста, Тимофей. Сам постоянно забываю)

  • Мария

    Михаил, спасибо большое за статью, очень пригодилась.

    Пыталась, кстати, ещё добавить помимо кластера ракурсов свою Z-транзакцию, запускающую отчёт, но всё время получала ошибку, что моей транзакции нет в списке объектов.

    Выяснилось, что название транзакции нужно ещё добавить через ракурс ведения SOBJ в таблицу OBJH, чтобы она появилась в SPRO.

    Возможно, мой комментарий сэкономит чьё-то время)