SAP UI5 Fiori 应用在启动时向 ABAP 后台发起的 OData 请求序列的顺序和作用分析
SAP UI5 Fiori 应用在启动时向 ABAP 后台发起的 OData 请求序列的顺序和作用分析
本文的写作动机，来源于我的知识星球里一位朋友的提问：
我们现在在 BTP 上给 successfactors 增强一个功能，画面 fiori ，针对画面上的fo 字段或者 picklist 类型字段，为了方便画面比较容易输入值，下拉框里面的值一般通过什么方式做成，而且不影响性能，现在我们考虑通过追加代码去取得下拉框的值，但是画面初期打开的时候，如果这样项目特别多，特别影响性能，想问一下有什么好的办法？或者这样例子应该怎么去实现？谢谢
我的一些回复：
初次打开画面的时候，能不能做到下拉框的延迟加载呢？也就是说，初次打开时，页面是只读模式的，此时下拉框的位置，仅仅需要显示下拉框里默认选择的 key 值对应的描述信息，此时下拉框退化成一个 Text Field.
仅仅当切换到编辑模式时，才从数据库读取 key 和 description. 这种方式在点 Edit 按钮切换成编辑模式时，也会感到一点延迟。
更高级一点的做法，就是在只读模式下，没等点击 Edit 按钮，就开始异步的去后台读取 key 和 description.
这个问题促使我去思考一个问题：SAP 标准的 Fiori 应用，在启动时是如何管理和处理发送到后台的 ABAP HTTP OData 请求的？
带着这个问题，我找了一个 SAP 标准的 Fiori 应用，CRM 领域的 My Opportunity，研究了这个应用打开时往 ABAP 后台发送的全部 OData 请求，并逐一分析了每个 OData 请求的发送原因，对每个请求的 HTTP 请求和 HTTP 响应的头部字段和正文负载(payload)，也做了详细的论述。
我们在 SAP CRM Fiori Launchpad 里点击 My Opportunity 的 tile：
这个 Fiori 应用得以启动，看到如下的界面：
这是一个典型的 Master - Detail 布局的 SAP UI5 应用，左边的区域称之为 Master List，右边是 Detail 视图。这种 Master-Detail 布局的应用开发方式，在笔者另一套 SAP UI5 开发教程里有详细叙述：
上图图例1显示了 系统里总共的 Opportunity 条数为 451，区域2 显示了默认 20 条数据。当我们滚动鼠标到第 20 条数据之后继续向下滚动，就会触发第 21 条数据到第 40 条数据的加载。这其实设计到 OData 读取数据的分页概念，默认情况下每页包含 20 条 Opportunity 数据，当应用启动时，只读取第一页的 Opportunity 数据，即默认显示 20 条 Opportunity.
图例3 即 Opportunity 明细页面，这里显示的是第一页 20条 Opportunity 中的第一条数据。
https://:44355/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html?sap-client=001#Opportunity-manageOpportunity&/detail/Opportunities(guid’FA163EE5-6C3A-1ED6-9DC1-A73EEF634C10’)
我们打开 Chrome 开发者工具，切换到 Networks 标签页，在 filter 里输入 /sap/opu/odata/sap/CRM_OPPORTUNITY，这是该 Fiori 应用消费后台 ABAP 服务的 url(图例2).
通过这个过滤条件，network 里显示了全部 6 条 OData 请求。
本文余下部分逐一介绍这六条 OData 请求的明细。