generate-rap-service-researched

RAP OData サービスの生成 — 調査を優先

コードを1行も書く前に、システムを詳しく調査し、ベストプラクティスを分析して反復的に計画を練り、製品品質の RAP OData サービスを生成します。

このスキルでは、対象 SAP システムの実際の機能、既存のコードパターン、SAP のドキュメント、ユーザー要件に基づいた実装計画を作成し、ユーザーの明示的な承認を得てから実行します。

スマートな既定値（調査前に質問せず、暗黙に適用）

設定	既定値	理由
パッケージ	トランスポートを含むユーザーの Z* パッケージ	本番運用に適しています。ユーザーが明示的に希望した場合に限り $TMP を使用します
キー戦略	UUID（sysuuid_x16）、管理番号採番	最もシンプルで、衝突のリスクがありません
ビヘイビアシナリオ	マネージド	フレームワークが CRUD を処理する、最も一般的な方式です
OData バージョン	V4	現行の SAP 標準です
ドラフト	トランザクション型の Fiori Elements UI サービスでは優先し、システムリリースと BO の制約を確認します	編集可能な FE アプリに最適な既定値ですが、すべての RAP サービスにドラフトが必要なわけではありません
Strict モード	システムのパターンまたは SAP の制約上の理由がない限り、strict ( 2 )	現行の RAP ベストプラクティスですが、常に適用されるわけではありません
命名	SAP 標準（参照セクションを参照）	既存のシステムパターンが見つかった場合は、それを優先します
管理項目	システムに適した項目（syuname/timestampl または abp_*）	システムの種類から判定します
サービス公開	既定では OData V4 UI プロバイダーコントラクト	API ファーストのサービスが用途でない限り、Fiori Elements に最適です

これらの既定値は出発点です。フェーズ1の調査で、既存のシステムパターンに基づいて変更する場合があります。

入力

ユーザーはビジネス要件を自然言語で説明します。曖昧な内容（「保全指図を追跡するものが必要です」）から詳細な内容（「設備階層、作業指図、作業時間記録を備えたプラント保全向け REST API」）まで対応できます。

必須なのはビジネス要件のみです。最初に必要なコンテキストを収集しますが、この段階では質問を重ねすぎないでください。調査を通じて、後から適切な質問が明らかになります。

任意で、ユーザーは次の情報を指定できます。

• パッケージ（必須 — 提供されていない場合は質問してください。ユーザーが明示的に指定した場合に限り、既定値として $TMP を使用します）
• トランスポート依頼（$TMP 以外のパッケージでのみ必要 — フェーズ1-preで解決します）
• 既知の制約（例：「既存のテーブル ZMAINT_ORDER を使用する必要がある」、「PM モジュールとの統合が必要」）

ユーザーが説明だけを提供した場合は、そのまま調査に進みます。適切な質問をするための情報がそろうのは調査後です。

---

フェーズ1-pre：パッケージとトランスポートの解決

パッケージが指定されていない場合、ユーザーに対象パッケージを尋ねます。次に、トランスポート依頼を解決します（パッケージが $TMP の場合のみ省略します）。

SAPTransport(action="check", objectType="DDLS", objectName="<placeholder_name>", package="<package>")

この処理では、トランスポートが必要かを確認し、そのパッケージで利用可能な既存のトランスポートを返します。トランスポートが必要な場合：

1. ユーザーがトランスポートを指定した場合：すべての作成操作にそれを使用します
2. 既存のトランスポートが見つかった場合：一覧を提示し、ユーザーに選択してもらいます
3. 利用可能なトランスポートがない場合：作成します：

   SAPTransport(action="create", description="RAP Service: <Entity>", package="<package>")
   

トランスポートが必要なのに利用できない場合は、停止してください。有効なトランスポートがなければ、$TMP 以外のパッケージではすべての書き込み操作が失敗します。

---

フェーズ1：システムの詳細調査

設計に着手する前に、対象システムを徹底的に調査します。調査で得た情報はすべて計画に反映します。

1a. システムの機能とバージョン

システムがサポートする機能を検出します。これにより、利用可能な RAP 機能、構文、命名規則、安全なデフォルトが決まります。

bootstrap-system-context によって ./system-info.md がすでに作成されている場合は、それを入力として使用します。作成されていない場合は、重要な読み取りをインラインで実行します。

SAPRead(type="SYSTEM")
SAPRead(type="COMPONENTS")
SAPManage(action="probe")
SAPLint(action="list_rules")

注： プローブ応答の rap.available は参考情報です。DDL ソースエンドポイントが検出されたかどうかを示しますが、RAP は利用可能な場合があります。作成を進め、エラーが発生した場合は対処してください。

以下を抽出して記録します。

• システムタイプ：BTP ABAP Environment とオンプレミスのどちらか（およびリリースレベル：7.52、7.54、7.57、S/4HANA 2020 以降など）
• ABAP 言語バージョン：Cloud（厳格で、リリース済み API のみ）と Standard（完全な ABAP）のどちらか
• RAP サポートレベル：マネージド、アンマネージド、抽象 BO に対応しているか。ドラフトに対応しているか。後付け採番に対応しているか。保存時ではなく変更時に判定を実行するか
• CDS 機能：ビュエンティティと従来型ビューのどちらか。テーブルエンティティに対応しているか。メタデータ拡張に対応しているか。アクセス制御に対応しているか
• 利用可能な機能：ATC、構文チェック、ユニットテストランナー、トランスポート管理、FLP カスタマイズ、abapGit/gCTS、バージョン履歴
• FLP サポート：flp 機能が利用可能な場合、作成後にサービスを Fiori Launchpad に登録できます
• リンタープロファイル：cloud と on-prem のプリセット、アクティブな ABAP バージョン、フォーマッタースタイル

1b. 既存の RAP プロジェクト — パターンの把握

既存の RAP アーティファクトを検索し、システムで確立されているパターンを把握します。一貫性を保つために、これは非常に重要です。

SAPSearch(query="BDEF Z*", maxResults=20)

SAPSearch(query="SRVD Z*", maxResults=20)

SAPSearch(query="SRVB Z*", maxResults=20)

SAPSearch(query="DCLS Z*", maxResults=20)

SAPSearch(query="DDLX Z*", maxResults=20)

Z BDEF が見つからない場合でも*、コードを書く前に、実際のシステム例を少なくとも 1 つ確認する必要があります。次の決定的なフォールバックを使用してください。

SAPRead(type="TABL", name="SCARR")

これにより、システムで実際に使用されている TABL アノテーションパターン（拡張カテゴリ、提供クラス、データ保守、クライアント処理）が分かります。次に、アクティブ化済みの CDS ビューを 1 つ読み込みます。

SAPSearch(query="DDLS I_*", maxResults=5)
SAPRead(type="DDLS", name="<first_result>")

これにより、CDS の規約（クライアント項目の処理、エイリアスのスタイル、アノテーションパターン）が分かります。実際のシステムテーブルと CDS ビューを少なくとも 1 つずつ確認するまでは、フェーズ 4 に進まないでください。 ドキュメントの記憶だけを頼りに作成することが、再試行を無駄にする最大の原因です。

結果が見つかった場合は、代表的な RAP スタックを 2〜3 件読み込み、チームのパターンを抽出します。

SAPRead(type="BDEF", name="<found_bdef>")

SAPRead(type="DDLS", name="<found_interface_view>")

SAPRead(type="DDLS", name="<found_projection_view>")

SAPRead(type="DDLX", name="<found_metadata_ext>")

SAPRead(type="SRVB", name="<found_service_binding>")

SAPContext(type="DDLS", name="<found_interface_view>", action="impact")

SAPRead(type="VERSIONS", name="<found_interface_view>", objectType="DDLS")

SAPRead(type="SKTD", name="<found_interface_view>")

これらから、以下を抽出します。

• 命名規則：どのようなプレフィックスパターンか。ZI_／ZC_／ZR_ か。エンティティのサフィックスパターンは何か。テーブルの命名規則は何か
• アーキテクチャスタイル：マネージドか、アンマネージドか。ドラフトが有効か。strict ( 2 ) か、strict か
• アノテーションパターン：どの @UI アノテーションスタイルか。ヘッダー情報のパターンは何か。ファセット構造はどうなっているか
• 項目の命名：キャメルケースのエイリアスか。アンダースコア形式か。略語のパターンは何か
• 管理項目のパターン：どのタイムスタンプ／ユーザー項目型を使用しているか（syuname と abp_creation_user、timestampl と abp_creation_tstmpl のどちらか）
• キー戦略：UUID（sysuuid_x16）か。セマンティックキーか。番号範囲か
• ビヘイビアパターン：どの判定／検証が標準か。認可パターンは何か
• ドラフト処理：with draft があるか。ドラフトテーブルの命名規則は何か。ドラフトアクションが含まれているか
• OData 公開：UI 用か Web API 用のバインディングか。V2 か V4 か。サービス定義／プロバイダーコントラクトのスタイルは何か
• 最近の変化：リビジョン履歴から、パターンが安定しているか、移行中かが分かるか
• ドキュメントの有無：重要な RAP アーティファクトに SKTD の注記が添付されているか

