最近、SAP Build Appsを触ってるんだけど、これのロジック部分、結構クセがあるっていうか…面白いよね。最初は「なんだこれ？」ってなるんだけど、慣れるとレゴブロックみたいで。今日はそのへんの思考の整理。メモみたいなもんだから、ちょっと散らかってるかも。
重点一句話
要するに、Build Appsのロジックって「何かが起きたら（イベント）、これをやる（フロー関数）」っていうのを、ただひたすら繋げていくだけ。そこに外部のデータ（データリソース）をどう絡めるかって話。
まずは動くものを見てみる：ダークモードの実装
いきなり理論から入っても眠くなるだけだし、正直、僕もそうだった。だから、先に具体的な例から。よくある「ダークモード切り替えスイッチ」をどうやって作るか、っていう話。
やりたいことはシンプル。トグルスイッチをオンにしたら背景が黒っぽくなって、オフにしたら元に戻る。これだけ。
このロジックの流れは、頭の中だとこんな感じになる。
- ユーザーがトグルスイッチをタップする（これが「イベント」）。
- 今の状態が「オン」か「オフ」かをチェックする（「If Condition」っていうフロー関数を使う）。
- もし「オン」に向かうなら、アプリの背景色を「黒」に変える処理を呼ぶ。
- もし「オフ」に向かうなら、背景色を「白」に戻す処理を呼ぶ。
これをBuild Appsのロジックキャンバス上で、文字通りブロックを線で繋ぐみたいに作っていく。すごく視覚的。
この「If Condition」ってやつが便利で、1つの入力に対して、条件次第で2つ（あるいはそれ以上）の違う出口に処理を分岐させられる。プログラミングでいうところのif-else文そのものだね。これがあるから、一つのイベントで動的に振る舞いを変えるアプリが作れるわけだ。
じゃあ、どうやって作るの？：イベントとロジックキャンバス
さて、さっきのダークモードの例で「イベント」とか「フロー関数」って言葉が出てきたけど、それがBuild Appsの心臓部。作業する場所は「ロジックキャンバス」って呼ばれる、まあ、方眼紙みたいな画面だ。
このキャンバス、実は3種類あるんだよね。
- グローバルロジックキャンバス：アプリ全体で一回だけ動くような処理を書く場所。例えば、アプリが起動した直後にユーザー情報を読み込む、とか。
- ページロジックキャンバス：特定のページが表示されたり、閉じられたりした時に動く処理を書く。ページごとに設定できるスピナー（くるくる回るやつ）とかはここで制御する。
- コンポーネントロジックキャンバス：一番よく使うやつ。ボタンとか、入力フィールドとか、個々の部品（コンポーネント）を触った時に動くロジックを書く場所。さっきのダークモードのトグルスイッチのロジックは、まさにここ。
で、ロジックの起点になるのが「イベント」。これがマジでたくさん種類があって、最初は混乱する。
例えば、「Page mounted」と「Page focused」。これ、似てるけど全然違う。個人的な解釈だけど、
- Page mounted：ページが「生成」されたときに一回だけ呼ばれる。HTMLでいうDOMが全部読み込まれた瞬間みたいな。だから、初回表示時に動的にコンテンツを作るみたいな重めの初期化処理はこっち。
- Page focused：そのページが「画面の前面に表示」されるたびに呼ばれる。他のページから戻ってきたときとかも。だから、毎回最新の情報を表示したい、みたいな更新処理はこっちが向いてる。
この違い、知らないで使うと「あれ、一回しか動かないぞ？」とか「戻ってくるたびに処理が走って重い…」みたいなことになる。よくあるハマりどころだね。
他にも「Component tap」（コンポーネントがタップされた時）とか、「Component onChange」（入力値が変わった時）とか、まあ色々ある。基本は「ユーザーが何かしたら」っていうのがイベントだって思っておけばOK。
もっと面白くする：外部データとの連携
アプリがただ画面の色を変えるだけじゃつまらない。やっぱり外部のデータを持ってきて表示したりしたいよね。天気予報とか、ニュースとか。ここで出てくるのが「データリソース」と「データ変数」。
ざっくり言うと、
- データリソース：「どこからデータを取ってくるか」の接続設定。APIのURLとかを登録するところ。
- データ変数：取ってきたデータを入れておくための「箱」。ページごとに作ったり、アプリ全体で使えるようにしたりできる。
で、このデータリソース、主に2つのやり方がある。ODataとREST API。どっちもWebサービスからデータを取ってくる技術だけど、性格がかなり違う。
SAP界隈だとODataがよく使われるけど、世の中のWeb APIはだいたいREST。どっちを選ぶべきか、結構迷うポイントだと思う。自分なりにまとめてみた。
| 項目 | OData Integration | REST API Direct Integration |
|---|---|---|
| 設定の楽さ | すごく楽。URLを入れるだけで、Build Appsがデータの構造（スキーマ）を自動で解釈してくれる。賢い。 | ちょっと面倒。どんなデータが返ってくるか、手動で定義しないといけないことが多い。まあ、それが普通なんだけどね。 |
| できることの柔軟性 | プロトコルで決まってるから、ある意味不自由。でも、フィルタリングとかソートとか、決まったやり方で強力な機能が使える。 | めちゃくちゃ自由。API側が提供してれば何でもできる。逆に言えば、APIの仕様次第。本当にただの「通信手段」。 |
| どんな時に使う？ | 相手がSAPのシステム（S/4HANAとか）の時。もう、ほぼこれ一択。お作法通りにやれば、安全・確実に繋がる。 | 世の中の多種多様な公開API（天気、地図、株価、なんでも）と繋ぎたい時。こっちのほうが汎用性は高いよね。 |
| 個人的な感想 | 良くも悪くも「お堅い優等生」。ルール通りで安心だけど、ちょっと融通が利かない感じ。 | ワイルドなやつ。何が返ってくるか分からないスリルがある。でも、使いこなせるとめちゃくちゃ楽しい。 |
元のチュートリアル（SAP Learning Hubで見つけたんだけど）では、面白い例として公開されてるジョークAPIを叩くっていうのをやってた。ボタンを押すたびにランダムでアメリカンジョークが表示されるアプリ。こういう遊び心、いいよね。
これ、まさにREST APIの典型的な使い方。APIのURLは `https://official-joke-api.appspot.com/random_joke`。これをデータリソースに登録して、「更新」ボタンの「Component tap」イベントに「Get record (GET)」っていうフロー関数を繋げるだけ。で、返ってきた値をテキストコンポーネントに表示させる。簡単。
あ、ちなみに、こういう海外のチュートリアルだとジョークAPIとか映画APIがよく使われるけど、日本の業務アプリで使うなら、例えば日本郵便の郵便番号検索APIとか、国税庁の法人番号APIとか、そういう実用的なものになるんだろうな。そこは文脈に合わせて読み替える必要があるね。海外の情報をそのまま鵜呑みにするんじゃなくて、自分たちの環境ならどう使うかな？って考えるのが大事。
強力だけど危険？：Formula Editorの存在
ここまで、ブロックを繋ぐだけの話をしてきたけど、Build Appsにはもっと複雑な計算や文字列操作ができる「Formula Editor」っていう武器もある。
これはもう、ほとんどExcelの関数。`IF(A, B, C)` みたいな条件分岐とか、`SUM(A, B)` みたいな計算とか、文字列を結合する `+` 演算子とか、なんでもあり。
これのおかげで、例えば「ユーザーが入力した数値Aと数値Bを足して、もし100を超えていたら『警告』って表示する」みたいな動的なロジックが、フロー関数をたくさん繋がなくても一行で書けたりする。
ただ…正直、これは諸刃の剣。すごくパワフルなんだけど、ここで複雑な式を書き始めると、あっという間に誰も読めない「秘伝のタレ」みたいなコードが出来上がる。後から修正するのが地獄になるやつ。
個人的には、シンプルな計算や、ちょっとした条件分岐くらいに留めておくのが平和だと思う。複雑なロジックは、やっぱりフロー関数を組み合わせて、視覚的に何やってるか分かるようにしておいた方が、後々の自分やチームのためになるんじゃないかな。マジで。
反例と誤解釐清
Build Appsのロジックについて、初心者がよく間違えるというか、勘違いしがちなポイントをいくつか。
- 「全部フロー関数でやろうとする」：さっきのFormulaの話と逆だね。簡単な足し算とか、テキストの結合まで、いちいちフロー関数を探して繋げようとしちゃう。Formulaを使えば一行で済むことも多いから、使い分けが大事。
- 「エラー処理を忘れる」：APIを叩くロジックは作るけど、もし通信が失敗したら？もしデータが空だったら？っていう「失敗した時の道」を用意し忘れる。フロー関数のノードには大抵、成功(success)の出口と失敗(error)の出口がある。失敗した時に「エラーメッセージを表示する」みたいな処理に繋いでおかないと、アプリが黙ってフリーズしたりして、ユーザーは何が起きたか分からなくなる。
- 「変数のスコープを意識しない」：ページ変数（そのページだけで使える）とアプリ変数（アプリ全体で使える）があるのに、何でもかんでもアプリ変数に入れちゃう。そうすると、意図しないところでデータが書き換わったりして、バグの原因になる。データはなるべく狭い範囲（スコープ）で持つのが基本だよね。
まあ、結局は習うより慣れろ、なんだけどね。いくつか簡単なアプリを作ってみると、このへんの感覚はすぐ掴めると思う。
結局のところ、SAP Build Appsのロジック構築って、一つ一つの部品はすごく単純。イベント、関数、変数。これらをどう組み合わせて、自分たちのやりたいことを実現するかっていうパズルみたいなもの。最初は戸惑うけど、この「視覚的に組み立てていく」感覚は、コードをガリガリ書くのとはまた違った面白さがあるね。
さて、もしあなたが最初に何か作ってみるとしたら、どんなAPIに繋いでみたい？天気予報？それとも電車の運行情報？面白いアイデアがあったら、ぜひコメントで教えてよ。
