Fiori: Flexible Programming Modelの概要

## はじめに
Flexible Programming Modelとは、OData V4ベースのFioriアプリを作成するときに使える開発手法で、Fiori elementsのような見た目を提供しながら比較的自由な拡張ができるという特徴があります。この記事は、Flexible Programming Modelの概要について説明することを目的としています。

## Flexible Programming Model登場の背景
Fiori elementsは開発工数が少なくて済み、見た目や操作感が統一されるため推奨される開発方法です。一方で、顧客固有の要件がどうしても入ってくるため、Fiori elementsを採用したとしても拡張開発が必要になることがあります。拡張箇所が多くなると結局開発工数、メンテナンスの工数が上がってしまいます。また、正しい方法で拡張しないと、UI5バージョンを上げたときに拡張部分が動かない可能性もあります。

Flexible Programming Modelでは、**Extension points**、**Building blocks**、**Controller extensions**という3つの機能を提供することで、以下を可能にしようとしています。
- カスタムUI5のコーディングを削減　⇒　ライフサイクルの安定性の向上とメンテナンス工数の削減
- 標準のFiori elements機能（ドラフトハンドリングやサイドエフェクト）を拡張で利用　⇒　開発効率の向上
- 拡張部分でも、UXの一貫性を保持

参考：[Leverage the flexible programming model to extend your SAP Fiori elements apps for OData V4](https://blogs.sap.com/2021/08/19/leverage-the-flexible-programming-model-to-extend-your-sap-fiori-elements-apps-for-odata-v4/)

## Flexible Programming Modelが提供する機能
Flexible Programming Modelでは以下の3つの機能が提供されています。

### 1. Extension points
Extension pointsとは、Fioe elementsのテンプレートで作成したアプリケーションを拡張できるポイントです。以下の拡張ポイントが用意されており、ざっと見る限り、List Reportの見た目に関して思いつく限りの拡張が可能になっています。

|Extension point  |できること  |
|---|---|
|Custom Section  |Object Pageにセクションを追加する  |
|Custom Subsection  |Object Pageのセクションに、サブセクションを追加する  |
|Custom Action  |テーブルのツールバーやObject Pageにカスタムアクション（ボタン）を追加する  |
|Custom Column  |テーブルにカラムを追加する。ODataのエンティティに持っていない項目を表示したいときに使用  |
|Custom Header Facet  |Object Pageのヘッダに項目を追加する  |
|Custom Form Element  |Object Pageのセクション内に項目を追加する  |
|Custom Filter  |フィルターバーに項目を追加する。ODataのエンティティに持っていない項目でフィルタしたいときや、コントロールの見た目を変えたいときに使用  |
|Custom Page  |List ReportやObject Pageの代わりに独自に定義したViewを使用する  |
|Custom View in List Report  |List Reportのテーブル表示部分に追加のタブを作成する  |

以下はCustom Sectionによる拡張の例です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276021/9b4822c5-b35f-0a34-d661-90619b0d907f.png)

参考：[SAP Fiori Elements: Flexible Programming Model Explorer > Overview of Extension Points](
https://sapui5.hana.ondemand.com/test-resources/sap/fe/core/fpmExplorer/index.html#/customElements/customElementsOverview)

### 2. Building blocks
Building blocksとは、OData V4をベースとしたFiori elementsの拡張やフリースタイルアプリで使えるUI部品で、Fiori elementsの部品と同じ見た目や動作を提供します。以下はFilter BarとTableのBuilding Blocksを使った画面の例です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276021/dd4df5a9-f52e-552e-d912-084fe763e025.png)

OData V2で使えるSmart Controlsと似ていますが、Building bolocksはFiori elementsのランタイムによって制御されるため、ドラフトハンドリングやサイドエフェクト、ナビゲーションといった機能もほとんどコーディングすることなく使えます。OData V4ではSmart Controlsは使えませんが、Building Blocksがその代わりになるものだと理解しています。

>Essentially, the building blocks for our OData V4 stack are an evolution of the smart controls for OData V2 – with improved architecture, cleaner code, better performance, and enhanced functionality.

