Поговорим о том, кто такие ABAP разработчики, как строится их карьера, чем они отличается, а в чем такие же как вы.

Часть первая, о людях и проектах

С чего все начинается

А начинается все достаточно прозаично - будущего абапера правдами и неправдами заманивают на позицию стажёра разработчика в консалтинговую компанию, именуемую в народе просто «галерой». Обещают крутые проекты, миллион долларов и вертолёт. Подкупаются обычно те, кто не видит себя в разработке сайтов или мобильных приложений, а при виде логотипа 1С начинают зевать.

Специфика ABAP разработки такова, что языку и системе в целом невозможно научится самостоятельно, более того, вы даже не сможете «пощупать», что это и как выглядит. Для того чтобы написать свой hello world, вам нужно получить доступ к системе. Да да, все разработки ведутся в режиме «онлайн», и просто так никто вас не пустит даже к себе в песочницу.

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

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

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

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

Сколько же это стоит?

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

• К0 - стажер, он же ассистент консультанта-разработчика. Обычно не более нескольких месяцев, до участия в коммерческих проектах.

• К1 - младший консультант-разработчик. Дали потрогать что то настоящее, но пока под присмотром. В среднем, год работы.

• К2 - консультант-разработчик. Обычно этот уровень сопровождается огромным количеством работы, поэтому развитие идет очень быстро. Если не халявить, и заодно выбить сертификацию, не занимает долго времени.

• К3 - старший консультант-разработчик. Опыт есть, при наличии сертификатов, вместе с К2 - основной состав на любом проекте, можете смело называть себя крепким мидлом. 3-4 года от начала карьеры.

• К4 - ведущий консультант-разработчик. К вашим решениям прислушиваются, приглашают на проектные совещания. На этом уровне многие уходят в архитекторы или тимлиды.

• К5 - эксперт консультант-разработчик. Опыт от 10 лет, либо фриланс, либо удаленная разработка на иностранных заказчиков, либо своя небольшая консалтинговая компания, работает на подрядах в крупных проектах.

По суммах приблизительно чуть меньше, чем в других направлениях разработки, с учетом двух факторов - в SAP ABAP не бывает 23-летних сеньоров, и все сильно зависит от вашего работодателя и проектов. Ко всему прочему, обратите внимание, что лишь примерно 10 процентов (статистика с hh.ru) вакансий идут с указанной зарплатной вилкой.

Пришло время поговорить, что же вы собственно будете кодить.

Как мы помним, разработка ПО это алгоритмы + структуры данных. С первым в ABAP всё как и везде, а вот со вторым надо разобраться. Здесь вы не встретите привычных массивов, связных списков и кортежей. Есть лишь три типа данных - переменная, структура и таблица(стандартная, сортированная, и hash). В этой части все сильно проще той же JAVA с List, Map, Hash и их бесконечными вариациями.

Все ABAP программирование делится на две практики: расширение стандарта, и Z-разработка.

Расширение стандарта.

Как мы знаем, SAP это огромная сложная система. Она вся уже кем то до нас написана, причём написана с учетом двух возможностей - кастомизации под клиента с помощью настроек, которыми занимается консультант, и более серьёзными изменениями алгоритмов бизнес логики. Есть целый ряд техник для расширения, все они уже не раз подробно рассмотрены в том числе в русскоязычном сегменте интернета. Здесь вам просто нужно следовать некоторым правилам, характерным для каждой техники, и в точности следовать постановке задачи. Чаще всего, если повезло с консультантом, в ТЗ уже будет прописано - где, в каком конкретно месте и как нужно модифицировать.

Z-разработка.

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

Отчетные - это просто вывод информации из БД в нужном пользователю формате, будь то на экран, выгрузка в различные форматы, отправка на почту или в какую либо систему по шине данных. Функциональные - те, в которых есть бизнес логика, те, которые приводят систему из одного состояния в другое.

Ну и конечно, выделяются так называемые интеграционные разработки. С этим в SAP все ок - вебсервисы, RFC, SAP PI, IDOС.

По существующие, с недавних пор, ответвления на фронт и бэк разработку и технологии поговорим в второй части статьи.

Интересный момент - писать можно, с некоторыми оговорками, используя аж 4 парадигмы - событийную, процедурную(perform), функциональную(FM) и ОО. ООП в своё время пришло в ABAP из Java, поэтому можно развернуться и почувствовать себя полноценным программистом.

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