1b2. Git／デリバリーコンテキスト（任意）

SAPManage(action="probe") が abapGit または gCTS のサポートを示し、対象パッケージがすでにリポジトリ連携ワークフローに含まれている可能性がある場合は、新しいアーティファクトを作成する前に、そのコンテキストを調べます。

SAPGit(action="list_repos")
SAPGit(action="objects", repoId="<repo_id>")
SAPGit(action="history", repoId="<repo_id>", limit=20)

これを使って、以下を確認します。

• 対象パッケージがすでにリポジトリで管理されているか
• どの命名規則／ブランチ規則が適用されているか
• パッケージがアクティブなデリバリーの対象で、既存のリポジトリレイアウトに合わせる必要があるか

1c. 既存のデータベーステーブルとドメインオブジェクト

ユーザーが既存のテーブルやビジネスオブジェクトに言及している場合は、それらを読み取ります。

SAPSearch(query="<mentioned_table_or_object>")

SAPRead(type="TABL", name="<found_table>")

SAPContext(type="TABL", name="<found_table>")

また、ドメイン内の関連する SAP 標準オブジェクトも検索します。

SAPSearch(query="<domain_keyword>", maxResults=10)

新しいサービスでデータを重複させずに活用できる既存の CDS ビューまたはテーブルがないか確認します。

BTP システム上の既存オブジェクトを基盤にする場合は、クリーンコア準拠のために、その API のリリース状態を確認します。

SAPRead(type="API_STATE", name="<found_table_or_view>", objectType="TABL")

オブジェクトが非推奨（C2）または未リリースの場合は、それを基盤にすることを避け、リリース済みの後継オブジェクトを検索します。

見つかった CDS オブジェクトにすでに依存しているものを把握するには、汎用の使用箇所検索ではなく、CDS 専用の影響分析を使用します。

SAPContext(type="DDLS", name="<found_view>", action="impact")

汎用の逆依存関係検索は、DDLS 以外のオブジェクトにのみ使用します。

SAPContext(type="CLAS", name="<found_class>", action="usages")

1d. コーディングガイドラインと品質基準

システムに ATC 設定やカスタムチェックバリアントがあり、コード品質基準を示しているか確認します。

SAPDiagnose(action="atc", type="CLAS", name="<any_existing_class>", variant="DEFAULT")

1b で既存の RAP クラスが見つかった場合は、そのうち1つを読み取り、リンターとフォーマッターの検出を実行して、基準となる状態を把握します。

SAPRead(type="CLAS", name="<found_bp_class>")
SAPLint(action="lint", source="<class_source>", name="<found_bp_class>")
SAPLint(action="get_formatter_settings")

これにより、適用されているリンタールール、厳格度レベル、キーワードやインデントの設定を確認できます。

1e. ベストプラクティスの調査 — SAP ドキュメント

SAP ドキュメント MCP サーバーは、汎用的なキーワードの羅列ではなく、意図を持って使用します。

1. まず、公式／リファレンス指向のクエリを実行します。
   • includeSamples=false
   • BTP／ABAP Cloud システムでは abapFlavor="cloud"
   • 該当する場合、従来型のオンプレミスシステムでは abapFlavor="standard"
2. 次に、サンプル指向のクエリを実行します。
   • includeSamples=true
3. 実際に利用する上位の検索結果に対して fetch(...) を使用します。
4. sap_community_search(...) は、公式ドキュメントだけでは不十分な場合に限り、特殊なケース、未文書化のエラー、回避策の調査に使用します。

以下の検索語は出発点となる提案です。ユーザー固有のビジネス要件や、決定が必要なアーキテクチャに応じて調整してください。このサービスについて不足している知識を補う検索クエリを作成します。

アーキテクチャとレイヤリング：

search(query="RAP projection BO vs RAP BO interface", includeSamples=false, abapFlavor="<cloud|standard>")
search(query="RAP service definition provider contracts odata_v4_ui odata_v4_webapi", includeSamples=false, abapFlavor="<cloud|standard>")

ドメイン固有 — ユーザーのビジネスドメインに合わせて調整します。

search(query="<business_domain> RAP example SAP", includeSamples=true, abapFlavor="<cloud|standard>")

たとえば、ユーザーが旅行アプリを求めている場合は、search("RAP travel booking managed scenario example") を実行します。

アーキテクチャ上の決定 — このサービスに関連するトピックのみを検索します。

search(query="RAP managed vs unmanaged scenario when to use", includeSamples=false, abapFlavor="<cloud|standard>")
search(query="RAP draft handling total etag draft-enabled associations", includeSamples=false, abapFlavor="<cloud|standard>")
search(query="RAP compositions parent child entity", includeSamples=true, abapFlavor="<cloud|standard>")

UI／サービスの動作 — UI に公開されるサービスの場合に検索します。

search(query="RAP value help metadata extension additional binding OData V4", includeSamples=false, abapFlavor="<cloud|standard>")
search(query="RAP feature control side effects authorization control", includeSamples=false, abapFlavor="<cloud|standard>")
search(query="metadata-driven UI metadata extension RAP Fiori Elements", includeSamples=false, abapFlavor="<cloud|standard>")

クリーンコア／リリース済み API — BTP またはリリース済みオブジェクトの再利用に関する場合に検索します。

search(query="ABAP API release RAP business object interface C1 C0", includeSamples=false, abapFlavor="cloud")

特殊なケース／トラブルシューティング — 公式ドキュメントで解決できない場合に限ります。

sap_community_search(query="<exact error text or obscure RAP symptom>")

重要： これらの検索をそのまま実行するだけではいけません。ユーザーの仕様を分析し、具体的な知識の不足を補う、的を絞ったクエリを作成してください。ユーザーが特殊な要件（たとえば、特定の SAP モジュールとの統合、特定のフィールド型、カスタム採番、共同ドラフト、リリース済み BO インターフェースの利用など）を求めている場合は、それらの詳細を検索します。

命名規則を実行時に調査する必要はありません。SAP の公式命名スキーマは、以下の「SAP 公式命名規則」リファレンスセクションに記載されています。標準として直接使用してください。

1f. 調査の要約

次に進む前に、調査結果を構造化して要約します。これをユーザーに提示します。

## System Research Summary

### System Profile
- Type: [BTP / On-Prem S/4HANA 20XX / ECC with ABAP Platform]
- ABAP Version: [Cloud / Standard ABAP 7.5X]
- RAP Support: [Full managed+draft / Managed only / Basic]

### Existing Code Patterns Found
- Naming: [e.g., "ZI_ prefix for interface views, ZC_ for projections, Z prefix + _D suffix for tables"]
- Architecture: [e.g., "All existing BOs use managed with draft, strict(2), UUID keys"]
- Field Style: [e.g., "CamelCase aliases, abp_ admin field types on BTP"]
- Annotation Style: [e.g., "Metadata extensions for all UI annotations, facet-based layout"]
- Service exposure: [e.g., "projection view + OData V4 UI binding, provider contract aligned"]
- N existing RAP services found: [list names]

### Domain Research
- Related existing objects: [tables, views, classes found]
- SAP standard objects in domain: [relevant standard CDS views, BAPIs]
- Clean core posture: [released APIs confirmed / successor required / custom tables only]
- Best practices from docs: [key findings]

### Quality Baseline
- ATC variant: [DEFAULT / custom]
- Lint findings: [clean / N issues on existing code]
- Strictness: [strict(2) / strict / none]
- Formatter settings: [keywordUpper / keywordLower / keywordAuto, indentation on/off]

---

フェーズ 2：確認事項

調査結果に基づいて、的を絞った質問をします。調査では回答できなかったことだけを尋ねます。質問はカテゴリ別にまとめ、調査結果に基づく推奨事項を提示します。

アーキテクチャに関する質問

