データモデルの一部ではないプロパティをサーバーに送信するのは、非常に悪いアプローチだと思います。OData 4.0 仕様には次のように記載されています(ただし、SAP GW はまだ OData 2.0 です)。
6.2 ペイロードの拡張性
OData は、特定の形式に従って、ペイロードの拡張性をサポートします。指定された OData-Version ヘッダーに従ってペイロードを正しく解釈するために受信者が理解する必要がある場合、形式に関係なく、追加のコンテンツが存在してはなりません。したがって、クライアントとサービスは、OData-Version ヘッダーで指定されたペイロードのバージョンで明確に定義されていないコンテンツを処理するか、安全に無視する準備ができている必要があります。
SAP GW は、要求をキャンセルして不適切な要求応答を返すことにより、予期しないプロパティを「処理」します。この動作を変更するオプションはなく、「OData」が壊れる可能性もあります。
フロントエンドでSAPUI5を使用していると思います。あなたが実際に望むものを達成する方法はたくさんあります - 私はこれについて非常に確信しています. しかし、「実際の」データを変更する、つまり「追加の」プロパティを追加することは、私の場合は必要ありませんでした。1 つの方法は、コントロールの編集可能なプロパティを次のようなものにバインドすることです。
"{view>/editmode}"
ご想像のとおり、これはビュー モデルであり、「ビュー モデル パターン」とも呼ばれます。コントローラーで (つまり、onInit で) JSONModel を作成してから呼び出すことを意味するだけです。
this.getView().setModel(oModel, "view");
コントロールのセットの編集を無効/有効にしたいときはいつでも、これを一度呼び出すだけです:
var bEditable = ...; // true or false
//...
this.getView().getModel("view").setProperty("/editMode", bEditable);
もう 1 つのオプションは、2 つの異なるビュー/ターゲット (1 つは editMode 用、もう 1 つは表示モード用) を持つことです。Fiori ガイドに従いたい場合は、このオプションを使用する必要があると思います。それはあなた次第です...
これらのオプションは、「すべて」のコントロールを編集可能または編集不可にするために、1 つのフラグを使用することを前提としています。
追加のアドバイスが必要な場合は、問題をよりよく説明するためにコードを投稿してください。