SAPUI5フリースタイルでは、画面構成やイベント処理を要件に合わせて実装する
前記事「既存SAP WEB GUIを生かしてFiori UIへ」では、SAP Screen PersonasとSAPUI5 Appletを使い、既存のトランザクションを残したまま画面をモバイル対応する方法を紹介しました。既存画面に必要な業務機能が揃っているなら、まずはその機能を生かせないか検討するのが現実的です。
しかし、業務によっては既存画面の改善だけでは足りない場面があります。業務手順に沿った独自の入力フローが必要なとき、複数の処理を1つの画面へまとめたいとき、現場の利用条件に合わせて画面を設計し直したいときです。こうした場面では、テンプレートに画面全体を委ねず、ViewとControllerを要件に合わせて構成するSAPUI5のフリースタイル開発が選択肢になります。
フリースタイル開発は、SAP Fiori elementsを使う場合と比べてアプリ固有のコードが増えます。だからこそ、開発AIエージェントによるコーディング支援を活用できる範囲も広がります。本記事では、フリースタイル開発の位置づけと構成要素、そしてAIと人の分担を紹介します。分担の原則は前記事と同じです。AIはコーディングに特化させ、人は要件の整理、画面の設計、そして検証に集中します。
SAP UIの改善に関心があり、「SAP Fiori elementsとフリースタイルのどちらを選ぶべきか」と悩んでいる開発者、アーキテクト、IT部門の担当者に向けて、判断の軸と実装の要点をお伝えします。
この記事で分かること
- フリースタイル開発とSAP Fiori elementsの違い、選び方の判断基準
- OData V2とV4の違いと、本記事でV2を使う前提
- フリースタイルアプリの骨格(manifest.json、MVC、ルーティング、ODataモデル)
- 入力フォーム、画面遷移、ODataサービスへの登録を実装するコードの要点
- AIに実装を任せる前に人が決めておくこと(フリースタイル版)
- 前記事のApplet開発との違いと、方式の選び方マップ
- 開発からデプロイまでの流れと、実装・運用で注意したい点
1. フリースタイル開発とは:SAP Fiori elementsとの違い
SAP Fiori elementsは定型的なUIパターンを活用し、フリースタイルは画面全体を要件に合わせて構成する
まず、SAPUI5を基盤とする代表的な開発方式として、SAP Fiori elementsとフリースタイルの違いを整理します。SAP Fiori elementsは、List ReportやObject Pageなどの定型的なUIパターンを、ODataサービスのメタデータとアノテーションを基に構成する方式です。アプリ固有のUIコードを抑えながら、一貫性のある画面を作りやすい点が特長です。フリースタイルでは、XML ViewとControllerを実装し、画面構成や操作を要件に合わせて設計します。
| 観点 | SAP Fiori elements | フリースタイル |
|---|---|---|
| 画面の作り方 | テンプレート+アノテーション | XML ViewとControllerを自分で設計 |
| アプリ固有のUIコード | 比較的少ない | 要件に応じて増える |
| 画面設計の自由度 | テンプレートの範囲内 | 要件に合わせて個別設計 |
| UXの一貫性 | 定型的なUIパターンにより保ちやすい | Fioriデザイン原則への準拠を開発側で担保 |
| 向いている場面 | 一覧・詳細など定型的な画面 | 業務手順に沿った独自の入力フロー、現場特化のUI |
判断の順序が重要です。まずSAP Fiori elementsで要件を満たせるかを検討し、標準的な画面パターンでは実現できない要件が明確な場合にフリースタイルを選びます。自由度の高さは、設計・実装・保守する範囲の広さにもつながるからです。
OData V4を前提に、SAP Fiori elementsの標準機能と独自拡張を組み合わせるFlexible Programming Modelも選択肢になります。本記事では、既存のOData V2サービスを使い、現場の業務手順に沿った入力フローを画面全体として設計するため、フリースタイルを採用します。OData V2とV4の違いは、次項で整理します。
1-1. OData V2とV4の違い
SAPUI5アプリがバックエンドとやり取りするODataには、V2とV4の2つのバージョンがあります。両者の違いを整理すると、次のようになります。
| 観点 | OData V2 | OData V4 |
|---|---|---|
| プロトコルの位置づけ | 従来からSAP Gatewayで広く使われてきた仕様 | OASIS標準として策定された最新仕様。SAPが今後の主軸としている |
| SAPUI5側のモデル | sap.ui.model.odata.v2.ODataModel。create()やread()を直接呼び出す書き方が中心 | sap.ui.model.odata.v4.ODataModel。バインディングを通じてデータを操作する設計で、V2とはAPIの考え方が異なる |
| バックエンド側の実装 | SAP Gateway Service Builder(SEGW)で作成した既存サービスが多い | ABAP RESTful Application Programming Model(RAP)やSAP Cloud Application Programming Model(CAP)で作成する |
| SAP Fiori elementsとの関係 | V2向けのテンプレート(sap.suite.ui.generic.template)を使う | V4向けのsap.feを使い、Flexible Programming Modelで拡張できる |
| ドラフト(一時保存) | 個別に設計・実装が必要 | RAPのドラフト処理と組み合わせて標準的に扱える |
| 既存資産・情報の量 | 既存のSAP標準サービスや社内サービス、公開事例が多い | 新規開発で採用が進んでいるが、既存環境ではまだV2サービスが主流の場合が多い |
SAPはV4を今後の主軸としており、新しくODataサービスから設計する場合や、SAP Fiori elementsのFlexible Programming Modelやドラフト処理を活用したい場合は、V4を検討するのが自然です。一方で、既存のSAP環境ではSAP Gatewayで作成されたV2サービスが広く使われており、開発者にとってはV2の方が浸透しています。本記事では、多くの読者が実際の環境や既存のコードと重ねてイメージしやすいよう、OData V2で進めます。第2章以降のコード例も、V2サービスを前提としています。
なお、本記事のコード例では、入力中の値を画面専用の一時モデルに保持し、「登録」ボタンを押した時点でODataサービスへ送る構成にしています(3-2で説明します)。V4サービスを使う場合も、送信処理の実装を差し替える範囲に絞れるため、画面側の設計はそのまま生かせます。
また、フリースタイルを選んでも、Fioriのデザイン原則(Role-based、Adaptive、Simple、Coherent、Delightful)から自由になるわけではありません。画面を自由に設計できるからこそ、利用者の役割に必要な情報へ絞り、端末に適応し、操作を単純に保つ規律が求められます。
2. 題材:現場向け作業実績入力アプリ
題材として、設備保全の担当者が現場で作業実績を入力するアプリを取り上げます。前記事では通知一覧をモバイル向けに再構成しました。本記事では、その一覧で選んだ通知番号を引き継ぎ、実施した作業を記録する画面をSAPUI5フリースタイルで作成します。
要件を整理すると、次のようになります。
- 通知を選んだ流れのまま、作業実績の入力へ進みたい(通知番号は引き継ぐ)
- 入力項目は最小限にする:作業内容、実施日、作業時間
- 手袋をしたままでも操作しやすい、大きな入力部品を使いたい
- 入力ミスを登録前にチェックしたい
- 登録処理を提供する既存のOData V2サービスを利用する
この要件は、SAP Fiori elementsの標準的な一覧・詳細画面だけでは表現しにくいものです。今回は「一覧を見て詳細を確認する」のではなく、通知の選択から作業内容の入力、確認、登録までを現場の手順に合わせて構成します。画面全体のレイアウトと操作を個別に設計する必要があるため、SAPUI5フリースタイルを使用します。
技術方式は前記事と異なりますが、既存のデータ、権限、業務処理を可能な限り再利用する考え方は共通です。利用できる既存のODataサービスがある場合は、通知データ、権限、登録の業務処理を再利用し、新しく作る範囲を画面中心に絞れます。本記事では、目的の登録処理を持つOData V2サービスがすでに存在するものとします。利用できるサービスがない場合は、バックエンド側の設計と実装も必要です。
| コード例の前提:後述するWorkConfirmationSetやQmnumなどは、通知にひもづく作業記録を登録する説明用ODataサービスの名称です。SAP標準の保全指図確認を実装する場合は、通知番号だけではなく、保全指図番号や作業番号など、対象APIのメタデータに定義された項目へ置き換える必要があります。 |
3. フリースタイルアプリの構成要素
画面、イベント処理、ルーティング、データアクセスの責務を分けて構成する
「自由に設計できる」といっても、フリースタイルアプリを無秩序に作るわけではありません。アプリ全体の設定はmanifest.json、画面はView、画面固有のイベント処理はController、データはModelやServiceというように責務を分けます。URLパターンと遷移先の対応はルーティングで宣言します。
3-1. manifest.jsonで画面遷移を宣言する
今回のアプリは「通知一覧」から「作業実績入力」へ進む2画面構成です。manifest.jsonには、OData V2サービス、デフォルトモデル、画面を配置するルートView、ルートと遷移先の対応を定義します。次のコードでは、説明に関係する部分だけを示しています。
{
"sap.app": {
"id": "workconfirm",
"type": "application",
"dataSources": {
"workConfirmationService": {
"uri": "/sap/opu/odata/sap/Z_WORK_CONFIRMATION_SRV/",
"type": "OData",
"settings": { "odataVersion": "2.0" }
}
}
},
"sap.ui5": {
"rootView": {
"viewName": "workconfirm.view.App",
"type": "XML",
"id": "appRoot",
"async": true
},
"dependencies": {
"libs": {
"sap.ui.core": {},
"sap.m": {},
"sap.ui.layout": {}
}
},
"models": {
"": {
"dataSource": "workConfirmationService",
"preload": true,
"settings": { "useBatch": true }
}
},
"routing": {
"config": {
"routerClass": "sap.m.routing.Router",
"type": "View",
"viewType": "XML",
"path": "workconfirm.view",
"controlId": "app",
"controlAggregation": "pages",
"async": true
},
"routes": [
{
"name": "worklist",
"pattern": "",
"target": "worklist"
},
{
"name": "entry",
"pattern": "entry/{notificationId}",
"target": "entry"
}
],
"targets": {
"worklist": { "id": "worklist", "name": "Worklist" },
"entry": { "id": "entry", "name": "Entry" }
}
}
}
}
ルーティングを動作させるには、ルートView内に遷移先を配置するAppコントロール(この例ではid="app")を用意し、Componentの初期化時にルーターを開始します。
sap.ui.define([
"sap/ui/core/UIComponent"
], function (UIComponent) {
"use strict";
return UIComponent.extend("workconfirm.Component", {
metadata: { manifest: "json" },
init: function () {
// UIComponentの標準初期化を先に実行する
UIComponent.prototype.init.apply(this, arguments);
// manifest.jsonに定義したルートの監視を開始する
this.getRouter().initialize();
}
});
});
通知一覧での操作をきっかけに画面を切り替えるには、行が選ばれたときにControllerからルーターのnavTo()を呼び出します。
onNotificationPress: function (oEvent) {
// 選択された行の通知番号をバインディングコンテキストから取得する
var oContext = oEvent.getSource().getBindingContext();
var sNotificationId = oContext.getProperty("Qmnum");
// URLで扱える形式にして、entryルートの必須パラメータへ渡す
this.getOwnerComponent().getRouter().navTo("entry", {
notificationId: window.encodeURIComponent(sNotificationId)
});
}
| TIPS:バインディングコンテキストとルーティング
バインディングコンテキストとは、画面上のコントロールが、モデル内のどのデータを参照しているかを示す情報です。この例では、選択された行のコンテキストから、その行に対応するQmnumを取得しています。 ルーティングとは、URLのハッシュパターンと表示するViewの対応関係を定義する仕組みです。entry/{notificationId}のように必須パラメータを定義すると、Controllerはルートが一致したときに通知番号を受け取れます。ブラウザの「戻る」や再読み込みにも対応できますが、再読み込み後に画面を復元するには、ルート引数を基に必要なデータを読み直す実装が必要です。 |
3-2. 入力フォームのXML View
入力画面はSimpleFormのレスポンシブレイアウトで組みます。入力値は画面専用の一時モデル(entry)とバインドし、確定するまでODataサービスへは送りません。
<mvc:View
controllerName="workconfirm.controller.Entry"
xmlns:mvc="sap.ui.core.mvc"
xmlns:f="sap.ui.layout.form"
xmlns="sap.m">
<Page id="entryPage"
title="作業実績の入力"
showNavButton="true"
navButtonPress="onNavBack">
<!-- 画面幅に応じてラベルと入力欄の配置が変わる -->
<f:SimpleForm id="entryForm"
editable="true"
layout="ResponsiveGridLayout">
<Label text="通知番号" labelFor="notificationText" />
<Text id="notificationText"
text="{entry>/NotificationId}" />
<Label text="作業内容" required="true"
labelFor="workTextInput" />
<TextArea id="workTextInput"
value="{entry>/WorkText}" rows="3" />
<Label text="実施日" required="true"
labelFor="workDateInput" />
<DatePicker id="workDateInput"
value="{path: 'entry>/WorkDate',
type: 'sap.ui.model.odata.type.DateTime',
constraints: {displayFormat: 'Date', nullable: false}}"
change="onWorkDateChange" />
<Label text="作業時間(時間)" required="true"
labelFor="durationInput" />
<StepInput id="durationInput"
value="{entry>/Duration}"
min="0.5" max="24" step="0.5"
displayValuePrecision="1" />
</f:SimpleForm>
<footer>
<OverflowToolbar>
<ToolbarSpacer />
<Button id="submitButton"
type="Emphasized" text="登録"
press="onSubmit" />
</OverflowToolbar>
</footer>
</Page>
</mvc:View>
DatePickerやStepInputは、キーボードだけでなくタップでも操作できます。日付や数値を自由入力だけにせず、選択・増減できるUIへ置き換えることで、入力形式のばらつきを抑えます。主要なコントロールには安定したidを付け、ラベルと入力欄はlabelForで関連付けています。
|
TIPS:データバインディングと入力用の一時モデル データバインディングとは、モデルの値と画面コントロールのプロパティを結び付ける仕組みです。たとえば{entry>/WorkText}は、一時モデルのWorkTextと入力欄を結び付けています。 この例では、入力中の値を画面専用のJSONModel(entry)に保持し、「登録」ボタンを押した時点でODataサービスへ送るデータを組み立てます。ODataモデルへ直接バインドする方法もありますが、変更の送信タイミングはモデルのグループ設定などに左右されます。一時モデルを使うと、入力と送信の境界を明示でき、入力チェックも実装しやすくなります。 |
3-3. 入力チェックとODataサービスへの登録
「登録」ボタンでは、作業内容、日付、作業時間を確認してからODataサービスへ送信します。次のコードには、一時モデルの初期化、ルート引数の受け取り、日付入力の状態表示、登録中の二重送信防止、登録完了後に一覧へ戻る処理も含めています。
sap.ui.define([
"sap/ui/core/mvc/Controller",
"sap/ui/model/json/JSONModel",
"sap/m/MessageBox"
], function (Controller, JSONModel, MessageBox) {
"use strict";
return Controller.extend("workconfirm.controller.Entry", {
onInit: function () {
// 入力途中の値を保持する画面専用モデルを作成する
this.getView().setModel(new JSONModel({
NotificationId: "",
WorkText: "",
WorkDate: null,
Duration: 0.5
}), "entry");
// entryルートに一致したときだけ通知番号を受け取る
this._oEntryRoute = this.getOwnerComponent()
.getRouter().getRoute("entry");
this._oEntryRoute.attachPatternMatched(
this._onEntryMatched, this);
},
onExit: function () {
// Controller破棄時にルートイベントの登録も解除する
if (this._oEntryRoute) {
this._oEntryRoute.detachPatternMatched(
this._onEntryMatched, this);
}
},
_onEntryMatched: function (oEvent) {
// URL用に符号化した通知番号を元へ戻し、入力値を初期化する
var sNotificationId = window.decodeURIComponent(
oEvent.getParameter("arguments").notificationId);
this.getView().getModel("entry").setData({
NotificationId: sNotificationId,
WorkText: "",
WorkDate: null,
Duration: 0.5
});
},
onWorkDateChange: function (oEvent) {
// 書式が不正な日付は入力欄上でもエラーとして示す
oEvent.getSource().setValueState(
oEvent.getParameter("valid") ? "None" : "Error");
},
onSubmit: function () {
var oEntry = this.getView()
.getModel("entry").getData();
var sWorkText = (oEntry.WorkText || "").trim();
var fDuration = Number(oEntry.Duration);
var bInvalidDate = this.byId("workDateInput")
.getValueState() === "Error";
// 表示上の必須記号とは別に、送信前の値を検証する
if (!sWorkText || !oEntry.WorkDate || bInvalidDate ||
isNaN(fDuration) || fDuration < 0.5 || fDuration > 24) {
MessageBox.error(
"作業内容、実施日、作業時間を確認してください。");
return;
}
this._setSubmitBusy(true);
// 画面用モデルからOData V2の登録データを組み立てる
this.getView().getModel().create(
"/WorkConfirmationSet",
{
Qmnum: oEntry.NotificationId,
WorkText: sWorkText,
WorkDate: oEntry.WorkDate,
Duration: String(fDuration)
},
{
success: this._onCreateSuccess.bind(this),
error: this._onCreateError.bind(this)
}
);
},
_setSubmitBusy: function (bBusy) {
// 登録処理中はボタンを無効化して二重送信を防ぐ
this.byId("submitButton")
.setBusy(bBusy).setEnabled(!bBusy);
},
_onCreateSuccess: function () {
this._setSubmitBusy(false);
// 完了を知らせたあと、現場の流れに合わせて一覧へ戻る
MessageBox.success("作業実績を登録しました。", {
onClose: this.onNavBack.bind(this)
});
},
_onCreateError: function () {
this._setSubmitBusy(false);
MessageBox.error("登録に失敗しました。再度お試しください。");
},
onNavBack: function () {
// 戻る操作では一覧のルートへ遷移する
this.getOwnerComponent().getRouter()
.navTo("worklist", {}, true);
}
});
});
| 技術上の整理:コード例はOData V2モデルのcreate()を使っています。OData V4では登録処理のAPIが異なります(V2とV4の違いは1-1を参照してください)。また、日付・数値の形式、エンティティ名、項目名はサービスのメタデータに従う必要があります。ルーティングの記法もSAPUI5のバージョンによって異なるため、対象環境の公式ドキュメントで確認してください。実際のアプリでは、画面文言をi18nリソースへ分離します。 |
前記事のAppletとの違いもここにあります。Appletは既存画面のGuiGridViewからデータを読み取り、Personasスクリプトを介して画面と連携しました。今回のフリースタイルアプリは既存画面を介さず、デフォルトのODataモデルを通じてサービスへアクセスします。既存画面から独立しているため、画面構成だけでなく、ルーティング、モデル、入力検証、エラー処理までアプリ側で設計します。
3-4. 開発からデプロイまでの流れ
実装したアプリが利用者へ届くまでの工程を整理すると、次のようになります。
| 工程 | 実施内容 | 主な確認事項 |
|---|---|---|
| 1. 要件整理・画面設計 | ワイヤーフレーム、画面遷移、受け入れ条件を決める | 利用者、端末、既存ODataサービスの有無 |
| 2. 実装 | manifest.json、View、Controller、ルーティングを実装する | SAPUI5バージョンとAPI互換性 |
| 3. ローカル確認 | 開発環境でモックデータを使い、画面と遷移を確認する | 入力チェック、レスポンシブ動作 |
| 4. デプロイ | SAPUI5 ABAP RepositoryまたはSAP BTPへ配置する | 名前空間、移送、キャッシュ |
| 5. Fiori Launchpad登録 | カタログ・グループ(スペース)へタイルを登録する | 利用者ロールへの割り当て |
| 6. テスト | 実データ・実機で一連の業務操作を確認する | 権限、性能、エラー時の挙動 |
4. AIと進めるフリースタイル開発:実装前の整理が重要
人が設計と完成条件を定め、AIによる実装支援の結果を人がレビューする
フリースタイル開発では、画面構成やイベント処理を要件に合わせて実装できます。その分、AIに実装を依頼する前に、仕様やインターフェース、完成条件を明確にしておく必要があります。本記事のようなアプリを開発する場合、あらかじめ整理しておきたいのは次の3点です。
- 画面構成とルーティングを決めておく:画面のワイヤーフレーム、画面間の遷移、URLパターン、各画面が受け取るパラメータを設計します。AIには、決定済みの画面設計に沿った実装を任せます。
- 準拠する技術条件を明示しておく:対象環境のSAPUI5バージョン、ODataのバージョンとサービス定義、Fioriデザインガイドラインを指定します。これにより、利用できないAPIや、サービスの定義と合わないコードが生成されるリスクを抑えられます。
- 画面ごとの受け入れ条件を先に定義しておく:必須チェック、エラー表示、レスポンシブ動作、登録成功・失敗時の挙動を画面単位で定義します。AIが生成したコードも、この条件に照らして人が確認します。
| AIが支援できる領域 | 人が確認・判断する領域 |
|---|---|
| View・Controller・ルーティング定義の実装 | 画面設計とワイヤーフレーム、業務手順との整合 |
| 入力チェックやエラー処理の実装案 | チェック仕様そのもの(何を必須とするか)の決定 |
| 公開ドキュメントを基にしたSAPUI5 APIの調査、非推奨API候補の洗い出し | 対象環境のバージョンやODataサービスとの互換性の確認 |
| テスト観点の列挙、確認手順の下書き | 実データ・実機での検証と、本番反映の判断 |
自由度が高い方式ほど、AIに渡す前に人が決めるべきことは増えます。フリースタイル開発でAIが速さを発揮するのは、設計の裁量を人が引き受けたときです。生成されたコードが業務要件と対象環境に合っているかを判断し、最終的な品質を担保することも、人の役割です。
なお、実データ、認証情報、接続先、非公開コードを外部サービスへ入力する前に可否を確認する、という情報管理の原則も前記事と同じです。
5. 開発時間とAI支援の効果
今回のアプリ開発では、AI支援の効果をアプリ実装工程に絞って比較します。この工程の実績は12時間でした。AI支援なしの想定工数60時間(見積値)と比べると、48時間/80%の差になります。
前記事のApplet開発では、実績3時間、想定16時間(見積値)で約80%の短縮でした。フリースタイル開発はアプリ固有のコードが多い分、AIによる実装支援を適用できる範囲も広がります。今回も短縮率は約80%となり、コーディングが中心の工程ではAI支援の効果が大きいという傾向は前記事と一致しています。規模が大きい分、短縮された時間の絶対量(48時間)はApplet開発を大きく上回りました。一方で、画面設計、ODataサービスとの結合確認、実機テストといった人が担う工程は残ります。
6. 実装・運用で注意したい点
SAPUI5のバージョンと非推奨APIを確認する
フリースタイルはアプリ固有のコードが多い分、SAPUI5のバージョン差の影響も受けやすくなります。利用するコントロールとAPIが対象環境のバージョンで推奨されているかを、公式ドキュメントで確認してから採用します。AIが生成したコードには古い書き方や非推奨APIが混ざることがあるため、レビューの観点としても有効です。
認可はODataサービス側でも担保する
画面を新しく作っても、権限の設計は省略できません。画面側の入力制御だけに頼らず、ODataサービス側の認可チェックが登録処理に対して有効であることを確認します。あわせて、アプリを利用者へ届けるためのロール設計(Fiori Launchpadのカタログ・グループの割り当て)も必要です。
画面文言はi18nリソースへ分離する
コード例では説明のため日本語をXML Viewへ直接書いていますが、実際のアプリでは文言をi18nリソースバンドルへ分離します。多言語対応の予定がなくても、文言の変更のたびに画面コードへ手を入れずに済む構成にしておくと、保守が楽になります。
実機で一連の業務操作を確認する
ブラウザの幅を狭めただけの確認では、タップ領域、ソフトウェアキーボード、回線速度を評価できません。現場で使う実機を使い、通知の選択から入力、登録、一覧への復帰までを一連の操作として確認します。
画面が動くことと、現場で迷わず短時間に入力を終えられることは、別の評価です。
7. まとめ:方式が変わっても、分担は変わらない
SAP画面の改善には複数の選択肢があります。整理すると次のようになります。
| 状況 | 選択肢 |
|---|---|
| 既存画面に業務機能が揃っており、画面体験だけを変えたい | SAP Screen Personas+SAPUI5 Applet(前記事) |
| 一覧・詳細など定型的な画面を標準UXで作りたい | SAP Fiori elements |
| 標準的な画面構成を基に、一部へ独自機能を加えたい | SAP Fiori elementsのFlexible Programming Model(OData V4) |
| 業務手順に沿った独自の画面フローが必要 | フリースタイル開発(本記事) |
どの方式を選んでも、AIと人の分担の原則は変わりません。AIはコーディングを支援し、人は要件の整理、画面の設計、準拠する基準の選定、そして動作・互換性・セキュリティの検証を担います。方式が変わっても、この分担が開発の速さと品質を両立させます。私たちは今後も、この分担を前提にSAP画面改善のプロジェクトを進めていきます。
まずは、いま困っている業務の流れを1つ選び、「既存画面を生かすのか、標準的な画面構成を基にするのか、独自の画面フローが必要なのか」を整理するところから始めてみてください。今回のように業務手順に沿った独自の入力フローが必要であれば、SAPUI5フリースタイルが選択肢になります。
【本記事の執筆・監修体制について】
執筆:あく抜き太郎
リアルテックジャパン株式会社 AI企画開発担当
2000年からインターネット業界に従事。インフラ・ネットワークエンジニア、プロジェクトマネージャー、テクニカルディレクター、社内情報システム責任者などを歴任。現在はAIを活用したシステム開発や、ロボット・IoTのPoC・開発に取り組む。情報システムの構築・改善やセキュリティ強化にも精通している。
専門領域:AI活用システム開発/ロボット・IoT/情報システム・セキュリティ
監修:リアルテックジャパン株式会社 SAPソリューション事業
最終監修責任者:代表取締役社長 松浦 一哉
- カテゴリ: Fiori・UI開発
- キーワード:Fiori・UI開発