各質問では、まずユーザーの仕様と調査に基づく具体的な推奨事項を示し、その理由を説明したうえで、利点と欠点を含む代替案を列挙します。これらは基盤となる決定事項です。作成後に変更すると、ほとんどの成果物を再構築する必要があります。 トレードオフをユーザーが理解していることを確認してください。 1. 実装シナリオ

仕様書の該当箇所を引用したうえで、[理由 — 例：「既存の永続化ロジックをラップする必要のない、新規のグリーンフィールド BO であるため」]、managed をおすすめします。

選択肢：

選択肢	メリット	デメリット
Managed	フレームワークが CRUD を自動的に処理するため、コードが少なく、開発も速くなります	永続化に対する制御が弱く、RAP の規約に従う必要があります
Unmanaged	永続化を完全に制御でき、既存の BAPI/FM をラップできます	CRUD をすべて自分で実装する必要があり、コード量が大幅に増えます
Managed with unmanaged save	Managed の利便性にカスタム保存を組み合わせられます（例：保存フェーズで BAPI を呼び出す）	より複雑で、保存シーケンスを理解する必要があります

Managed で問題ありませんか。それとも既存のロジックをラップする必要がありますか？

2. エンティティ構造

仕様書の該当箇所を引用したうえで、[理由 — 例：「明細項目についての記述があり、これは典型的な親子パターンであるため」]、[単一エンティティ／コンポジション] をおすすめします。

選択肢：

選択肢	メリット	デメリット
単一ルートエンティティ	最もシンプルで、テーブルと CDS スタックがそれぞれ 1 つです	階層をモデル化できません
コンポジション（親 → 子）	実際の業務階層（受注 → 明細）をモデル化でき、ドラフトが子にも連鎖します	子エンティティごとに、専用テーブル、ドラフトテーブル、CDS スタックが必要です
アソシエーション	関連エンティティへの軽量な参照を提供します（例：得意先の参照）	ライフサイクル上の依存関係がなく、カスケード削除もありません

必要なエンティティの数と、それらの関係を教えてください。

3. キー戦略

仕様書に基づき、[理由 — 例：「ユーザーに表示される業務キーについての記述がなく、UUID が最もシンプルで信頼性の高い方法であるため」]、UUID（内部採番・早期採番） をおすすめします。

選択肢：

選択肢	メリット	デメリット
UUID（内部採番・早期採番）	自動生成され、ユーザー入力が不要で、衝突のリスクがなく、最もシンプルです	キーが人間にとって読みやすくありません
セマンティックキー	ユーザーが意味のあるキー（例：受注番号）を指定できます	一意性の検証が必要で、ユーザーは事前にキーを把握している必要があります
番号範囲	サーバーが連番を割り当てるため、人間にとって読みやすい番号になります	番号範囲オブジェクトの設定が必要で、セットアップの手間が増えます

どのキー戦略がユースケースに適していますか？

4. サービスの公開／プロバイダー契約

Fiori Elements 向けのサービスであれば OData V4 UI を、主にプログラムから利用するサービスであれば OData V4 Web API をおすすめします。サービス定義のプロバイダー契約とサービスバインディングの種類は、一致している必要があります。

サービスの公開に関する重要な情報：

• OData V4 UI：Fiori Elements のリストレポート／オブジェクトページアプリに適した、最も標準的な選択肢です。
• OData V4 Web API：主な利用者が連携コード、テスト、外部アプリの場合に適しています。
• OData V2：レガシーシステム／UI クライアントの要件が厳格な場合に限り使用してください。

主な利用者はどちらですか：Fiori UI、それとも API／連携機能ですか？

4b. ドラフトモデル

ユースケースが明確にドラフト不要である場合、API 専用である場合、またはシステム／バージョンの制約がある場合を除き、トランザクション処理を行う Fiori Elements アプリケーションでは ドラフト をおすすめします。

SAP ドキュメントに記載されている重要な制約：

• ドラフトには、専用のドラフトテーブルとトータル ETag が必要です。
• ドラフト対応のコンポジション階層に含まれるすべての子は、BDEF に定義する必要があります。
• OData V2 と V4 では、一部の OData／Fiori の動作が異なります。

このサービスをドラフト対応にしますか？ 4c. 認可モデル サービスに初日から明示的な行レベルの認可を設定するため、@AccessControl.authorizationCheck: #MANDATORY + DCLS をおすすめします。SAP の RAP ドキュメントでは、RAP BO に #CHECK ではなく #MANDATORY を使うことが推奨されています。

選択肢：

選択肢	メリット	デメリット
#MANDATORY + DCLS	適切な RAP の基本設定で、本番環境に対応した認可モデル	アクセス制御の設計上の判断が必要
#NOT_ALLOWED / #NOT_REQUIRED	プロトタイプを迅速に作成可能	本番環境の認可には不適切

継承条件を含む厳格な基本 DCLS を今生成し、ドメイン固有のルールは後続対応として記載しますか？

データモデルに関する質問

5. フィールドと型

説明に基づいて、次の業務フィールドを特定しました。

フィールド	提案する型	備考
...	...	...

これらで正しいですか？追加、削除、型の変更が必要なフィールドはありますか？

6. 値ヘルプ／固定値

ドロップダウンまたは値ヘルプが必要なフィールドはどれですか？

• ステータスフィールド → 固定値（例：新規／オープン／完了）？
• 参照フィールド → 他の CDS ビューから値ヘルプを取得？

7. 既存のデータソース

［調査でテーブル／ビューが見つかった場合］ このサービスでは既存のテーブル <TABLE> から読み取りますか？それとも新しいテーブルを作成しますか？

7b. 適切な DDIC の型定義（本番サービス）

本番品質のサービスでは、インライン型の代わりに**適切なドメイン（DOMA）とデータエレメント（DTEL）**を作成できます。これにより、次のことが可能になります。

• 複数のテーブル／ビューでフィールド型を再利用
• ドメインに固定値リストを設定（例：A＝有効、I＝無効のステータスドメイン）
• すべての UI でフィールドラベル（短／中／長／見出し）を統一
• データエレメントに検索ヘルプを割り当て

$TMP のプロトタイプではインライン型で問題ありません。移送可能なパッケージでは、適切な DOMA／DTEL の使用をおすすめします。 業務フィールド用に専用のドメインとデータエレメントを作成しますか？

命名に関する質問

8. エンティティの命名

SAP の公式命名規則を使用しています（下記の参考セクションを参照）。たとえば、エンティティ名が Travel の場合：

成果物	SAP の規則	提案する名前
有効データの永続化テーブル	A_ 接頭辞	ZA_TRAVEL
ドラフトテーブル	D_ 接頭辞	ZD_TRAVEL
ベース／インターフェース CDS ビュー	R_ または I_ 接頭辞、TP 接尾辞	ZR_TravelTP
プロジェクション CDS ビュー	C_ 接頭辞	ZC_Travel
インターフェース BDEF	ルートエンティティと同じ	ZR_TravelTP
プロジェクション BDEF	プロジェクションビューと同じ	ZC_Travel
メタデータ拡張	注釈対象の CDS エンティティと同じ	ZC_Travel
サービス定義	UI_ 接頭辞（UI サービスの場合）	ZUI_Travel
サービスバインディング	UI_ 接頭辞、_O4 接尾辞	ZUI_Travel_O4
ビヘイビアプールクラス	BP_ 接頭辞	ZBP_R_TravelTP

［システムで異なるパターンが見つかった場合］注：システム上に異なる命名規則（<pattern found>）を使用している既存の RAP プロジェクトが見つかりました。SAP 標準の命名を既定で使用しますが、システム全体の既存の命名規則に合わせたい場合や、まったく別の命名規則を使いたい場合はお知らせください。

名前を変更しますか？

UI／サービスに関する質問

9. Fiori Elements フロントエンド

このサービスは Fiori Elements アプリ（アノテーションから自動生成される UI）で利用されますか？

利用する場合、計画に含まれるメタデータ拡張（DDLX）と UI アノテーションは、Fiori Elements のリストレポート＋オブジェクトページ（最も一般的なパターン）向けに最適化されます。

注：ARC-1 は現在、Fiori Elements フロントエンドアプリ自体は生成せず、適切なアノテーションを設定したバックエンド OData サービスのみを生成します。Fiori アプリは ADT（サービスバインディングで「Create Fiori Project...」を選択）または VS Code の SAP Fiori tools から生成できます。計画には、後続の手順としてこの方法のガイダンスを含めます。

利用しない場合（フリースタイルの UI5 アプリ、または UI 以外のコンシューマー）、アノテーションを簡素化できます。

9b. バックエンド主導の UI 機能

