BC400_RU_ECC_2005
.pdf
BC400 |
Урок: Считывание таблиц базы данных |
REPORT sapbc400dds_select_sflight_tab.
DATA: it_flight TYPE sbc400_t_sbc400focc,
wa_flight LIKE LINE OF it_flight.
PARAMETERS pa_car TYPE s_carr_id.
* Select all flights belonging to PA_CAR :
SELECT carrid connid fldate seatsmax seatsocc
FROM sflight
INTO CORRESPONDING FIELDS OF wa_flight
WHERE carrid = pa_car.
*Calculate occupation of flight wa_flight-percentage =
100 * wa_flight-seatsocc / wa_flight-seatsmax.
*Insert flight into internal table
INSERT wa_flight INTO TABLE it_flight.
*If you are using standard tables, "APPEND wa_flight TO it_flight."
*would be the same as the above INSERT-statement.
ENDSELECT.
IF sy-subrc = 0.
*Sort internal table
SORT it_flight BY percentage.
*Create list
LOOP AT it_flight INTO wa_flight. WRITE: / wa_flight-carrid,
wa_flight-connid, wa_flight-fldate, wa_flight-seatsocc, wa_flight-seatsmax, wa_flight-percentage, ’%’.
ENDLOOP.
ELSE.
WRITE: ’No ’, pa_car, ’flights found !’.
Продолжение на следующей странице
|
© 2006 г. SAP AG All rights reserved. Авторские |
171 |
06-04-2006 |
права защищены. |
Глава 5: Сбор данных |
BC400 |
ENDIF.
172 |
© 2006 г. SAP AG All rights reserved. Авторские |
|
права защищены. |
06-04-2006 |
BC400 |
Урок: Считывание таблиц базы данных |
Резюме по уроку
Теперь вы сможете:
•перечислять различные методы поиска соответствующих таблиц баз данных
•реализовывать доступ для чтения к определенным столбцам и строкам в таблице базы данных
•описывать различные способы получения доступа для чтения к нескольким таблицам базы данных
|
© 2006 г. SAP AG All rights reserved. Авторские |
173 |
06-04-2006 |
права защищены. |
Глава 5: Сбор данных |
BC400 |
Урок: Проверка полномочий
Обзор урока
На этом уроке описываются цели использования проверки полномочий и способы ее внедрения в программах.
Цели урока
Прослушав этот урок, вы сможете
•пояснять концепцию полномочий SAP
•внедрять проверки полномочий
Практический пример
Проверки полномочий в программах необходимы для защиты данных от несанкционированного доступа.
Проверки полномочий
Критически важные данные и функции SAP-системы должны быть защищены от несанкционированного доступа. В рамках имеющейся программы необходимо внедрить проверки полномочий для предоставления пользователям доступа лишь к тем областям, на работу с которыми у пользователей имеются полномочия. Концепция полномочий SAP представлена на рисунке ниже.
174 |
© 2006 г. SAP AG All rights reserved. Авторские |
|
права защищены. |
06-04-2006 |
BC400 |
Урок: Проверка полномочий |
Рисунок 101: Концепция полномочий SAP
Рисунок 102: Объекты полномочий и полномочия (пример)
|
© 2006 г. SAP AG All rights reserved. Авторские |
175 |
06-04-2006 |
права защищены. |
Глава 5: Сбор данных |
BC400 |
Объекты полномочий могут быть определены в рамках классов объектов.
При определении объекта полномочий необходимо указать соответствующие поля (без значений). Фактические полномочия создаются путем присвоения значений полям. Полномочия могут быть интегрированы в необходимые
основные записи пользователей посредством профиля полномочий.
Для объекта полномочий может быть создано несколько разных видов полномочий (для интеграции в различные основные записи пользователей).
Рисунок 103: Проверка полномочий (принципиальная схема)
Для проверки наличия в основной записи пользователя необходимых полномочий на использование функции во время выполнения может использоваться оператор AUTHORITY-CHECK . Выполнение программы продолжается при получении положительного результата проверки
(sy-subrc):
sy-subrc = 0: пользователь имеет требуемые полномочия -> выполнение функции (например, SELECT);
Else: полномочия отсутствуют -> вывод соответствующего сообщения для пользователя.
Рекомендация: Помимо вышеописанного, проверки полномочий могут также использоваться для защиты программ и транзакций. Однако подобные проверки должны считаться лишь дополнением к вышеописанной концепции, но не заменять ее.
176 |
© 2006 г. SAP AG All rights reserved. Авторские |
|
права защищены. |
06-04-2006 |
BC400 |
Урок: Проверка полномочий |
Как правило, определение объекта полномочий и внедрение проверок полномочий входит в сферу ответственности разработчиков, тогда как за последующие шаги, такие как определение полномочий и определение профиля, а также разработку основных записей пользователей, несет ответственность администратор.
В следующем разделе представлено описание двух шагов, выполняемых разработчиком.
Рисунок 104: Создание объектов полномочий
Перед внедрением требуемой проверки полномочий в программе, необходимо определить структуру (поля) соответствующей концепции полномочий. В состав объекта обычно входит поле ACTVT (операция) и дополнительное поле, в котором указывается тип защищаемых данных (например, номер материала, авиакомпания и т.д.). Значения этих полей полномочий указывают возможность выполнения тех или иных операций пользователем.
После этого для создания полей используется транзакция SU20. Поле ACTVT уже существует в системе.
Затем выполняется транзакция SU21 для создания класса объектов и последующего создания объекта полномочий путем указания соответствующих полей. Если в состав объекта входит поле ACTVT,
необходимо также выполнить ведение допустимых операций в отношении объекта. При этом из всех возможных операций выбираются те, применение которых в отношении данного объекта является целесообразным.
|
© 2006 г. SAP AG All rights reserved. Авторские |
177 |
06-04-2006 |
права защищены. |
Глава 5: Сбор данных |
BC400 |
Наконец, проверка полномочий внедряется в программе. Проверка полномочий представлена на следующем рисунке.
Рисунок 105: Проверка полномочий (пример синтаксиса)
Для проверки полномочий в программе указываются те полномочия, наличие которых должно проверяться в основной записи текущего пользователя. Полномочия указываются путем ввода объекта полномочий, его полей, а также соответствующих значений полей. Синтаксис см. на представленном выше рисунке.
Врассматриваемом примере выполняется проверка того, имеет ли пользователь полномочия для объекта S_CARRID, для которого в поле CARRID (авиакомпания) содержится название авиакомпании, введенное пользователем, а в поле ACTVT (операция) содержится значение "03" (просмотр).
Втаблице ТАСТ содержатся все возможные коды операций и их описания. В свою очередь, таблица TACTZ содержит коды операций, которые являются
допустимыми для конкретных объектов.
178 |
© 2006 г. SAP AG All rights reserved. Авторские |
|
права защищены. |
06-04-2006 |
BC400 |
Урок: Проверка полномочий |
После выполнения оператора AUTHORITY-CHECK необходимо проверить код возврата sy-subrc и соответствующим образом скорректировать дальнейшее выполнение программы.
Рекомендация: Если какое-либо поле не должно включаться в проверку, можно либо не вводить его в оператор AUTHORITY-CHECK, либо ввести DUMMY в качестве значения этого поля. Запись "DUMMY" представляет собой предварительно определенное описание, вводимое без кавычек.
Пример подавления проверки поля: при вызове транзакции изменения всегда производится проверка наличия у пользователя полномочий на изменение данных любой авиакомпании. Если проверка завершается неуспешно, для пользователя немедленно выводится соответствующие сообщение. Для внедрения такой проверки может использоваться следующий синтаксис:
AUTHORITY-CHECK OBJECT ’S_CARRID’
ID ’CARRID’ DUMMY
ID ’ACTVT’ FIELD ’02’.
Рисунок 106: Внедрение проверок полномочий в программах
|
© 2006 г. SAP AG All rights reserved. Авторские |
179 |
06-04-2006 |
права защищены. |
Глава 5: Сбор данных |
BC400 |
Во избежание орфографических ошибок в именах объектов и полей следует использовать оператор AUTHORITY-CHECK, генерируемый в исходном тексте при использовании кнопки Модель . После этого выполняется ведение значений полей и внедрение проверки sy-subrc.
180 |
© 2006 г. SAP AG All rights reserved. Авторские |
|
права защищены. |
06-04-2006 |