Архив метки: abap

CCAPPS поможет с ABAP кодом

Транзакция CCAPPS поможет с ABAP кодом именно для заказчиков. Консультантам обычно наплевать, сделали и ушли, а заказчики остаются с самоваром. Каждый самовар нужно мыть, чистить, полировать. Код, которые вы используете в системе нужно также периодически освежать и протирать тряпочкой. Это поможет безболезненно переходить к новым версиям системы, поможет пересматривать процессы и необходимость самого кода. Наша страна известна большим количеством перевнедрений с нуля просто потому, что старое ворошить оказалось сложно. Проще с нуля.

CCAPPS является кусочком функциональности Solution Manager для управления исходным кодом в системах. SM умеет многое, особенно в больших и разрозненных ландшафтах, где больше, чем одна классическая линейка DEV-TST-PRD. Например, вы с помощью этой транзакции сможете проанализировать ваш код на совместимость с версией системы, сможете найти двойники, которые лучше вынести в общие функциональные модули или отказаться в пользу стандартных ФМ. Вы сможете посмотреть какой код используется пользователями, а какой просто лежит на полке и просится в мусорку. Подключите сюда ATC (ABAP Test Cockpit), о котором я писал раньше, и получите качественную оценку кода. Подключите Code Inspector и ни одна мышь не проскочит с кривыми наименованиями.

Сейчас работаю на проекте, где этого всего нет. Только начинаю внедрять. И качество софта, который был разработан подрядчиками оставляет желать лучшего. Никаких правил именований, сложные select с join, отсутствие проверок полномочий и стандартных практик из курсов SAP.

А еще вспомните про расхождения в системах по настройкам (SCU3), словарю (не помню транзакцию) и коду (CCAPPS). Регулярное выполнение этих программ позволит избежать существенных расхождений между системами, что позволит производить нормальное копирование систем, сопровождение. Если завести все в SM, то он за вас будет каждую ночь бегать по системам и давать пинков всем и вся, а директорам складывать красивые BI отчеты на стол.

Почему не стоит бояться ABAPа

Часто слышу про такую фантазию как zero-abap project. Проекты, где нет АБАПа. Почему все заказчики так его бояться и почему в России без него нельзя запустить проект? Основной аргумент заказчика обычно таков, что при использовании абапа нельзя нормально обновлять систему, что это влечет к увеличению стоимость сопровождения и бла-бла-бла. Интересно, а изменение схемы, кадровых мероприятий, использования OM объектов не влечет к тем же проблемам? ABAP он хотя бы изолирован от всего остального, его видно издалека, а изменения в настройках системы обычно без стакана чая не разберешь. Особенно, когда приходит нота с необходимостью внести изменения в стандартную схему, которую ты уже похоронил, а тут надо разобраться какие операции вносить, а какие не нужно.

Я считаю, что большее зло, это изначально неверная архитектура системы, затыкание дыр промежуточными решениями, кодинг расширений в схемах. Большая часть абапа зачастую приходится на отчетность и user-exit, которые самостоятельно и мало зависят или влияют на обновления системы. САП предоставил инструмент для разграничения полномочий и сфер влияния. Только в логике настроек такого нет инструмента, так как там все слишком взаимосвязанно.

 

Реализация ABAP Unit test

И не говорите мне, что я зануда.

Дело было так. Я когда-то уже вещал вам про TDD методологию, а сегодня решил на практике попробовать как оно работает в SAP. Сделал простой OData сервис, его и решил протестировать автоматизированно.

А теперь я хочу его автоматизированно тестировать. Ранее я рассказывал про sECATT. Сегодня поговорим про Unit тестирование. Это такая штука, которая программируется на языке программирования ABAP и позволяет проверять логику работы _внутри_ программы. То есть, она не имитирует работу пользователя, а проверяет внутренние процедуры, методы, функции на ожидаемый результат. Например, всегда должно сохранять данные с корректным форматом, никогда нельзя сохранять данные с некорректным форматом. Делаем для этого два метода – тест на положительный результат и тест на отрицательный результат.
Читать далее

Персонализация в SAP

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

Внимательные САПеры и САПерки видел в транзакциях SU01, PFCG закладку “Personalization”, где перечислены куча строчек и нельзя что-то изменить. Оказывается, это объекты персонализации, которые можно самому разрабатывать, использовать в своих программах. Суть объекта персонализации состоит в том, чтобы на уровне роли или конкретного пользователя сохранить особенные значения (персонализацию), которые влияют на интерфейс. Например, настройки табличек, настройки экрана, настройки взаимодействия, значения по-умолчанию. Особая прелесть этих объектов заключается в том, что можно на уровне роли присвоить значение объекта, и оно унаследуется по-умолчанию всем присвоенным к роли пользователям.

Например, если в роли создать объект Assign user group to SAP Query SAP_QUERY_USERGROUP, а в нем указать группу пользователей SAP Query, то всем пользователям присвоится эта группа и отчеты, к ней привязанные. Если присмотреться к уже созданным объектам, то технологией начали пользоваться совсем недавно (хотя сама она достаточно давно появилась в системе), в новых компонентах.

Создать свой объект можно в транзакции PERSREG. Информация о персонализации может храниться в различных видах: строка, таблица, структура – очень удобно. Для работы в своих программах с объектами персонализации используется класс CL_PERS_ADMIN и его методы.

Для массового изменения значения объекта персонализации используется транзакция SPERS_TEST.

Будущее ABAP

Я вам еще не надоел своими умозаключениями насчет будущего?

ABAP для HANA становится другим. Скажем так, совсем другим. Большинство исходных кодов системы написано процедурным языком программирования, когда вся логика зашита в маленьких кусочках кода – процедурах и функциях. Никакого наследования, полиморфизма, инкапсуляции. Раньше так на ассемблере программировали.

С течением времени появляется объектно-ориентированное программирование (ООП). Это классы, интерфейсы, объекты. Решается много проблем процедурного программирования, но многие программисты “старой закалки” не переходят на ООП. Почему? Потому что редко нужно писать свои интерфейсы, а чаще дорабатывать и отчеты рисовать. Да и на процедурках проще, хоть и одноразово.

САП начал смотреть по сторонам, что мы наглядно видим в облачных решениях, UI. Я только что закончил читать статью про ABAP for HANA (http://scn.sap.com/community/abap/eclipse/blog/2014/02/04/new-data-modeling-features-in-abap-for-hana). Дело все в современном подходе к разработке веб-решений. Еще в 2012 году, когда я сел изучать Ruby On Rails, я столкнулся с понятием аннотации. Позже в фреймворке Symfony на PhP тоже самое для ORM моделей. Что такое аннотация? Это набор ключевых слов, параметров, которые определяют работу модели данных. Например, как модель нужно сохранить в базе данных, как модель нужно маршрутизировать (роутинг), как обеспечить целостность модели, как визуализировать модель и так далее.

Читать далее