はじめに
SAP Integration Suiteでは、標準コンポーネントを組み合わせることで、比較的短時間でiFlowを開発できます。
一方で、開発者ごとに実装方法が異なると、iFlowが増えるにつれて保守性や可読性に差が生まれます。
例えば、次のような課題が発生します。
- 同じような処理なのに、人によって実装方法が異なる
- 修正箇所を探すのに時間がかかる
- 他のメンバーが作成したiFlowを理解するまで時間がかかる
- 保守担当者によって品質にばらつきが生まれる
SAP Help PortalのIntegration Flow Design Guidelinesでも、
と示されています。
そこで私たちのチームでは、開発開始前に実装ルールを定め、レビューでも共通の観点で確認しています。
今回は、その中でも特に効果が大きかったルールを紹介します。
保守しやすいiFlowを作るための実装ルール
①Groovyは必要最小限にする
※悪い例①
Groovyは非常に強力で柔軟性が高く、多くの要件を実現できます。一方で、便利だからといって何でもGroovyで実装することには注意が必要です。
例えば、Groovyを多用すると次のような課題が生じます。
- 読める人が限られる
- 保守担当者の負担になる
- バグの原因になりやすい
- iFlowを見ただけでは処理内容が把握しづらくなる
💡 チームの基本ルール
「標準コンポーネントで実現できる処理はGroovyを書かない」
※上記に基づいて直した例①
例えば、次のような処理を利用し、標準機能を優先します。
- Content Modifier
- Router
- Message Mapping
- XSLT Mapping
- General Splitter
Groovyを使用するのは、次のような場合に限定しています。
- 標準機能では実現できない場合
- Groovyを使った方が保守性・可読性が向上すると判断できる場合
例えば、以下のようなケースです。
- 条件が何十個もある複雑なデータ変換
- 重複データの除去
- タイムゾーン変換や日付計算などの日付操作
- 独自の計算ロジック
このように、「標準機能を優先し、必要な場合のみGroovyを利用する」という考え方を採用することで、保守しやすく、誰が見ても理解しやすいiFlowを実現できます。
②フローの向きを統一する
※悪い例②
iFlowは自由に配置できるため、レイアウトに明確なルールがないと、人によって大きく見た目が変わってしまいます。
気付かないうちに横一直線の長いフローになったり、線が交差したり、処理の流れを追いにくいiFlowになることも少なくありません。
💡 チームの基本ルール
「右方向へ流し、必要に応じて下へ展開する」
※上記に基づいて直した例②
分岐後の処理は下方向へ展開することで、視線の流れに沿って処理を追えるようにしています。
また、
- 線が交差しない
- 戻る線を書かない
- 関連する処理は近くに配置する
ことも意識しています。
実際、このルールだけでも初見のメンバーが処理を理解するまでの時間が大きく短縮されました。
③ステップ名を省略しない
例えば次のような名前では、処理内容が分かりません。
悪い例
Script1
Script2
Routerこれでは、実際にステップを開かなければ何をしているのか判断できません。
一方で、
良い例
Convert XML to JSON
Set Property
Check Company Codeのように処理内容が分かる名前を付けておけば、iFlow全体を見ただけで処理の流れを理解できます。
【レビュー】iFlow開発のチェックリスト
実装ルールを作るだけではなく、レビューでも同じ観点で確認することが重要です。
私たちのチームでは、主に次のような項目を確認しています。
| チェック項目 | 確認内容 |
|---|---|
| Groovy | 標準機能で実現できる処理をGroovyで実装していないか |
| レイアウト | フローの向きや配置が統一され、読みやすいか |
| ステップ名 | 処理内容が分かる名前になっているか |
| Property | 不要なPropertyが残っていないか |
| References | 不要な資料が残っていないか |
| Externalized Parameters | 不要なParameterが残っていないか |
こうしたレビュー項目を設けることで、開発者ごとのばらつきを抑え、品質を一定に保つことができます。
分かりやすいiFlowの例
上記のルールを反映したiFlowの例を以下に示します。
画像のように、iFlow全体を俯瞰しただけで「どのような処理を行っているのか」が把握できることを目指しています。
おわりに
iFlowは「動けばよい」というものではなく、数年後に別の担当者が改修する可能性もある長期運用を前提とした資産です。
だからこそ、
- 読みやすいこと
- 修正しやすいこと
- 誰が担当しても理解・保守できること
を意識した実装が重要だと考えています。
チーム内で実装ルールを共有することで、レビュー基準が統一され、品質のばらつきを抑えることができます。
また、実装が特定の担当者に依存しにくくなるため、担当者の交代や長期運用にも対応しやすくなります。
これからSAP Integration Suiteで実装ルールを整備しようと考えている方の参考になれば幸いです。
投稿者プロフィール
- 2023年度入社。Java系や内部管理会計開発などを経て、現在ではSAP BTP/Fioriの開発案件に携わっています。