Fiori Elements アプリの場合、次のいずれかを最初から計画に含めますか？

• フィールド単位の読み取り専用／必須の動作
• バリューヘルプ
• 副作用
• アクションまたは更新に対する機能制御

注：機能制御と副作用は RAP の概念ですが、主に Fiori Elements UI で利用できます。

10. 検索可能なフィールド

どのフィールドを検索可能にしますか（検索バーに表示するフィールド）？

ビジネスロジックに関する質問（該当する場合）

12. 必要な検証

どのビジネスルールを適用しますか？

• 必須フィールドはありますか？
• フィールド間の検証（例：開始日 < 終了日）は必要ですか？
• ステータス遷移ルールは必要ですか？

13. 必要な判定

どの値を自動計算しますか？

• 作成時のデフォルト値は必要ですか？
• 派生フィールド（例：合計 = 価格 × 数量）は必要ですか？

14. カスタムアクション

標準的な CRUD 以外に、「承認」「リリース」「キャンセル」などのアクションが必要ですか？

重要：14 個の質問をすべて尋ねてはいけません。調査によって多くの質問への回答が得られているはずです。本当に必要な質問だけを尋ねてください。残りの質問をまとめ、簡潔に提示してください。それぞれについて推奨事項も示してください。

続行する前に、ユーザーの回答を待ってください。

---

フェーズ 3：実装計画

調査結果とユーザーの回答に基づいて、詳細な実装計画を作成します。

3a. アーティファクトスタック全体を設計する

包括的な設計表を作成します。

## RAP Service Implementation Plan: <Service Name>

