Меню

Объектный подход при ABAP разработке. Создание программы «Bank Statement»

Объектный подход при ABAP разработке. Создание программы «Bank Statement»

Предпосылки создания программы «Bank Statement»

 

Классический вариант реализации программы «Bank Statement» (использовался мною на трёх проектах) основан на конструкциях If … endif, case … endcase языка программирования ABAP. При заключении/расторжении договора с банком, выборе дополнительных данных, изменении формата выгрузки приходится изменять программу и добавлять новые конструкции if…endif, case…endcase. В результате программу становится сложно сопровождать, возникают трудности в добавлении новой функциональности по работе с новым форматом.

Назначение программы «Bank Statement»

Назначением программы является обеспечение обмена электронными документами различных форматов с банками:

  • выгрузка из системы платёжных поручений соответствующих форматов для отправки в различные банки
  • загрузка полученных от банков файлов различных форматов с информацией о проведённых по расчётным счётам компании операций

Например, есть предприятие «А». Предприятие имеет несколько филиалов в различных регионах. Каждый филиал работает с одним или несколькими банками. Каждый банк имеет свой набор форматов электронных документов и требует обмена информацией именно в «своём» формате (xml, ms excel и т.д).

Основная сложность при создании и сопровождении программы «Bank Statement» заключается в том, что достаточно часто требования к форматам изменяются по причинам:

  • предприятие и филиалы заключают или расторгают договора с различными банками;
  • банки изменяют формат и набор электронных документов.

Описание программы «Bank Statement»

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

В Таблице 1 представлено описание всех классов и интерфейсов, используемых в программе.

Таблица 1

Ниже на Диаграмме 1 представлено взаимодействие классов.

Диаграмма 1

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

Рассмотрим подробнее два основных класса в архитектуре:

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

Класс lcl_appl_bank_statement: Используется для определения конкретного класса, реализующего интерфейс, для обработки данных платежа. Для создания конкретного класса необходимо определить имя класса. Для определения имени класса можно воспользоваться такими способами как: BADI (предварительно определив реализации в зависимости от фильтра), определение в таблице настройки (создать свою или использовать стандартную таблицу), создать признак для нужной структуры и заполнить дерево принятия решения. Реализацию способа, необходимо поместить в метод get_class_name. Далее проверяется наличие класса в системе с помощью ф.м. SEO_CLASS_EXISTENCE_CHECK. Чтобы не создавать объект конкретного класса каждый раз, в классе определена буферная таблица, которая хранит ссылку на объект класса. Определение типа таблицы представлено ниже.

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев5

Комментарий от  

Олег Точенюк

  |  03 июля 2012, 15:27

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

Комментарий от  

Олег Точенюк

  |  03 июля 2012, 15:28

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

Имел в виду не код ФМ, а конечно же имя ФМ.

Комментарий от  

Дмитрий Волков

  |  03 июля 2012, 22:38

Очень интересный подход. А исходный код тестовой программы прилагается или по запросу?

Комментарий от  

Сергей Рыбин

  |  04 июля 2012, 14:21

Очень интересный подход. А исходный код тестовой программы прилагается или по запросу?

Добрый день, Дмитрий! Исходный код должны были приложить к статье, но что-то я его не вижу.

Комментарий от  

Сергей Рыбин

  |  04 июля 2012, 14:26

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

Добрый день, Олег! Да, можно все сделать без классов, но так как изучаю ООП, то стараюсь все сделать с помощью классов. :)