コラム |第2回 クリーンコアを維持するための拡張開発ーDeveloper拡張| {{ site_settings.logo_alt }}

前回、SAPが近年提唱しているクリーンコアとは何か、その目的や効果と、クリーンコアを維持するための拡張開発（アドオン）の種類とその選定方法を説明しました。今回は、4つの拡張開発方式のうち、Developer拡張について解説します。

Developer拡張とは？

SAP S/4HANA（以下、S/4HANA）上に直接アドオンをするIn-App拡張と呼ばれる拡張手法の一つで、S/4HANAをクリーンコアの状態で維持し、またその状態に到達しやすくするための新しい拡張方式です。大きく５つの特徴があります。

Developer拡張の特徴

• S/4HANAシステム内で SAP標準リポジトリオブジェクトの拡張および独自のカスタムオブジェクトの新規開発が可能。SAP標準オブジェクトの変更は不可。
• 開発言語はABAP、ADT (ABAP Development Tools）を使用して実装
• コアとカスタムコードを分離する新しい実装ルールが適用される
  例）テーブル参照をする場合、直接のテーブル参照はNG。Public APIとなっているCDS Viewを使用してアクセスするなど
• S/4HANA内でデータをPublic API(CDS View経由）で参照することができ、SAPオブジェクトと密結合した拡張機能を実装可能
• Key User拡張と組み合わせて使用することが可能
  例）Custom Fieldを使って項目拡張をした項目に対して追加のチェックロジックを実装する際にDeveloper拡張を使うなど

次に、これまでの実装方法（クラッシック拡張）とDeveloper拡張はどう異なるのか、図を用いて説明しましょう。

これまでの実装方法（クラシック拡張）

運用保守時のインターフェースエラー発生を悲観的に想定し、エラーの原因特定とリカバリーの容易さを目的に下記の方式を多く採用していました。

S/4HANA標準APIを外部から実行するのではなく、アドオンテーブル（IFワークテーブル）を経由して業務テーブルにデータ更新を行うようにしている点が特徴です。

ところが、Fit to Standard導入が基本のS/4HANA Public Cloud（RISE with SAP）の環境下では、下図のように、これまで利用可能だったものが利用不可になります。

これからの実装方法（Developer拡張）

クラシック拡張で採用していた実装方式をDeveloper拡張で実現しようとすると下記の構成となります。

クラシック拡張とDeveloper拡張の比較

システム間データ連携機能(バッチ処理)の実装方法ついて、従来アドオン方法(クラシック拡張)で利用してきた機能が、開発者拡張を利用するとどのように置き換わるのか、比較、整理しました。

クリーンコアを維持するためのテクノロジーは準備されている

S/4HANA Public Cloud（RISE with SAP）の環境下にあっても、クラッシック拡張と同等レベルの機能開発は可能です。

もちろん、ABAPクラス、BOインターフェース、ジョブ実装クラス、EML言語など、新しく習得すべき事が多いのも事実ですが、決して難解ではないため、尻込みする必要はありません。拡張開発方法相互の親和性という点では今の段階では一部不便なところも見受けられますが、その解消も時間を置かず解消されると期待しています。

今後も、SAP製品の最新技術情報を積極的に入手し、検証を重ね、より良いアーキテクチャーを追求していきたいと考えています。

※本稿記載のDeveloper拡張について、開発画面キャプチャを利用した開発者向け資料は、下記からダウンロードできます。

ダウンロードはこちら