Будущее 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 моделей. Что такое аннотация? Это набор ключевых слов, параметров, которые определяют работу модели данных. Например, как модель нужно сохранить в базе данных, как модель нужно маршрутизировать (роутинг), как обеспечить целостность модели, как визуализировать модель и так далее.

В веб-программировании все примерно также начиналось. А давайте забабахаем виртуальные вьюхи (еще в оракле, насколько помню, появились в начале 2000-х). Пишешь такую строчку: взять огурцы из вагона, апельсины из ящика, молоко из холодильника и все собрать в одном виде как будто на витрине магазина. Если тебе нужно добавить помидоры из погреба, то просто меняется строчка в определении этой вьюхи (DDL — Data Definition Language), и все работает. Как бы круто! Вот и САП с помощью CDS (Core Data Services) решил тоже самое предложить программистам. Иными словами, для HR можно больше не использовать ФМ для чтения инфотипов, не использовать PROVIDE в логической базе данных, не нужен GET PERNR. Можно просто вот так сделать (код не проверял):

define view EmployeeDocuments as select from pa0000 as A, pa0290 as B

so

left inner join {

key a.pernr as EmployeeNumber,

a.sname as EmployeeName,

b.subty as DocumentName,

b.docnu as DocumentNumber

}

Как-то так примерно. Нет системы под рукой, чтобы проверить. А хотите только женщин с паспортами?

define view WomenWithPassport as select from EmployeeDocument as A, PA0002 as B

where b.gesch = 2 and a.DocumentName = 21.

Но это пока баловство, которое хорошо расширяется, позволяет быстро создавать отчеты (аналог Universe в Business Objects) и так далее по списку. Дальше веб пошел в сторону ORM (Object-Relational Mapping). Если очень просто, то это очередной уровень абстракции над физическими табличками, который позволяет создавать бизнес-объекты. Например (в условной нотации).

Класс Сотрудник {

Принадлежит классу Физическое Лицо;

Обладает классом Документы;

Атрибуты:

Пол

Дата рождения

ФИО

}

По существу мы определили сотрудника вместо кучи избыточных таблиц PA0***. А еще мы хотим попросить систему проверять данные вместо нас. Например, вот так:

@@ValidityCheck

@@Length: {0..255}

ФИО

@@validityCheck

@@ValueIn: {mail, femail, undefined}

Пол

То есть, с помощью аннотаций мы задаем правила проверки данных перед сохранением объекта в базе. Система сама создаст таблички под нужные параметры класса (какие атрибуты, размерность, связи с документами и физлицом). Система сама осуществит все проверки в любых разрезах. И потом в OData мы можем получить информацию с помощью роутинга:

GET /Сотрудник/15 — получить данные по табельнику 15

GET /Сотрудник — получить список сотрудников

И скоро это нас ждет на телеэкранах Eclipse & ABAP (или уже есть, а я не дочитал?).

Едем дальше. Вскоре САП сделает или уже сделал эти аннотации для поддержки бизнес-моделей. Это означает, что программировать на ABAP для создания новой бизнес-логики станет проще и быстрее. Это server-side. Вернемся к веб. Веб посмотрел на мир, увидел хорошие каналы связи, мощные компьютеры у клиентов (ПК, планшеты, смартфоны) и побежал за мощностями к клиенту. Как так? А просто! Логику стали перекладывать на клиента, на браузеры. Если раньше задача браузера была просто отрисовать то, что прислал сервер, то сегодня браузер строит DOM модель документа, динамически управляет этой моделью через AJAX. Уже даже появились технологии, которые реализуют MVC на сервере и MVC на клиенте для распределения вычислений. Тот самый сервисный подход, о котором я писал ранее.

При чем тут САП? Вскоре мы тоже увидим абап, который будет рисовать простым языком модели (не напоминает OData?) на сервере, реализовывать и распределять логику обработки моделей server-client (не напоминает Smart Templates в SAPUI5?). Это позволит еще дальше уйти от традиционного абапа, еще сильнее акцентировать архитектуру на сервисном подходе не только в части взаимодействия с внешними системами, но и внутри ядра.