ここでは、バックグラウンドの研究とどのようにIEでODataのデータを消費する私の今日のモデルは次のとおりです。
SPROの内側：
このモデルプロバイダクラスは、このモデルをLWM_CUSTOMER_BRIEFING構造、ならびに構造体との間の関係のすべてを定義します。
今のモデリングを行うためのグラフィカル・インターフェース・ツールではありません、我々は唯一の内部DEFINE CL_LWM_CB_ADAPTER_MDPに構造モデルを定義することができます。具体的なアプローチは、データ内のエンティティの種類の事前定義された背景を使用することである
顧客は、このパッケージの内側にすべてのDDICオブジェクトのすべての使用ブリーフィング：LWM_CRM_CUSTOMER_BRIEFING
そのような関連付けとして、関係を構築しながら、一方のエンティティによって作成され、内部を画定するABAPコードで、それらは、DDICオブジェクトに関連付けられています。
通过http://ldcigm2.herr.corp:50018/sap/opu/sdata/sap/customer_briefing?sap-client=001 我们可以拿到customer briefing的service document。
Service document里面只定义了哪些entity暴露了哪些操作，真正metadata的full definition xml用这个URL down：
http://ldcigm2.jerry.corp:50018/sap/opu/sdata/sap/customer_briefing/KaTeX parse error: Expected 'EOF', got '&' at position 24: …?sap-client=001&̲format=xml
service document也能通过SICF进去之后，从sap node出发，点test拿到。
比如这部分就说明CustomerCollection这个节点能够执行“search”的action:
然后我们在IE里面测试：
http://ldcigm2.jerry.corp:50018/sap/opu/sdata/sap/CUSTOMER_BRIEFING/CustomerCollection?sap-client=001&$format=xml&search
返回所有的Customer信息，Customer node的property就是在figure1里面看到的那些。
Search 所有name property中包含“UT_Customer” 的Customer
http://ldcigm2.jerry.corp:50018/sap/opu/sdata/sap/CUSTOMER_BRIEFING/CustomerCollection?sap-client=001&$format=xml&search=UT_Customer
返回Partner ID = 133的customer的detail 信息
http://ldcigm2.jerry.corp:50018/sap/opu/sdata/sap/CUSTOMER_BRIEFING/CustomerCollection(133)?sap-client=001&$format=xml
所有这些操作都在service provider class CL_LWM_CB_ADAPTER_RDP里面实现，
如果我们直接在IE里面通过http://ldcigm2.jerry.corp:50018/sap/opu/sdata/sap/CUSTOMER_BRIEFING/CustomerCollection(133)?sap-client=001&$format=xml
的URL consume OData service：
Gateway 系统上首先会根据OData service expose出来的external name找到internal使用的service ID:
然后根据service ID找到对应的CRM 系统的destination：
通过RFC直接call CRM系统上的一个remote function module：
在CRM的这个FM上设个断点，发现断点已经被触发了。
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
