Содержание

0. Зачем это нужно

1. Введение

2. Персонализация

3. Расширение описаний Словаря Данных

4. Customer Exits

4.1. Расширения программ

4.2. Расширения меню

4.3. Расширения экранов

5. Business Transaction Events

0. Зачем это нужно

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

SAP предоставляет большой набор технологий и реализующих их инструментов, позволяющих изменить работу существующего программного обеспечения так, чтобы прием новых версий от производителя не приводил к потере изменений. Все они называются (в широком смысле) «enhancements», традиционно в нашем контексте это слово переводится как «расширения», мы в дальнейшем будем использовать именно этот вариант перевода. Существует несколько возможностей расширения, а раз так, то все они имеют свои достоинства и недостатки, и – стало быть – собственные области применения.

Однако в ряде случаев все же приходится вносить изменения непосредственно в поставляемое программное обеспечение с риском потери этих изменений при установке новых версий. Все такие случаи нужно контролировать, и для этого SAP тоже имеет соответствующие инструменты. Если придет новая версия, конфликтующая с внесенными изменениями, то приходится решать:  

- принимать ли новую версию и тем самым терять свои модификации;     

- сохранять ли старую версию и тем самым терять все то новое, что содержится в новой версии;       

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

Это называется «adjustment», мы будем переводить это словом «корректировка». Раз уж возможен прием новых версий, которые отменят внесенные изменения, то нужны инструменты, позволяющие определить, в чем новые версии конфликтуют со старыми, и осуществлять корректировку. Такие инструменты в SAP тоже есть.

Основные концепции, технологии, инструменты, возможности, синтаксические конструкции, связанные с расширениями и модификациями изучаются в пятидневном семинаре BC425. Расширения и модификации.

1. Введение

Изменить работу стандартного программного обеспечения SAP можно различными способами:      

- настройка (customizing) позволяет сконфигурировать бизнес-процессы и -функции в соответствии с конкретными потребностями, стандартные настройки SAP собраны в транзакции SPRO в разделе SAP Img (SAP Implementation Guide);

- персонализация (personalization) позволяет создать окружение, нужное для работы конкретного пользователя или всех пользователей той или иной роли, обычно не требует серьезной разработки (хотя при персонализации часто возникают объекты репозитария, обычно относящиеся к разработкам), например, персонализация позволяет создать ролевые меню для пользователей, вариантные транзакций, упрощающие состав экранов;       

- расширения (enhancement) в широком смысле представляют собой изменения в таких объектах репозитария, новая версия которых никогда не придет от поставщика, таким образом, риск потери изменений при правильном применении расширений не возникает;   

- модификация (modification) пердполагает изменение объектов репозитария созданных поставщиком (SAP или партнером) и, следовательно, приводит к риску потери изменений при приеме новых версий;  

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

Расширения словаря позволяют (если это специально не запрещено) добавлять новые поля к таблицам и ракурсам (view), добавлять новые элементарные средства поиска к комплексным, фиксированные значения или диапазоны к доменам. Можно менять тексты элементов данных.

Расширения программ всегда представляют собой вызов таких «кусков» программного кода, новая версия которых никогда не придет от поставщика. Это можно делать с помощью традиционных технологий User Exits, Customer Exits, Business Transaction Events, классические BAdI и нескольких новых (с версии 7) технологий, объединенных в рамках Enhacement Framework.

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

Расширения экранов позволяют дополнить экран новыми экранными элементами, если это предусмотрено поставщиком. Важно, что эти новые элементы создаются на подэкране некоторой другой программы. А раз эти элементы принадлежат другой программе, то нужно позаботиться, чтобы данные попали в эту другую программу, а после изменения связанных с ними данных, эти измененные данных должны быть возвращены обратно. Поэтому каждое расширение экрана обычно сопровождается парой программных расширений (передача «туда» и получение «оттуда»).

Желательно, чтобы технологии расширения допускали множественную имплементацию. Чтобы различные разработчики (разные партнеры и сами клиенты) могли бы к одному и тому же месту подключать различную функциональность. Разумеется, разработчики расширений тоже могут быть заинтересованы в том, чтобы и сами их расширения могли бы быть расширены. И так далее. Хотелось бы, чтобы технологии расширений были в этом смысле транзитивны.

Существует несколько технологий программных расширений. Исторически первая из них User Exits состоит в том, что по ходу исполнения ABAP-программы вызываются особые подпрограммы. Изначально эти подпрограммы не содержат ничего, кроме комментариев. При необходимости можно изменить код этих подпрограмм. Эти подпрограммы собраны поставщиком в инклюды, причем новая версия этих инклюдов от поставщика никогда не придет. Поэтому нет риска потери своих изменений при приеме новых версий. Весьма часто для получения нужного эффекта требуется реализация сразу нескольких таких подпрограмм в режиме все или ничего: либо все они работают, либо ни одна не работает. Недостатком этой технологии является то, что в ней нет инструмента, позволяющего осуществлять включение/выключение. Хотелось бы иметь общий «рубильник».

В рамках технологии Customer Exits по ходу исполнения ABAP-программы вызываются функциональные модули. Но вызываются они специальной ABAP командой, которая по содержимому специальной конфигурационной таблицы принимает решение, следует ли действительно вызывать этот функциональный модуль. Таки образом, появляется возможность одновременно включить или выключить сразу несколько программных расширений. Внутри такого функционального модуля написано обращение к инклюду, новая версия которого никогда не придет от поставщика, поэтому нет риска потери изменений при приеме новых версий. Обе технологии User Exits и Customer Exits обладают общим недостатком – пользовательский программный текст пишется в инклюдах, имена которых статически зашиты в вызывающие программы, а потому нет возможности множественной имплементации. А хотелось бы.

