Есть три существенных пункта о CDS, которые хочу обозначить:

• Это не что-то принципиально новое, это обобщение принципов и способов работы с базой данных в единый набор инструкций.
• Эффективность результата, как скорость обработки и вывод данных — можно поставить под вопрос, но если об этом не задумываться, вероятность, что всё будет работать действительно плохо — очень маленькая.
• Если вы не знаете, как можно использовать CDS в решении поставленных перед вами задач — вы упускаете важный и сильный инструмент из виду.

Хорошее решение может быть построено на старых принципах, если эти принципы лучше новых, но если вы просто не знаете и не понимаете как использовать новые инструменты, то вы не можете утверждать, что ваше решение — это отличное решение. Вы лишь создали то, что умеете.

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

1. Техника

CDS — Core Data Services, что можно понять, как ядро сервисных возможностей при работе с данными. Набор общих, взаимосвязанных инструкций, используемых при выборе из базы данных.

Несложно найти статьи и описания, где вам расскажут, что в ABAP используются классические open SQL команды и то не в полном объёме, вся обработка выбранных данных нагружает сервер приложений, а CDS — это гораздо более полноценный инструмент, дающий столько возможностей, что практически всю реализацию отдельных потребностей в виде отчётов, можно перенести на сервер базы данных. Именно этот момент в общем потоке информации как правило опускается, ведь для людей погружённых в технические тонкости разработки вполне очевидно, что это один из важных эффектов, к которым мы получаем доступ используя инструменты CDS.

Поэтому хочу заострить внимание консультантов: база данных HANA — значительно более производительная, поэтому есть смысл переложить на её мощности часть нагрузки, освободив резервные мощности сервера приложений. Ведь как мы все знаем, SAP R3 — это модель из трёх частей: БД — Сервер приложений — Клиент. Раньше базы данных были не так производительных, поэтому много усилий прилагалось, чтобы хранение данных в БД было оптимальных, а запросы к ней не «вешали» систему. Теперь HANA может значительно больше и есть смысл дать ей эти мощности использовать на полную. CDS  — это именно возможно построить отчёт прямо на сервере БД. Одна из важных возможностей, один из смыслов создать CDS.

Другой значительный момент: когда мы слышим упоминание CDS, в 80 % речь идёт о CDS-view. Это то самое описание, код представления, в котором описано: что и где выбирать, как это обрабатывать, как будет выводиться результат. И хотя терминология важна, в данном случае нет принципиальной потребности каждый раз уточнять, что речь идёт о View, то есть ракурсе или представлении, в простонаречье «вьюха». Всё что можно найти в нашем объекте CDS — будет использовано как описание в коде нашего CDS-view, в ABAP словаре это будет объект, ракурс БД CDS, который можно будет просмотреть как обычную табличку, а провалившись в определение данных (Data Defenition) мы увидим полное описание (Рис. 1).

Рис. 1. Ракурс БД CDS в словаре АВАР

Рис. 2. Описание CDS на DDL

Описание может выглядит как обычный запрос SELECT из БД, а может как большой и многоступенчатый запрос с присоединениями, объединениями, вычислениями и т. д., практически программа (Рис. 2).

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

2. Практика консультанта SAP

Что мы получаем и что мы можем использовать? Как выбрать самый эффективный инструмент, самую полезную реализацию из всех возможностей в рамках CDS?

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

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

Документ закупки, который формируется в транзакции модуля логистики, формирует несколько последующих документов разных модулей SAP ERP: документ логистики, документ финансов, контроллинговый документ, возможно документ спец.регистров. Каждый документ — это собственный объект, хранящийся в различных таблицах базы данных, с отдельно хранимым заголовком, отдельно хранимыми позициями, каждая позиция может содержать ссылки на другие объекты, к которым она имеет отношение: договора, номера заказов, СПП-элементов, МВЗ и т. д. Всё это представляет из себя большой набор разносторонних данных.

Моё текущее привлечение на проектах — налог на прибыль. Для анализа того, каким образом отражена суммовая позиция, мне нужно знать несколько ключевых элементов: счёт главной книги, объект контировки, тип объекта контировки, дополнительные ссылочные ключи. Для составления отчётов с такими данными я могу создать программу, которая будет делать из разных таблиц выборки и состыковывать их между собой. Но могу и собрать CDS-view, который смогу просто вызывать в любых других транзакциях, более того, я могу их вызывать в User Exit при оффлайн переносах в модуль FI-SL. Именно эта возможность поместить целую логику в объект схожий с прозрачной таблицей, именно она может стать фундаментом представления о том, что именно отражает каждая отдельная сумма, при обзоре и контроле происходящего в рамках вашего проекта.

С приходом HANA и S4, появилась большая таблица ACDOCA, однако и в ней есть не всё, что нужно, например упомянутые выше типы объектов контировки. ACDOCA упоминается в первую очередь, когда заходит речь о полноте данных в строку, но и её надо обогащать. В классическом подходе на сервере приложений это выглядит, как отдельный функциональный модуль (приложение, метод класса), который примет входные параметры, выполнит выборку из БД или несколько выборок, обработает их и вернёт нужное вам представление. В случае, если там нужны сложные алгоритмы и это, по сути, целая программа, со своим анализом и выводами — хорошо, пусть будет программа. Если это группировка различных данных в БД, то эту задачу можно полностью отдать серверу БД, что вероятно ускорит общий вывод результата. Описание данных в CDS view даст вам не только нужный объём информации о конкретной транзакционной записи, но и избавит вас от всего лишнего, при этом вы получаете один из базовых объектов словаря, по сути, равнозначный прозрачной таблице, в плане обращение к нему.

В моём повествовании наверняка найдётся масса технических неточностей, но перед консультантом стоит задача упорядочивания потребностей заказчика в логичную и информативную систему, поэтому я рассматриваю CDS-view как простую таблицу, которую можно просмотреть браузером таблиц SE16 и в его производных, обновлённых версиях. В тот момент, когда заказчик буквально вываливает на вас массу локальных терминов, упрощённых обозначений, поток мыслей, важно создать фундамент, на котором будет строиться решение. Для новых сущностей, объектов, документов, можно создать одну большую кластерную таблицу, с целью свести момент записи данных в одну точку. Когда у нас несколько разных таблиц отвечают за отражение одного объекта, одного документа, то запись новых, сгенерированных данных, в случае сбоя будет неполноценная. В одних таблицах она уже создалась, а в других нет и возможно уже не создастся. Когда у нас одна таблица для всех транзакционных данных, запись в неё либо произошла успешно, либо нет и в случае «нет», мы можем повторить запись, не опасаясь пересечения с уже записанными данными (это случится, если таблиц много и часть из них уже записались). В будущем, с помощью CDS-view, мы будем выбирать из этого кластера данных только то, что нужно, не заполняя память или экранный вывод десятками ненужных нам столбцов данных. А если по проекту, мы создаём отчёт или систему отчётов, CDS-view будет выдавать в понятном виде, в строку всё то, что нам нужно для анализа и рассмотрения сути каждой отдельной операции, события или описания объекта.

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

Вывод

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

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

Об авторе

Владимир Кравченко 

Консультант SAP с 2007 года. Прошёл путь с 1-й линии поддержки, до руководителя группы. Разрабатывал концепции, подходы и решения по участкам налога на прибыль, капитального строительства и учёта затрат. Организовывал команду поддержки для крупного заказчика.