CRM OData multiple origin Composition的测试

首先，对 OData multiple origin 功能测试的结论是：如果gateway系统上针对一个odata service维护了多个mark成default的backend system，在creation的case下，runtime时候gateway只会向第一个
Default system发起请求。

如果我们在gateway上维护多个default backend system，比如QHA/504和QHD/504:

在gateway上创建一个Opportunity：

QHA/504上能够看到该Opportunity：

And this Opp is NOT created in QHD/504 ( the Opp 3494 in QHD/504 actually points to another Opp created previously ):

这个system排列顺序是按照字母排序的，即使我把QHA对应的那行删除，然后重新插入，它仍然会出现在QHD前面。

如果切换成如下的设置：

gateway将只会从第一个mark成default的backend 系统取值，因为我在QD0/504没有user，所以UI上将看不到任何结果：

Opportunity Odata model里有三个entity set mark成address = true:

SAP help里的解释是mark成address = true的entity set能够直接通过url访问，比如如下两个例子：document history和maxhit.

而对于其他通过$expand访问的entity set， 比如Attachments，product等等，虽然表面上也是通过url直接访问：

但是根据SAP help里的定义，framework在访问这些entity set时，总是先拿到root entity set，即Oppportunity，再执行expand操作。

下面的例子是Framework处理documentHistory的读操作：框架直接call GET_ENTITYSET method直接根据传入的guid将history返回：

但是对于这个expand的url而言：
https://jerry.corp:7080/sap/opu/odata/sap/CRM_OPPORTUNITY/Opportunities(guid’3440B5B1-73AE-1ED4-9ED9-F49FBCEA5CC2’)?$expand=Products,ChangeDocs,Competitors,OpportunityLogSet&sap-client=001

框架的处理是先从Opportunity出发：

line 28先读取Opp header，再call line 41的read function 读取需要expand的sub entity set信息。