SAP CPI の命名規則：チームで徹底できるルールパック

SAP Cloud Integration（SAP CPI）のチームの多くには命名規則があります。しかし、すべての iFlow がそれに従っているチームはずっと少数です。ルールは wiki のページにあるだけで、トランスポートの前に Content Modifier の名前をチェックする人はいないからです。

この記事では、ステップ、チャネル、プロパティ、アドレスの出発点となる命名規則を提案し、それをツールでチェックできるルールとして書く方法と、チームで共有して徹底する方法を説明します。

SAP CPI で名前が重要な理由

何かが壊れたとき、目にするのはステップの名前です。モニターは失敗したステップを名前で報告しますし、「注文 ID を設定するステップ」を検索して見つかるのは、名前がそう示している場合だけです。設計ドキュメントや引き継ぎ資料も、ダイアグラムのラベルどおりに読まれます。「Content Modifier 3」では何もわかりませんが、CM_SetOrderHeaders なら何をするのかがわかります。

名前が統一されていれば、2 つの iFlow を比べることもできます。規則を知っているレビュー担当者なら、チームのどの iFlow もひと目で読めます。

出発点となる命名規則

ほとんどのチームでは、ステップの種類を表す接頭辞に、何をするのかを PascalCase で続ければ十分です。これは Kitegra に同梱されているパックで、SAP の標準ではなく、調整するための出発点です。

命名規則をルールとして書く

ツールでチェックできる命名規則とは、要素の種類ごとに 1 つずつのルールの一覧です。リテラルのテキストは完全に一致する必要があり、<Placeholder> は任意のテキストを表します。<PascalCase>、<camelCase>、<UPPER>、<lower>、<Number> は、それぞれその形のテキストを表します。種類ごとに最初のルールが適用され、各ルールには重要度（「エラー」、「警告」、「情報」）があります。

Kitegra では、ルールは JSON のルールパックです。抜粋を示します。

{
  "rules": [
    {
      "id": "content-modifier",
      "target": "content-modifier",
      "pattern": "CM_<Action>",
      "example": "CM_SetOrderHeaders",
      "notes": "Content Modifier: CM_ and what it sets.",
      "severity": "warning",
      "enabled": true
    },
    {
      "id": "mapping",
      "target": "mapping",
      "pattern": "MM_<Source>_to_<Target>",
      "example": "MM_Order_to_SalesOrder",
      "notes": "Message Mapping: source and target message.",
      "severity": "info",
      "enabled": true
    },
    {
      "id": "property",
      "target": "property",
      "pattern": "<camelCase>",
      "example": "orderId",
      "notes": "Exchange property names in camelCase.",
      "severity": "info",
      "enabled": true
    }
  ]
}

チームで合意する

1. 拡張機能のオプションページを開き、「命名ルール」を探します。最初はデフォルトのパックが入っています。
2. ルールの「パターン」、「重要度」、「メモ」を変更するか、「ルール有効」でルールをオフにするか、「ルールを追加」を選んでチェックする「対象」を選びます。
3. 「JSON をエクスポート」を選び、チームが標準をまとめている場所に、トランスポートのガイドラインと並べてファイルを置きます。
4. 同僚はそれぞれ、そのファイルで「JSON をインポート」を選びます。Kitegra でサインインしていれば、パックはどのコンピューターにも引き継がれます。

同期は 1 人のパックをその人のすべてのコンピューターでそろえるものです。チーム全員を同じルールにそろえるのは、共有した JSON ファイルです。

iFlow をルールでチェックする

iFlow を開き、「Kitegra ツール」ボタンをクリックして「インスペクター」を選びます（または Alt+Shift+K を押します）。「命名」タブには、ルールに合わないすべての名前が一覧表示され、ボタンにその件数が表示されます。実際の名前、「期待値」、「例」、そしてステップの内容から判断できる場合は、ステップの処理内容から作った「提案」の名前です。結果をクリックすると、ダイアグラム上でそのステップが選択されます。

編集モードでは、「名前を変更」が提案された名前をステップの Name 欄に入力します。保存はしません。パネルには「名前を変更しました。保持するには iFlow を保存してください。」と表示され、判断はあなたに任されます。

同じ結果は、iFlow レビューのチェックリストで紹介しているように、iFlow レポートで設計チェックと並んで表示されます。また、よい名前は生成した設計ドキュメントを読みやすくします。

Kitegra でできること

命名は、Kitegra の iFlow Inspector の一部です。チェックはブラウザー内で iFlow のモデルを読み取って行います。サインインするとルールパックは Kitegra アカウントと同期されますが、iFlow の内容が送られることはありません。

Helper、Message Monitor、iFlow Inspector、iFlow Docs は、それぞれ使用した iFlow の数をカウントします。Kitegra アカウントなしではモジュールごとに 5 つ、Free プランでは 50、Starter では 100、Pro では 300 で、Business は上限なしです。Toolbox とワークスペースの追加機能は無料です。プランを比較する。

次の iFlow で試してみましょう

Kitegra が SAP Integration Suite のデザイナーに何を加えるのかを読むか、Kitegra のほかの Chrome 拡張機能と並べて確認できます。

よくある質問