### Architecture Decisions
| Decision | Choice | Rationale |
|----------|--------|-----------|
| Scenario | Managed / Unmanaged | [why] |
| Service exposure | OData V4 UI / OData V4 Web API / OData V2 | [why] |
| Draft | Yes / No | [why] |
| Key strategy | UUID / Semantic / NumberRange | [why] |
| Provider contract | `odata_v4_ui` / `odata_v4_webapi` / `odata_v2_*` | [why] |
| Strict mode | strict(2) / strict | [system dependent] |
| Admin fields | syuname+timestampl / abp_* types | [system dependent] |
| Authorization | `#MANDATORY + DCLS` / prototype-only | [why] |
| Build engine | ARC-1 (manual stack) / SAP `abap-mcp` generator (single-root seed) | [generator only if it's connected AND the model is a single root, managed+draft] |

### Entity Model
| Entity | Role | Key Fields | Business Fields |
|--------|------|-----------|-----------------|
| <Root> | Root entity | key_uuid | field1, field2, ... |
| <Child> | Composition of Root | key_uuid, parent_uuid | field_a, field_b, ... |

### Artifact Stack
| # | Type | Name | Description | Dependencies |
|---|------|------|-------------|-------------|
| 1 | DDLS | <table> | Database table entity | — |
| 2 | DDLS | <draft_table> | Draft table (if draft) | — |
| 3 | DDLS | ZI_<Entity> | Interface CDS view | #1 |
| 4 | DCLS | ZI_<Entity>_DCL | Access control for interface CDS view | #3 |
| 5 | CLAS | ZBP_I_<Entity> | Behavior pool class | #3 |
| 6 | BDEF | ZI_<Entity> | Interface behavior definition | #3, #5 |
| 7 | DDLS | ZC_<Entity> | Projection CDS view | #3 |
| 8 | BDEF | ZC_<Entity> | Projection behavior definition | #6, #7 |
| 9 | DDLX | ZC_<Entity> | Metadata extension | #7 |
| 10 | SRVD | ZSD_<Entity> | Service definition | #7 |
| 11 | SRVB | ZSB_<Entity>_V4 | Service binding | #10 |

### Field Definitions
| Field | DB Column | CDS Alias | Type | Annotations | Notes |
|-------|-----------|-----------|------|-------------|-------|
| Key | key_uuid | KeyUuid | sysuuid_x16 | @Semantics | Internal numbering |
| ... | ... | ... | ... | ... | ... |

### Behavior Definition Spec
- Scenario: managed
- Draft: with draft / without draft
- ETag: LocalLastChangedAt
- Lock: master [total etag LastChangedAt]
- Numbering: managed (KeyUuid)
- Read-only fields: KeyUuid, CreatedBy, CreatedAt, LastChangedBy, LastChangedAt, LocalLastChangedAt
- Draft actions: Resume, Edit, Activate (optimized), Discard, Prepare
- Determinations (Phase 1): [list with triggers]
- Validations (Phase 1): [list with triggers]
- Custom actions (Phase 1): [list or "none — add later"]

### UI Annotations Spec
- Header: typeName="<Entity>", title=<MainField>, description=<SecondaryField>
- Facets: [list facet structure]
- List columns: [ordered list with position, importance]
- Selection fields: [filter bar fields]
- Search fields: [searchable fields]

### Naming Convention Used
<Document which convention was followed and why — matches existing code / SAP standard / user preference>

### Quality Checks Planned
- Lint validation before each write (automatic via arc-1)
- PrettyPrint of ABAP sources using SAP formatter settings before CLAS writes
- Syntax check after each activation
- ATC check after full stack activation
- Revision/history readback if iterating on pre-existing artifacts
- [If behavior logic]: Unit test skeleton

3b. 承認用に計画を提示する

計画を明確に提示し、承認を求めます。作成後の変更は大幅に難しくなることを強調してください。

実装計画の準備ができました

[N] 個のエンティティを含み、ドラフトが[あり／なし]で、[命名規則]を使用する[マネージド／アンマネージド] RAP サービスを設計しました。

[アーティファクトスタック表とフィールド定義表を表示]

⚠️ 重要：承認する前に、慎重に確認してください。 SAP システム上にアーティファクトを作成した後で、基本的な決定事項（マネージドかアンマネージドか、キー戦略、エンティティ構造、ドラフトの有無）を変更するには、ほとんどのアーティファクトを削除して再作成する必要があります。作成後に構成を変更するより、今の段階で計画を変更するほうがはるかに簡単です。不明な点がある場合や、決定に迷っている場合は、今のうちに質問してください。

次の点を確認してください：

1. アーティファクト名は正しいですか？
2. フィールドは漏れなく含まれ、型も正しいですか？
3. アーキテクチャ（マネージド／ドラフト／キー）は要件を満たしていますか？
4. 設計上の決定について質問はありますか？
5. 作成を開始する前に変更はありますか？

続行する場合は「approve」と入力してください。質問がある場合や変更したい場合は、その内容を伝えてください。

ユーザーから明示的な承認を得るまで、続行してはいけません。

---

フェーズ 4：実装

承認後、アーティファクトを作成します。可能な場合は一括作成を使用してください。

早期に失敗を検出する：最初の DDLS／BDEF 書き込みが 415 または 500 で失敗した場合、それ以降の CDS 書き込みを直ちにすべて停止してください。異なる型で再試行してはいけません。根本的な問題はオブジェクト固有ではなく、システムレベルのものです。SAPManage(action="probe") を実行して、rap.available のステータスを確認してください。

必須：エラー復旧プロトコル

保存に失敗した場合（400、007、構文エラー）、例外なく次のプロトコルに従ってください。

1. 停止してください。 少しだけ変更して再試行してはいけません。削除して作り直してもいけません。
2. まずエラー全文を読んでください。 ARC-1 は構造化された DDIC 診断情報（SBD... メッセージ ID、V1..V4 変数、行単位の詳細）を返すようになりました。ソースベースの DDIC 作成では、非アクティブな構文チェックの結果が追加される場合もあります。これらの詳細を使って、失敗している正確なフィールド／アノテーションを特定してください。
3. 読み戻して、実際に保存された内容を確認してください：SAPRead(type=X, name=Y)
4. 原因を切り分けてください。 必要最小限のソース（キー項目と必須のアノテーションのみ）を試してください。最小構成で成功する場合は、フィールドを一つずつ追加してください。最小構成でも失敗する場合は、問題はフィールドではなく、アノテーションまたはオブジェクトタイプです。
5. 再試行のたびに変更するのは一つだけにしてください。アノテーションとフィールドを同時に変更してはいけません。
6. 同じオブジェクトで3回失敗したら、停止してください。エラー全文をユーザーに伝え、指示を求めてください。試行錯誤を続けてはいけません。

重要な原則： 問題はほぼ常にソースの内容であり、オブジェクトの状態ではありません。同じソースで削除して作り直しても、同じエラーが発生します。まずソースを修正してください。

必須：まず batch_create を使用する

必ず最初に batch_create を試してください。 順次作成から始めてはいけません。batch_create は1回の呼び出しですべてのオブジェクトを作成します。依存関係の順に、配列の先頭から配置してください（テーブル → ビュー → DCLS → クラス → BDEF → サービス定義）。

SAPWrite(action="batch_create", objects=[...], package="<package>", transport="<transport>")

コンポジションで関連付けられた DDLS や、相互依存するその他の兄弟オブジェクト（親の composition [0..*] of ZR_CHILD で、子も同じバッチに含まれる場合）には、activateAtEnd: true を渡してください。これにより ARC-1 はまずすべてのオブジェクトの非アクティブなドラフトを書き込み、その後、最後に1回だけ activateBatch を実行します。SAP のアクティベーターはグラフ全体を一度に確認し、兄弟オブジェクト間の相互参照を解決します。オブジェクトごとに個別にインラインアクティベーションを行うと、子がまだ非アクティブな状態で親をアクティベートするため、親で "data source ZR_CHILD does not exist or is not active" というエラーが発生します。

SAPWrite(action="batch_create", activateAtEnd: true, objects=[...], package="<package>", transport="<transport>")

生成されたオブジェクトの一部で明示的なアイテム単位のルーティングが必要な場合は、個々のオブジェクトに package と transport を指定してください。アイテム単位の値は最上位のバッチ値より優先され、復旧したプランで複数のパッケージが混在する場合に必要です。

SAPWrite(action="batch_create", objects=[
  {type: "TABL", name: "<table>", package: "<package>", transport: "<transport>", source: "<ddl>"},
  {type: "DDLS", name: "ZI_<entity>", package: "<package>", transport: "<transport>", source: "<ddl>"}
])

batch_create がエラーを返した場合に限り、順次作成（フェーズ 4b）に切り替えてください。バッチに失敗した場合は、エラーを読み、失敗した特定のオブジェクトのソースを修正してから、batch_create を再試行してください。バッチで1回失敗しただけで順次モードに切り替えてはいけません。

4-pre. 実装前チェック

アーティファクトを作成する前に、競合の原因となる可能性のある未処理の非アクティブオブジェクトがないか、必要に応じて確認してください。

SAPRead(type="INACTIVE_OBJECTS")

注： /sap/bc/adt/activation/inactive エンドポイントを利用できないシステムでは、404 が返される場合があります。その場合は、このチェックを省略して作業を続行してください。これは利便性のためのチェックであり、必須ではありません。

競合する名前の非アクティブオブジェクトがある場合は、先に解決してください（アクティベートするか、削除します）。

リセット／作成前のチェックで、対象の名前がリポジトリ内のどこかに存在するか確認する必要がある場合は、TADIR に対する長い SAPQuery ではなく、オブジェクトディレクトリの完全一致検索を使用してください。

SAPSearch(searchType="tadir_lookup",
  names=["<table>","ZI_<entity>","ZC_<entity>","ZSB_<entity>_V4"],
  objectTypes=["TABL","DDLS","BDEF","SRVD","SRVB","CLAS"])

検索結果は、指定された名前ごとに完全一致をまとめて missing を返します。このチェックのために、大きな WHERE OBJ_NAME IN (...) SQL リストを作成しないでください。

クリーンアップ後は、名前が本当に消えていることを確認してください。 ADT のデフォルトの情報システムエンドポイントは、ワークベンチリソースに解決できない TADIR 行を除外するため、中断された作成／削除処理で残った孤立した「ゴースト」（残存する TADIR 行）は表示されません。source: "both" を指定して検索を再実行し、ゴーストを検出してください。これには sql スコープが必要です（管理者は SAP_ALLOW_FREE_SQL=true を設定する必要があります）。

SAPSearch(searchType="tadir_lookup",
  names=["<table>","ZI_<entity>","ZC_<entity>","ZSB_<entity>_V4"],
  source: "both")

応答に splitBrain 配列が含まれる場合、一覧にある名前は TADIR に存在するものの、ADT では解決できません。作成を再試行する前に、SE03／RS_DD_TADIR_CLEANUP を使ってクリーンアップしてください。

4-doma. ドメインとデータエレメントを作成する（Phase 2 で承認された場合）

ユーザーが適切な DDIC の型指定を選択した場合は、テーブルエンティティより先にドメインとデータエレメントを作成します。

SAPWrite(action="create", type="DOMA", name="Z<DOMAIN>", package="<package>", transport="<transport>",
  dataType="CHAR", length=1, fixedValues=[{low:"A", description:"Active"}, {low:"I", description:"Inactive"}])

SAPWrite(action="create", type="DTEL", name="Z<DATAELEMENT>", package="<package>", transport="<transport>",
  typeKind="domain", dataType="Z<DOMAIN>", labels={short:"Status", medium:"Object Status", long:"Object Status", heading:"Status"})

SAPActivate(objects=[{type:"DOMA", name:"Z<DOMAIN>"}, {type:"DTEL", name:"Z<DATAELEMENT>"}])

次に、テーブルエンティティの DDL でインライン型の代わりにデータエレメントを参照します（例：status : abap.char(1) の代わりに status : z<dataelement>）。

4-gen. （任意）単一ルートのビルドを SAP の公式ジェネレーターに委任する

公式 SAP ABAP MCP サーバーが ARC-1 とともに接続されていて（ABAP Development Tools for VS Code / Eclipse ADT 3.60+ に同梱されている abap-mcp サーバー）、承認済みプランの ビルドエンジン がジェネレーターの場合は、単一ルートのビルドを SAP の Generate ABAP Repository Objects フレームワークに委任し、そのフレームワークで対応できないすべての作業を行うため、ここに戻ります。単一のルートエンティティに限り有効です（ジェネレーターは「エンティティは最大 1 つ、コンポジションなし」で実行されます）。テーブル上で managed+draft であり、last_changed : abp_lastchange_tstmpl + local_last_changed : abp_locinst_lastchange_tstmpl を使用するエンティティが対象です（または、テーブルを生成するゼロから作成する方法を使用します）。一度限りの処理であり、生成後には使用しません。それ以外の場合は 4a/4b を使用してください。

1. プローブして ID を解決します（リリース固有のため、ハードコードしないでください）。 abap_generators-list_generators ツールがない場合は、4a/4b を使用します。ツールがある場合は呼び出して、表示名が 「OData UI Service」（または「OData Web API Service」）のものを照合し、返された id を使用します（SAP_BASIS 758 では uiservice/webapiservice、816 では ui-service/webapi-service/x-ui-service）。
2. スキーマから生成します。 abap_generators-get_schema(generatorId, packageName, referencedObjectType="TABL", referencedObjectName="<table>") を呼び出し、返されたスキーマから必須フィールドをすべて設定してから、計画したパッケージとトランスポートに abap_generators-generate_objects(generatorId, …) で生成します（変更を伴う操作のため、4a と同じガードレールに従ってください）。
3. ARC-1 で続行します。 検証（4d）を行った後、ARC-1 を使用してフィールド／子／アクション／ロジックを追加し、品質チェックを実行します。ジェネレーターは自身の出力を拡張しません。サマリー（Phase 5）に、どのアーティファクトがジェネレーター由来で、どれが ARC-1 由来かを記録します。

4a. 一括作成（推奨）

システムが対応していて、アーティファクトの構成が単純な場合は、次のようにします。

SAPWrite(action="batch_create", objects=[
  {type: "TABL", name: "<table>", description: "<desc>", source: "<ddl>"},
  {type: "DDLS", name: "ZI_<entity>", description: "<desc>", source: "<ddl>"},
  {type: "DCLS", name: "ZI_<entity>_DCL", description: "<desc>", source: "<dcl>"},
  {type: "DDLS", name: "ZC_<entity>", description: "<desc>", source: "<ddl>"},
  {type: "BDEF", name: "ZI_<entity>", description: "<desc>", source: "<bdef>"},
  {type: "BDEF", name: "ZC_<entity>", description: "<desc>", source: "<bdef>"},
  {type: "DDLX", name: "ZC_<entity>", description: "<desc>", source: "<ddlx>"},
  {type: "SRVD", name: "ZSD_<entity>", description: "<desc>", source: "<srvd>"},
  {type: "CLAS", name: "ZBP_I_<entity>", description: "<desc>", source: "<class>"},
  {type: "SRVB", name: "ZSB_<entity>_V4", description: "<desc>", serviceDefinition: "ZSD_<entity>", bindingType: "ODataV4-UI"}
], package="<package>", transport="<transport>")

オブジェクトは配列の順序どおりに作成されます。依存関係のあるものより先に、依存先を配置してください。

4b. 順次フォールバック

バッチ作成に失敗した場合、またはスタックが複雑な場合（コンポジション、複数のエンティティ）は、2回に分けて順次作成します。これにより、BDEF↔ビヘイビアプールのデッドロックを回避し、オンプレミスの 7.5x での再試行を減らせます。

パス 1 — 最小限の動作する BO（CRUD + コンポジション）：

1. アクティブテーブルのみ → それぞれ作成してアクティブ化します。ドラフトテーブルは後回しにします。
2. 子インターフェース CDS ビュー → 作成してアクティブ化します。
3. コンポジション（composition [0..*]）を含むルートインターフェース CDS ビュー → 作成してアクティブ化します。
4. 空のビヘイビアプールクラス（METHODS ... FOR ... 宣言なし） → 作成してアクティブ化します。
5. CRUD とコンポジション作成のみを含む インターフェース BDEF。アクション、デターミネーション／バリデーション、strict／認可の強化はまだ追加しません。
6. リダイレクトを含む プロジェクション CDS ビュー → 作成してアクティブ化します。
7. プロジェクション BDEF（projection; ヘッダーのみ。use 句のみ使用） → 作成してアクティブ化します。
8. サービス定義 + サービスバインディング → 作成してアクティブ化し、公開します。

この時点で、サービスをプレビューでき、安定した状態になります。

パス 2 — ビジネスロジック + 強化：

9. インターフェース BDEF にアクション／デターミネーション／バリデーションを追加してアクティブ化します。
10. 不足しているビヘイビアハンドラーのシグネチャを生成します：

• 最初に使用する方法：SAPWrite(action="scaffold_rap_handlers", type="CLAS", name="ZBP_I_<entity>", bdefName="ZI_<entity>") で不足しているシグネチャを一覧表示します。
• 次に autoApply=true を指定して再実行し、可能であればクラスセクション（main、definitions、implementations）に宣言と空の実装スタブを挿入します。
• 次のフォールバック：提案が利用できる場合は SAPDiagnose(action="quickfix", ...) + SAPDiagnose(action="apply_quickfix", ...) を使用します。
• フォールバック：MCP のクイックフィックス提案が公開されていない場合は、エディターの ADT クイックフィックスを使用します。

11. SAPWrite(action="edit_method", ...) でメソッド本体を実装します（ビヘイビアプールが不安定な場合は、クラス全体の書き換えを避けます）。
12. シグネチャとメソッド本体をアクティブ化してから、strict ( 2 ) と認可ハンドラーを追加します。
13. ドラフトは最後に追加します。手書きのドラフトテーブル定義より、生成されたドラフトテーブル（ADT クイックフィックス）を優先します。
14. BO のロジックに問題がないことを確認してから、DCLS と DDLX を作成／アクティブ化します。

パス 2 の変更後、相互依存するオブジェクトをまとめてアクティブ化します：

SAPActivate(objects=[
  {type: "CLAS", name: "ZBP_I_<entity>"},
  {type: "BDEF", name: "ZI_<entity>"},
  {type: "BDEF", name: "ZC_<entity>"}
])

注： アクティブ化では、行番号と URI を含む詳細なエラー／警告メッセージが構造化レスポンスとして返されます。エラーがあるとアクティブ化はブロックされます。警告があってもアクティブ化できますが、確認が必要です。ソース全体を読み直すのではなく、この情報を使って問題の正確な箇所を特定してください。

4c. ソースコードテンプレート

計画のソースコードテンプレートを使用します。調査結果に基づいて調整してください：

• BTP システム：abp_* 管理フィールド型、ABAP Cloud 構文、strict ( 2 ) を使用します
• オンプレミスシステム：syuname／timestampl 型を使用し、既存コードに応じてクラシック構文または Cloud 構文を使用します
• 既存のパターンに従う：既存の RAP プロジェクトで特定のアノテーションスタイルやフィールド命名パターンが使われている場合は、完全に同じ形式にします
• ドラフト：ドラフトテーブル、インターフェース BDEF のドラフトアクション、プロジェクション BDEF の use draft を含めます
• サービス公開：サービス定義のプロバイダーコントラクトが、計画したバインディング型と一致することを確認します
• ABAP のフォーマット：SAP 標準のキーワードの大文字小文字やインデントを使用する場合は、生成した ABAP クラスを書き込む前に SAPLint(action="format", source="<abap_source>", name="<class_name>") を実行します

4d. 作成後の検証

すべてのアーティファクトを作成してアクティブ化した後：

1. ビヘイビアプールの構文チェックを実行します：

   SAPRead(type="SYNTAX", objectType="CLAS", name="ZBP_I_<entity>")
   

2. スタック全体の ATC チェックを実行します（ATC が利用できる場合）：

   SAPDiagnose(action="atc", type="BDEF", name="ZI_<entity>")
   

3. 非アクティブなオブジェクトが残っていないことを確認します（一部のシステムでは 404 が返る場合があります。その場合はスキップします）：

   SAPRead(type="INACTIVE_OBJECTS")
   

4. 主要なアーティファクトを読み戻し、正しいことを確認します：

   SAPRead(type="BDEF", name="ZI_<entity>")
   SAPRead(type="DDLS", name="ZI_<entity>")
   SAPRead(type="SRVD", name="ZSD_<entity>")
   

5. ビヘイビアプールのLint + フォーマッターのチェックを実行します：

   SAPRead(type="CLAS", name="ZBP_I_<entity>")
   SAPLint(action="lint", source="<behavior_pool_source>", name="ZBP_I_<entity>")
   SAPLint(action="get_formatter_settings")
   

見つかった問題を修正します。必要に応じて再アクティブ化してください。

4e. サービスバインディングの作成と公開

サービスバインディングを作成します。

SAPWrite(action="create", type="SRVB", name="ZSB_<entity>_V4", package="<package>", transport="<transport>",
  serviceDefinition="ZSD_<entity>", bindingType="ODataV4-UI", description="<Entity> OData V4 Service")

サービスバインディングを有効化します。

SAPActivate(type="SRVB", name="ZSB_<entity>_V4")

サービスバインディングを公開します（OData サービスが利用可能になります）。

SAPActivate(action="publish_srvb", name="ZSB_<entity>_V4")

公開ステータスとサービス URL を確認します。

SAPRead(type="SRVB", name="ZSB_<entity>_V4")

⚠️ チェックポイント：SRVB の読み取り結果で、published: true、想定されるバインディングタイプ、およびサービス URL が表示されていることを確認してください。OData V4 バインディングでは、公開／非公開の設定はサービスバージョンごとではなく、バインディング全体に適用されます。

4f. サービスのプレビュー

サービスバインディングを公開した後、RAP サービスを直接プレビューできます。ADT では、ユーザーはサービスバインディングを開き、エンティティ（例：「Root」）を選択して「プレビュー...」をクリックすると、ブラウザーで Fiori Elements のプレビューを起動できます。これにより、ADT ビジネスサービスエンドポイント経由でプレビュー URL が生成されます。

ユーザーに次のように伝えてください。

サービスを公開しました！ ADT でサービスバインディング ZSB_<ENTITY>_V4 を開き、ルートエンティティを選択して「プレビュー...」をクリックすると、自動生成された Fiori Elements のリストレポート＋オブジェクトページを確認できます。

---

フェーズ 5：検証と概要

5a. 最終確認チェックリスト

RAP Service Generation Complete!

## Architecture
- Scenario: [managed/unmanaged]
- Draft: [enabled/disabled]
- Key strategy: [UUID/semantic/number range]
- OData version: [V4/V2]
- Followed conventions from: [existing code / SAP standard]

## Created Artifacts
  [x] Database table entity: <table_name>
  [x] Draft table entity: <draft_table> (if applicable)
  [x] Interface CDS view: ZI_<Entity>
  [x] Interface behavior definition: ZI_<Entity>
  [x] Projection CDS view: ZC_<Entity>
  [x] Projection behavior definition: ZC_<Entity>
  [x] Metadata extension: ZC_<Entity>
  [x] Service definition: ZSD_<Entity>
  [x] Behavior pool class: ZBP_I_<Entity>
  [x] Service binding: ZSB_<Entity>_V4
  [x] Service binding published

## Quality Checks
  [x] All artifacts activated successfully
  [x] Syntax check: clean
  [x] Lint check: clean
  [x] ATC check: [clean / N findings noted]

## Consistency with Existing Code
  [x] Naming matches existing convention: [pattern]
  [x] Annotation style matches: [pattern]
  [x] Admin fields match: [pattern]

5b. 次のステップ

計画に基づいて、後続の操作を提案します。

## Recommended Next Steps

1. **Preview the service** in Fiori Elements (ADT → Service Binding → select entity → Preview...)
2. **Add business logic** → use `generate-rap-logic` skill:
   - Determinations: [list from plan]
   - Validations: [list from plan]
3. **Add value helps** for reference fields
4. **Add custom actions** if needed (e.g., Approve, Release)
5. **Generate unit tests** → use `generate-abap-unit-test` skill
6. **Add compositions** for child entities (if multi-entity scenario planned for Phase 2)
7. **Register in FLP** (if FLP feature available) → use SAPManage:
  - `SAPManage(action="flp_create_catalog", catalogId="Z_<ENTITY>_C", title="<Entity> Catalog")`
  - `SAPManage(action="flp_create_tile", catalogId="Z_<ENTITY>_C", tile={id:"Z_<ENTITY>_T", title:"<Entity>", semanticObject:"<Entity>", semanticAction:"manage"})`
  - `SAPManage(action="flp_create_group", groupId="Z_<ENTITY>_G", title="<Entity>")`
  - `SAPManage(action="flp_add_tile_to_group", groupId="Z_<ENTITY>_G", catalogId="Z_<ENTITY>_C", tileId="Z_<ENTITY>_T")`
8. **Create DOMA/DTEL** (if not done in Phase 4) for proper reusable typing
9. **Release transport** (if transportable package) → use `SAPTransport(action="release_recursive", transport="<TR>")` to release tasks and parent in one step
10. **Attach generated documentation** (optional) → use `SAPWrite(action="create", type="SKTD", refObjectType="SRVD", name="<service_doc_name>", source="<architecture_summary_markdown>")`
11. **Review current assignment + revision context on later iterations** → use `SAPTransport(action="history", type="SRVD", name="ZSD_<ENTITY>")` for the current lock/assignment status and `SAPRead(type="VERSIONS", name="ZSD_<ENTITY>", objectType="SRVD")` for actual revision history. Candidate requests from `history` are assignment choices, not historical membership.
12. **If the package is repo-managed** → use `SAPGit` (`list_repos`, `objects`, `history`) before changing naming or branch conventions

---

オンプレミス 7.5x RAP クイックリファレンス（フェーズ 4 の前にお読みください）

このセクションでは、オンプレミスの ABAP 7.5x システムで保存に繰り返し失敗する原因となる、よくある問題について説明します。ここに記載されたルールは、すべて実際の失敗から得られたものです。いずれかに違反すると、多くの場合、保存時に SBD_MESSAGES 007 エラーが返されます。ARC-1 では現在、より詳細な情報が表示されますが、これらの問題が根本原因であることに変わりはありません。

TABL（透過テーブル）— 必須アノテーション

これらのアノテーションをすべて設定しないと、テーブルの保存は必ず 007 エラーで失敗します。

@EndUserText.label : '<description>'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table <name> {
  key client    : abap.clnt not null;
  key <uuid_key> : sysuuid_x16 not null;
  ...
}

TABL のフィールドタイプ — 修飾名を使用する

正しい形式	誤った形式（007／有効化エラーの原因）
abap.int4	int4
abap.char(N)	char(N)
abap.numc(N)	numc(N)
abap.dec(N,M)	dec(N,M)
abap.clnt	clnt
sysuuid_x16	UUID に raw(16) を使用
timestampl	TABL で abap.utclong を使用
syuname	TABL で abap.uname を使用
abap.cuky	cuky
abap.curr(N,M)	参照アノテーションなしの curr(N,M)
abap.char(1)（X／空白の真偽値）	TABL で abap.boolean を使用

クライアントの処理

• TABL：key client : abap.clnt not null; を最初のキー項目として含めます
• CDS ビューエンティティ：クライアントを選択リストから完全に省略します。SAP がクライアントのフィルタリングを暗黙的に処理します。ビューエンティティでは @ClientHandling アノテーションを追加しないでください。追加すると拒否されます。

コンポジションとアソシエーションのルール

• コンポジション：on 句は使用しません。composition [0..*] of ChildView as _Child と記述します。フレームワークがキーに基づいて自動的に解決します。on を追加すると、「コンポジションでは On 条件は許可されていません」というエラーが発生します。
• アソシエーションの on 条件：DB の列名ではなく、選択リストの CamelCase エイリアスを使用します。$projection.ClubUuid = _Club.ClubUuid と記述し、$projection.club_uuid とは記述しません。DB の列名を使用すると、「参照先の選択リスト名がエイリアスによって隠されています」というエラーが発生します。
• 外部キーの関係：ビューエンティティ内で CDS のコンポジション／アソシエーションを通じて表現します。TABL 定義に foreign key 句を追加しないでください。テーブルはシンプルなままにしてください。

親子関係の有効化順序

子ビューエンティティを先に有効化してから、ルートを有効化します。ルートの composition は子を参照するため、子が有効化済みである必要があります。両方を指定した一括有効化を使用します：SAPActivate(objects=[{type:"DDLS",name:"<child>"},{type:"DDLS",name:"<root>"}]) — 有効化エンジンが順序を解決します。

Lint と ABAP 以外の型

ABAP ソースと DDLS では、書き込み前の Lint がデフォルトで実行されます。BDEF/SRVD/SRVB/DDLX/TABL/DOMA/DTEL では、ほとんどの意味チェックにアクティベーションまたは RAP の事前検証が引き続き必要です。RAP の事前検証はデフォルトで有効にしてください。preflightBeforeWrite: false を使用するのは、回避する特定のルールを理解したうえで、対象を限定して復旧する場合だけにしてください。既知の有効なケースで Lint によって処理がブロックされる場合は、その書き込みに限って lintBeforeWrite: false を使用し、オーバーライドを局所的に保ってください。

---

エラーからの復旧

既存の RAP プロジェクトが見つからない場合

問題ありません。システムが RAP に対応したばかりである可能性があります。SAP 標準の命名規則と、ドキュメントに記載されたベストプラクティスを使用してください。計画には次のように記載してください。

"システム上に既存の RAP プロジェクトが見つかりませんでした。SAP 標準の命名規則と、ドキュメントに記載された最新のベストプラクティスを使用します。"

システムが必要な機能に対応していない場合

調査により、システムにユーザーが必要とする機能（例：古いオンプレミス環境でのドラフト、7.55 より前のテーブルエンティティ）がないと判明した場合は、次の手順を実行してください。

1. 制限事項をユーザーに伝えます
2. 代替案を提案します（例：テーブルエンティティの代わりにクラシック DDIC テーブルを使用する、ドラフトなしで実装する）
3. それに応じて計画を調整します

バッチ作成に失敗した場合

順次作成（フェーズ 4b）に切り替えてください。成功したオブジェクトと失敗したオブジェクトを報告します。失敗したオブジェクトを修正して再試行してください。

よくある問題

エラー	原因	対処方法
DDLS/BDEF で 415 Unsupported Media Type が発生する	RAP/CDS エンドポイントが想定どおり応答していない	SAPManage(action="probe") でシステム情報を確認します。ICF サービスが有効化されていることを確認します。システムの機能を確かめるため、ADT でオブジェクトを作成してみてください。
作成時に Resource X does already exist が発生する	以前に作成したスタブ、または名前の競合	直ちに SAPWrite(action="update", ...) に切り替え、ソース全体を再送信します。同じペイロードで create を再試行しないでください。
機能がサポートされていない	システムのバージョンが古すぎる	利用可能な機能に合わせて計画を調整します
有効化エラー	依存関係の順序が誤っている	一括有効化するか、依存関係の順に逐次有効化します
Lint によって書き込みがブロックされる	コードが lint ルールに適合していない	生成されたコードを lint に通るよう修正するか、lint の設定が厳しすぎないか確認します
BDEF の構文エラー	フィールドエイリアスまたはエンティティ参照が誤っている	CDS エイリアスと BDEF のフィールド参照を照合します
移送が必要	移送なしで $TMP 以外のパッケージを使用している	SAPTransport(action="check") を使って移送を検索または作成します — Phase 1-pre を参照してください
作成時にロックが競合する	オブジェクトが別のユーザーまたは移送によってロックされている	待つか、別の名前を使用します。競合する移送がないか SAPTransport(action="list") で確認します
Annotation with reference to currency code for field X is missing	abap.curr フィールドに通貨参照がない	各金額フィールドの直上に @Semantics.amount.currencyCode を追加し、abap.cuky フィールドと組み合わせます。
"global or instance" was expected, not "none"	7.5x で BDEF の認可列挙値が無効	( global ) または ( instance ) を使用するか、ハンドラーが存在するまで認可の設定を延期します。
dependent entity cannot have the identically named field ... as the etag master entity	ルートと子の etag 名が競合している	ルートエンティティと従属エンティティで異なる etag フィールド名を使用します。
投影 BDEF で "draft or side" was expected, not "etag" が発生する	7.5x では use etag ヘッダーが無効	投影ヘッダーは projection; のみにします。
not a suitable draft persistency ... there is no "X" field	手書きのドラフトテーブルの列名が一致しない	クイックフィックスでドラフトテーブルを生成することを推奨します。または、CDS 名の派生ルールに正確に従います。
DDLX で Annotation 'UI.headerInfo.X' used at wrong position が発生する	7.5x の DDLX でサポートされていないアノテーションスコープ	@UI.headerInfo、@Search.searchable、@ObjectModel.* を投影 DDLS ソースに移動します。
DDLX で Multiple entries with same name 'X' not allowed が発生する	同じフィールドにアノテーションブロックが重複している	フィールドのアノテーションを 1 つのブロックにまとめます。
振る舞いプールクラスの更新時に [?/011] が発生する	METHODS ... FOR ... に対するクラス全体の振る舞いプール書き込みパスが不安定	まず SAPWrite(action="scaffold_rap_handlers", ...) を使用し（必要に応じて autoApply=true を指定）、次にクイックフィックスにフォールバックし、その後 SAPWrite(action="edit_method", ...) でメソッド本体にパッチを適用します。

---

補足

方針

このスキルでは速度よりも正確さと一貫性を優先します。追加の調査時間（5～10 分）をかけることで、次のメリットが得られます。

• 既存コードとの命名の競合を回避できます
• 確立されたチームの規約に自動的に従います
• エラーが発生する前にシステムの制限を把握できます
• コードベースに自然になじむコードを作成できます
• 確定する前に、アーキテクチャに対するユーザーの信頼を高められます

このスキルで（まだ）できないこと

• 1 回の実行での非常に大規模な複数 BO のランドスケープ — 1 回の実行につき、1 つのビジネス機能に留めてください
• 非管理型の保存の実装（計画を立て、管理型のラッパーを実装し、保存ハンドラーを後続作業として記載します）
• カスタム CDS 関数／アクション（計画を立て、標準の CRUD を実装し、後続作業として追加します）
• Fiori アプリの生成（OData サービスを生成します。Fiori Elements アプリはアノテーションから自動生成されます）

他のスキルとの関係

スキル	関係
generate-rap-service	Vibe コード版です。より高速で、網羅性は低く、プロトタイプに適しています
generate-rap-logic	自然な次のステップです。計画で特定された判定／検証を実装します
generate-abap-unit-test	次のステップです。ビヘイビアプールのテストを生成します
explain-abap-code	調査中に、システム上で見つかった既存の RAP プロジェクトを理解するために使用できます
implement-feature	arc-1 コードベース自体に RAP 以外の機能を実装するためのものです

---

参考：RAP アーティファクトに関する SAP 公式命名規則

出典：SAP Help — 開発オブジェクトの命名規則

一般規則

[/<namespace>/][<prefix>]_<object_name>_[<suffix>]

• 組織に予約されている独自の名前空間を使用します（顧客オブジェクトには Z* または Y*）
• /DMO/ 名前空間は SAP のデモ用途専用です。本番開発では決して使用しないでください
• プレフィックスは、同じオブジェクト種別内の型の意味上の違いを示します
• サフィックスは、追加の区別（例：OData バージョン、開発ガイドのバリアント）を示します

ABAP ディクショナリーオブジェクト

オブジェクト	規則	例（顧客名前空間）
アクティブ永続化テーブル	A_ プレフィックス	ZA_TRAVEL
ドラフトテーブル	D_ プレフィックス	ZD_TRAVEL

CDS オブジェクト

オブジェクト	規則	注記	例
ベース／ルート CDS ビューエンティティ	R_ プレフィックス	ベース BO エンティティです。トランザクション処理との関連を示すには TP サフィックスを使用します	ZR_TravelTP
インターフェース CDS ビュー	I_ プレフィックス	再利用可能なインターフェースビューレイヤーです（一部のパターンでは R_ の代替）	ZI_Travel
プロジェクション CDS ビュー	C_ プレフィックス	C はコンシュンプションレイヤーを表します。複数のプロジェクションがある場合、名前にはプロジェクションの役割を反映します	ZC_Travel
拡張インクルードビュー	E_ プレフィックス	拡張性のためのものです	ZE_Travel
ビヘイビア定義	ルートエンティティと同じ名前	BDEF は常に、属する CDS ビューと同じ名前を持ちます	ZR_TravelTP（インターフェース）、ZC_Travel（プロジェクション）
メタデータ拡張	CDS エンティティと同じ名前	1 つのエンティティに複数の拡張がある場合は、番号付きサフィックスを追加します	ZC_Travel、ZC_Travel_2

ビジネスサービス

オブジェクト	規則	注記	例
サービス定義	必須のプレフィックスなし	UI／API 間で再利用しない場合は、UI_ または API_ プレフィックスを使用できます	ZUI_Travel または Z_Travel
サービスバインディング（UI）	UI_ プレフィックス	Fiori Elements／UI での利用向け	ZUI_Travel_O4
サービスバインディング（Web API）	API_ プレフィックス	プログラムによる利用／統合向け	ZAPI_Travel_O4
OData V2 サフィックス	_O2		ZUI_Travel_O2
OData V4 サフィックス	_O4		ZUI_Travel_O4

ソースコードオブジェクト

オブジェクト	規則	注記	例
ビヘイビアプールクラス	BP_ プレフィックス	BO のビヘイビアを実装するグローバルクラスです	ZBP_R_TravelTP
ローカルハンドラークラス	LHC_ プレフィックス	ビヘイビアプール内のローカルクラスです	LHC_Travel_Create
ローカルセーバークラス	LSC_ プレフィックス	ビヘイビアプール内のローカルクラスです	LSC_Travel

完全な例：「Travel」エンティティ（V4、UI、ドラフト、マネージド）

#	オブジェクトタイプ	SAP の命名規則	名前
1	データベーステーブル（アクティブ）	A_ 接頭辞	ZA_TRAVEL
2	データベーステーブル（ドラフト）	D_ 接頭辞	ZD_TRAVEL
3	ベース CDS ビューエンティティ	R_ 接頭辞 + TP 接尾辞	ZR_TravelTP
4	プロジェクション CDS ビュー	C_ 接頭辞	ZC_Travel
5	インターフェース BDEF	= ルートエンティティ名	ZR_TravelTP
6	プロジェクション BDEF	= プロジェクションビュー名	ZC_Travel
7	メタデータ拡張	= プロジェクションビュー名	ZC_Travel
8	サービス定義	UI_ 接頭辞（任意）	ZUI_Travel
9	サービスバインディング	UI_ 接頭辞 + _O4 接尾辞	ZUI_Travel_O4
10	ビヘイビアプールクラス	BP_ 接頭辞	ZBP_R_TravelTP

R_ と I_ の接頭辞に関する注意事項

• R_（ベース／ルートビューエンティティ）：SAP 標準の RAP 開発ガイド（マネージド、アンマネージド、ドラフト）で使用されています。新しい RAP 開発における現在の SAP 推奨です。
• I_（インターフェースビュー）：以前から使用されており、現在も一般的です。再利用可能なインターフェース層を表します。既存のチュートリアルや古いプロジェクトの多くでは、R_ の代わりに I_ が使用されています。
• どちらも有効です。SAP の最新ガイドに沿った新しいプロジェクトでは、R_ をデフォルトにしてください。システム上の既存コードで I_ が使用されている場合は、一貫性を保つためにそれに合わせてください。

テーブルの命名に関する注意事項

• SAP では、アクティブテーブルとドラフトテーブルにそれぞれ A_ と D_ の接頭辞を使用します。
• 古いチュートリアルやコミュニティのパターンの中には、テーブルに _D 接尾辞、ドラフトに _DD を使用するものがあります。これはSAP の公式規則ではありませんが、実際には広く見られます。
• SAP の「OData UI Service from Scratch」ウィザードでは、これらの接頭辞を付けたテーブルが自動的に生成されます。