引用：[Leverage the flexible programming model to extend your SAP Fiori elements apps for OData V4](https://blogs.sap.com/2021/08/19/leverage-the-flexible-programming-model-to-extend-your-sap-fiori-elements-apps-for-odata-v4/)

#### 特徴
以下はFilter BarとTableを表示するためのViewのソースです。Building blocksは`sap.fe.macros`というネームスペースで提供されるコントロールなので、先頭でこのネームスペースを宣言する必要があります。
Building blocksのコントロールでは`metaPath="@com.sap.vocabularies.UI.v1.<annotation>`という形でUIアノテーション、またはODataの項目を指定します。Smart Controlsの場合、特定のアノテーションがすでに定義されている前提か、コントロールに対して直接見え方を設定していました。Building blocksでは任意のアノテーションを指定できるため柔軟性が上がっています。

```xml
<mvc:View
	xmlns="sap.m"
	xmlns:mvc="sap.ui.core.mvc"
	xmlns:macros="sap.fe.macros"
	controllerName="sap.fe.core.fpmExplorer.tableFilterBar.TableFilterBar"
>
	<Panel headerText="Table in Display Mode with FilterBar">
		<macros:FilterBar metaPath="@com.sap.vocabularies.UI.v1.SelectionFields#SF1" id="FilterBar" />
		<macros:Table metaPath="@com.sap.vocabularies.UI.v1.LineItem" readOnly="true" id="LineItemTable" filterBar="FilterBar" />
	</Panel>

	<Panel headerText="Table in Display Mode with FilterBar liveMode=true">
		<macros:FilterBar metaPath="@com.sap.vocabularies.UI.v1.SelectionFields#SF1" id="FilterBar2" liveMode="true" />
		<macros:Table metaPath="@com.sap.vocabularies.UI.v1.LineItem" readOnly="true" id="LineItemTable2" filterBar="FilterBar2" />
	</Panel>
</mvc:View>
```

#### 提供されているBuilding blocks

現時点では、以下のBuilding blocksが提供されています。

|Building block  |説明  |
|---|---|
|Field  |単一項目  |
|Form  |フォーム。FieldGroupまたはFieldGroupを含んだCollectionFacetのアノテーションを指定する  |
|Form Element  |フォーム内に配置する項目。ラベルや可視性を項目単位でコントロールできる。Form Elementの中でFieldを使用することもできる  |
|Table  |テーブル。LineIteまたはPresentationVariantのアノテーションを指定する  |
|Filter Bar  |検索で使うフィルターバー。SelectionFieldsアノテーションを指定する  |
|Micro Chart  |Object Pageのヘッダやフォーム内、テーブル列で使う小さなチャート。Chartアノテーションを指定する  |
|Chart  |セクション1つを使う大きなチャート。Chartアノテーションを指定する  |
|Flexible ColumnLayout Actions|Flexible ColumnLayoutで"Close", "Enter Full Screen", "Exit Full Screen"ボタンを右上に表示する|
|Share|メール送信、タイルとして保存などができるShareボタンを表示する|
|Paginator|リスト上で表示する明細を切り替えることができる改ページボタンを表示する|

参考：[SAP Fiori Elements: Flexible Programming Model Explorer > Overview of Building Blocks](https://sapui5.hana.ondemand.com/test-resources/sap/fe/core/fpmExplorer/index.html#/buildingBlocks/buildingBlockOverview)

### 3. Controller extensions
Controller extensionsはFiori elementsのロジックを拡張（追加・上書き）するためのフックです。各extensionはクラスになっていて、関連する複数のメソッドを提供します。

|Controller extension  |説明  |
|---|---|
|Edit Flow  |CRUD処理の前にロジックを追加、およびCRUD処理を実行するメソッドを提供  |
|Custom State Handling  |Stateとはナビゲーションの際にViewの状態（フィルタの選択値など）を保持するオブジェクト。このフックによって、拡張した項目をStateの保存時に追加したり、Stateを読み込んだ際に取得することができる  |
|"Share" Functionality  |"Share"機能を使ってメールを作成する際、件名を変更することができる（他にも、メソッドadaptShareMetadatのパラメータにあるものは変更ができそう）  |
|Routing Extensibility  |アプリ内でのルーティングの前後にロジックを追加できる。デフォルトのルーティング先を書き換えることも可能  |
|Intent Based Navigation  |別のアプリにナビゲーションする際、選択パラメータやアクション、セマンティックオブジェクトを書き換えられる  |

参考：[SAP Fiori Elements: Flexible Programming Model Explorer> Controller Extensions overview](https://sapui5.hana.ondemand.com/sdk/test-resources/sap/fe/core/fpmExplorer/index.html#/controllerExtensions/controllerExtensionsOverview)

## Flexible Programming Modelはどのように使えるか
以下のブログでは、Flexible Programming Modelの活用パターンとして4つの例が紹介されています。
[Leverage the flexible programming model to extend your SAP Fiori elements apps for OData V4](https://blogs.sap.com/2021/08/19/leverage-the-flexible-programming-model-to-extend-your-sap-fiori-elements-apps-for-odata-v4/)

①一つのList Reportから異なるObject Pageに遷移
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276021/7c36ec64-ac6f-8d4a-b78c-6689a86cec05.png)

②Object Pageのみのアプリ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276021/14fc767d-35da-8208-0eb9-643e75994e2e.png)

③カスタムページを任意の場所に配置
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276021/c1f8f0a4-934e-483f-839a-573a816f7a87.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276021/1382f5a0-a46d-b846-6dc0-ec6e53e44a17.png)

このような柔軟なページの配置が可能なのは、OData V4ベースのFiori elementsがフリースタイルと同じ[ルーティングの仕組みを使用してい](https://sapui5.hana.ondemand.com/sdk/#/topic/1559b2bb30134d8c9240bdd378d6543e)るからです。これにより、ルーティングのターゲットにFiori elementsのテンプレートを置くことも、フリースタイルのビューを置くこともできるようになっています。

#### BASで使えるFlexible Programming Modelのテンプレート
2022年12月現在、BAS(SAP Business Application Stuido)には以下のテンプレートが用意されています。

**List Report**：上記①または③のList Reportが先頭に来る場合に使用
**Form Entity Object Page**：上記②のパターンで使用。OData V4かつドラフト対応していることが前提
**Custom Page**：上記③で、カスタムページが先頭に来る場合に使用
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276021/d0ec01e0-e445-92ab-54db-a45f6a6346c3.png)

## Flexible Programming Modelを使うと何がうれしいか
従来のFiori開発では、「Fiori elementsを使うのか、フリースタイルで行くのか」を最初に決める必要があり、一旦決めたら後戻りはできませんでした（変更する場合は作り直しが必要）。Flexible Programming Modelを選択することで、たとえばList Reportのテンプレートで作成して、カスタムページで実装する必要があるとわかったらカスタムページを足すということも可能です。このように**Fiori elementsのテンプレートとカスタムレイアウトを自由に行き来できる**点がFlexible Programming Modelの利点です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276021/9bcf8cc9-d927-08e7-d87e-6bcd5809927d.png)
引用：[SAP Fiori: What’s new for SAP S/4HANA 2022 (on-premise and private cloud)](https://blogs.sap.com/2022/10/12/sap-fiori-whats-new-for-sap-s-4hana-2022-on-premise-and-private-cloud/) 

だいぶ前にUI5のドキュメントで「拡張箇所が10個以上になるならフリースタイルにしなさい」というような記述を見た記憶があるのですが（リンクは見つけられませんでした）、Flexible Programming Modelは拡張を推奨しているように思われます。

## 関連リンク
- Flexible Programming Modelに関するドキュメント、サンプル
[SAP Fiori Elements: Flexible Programming Model Explorer](https://sapui5.hana.ondemand.com/test-resources/sap/fe/core/fpmExplorer/index.html#/overview/introduction)

- Youtube
[SAP Fiori elements Flexible Programming Model](https://www.youtube.com/watch?v=oqvHN8tbRRw&list=PLo17W6sWsxWM0yervb4VUxglVAop34_DQ&index=2)

## Flexible Programming Modelを使って色々やってみた記事
- [Form Entry Object PageでObject Pageだけのアプリを作る](https://qiita.com/tami/items/1288205d3936e56c6e53)
- [Flexible Programming Model: 登録と照会で別のページを使う試みでできたこと、できなかったこと](https://qiita.com/tami/items/bd16adb3ca014cf00b1b)
- [Flexible Programming Model: 登録と照会で別のページを使う試み（2）](https://qiita.com/tami/items/595f746f855bf53b8ccf)