Техники расширений стандартной системы SAP. Обзор ситуации. Пользовательские расширения

Уважаемые коллеги!

Я начинаю публикацию на портале SAPLand цикл статей «Техники расширений стандартной системы SAP».

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

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

Все статьи цикла приведены внизу публикации.

1. Обзор ситуации

1.1. Необходимость расширений

Система SAP развивается уже более 40 лет; за это время количество поддерживаемых бизнес процессов и вариантов их использования исчисляется, наверное, тысячами. Для конфигурирования поведения системы в рамках пользовательского бизнес процесса предоставляется специальное конфигурационное меню системы (Транзакция SPRO). Однако на практике возникают ситуации, когда конфигурирования недостаточно и требуется программное вмешательство в работу стандартных алгоритмов системы.

Разработчики системы SAP, «иногда» понимали, что они не смогут перекрыть все варианты построения бизнес-процесса клиента. Например, какие-то специфические проверки при формировании значений в полях ввода. Конечно, с одной стороны очень просто активировать маску ввода для любого поля экрана, которое не привязано к проверочной таблице. Однако, если в внутри маски, например, символы с 5 по 8 должны содержать код балансовой единицы, которую надо проверить на существование, то возникает альтернатива: реализовать на уровне системы какой-то сложный анализатор масок ввода (с привязкой к проверочным таблицам) или использовать другие механизмы проверки значений. Самым простым способом является предоставление возможности включения программного кода проверки клиенту, внедряющему у себя систему SAP. Однако, методика включения такого кода может быть очень различной.

1.2. Варианты включения пользовательского кода

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

Второй вариант - это разработка механизмов включения пользовательского кода в стандартную бизнес-логику работы программы.

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

2. Пользовательские расширения

2.1. Эволюция техник расширения

В общем случае, точки, в которых пользователю можно расширить логику работы системы, называют точками пользовательского расширения системы (User Exits). Однако, в связи с тем, что система развивается и существует уже более 20 лет (имеется в виду версия SAP R/3), вместе с её изменением менялись взгляды и подходы к реализации пользовательских расширений. Поэтому к настоящему моменту система имеет множество различных вариантов использования программных расширений. При этом как техника расширения, так и возможности, определяемые вариантами использования, могут кардинально отличаться.

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

Рис.1. Эволюция техник расширения системы

2.2. Доступные техники расширений

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

• Field-Exit – Наверное, один из самых старых вариантов включения пользовательских расширений в логику работы программы. В общем виде, данное расширение позволяет проверить значения, введенные (в диалоге или при использовании пакетного ввода) в поля стандартных транзакций. В данном типе расширения можно только проверить введенное пользователем значение, например, на существование в каком-то справочнике или сформировать/проверить введенные данные по собственной маске. К сожалению, получить «регламентированный» доступ к значениям других полей в контексте выполнения программы, для общего анализа введенных в поле данных – невозможно. Однако, существуют механизмы, которые позволяют все - таки обойти это ограничение.
• Customerexits (Проекты расширений) – пользовательские расширения, использующие технику проектов, транзакции CMOD/SMOD. Данная техника используется практически в любой функциональности системы. Это наиболее широкий способ использования программных расширений. Для реализации технологии, используется вызов специального функционального модуля, для этого в язык системы был введен отдельный оператор вызова функции расширения. Основная проблема данного типа расширений - это поддержка написанного кода расширения несколькими разработчиками, кроме того отсутствует возможность «регламентированного» доступа к переменным вне функционального модуля системы, т.е. разработчики заранее определили набор переменных, которые передаются для анализа и набор переменных, которые можно изменить в данном типе расширения. Как и при использовании техники Field-Exit существует механизм обхода ограничения на доступ к переменным. Решение об использовании такой техники, принимает пользователь. Разработчики SAP не используют такого рода расширений, эта техника полностью отдана на откуп клиентам. Я встречал рекомендацию: если это возможно, в общем случае, использовать именно этот механизм расширений.
• Userexits (Пользовательские подпрограммы) – пользовательские расширения для которых требуется получение ключа разработчика, так как реализация данного расширения представляет собой модуль находящийся в пространстве имен SAP. При этом в данном модуле реализованы подпрограммы, в которые требуется добавить пользовательский код. Так как эти подпрограммы выполняются в рамках контекста