Нестандартные проверки в транзакциях логистики

SAP предоставляет множество инструментов для адаптации системы к потребностям конкретного предприятия. Такими инструментами, например, являются User-Exit и Badi-расширения. Как правило, с помощью User-Exit и Badi дополняют логику стандартного SAP-бизнес-процесса специфичными для предприятия данными, правилами выполнения и проверками.

Остановимся более подробно на реализации контрольных проверок, т.е. рассмотрим случай использования User-Exit и Badi для проверки корректности пользовательского ввода и анализа допустимости дальнейшего выполнения бизнес-процесса. Про развитие ABAP-кода таких расширений можно сказать, что «аппетит приходит во время еды». Как правило, при внедрении SAP-системы, выполняется реализация только необходимого минимума таких проверок. Затем, в процессе продуктивной эксплуатации системы, возникает желание максимально защитить систему проверками от любого некорректного ввода данных. Всё это выливается в то, что при обнаружении каждой новой ошибки ввода в код расширения дописывается очередное «if-else» условие, обрабатывающее выявленную ошибочную ситуацию. В итоге через 3-4 года эксплуатации системы код расширения может превратиться в сотни строк плохо читаемого кода с большим количеством констант – ошибочная ситуация, как правило, диагностируется по определенному сочетанию значений ввода – в коде проверки эти значения обычно прописываются напрямую константами.

В такой ситуации изменение существующего процесса или внедрение нового с большой вероятностью потребует анализа кода проверки и добавления новых «if-else» условий для обработки исключений или пополнения перечня используемых констант в коде новыми значениями. Такие изменения потребуют или тесного взаимодействия ABAP-разработчика с консультантом или наличия у консультанта навыка понимания ABAP-кодировок, т.к. необдуманная вставка нового «if-else» условия может разрушить логику какого-либо уже эксплуатирующегося бизнес-процесса.

В статье предлагается подход к реализации пользовательских контрольных проверок в User-Exit и Badi транзакций логистики, позволяющий избавиться от использования констант в программных кодах проверок и сделать их гибко-настраиваемыми - это позволит выполнять отключение проверок или изменение их параметров без обращения к ABAP-разработчику, а только путём настроек управляющих таблиц.

Идея настраиваемых контрольных проверок

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

1. Для каждого отдельного - или создаётся отдельная коммуникационная структура, которая содержит поля, необходимые для выполнения проверок и доступные для заполнения в области видимости используемого расширения. В случае необходимости использования в проверках атрибутов ссылочных справочников и документов следует включить в коммуникационную структуру соответствующие поля.
2. При выполнении - или создаётся заполненная строка коммуникационной структуры, содержащая в себе значения полей проверяемого объекта (строки заказа, заголовка документа, партии поставки и т.п.) и значения полей ссылочных объектов (справочников, документов-оснований и т.п.). Единожды заполненная структура используется для выполнения всех последующих проверок – т.е. исключаются повторные выборки уже полученных ранее данных, что часто встречается при последовательном «-» кодировании всех проверок внутри выбранного расширения.
3. Алгоритм выполнения проверок в - или представляет собой последовательный перебор шагов проверки. Каждый шаг реализует некоторую отдельную проверку. Для шага задаётся текст сообщения об особой ситуации и уровень сообщения – информационное, предупреждение или ошибка.
4. У каждого шага проверки должен быть набор параметров – ограничений, заданных по типу - для определённого поля коммуникационной структуры. Имя параметра соответствует имени поля в коммуникационной структуре. Набор параметров определяет критерии, которым должны удовлетворять значения полей в строке коммуникационной структуры. Т.е. если строка коммуникационной структуры удовлетворяет ограничениям, заданным всеми параметрами шага, то следует считать, что особая ситуация диагностирована. Например, необходимо проверить заполнение поля «отпускающий склад» в заказе на перемещение. Для такой проверки необходимо настроить два параметра (см. Рис. 6): 
   
   параметр RESWK, задающий ограничение для поля коммуникационной структуры «Завод поставщик» - это поле должно быть заполнено, что означает, что рассматриваемый заказ является заказом на перемещение; 
   
   параметр , задающий ограничение для поля коммуникационной структуры «Отпускающий склад» - это поле должно быть пустым, т.е. пользователь не ввёл в позицию отпускающий склад.
   
   Если в рассматриваемой позиции заказа (а значит и в построенной для неё коммуникационной структуре) заполнен завод-поставщик, но не указан отпускающий склад, то диагностирована ошибка: в позиции заказа на перемещение не указан отпускающий склад.
5. Возможностей сравнения полей коммуникационной структуры и параметров может не хватить для реализации каких-либо сложных проверок. В этом случае, следует предусмотреть опциональную возможность вызова для каждого шага проверки указанного в настройке функционального модуля с регламентированным интерфейсом для уточнения факта диагностирования особой ситуации. Так же необходимо предусмотреть возможность передачи в ФМ значений произвольных параметров из настроек шага – это позволит проектировать более универсальные функциональные модули с возможностью их повторного использования в разных проверках с разными значениями параметров.

Схема выполнения проверки, поясняющая описанную выше методику, приведена на Рис.1.

Рис. 1. Схема выполнения проверки объекта

Шаг проверки диагностирует особую ситуацию, если содержание коммуникационной структуры удовлетворяет одновременно всем ограничениям, заданным параметрами шага, и функциональный модуль шага так же вернул истинное значение – т.е. ограничения всех параметров и результат выполнения функционального модуля учитываются по правилу логического «И». В случае отсутствия в настройке шага функционального модуля, особая ситуация определяется только на основании применения ограничений к коммуникационной структуре – т.е. как будто бы функциональный модуль вернул истинное значение.

Объект содержит ошибку и его сохранение запрещается, если хоть один из шагов проверки диагностировал особую ситуацию с типом сообщения «E». Т.е. результаты выполнения всех настроенных для объекта шагов проверок учитываются по правилу логического «ИЛИ».

Таким образом, алгоритм проверки можно записать в виде булевой функции , которая принимает истинное значение, если объект содержит ошибку:

Здесь символами  и  обозначена операция конъюнкции – логическое «И», а символом  - операция дизъюнкции – логическое «ИЛИ». Поясним остальные обозначения формулы:

 – поля коммуникационной структуры;

 – количество шагов проверки;

 - функциональный модуль шага  проверки. Если в настройке шага не указан функциональный модуль, то принять: ;

 - множество параметров шага , задающих ограничения для полей коммуникационной структуры;

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

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

Необходимые настроечные таблицы

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

ZCHECKOBJ – таблица ведения допустимых объектов (Табл. 1), для которых будут выполняться проверки. Таблица должна содержать следующие поля:

Таблица 1. ZCHECKOBJ

Название	Техническое наименование	Комментарий / источник данных
Тип проверки (BAdI-определение)	EXIT_NAME	Наименование расширения системы, в котором будет выполняться цикл настроенных проверок. Возможные значения: «MB_MIGO_BADI», «ME_PROCESS_PO_CUST» и пр.
Имя метода	METHO_NAME	Наименование метода (функции) расширения системы, в которой будет выполняться цикл настроенных проверок. Возможные значения: «CHECK_ITEM»,