Работа программиста держится на трёх китах: код, документация, тесты. С первым и вторым тут все хорошо, а вот про последнее поговорим отдельно.

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

Поговорим о перспективах

Самое главное, то, о чем всегда беспокоится любой программист - они есть. Как я уже говорил, здесь не нужно куда то бежать, изучать новые фреймворки, и прыгать с одной компании в другую - ABAP везде одинаковый. Больше всего ценится именно знание «стандарта» и всех тонкостей системы, а не новомодных штучек(да да, я про те фишки, что появились в последние лет 5). Венец карьеры многих экспертов - либо растут в тим-лидов и архитекторов. Либо, прокачавшись на протяжении 5-10 лет, уходят в свободное плавание на условиях фриланса через собственное юрлицо.

Работы хватает, а вакансии на стажёров никогда не пропадают с сайтов объявлений.

Самый большой страх и минус abap разработки

То, что когда нибудь SAP кончится, и мы все останемся без работы - этому мифу уже десятки лет. Но взглянем правде в глаза - с abap тяжело соскочить на любое другое направление современной разработки, опыт будет просто нерелевантен. Поэтому многие параллельно изучают смежную ветвь, относительно молодую - ui5. Это JS фреймворк для фронтенда, продвигаемый SAP, благодаря которому можно обрести запасной плацдарм, и быть «в тренде».

Даже если предположить, что все клиенты SAP вот прям сейчас начнут переходить на что то другое, процесс займет 5-10 лет. Потому что смена ERP системы это не просто запустить сервер, и вывести каждому пользователю на рабочий стол ярлычок. Это огромные суммы, потраченные на лицензии, железо, внедрение, разработку, развитие, поддержку. Это бесконечные человеко-часы на наладку бизнес-процессов. Это гигантский опыт, планы и перспективы, экспертиза, которую не выбросить на помойку за один день.

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

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

Почему так не популярно?

Не хватает правильной рекламы. Чтобы объяснить, что устаревший интерфейс, местами COBOL'о подобный синтаксис и прочее это не баг, а фича. Что ты делаешь то, что позволит огромной компании сэкономить( а значит заработать) миллионы, что твои решения повлияют на работу тысяч людей, что ты фактически руками творишь внутреннюю кухню крупнейших корпораций. А если SAP и ABAP такие, какие они есть сейчас( то есть малопривлекательные среди попсовых мейнстримовых технологий) - то этому есть объективные причины. Если кому то больше хочется в самом модном ide на модном стэке и вышедшем позавчера хайповом фреймворке делать условные приложения, которыми будет пользоваться полторы калеки, или очередной веб-сайт, такой же как миллионы других - нам не по пути.

А SAP, и ABAP в частности, развивается реактивно. И реактивно, это не значит сверх быстро, как истребитель. Это значит, что сначала формируется запрос от бизнеса, а затем в ответ на него, после тщательной аналитики, предлагается решение. Это как ПДД, тут каждый statement написан кровью.

Часть вторая, о технологиях( историческая справка ABAP Development )

Эволюция модели программирования ABAP: краткий список версий платформы

В 2003 году SAP AG представила первую версию SAP NetWeaver( SAP R/3), затем в 2005 году SAP ERP 2005 (в последующем была переименована в SAP ERP 6.0). В этих версиях мы впервые познакомились с Classic ABAP.

Классический ABAP

Классический ABAP это программирование в среде разработки SAP Workbench, платформа SAP NetViewer. Позволяет работать с внутренними локальными структурами данных и с глобальными напрямую в БД, с интерфейсом пользователя, с интерфейсами выгрузки данных (word, excel, pdf, …), поддерживает множество технологий связи с другими системами (BAPI, RFC, …), и некоторые другие функции. Основные программные единицы это отчеты, состоящие из инклудов, логически код разбит на подпрограммы, функциональные модули, и объекты ООП. Классическая ABAP программа состоит из СЭ, затем выборки данных с использованием opensql, какой либо логики с использованием операторов работы с таблицами и структурами (loop & read table) и вывод на экран данных.  В контексте исторической справки нас интересует модель разработки и подход к реализации пользовательского интерфейса – редактор экранов, технология Dynpro.

