はじめてのカスタムCDS View – S/4HANA Public Cloud キーユーザ拡張

今回はキーユーザ拡張におけるカスタムCDS Viewについてお話しします。
CDS View自体はもう何年も前から存在し、様々な企業の基幹システムの中で活用されています。
私自身もSAP導入プロジェクトでCDS Viewに携わってきましたが、その関わりは設計が中心であり、開発については直近のプロジェクトが初めての経験となりました。
本記事では、開発の視点より自分の目で見て得られたものを、皆様にご紹介できればと思います。
まず最初はCDS Viewとはからご紹介し、後半でキーユーザ拡張にまつわるお話しをさせて頂きます。

CDS Viewとは

CDS Viewとは、従来は個々のプログラム内に実装されることが多かったデータの取得・結合・計算処理を、再利用可能なデータモデルとして定義したものです。 業務上関連するデータを一つのまとまりとしてモデル化し、計算や抽出条件などのビジネスロジックを組み込むとともに、各項目に金額・通貨、数量・単位などの業務的な意味を持たせることができます。

ECC時代にはテーブルを直接利用することも多くありましたが、S/4HANA Cloudのキーユーザ拡張では、SAPから公開されている標準CDS Viewを利用します。カスタムCDS開発では、これらの標準CDS Viewを再利用してCDSを作成するのが基本です。

CDS Viewのモデリング

前段ではCDS Viewの概念と単体でのモデリングについて紹介しました。一方、最終的なビジネスデータを考えた場合、１つのCDS Viewでモデリングが完結する訳ではありません。ビジネスデータを分解・整理・階層化したものを、最終的なビジネスデータ（複数もしくは階層を伴ったCDS View）として構築します。

CDS Viewの構成要素

CDS Viewはどういった要素で構成されているのか（開発する際にどういう内容を定義するのか）についてご紹介します。
CDS Viewの構成要素として、データソース、パラメータ、要素、要素プロパティ、フィルタがあります。
各構成要素の説明は、下図の表をご参照ください。

データソースには、そのCDS Viewの基本データとなるCDS View（プライマリ）や、結合したいCDS View（関連）を定義します。例えば、AというCDS Viewを作成し、次にAをプライマリデータソースとするBというCDS Viewを作成した場合、前段で紹介したような、階層化されたCDS Viewの構成になります。

キーユーザ拡張は業務知識を生かしたローコード開発

キーユーザ拡張は、SAPでは「業務プロセスやSAPの業務機能には詳しいが、本格的なABAP開発者ではない人向けの拡張方式」と定義されています。言い換えるとキーユーザ拡張では本格的なABAP開発などは公開されておらず、画面操作で定義開発が可能な開発方式となります（所謂ローコード・ノーコード開発）。

とはいえ、前段までで紹介したCDS Viewの概念やモデリングを理解したり、条件分岐や関数を駆使してビジネス
ロジックを開発することは、キーユーザとはいえ難しい部分があるかと想像します。

そういった事もあり我々ベンダーがキーユーザ拡張開発のご支援する事となります。

キーユーザ拡張におけるCDS Viewの設計・開発を通じて得た気づき

キーユーザ拡張でCDS Viewを設計・開発する際に気づいた事についてご紹介します。
キーユーザ拡張で開発を行う際に、あれ？これはキーユーザ拡張では出来ないのか、これは開発者拡張で公開されている関数か、といったような事が色々ありましたので以下の表にまとめました。

このキーユーザ拡張ですが、前段でキーユーザ向けのローコード・ノーコード拡張と説明しましたが、実際に経験してみるとベンダー開発者の視点で見ても、非常に奥深くやりごたえのある内容に感じました。
その話はまた別の機会にさせて頂きます。

気付きに関するエピソードのご紹介

前段でお話しした気付きについて、いくつか具体的なエピソードをご紹介します。

• 階層化CDS Viewにおける項目修正
  プロジェクトで開発を進めるうえで変更はつきものですが、それが階層化されたCDS Viewの下層にある項目となると中々面倒な改修となります。しかも項目の修正作業以外の作業は、上層のCDS Viewから目的のCDS Viewに辿り着くまでただひたすら対象項目を削除していくという地味な作業です。
  こういった場合の予防策としては、項目が計算要素（ロジック）に限られますが、計算要素自体を上層のCDS Viewに移す事です。
  また、この事を知らない時に改修に対する工数見積もりをした際、作業工数が見積もりより多めに掛かかりました（誤差の範囲ですが）。
• キーユーザ拡張の機能制限におけるCDS階層の分割
  こちらも開発当初かなり戸惑った内容になります。具体的には、CDS A を定義する際、他にCDS B、Cとあり、AとBを結合し、BとCを結合するといった事が普通に可能と考えていたのですが、キーユーザ拡張では出来ませんでした。
  ECC時代の例で恐縮ですが、受注ヘッダ、受注明細、受注納入日程行、という３階層が１つのCDSでは出来ないというイメージです。
  この例以外にも、CDS Aの中で定義した計算要素の値を結合キーとして使用しCDS Bと結合する、という事も出来ません。
  いずれの場合もCDS定義を分割して開発する事が必要でした。
• 結合を諦めたCDS View（CDSシナリオが分析キューブ/分析次元の場合）
  会計系のCDS Viewでおなじみの原価センタですが、原価センタマスタCDSのキー項目は「管理領域＋原価センタ＋有効終了日」となっています。有効終了日が過去履歴分レコードが存在します。原価センタマスタCDSを結合し、条件に合致する1件を取得したい場合、日付までイコールで指定出来れば問題ありません。しかしそれが出来ない場合、結合を諦めざるを得ません。CDSシナリオの分析キューブ/次元の場合は不確かな条件を許可していない為です。
  もし使用する標準のCDSが、アソシエーションとして原価センタマスタを保持している場合はそちらが使えます。アソシエーションは事前の定義で結合が完了しているためです。

まとめ

如何でしたか。今回はCDS Viewの概要と実際の設計・開発を通じて得た内容をご紹介しました。

簡単にまとめると以下の通りです。

• CDS Viewは、複数のデータを取得するためだけの仕組みではありません。業務上関連するデータを整理し、計算や条件などのビジネスロジックと、金額・通貨、数量・単位といった意味を持たせたデータモデルです。
• 最終目的のCDS Viewを一つで作り込むのではなく、ビジネスデータ単位に分解・整理し、必要に応じて 階層化することで、各CDS Viewを再利用しながら目的に応じたデータモデルを段階的に構築できます。
• キーユーザ拡張では、画面操作を中心にカスタムCDS Viewを作成できますが、利用可能なデータソースや関数には制約があります。そのため、作成方法だけでなく、どの単位でデータを整理し、どのように組み合わせるかというモデリングの考え方が重要になります。

今回の記事が、CDS Viewを単なる機能ではなく、業務データを整理・活用するための仕組みとして
理解するきっかけになれば幸いです。