Технология Business Transaction Events (BTE, ранее именовалось Open FI) допускает множественную имплементацию. Она состоит в том, что в нужные места ABAP-программы вставлены вызовы функциональных модулей, внутри которых циклически вызываются те функциональные модули, которые зарегистрированы на это событие и перечислены в особой конфигурационной таблице. На одно BTE может быть зарегистрировано несколько функциональных модулей в том числе от разных поставщиков, следовательно, возможна множественная имплементация. Имена этих функциональных модулей выбираются разработчиками клиентов или партнеров (желательно из собственного уникального диапазона имен, ну или хотя бы на «Z_») и потому можно избежать риска потери изменений при получении новой версии от поставщика. Более того, SAP понимает, что разработчики программных расширений заинтересованы в максимально широком распространении своих расширений, а потому SAP предусмотрел особый, пользовательский диапазон номеров BT-событий (начиная с 9000000), что позволяет разработчикам расширений делать свои расширения расширяемыми и дальше. Недостаток в том, что этот диапазон номеров един для всех. То есть, хотя имплементации множественны и транзитивны, но увы транзитивность имплементаций не множественна.

Классические Business Add-Ins (BAdI) устроены так. Разработчик поставщика создает объект репозитария типа BAdI, которому соответствуют некоторый интерфейс (в смысле объектно-ориентированного программирования) и служебный класс, обладающий этим интерфейсом. В ABAP-программе создается сначала объект этого служебного класса, п потом в нужных местах вставлены вызовы его методов. Разработчик клиента (или партнера) создает в репозитарии объект типа имплементация, указывая при этом, какой именно BAdI имплементируется, этой имплементации соответствует класс, обладающий интерфейсом, указанным для BAdI, методы этого класса имплементируют определения методов интерфейса BAdI. Методы служебного класса состоят в том, что последовательно (в цикле) исполняются методы всех активных имплементаций. Поэтому программные расширения с помощью BAdI допускают множественную имплементацию. Эта технология сколь угодно транзитивна (в имплементациях можно предусмотреть BAdI для дальнейшего расширения создаваемых расширений и так далее). Транзитивность вполне множественна, поскольку BAdI, их имплементации, классы, интерфейсы – это самостоятельные объекты репозитария они имеют имена. Надо только давать эти имена из своего уникального диапазона имен.

Все названные технологии обладают общими недостатками. Наиболее существенные из них следующие. Программные расширения можно сделать только в тех местах, где разработчиком заранее предусмотрены соответствующие вызовы: (1) на две строчки раньше, та три строчки позже ... увы, увы; (2) все эти технологии предполагают только добавление новой функциональности (ну а как иначе, ведь расширение же), а если требуется заменить ненужную на нужную, или просто отменить, ничего не получится; (3) технологий несколько, и каждая (кроме User Exits) имеет свой собственный инструмент включения/выключения («рубильник»), а User Exits вообще не имеет такого инструмента. Часто же нужно одновременно включить/выключить сразу несколько расширений сделанных, быть может, по разным технологиям.

В седьмой версии ситуация радикально улучшилась. Теперь мест, к которым можно сделать свои расширения стало гораздо больше; появилась возможность не только добавлять новую функциональность, но и заменять или даже отменять старую – это называется Enhancement Framework. Появился инструментарий, позволяющий разумным образом включать/выключать расширения, сделанные в рамках Enhancement Framework, и разрешать возникающие конфликты – это называется Switch Framework.

2. Персонализация

С помощью транзакции SE43 можно создать меню функциональной области (Menu Area) и включить в него другие меню, нужные транзакции, отчеты. Меню функциональной области это отдельный объект репозитария и ему нужно дать допустимое имя. Желательно из своего диапазона, или в крайнем случае назвать его на «Z» или «Y». При включении отчетов будут автоматически созданы транзакции для их запуска.

Роли и ролевые меню создаются транзакцией PFCG и подробно рассматриваются в трехдневном семинаре ADM940. Концепция полномочий для SAP S4/HANA и SAP Business Suite.

Функциональность программного обеспечения, поставляемого SAP, предназначена для автоматизации информационных потоков многих различных вариантов ведения бизнеса. Поэтому в ряде случаев она может оказаться избыточной для конкретных случаев, на экранах могут оказаться ненужные в данном случае поля, органы управления. Для упрощения транзакций можно создать транзакцию варианта. Сначала с помощью транзакции SHD0 создается вариант транзакции (Transaction Variant). Он состоит из вариантов экранов, появляющихся при проходе транзакции. В этих вариантах экранов можно деактивировать, «выключить» ненужные поля экрана и функциональные коды ненужных органов управления. Можно также некоторые поля оставить на экране, но запретить изменение значений в этих полях. С помощью инструмента GUI XT можно добавить на варианты экранов некоторые экранные элементы, например, рисунки или нажимные кнопки. Добавление новых кнопок не может расширить функциональность, но может упростить работу: в случае, если часто используется пункт меню, допустим, третьего уровня вложенности, можно соответствующий этому пункту функциональный код вынести на добавляемую нажимную кнопку.

Над созданным вариантом транзакции (Transaction Variant) можно создать транзакцию специального типа – транзакцию варианта (Variant Transaction, ну да, такая у нас терминология).