Новый подход к UI (BSP)

Приложения, разработанные по технологии Java Server Pages (JSP), которые, в основном, используются для динамической генерации содержимого (например, HTML, ABAP, XML, C#) в HTML и выдаче сервером ответа браузеру клиента

Но в середине двухтысячных нас мир снова изменился. Человечество открыло для себя то, что Tim O’Reilly в своей статье от «What Is Web 2.0» от 30 сентября 2005 года назвал WEB 2.0. Для нас это означает, что люди, а значит и клиенты и пользователи SAP увидели перспективу в переводе интерфейса из декстопного в более функциональный web. Появились новые концепции разработки, программирование разделилось на back end и front end. SAP так же не отставал от тренда, и представил такую технологию, как BSP.

Новый подход к UI (WDP)

Приложения Web Dynpro основаны на модели MVC —
Модель — это позволяет получить доступ к внутренним данным в приложении Web Dynpro.
Просмотр — используется для обеспечения представления данных в веб-браузере.
Контроллер — используется для управления связью между моделью и представлением, где он принимает данные от пользователей, получает данные о процессах из модели и отображает данные в браузере.

 

Web Dynpro — это среда ABAP для веб-разработки, основанная на концепции Model View Controller (MVC) программирования пользовательского интерфейса. Он доступен для Java и ABAP в соответствии с платформой и поддерживает аналогичные функции.

Web Dynpro имеет следующие принципы:

• Разделение отображения и бизнес-логики

• Легкое изменение макета с использованием графических инструментов

• Нет зависимости платформы от интерфейсов

Новый подход к UI (UI5/Fiori & Odata)

Процесс разработки при создании приложения SAP Fiori (SAPUI5) состоит из двух частей. В Back end выполняется создание, внедрение и публикация сервиса Open Data Protocol (OData). Во Front end выполняется сборка приложения SAPUI5 и его развертывание в системе SAP Gateway. Далее приложение извлекает из бэкэнда SAP данные в реальном времени и выводит их на экран.

В 2013-2014 году SAP представил SAP S/4HANA, и вместе с ней были внедрены новые технологии и новая модель разработки.

Для Back end был использован API SAP OData — Open Data Protocol – это открытый веб-протокол для запроса и обновления данных. Протокол позволяет выполнять операции с ресурсами, используя в качестве запросов HTTP-команды, и обмениваться данными в форматах JSON или XML.

Для Front end был использован framework js SAPUI5  - набор инструментов для создания пользовательских интерфейсов в приложениях SAP, использующий Odata, JS, HTML5, XML, JSON.

Набор принципов построения пользовательского интерфейса с применением технологии SAP UI5 получил название SAP Fiori.

Odata: Сущность и методы

Проектирование модели данных Odata возможно несколькими способами. Первый и самый простой, по уровню абстракции, из них, это создание сущности на основе словарных обьектов SAP, то есть создание структуры типов сущностей (Entity Types), на основе существующих ABAP структур (DDIC Structure).

В данном примере мы создаем тип под названием Group, на основе табличной структуры FMBL, причем мы можем выбрать какие именно поля мы будет использовать, и какие у них будут свойства.

Из приведенного выше изображения видно, что каждый тип сущности будет иметь собственную папку Properties (Свойства) и Navigation Properties (Свойства навигации). И каждый набор сущностей будет иметь свои собственные операции (создание, обновление, чтение, удаление).

RESTful ABAP Programming Model

Начиная с версии 7.4, SAP отошел от модели классической ABAP разработки, и перешел на модель SAP FIORI. В новейшей модели, именуемой RAP, появилась новая концепция определения поведения и состояния.

Модель программирования ABAP RESTful определяет архитектуру для эффективной сквозной разработки сервисов OData, изначально оптимизированных для SAP HANA (таких как приложения Fiori), в среде SAP Cloud Platform ABAP. Он поддерживает разработку всех типов приложений Fiori, а также сервисов A2X. Он основан на таких технологиях и инфраструктурах, как Core Data Services (CDS) для определения семантически богатых моделей данных и инфраструктуры модели для создания сервисов OData с привязками к протоколу OData и службами приложений на основе ABAP для пользовательской логики и пользовательских интерфейсов на основе SAPUI5.

Итог

SAP разработка это увлекательно, это сложно, это перспективно. Но не для всех.