SAP CRM Fiori busy dialog的工作原理

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/i042416/article/details/86764360

为了更深入理解busy dialog，可以看附件两个视频。

我在Opp header ETAG的后台实现里加了一个10s的延时。

1. 第一个video timeout_1500.wmv: 虽然list和detail的数据都ready了，但是因为ETAG需要10s才能返回，整个UI被这个ETAG的request造成的busy dialog锁住了，直到10s后UI才能点击

2. 第二个video是把默认的timeout从1500毫秒改成30秒，即busy dialog不会显示。从video里看出UI始终是可操作的，尽管后台的ETAG还没有回来。
   这个busy dialog实际上也是一种保护措施。如果UI上某些操作必须依赖于最新的ETAG，采用这种方式可以让user同步的ETAG请求返回UI之前就能够进行操作，会造成state的inconsistency。

Key message we could find in the source code:

1. after sap.ca.ui.utils.busydialog.requireBusyDialog() is called in application, we can only see the rotating wheel in UI after 1.5 seconds - defined in BUSYDIALOG_TIMEOUT.

2. the requireBusyDialog and releaseBusyDialog must be called in pair. There is private variable _iRequiredCount maintained inside the implementation. When require function is called, _iRequiredCount++; release for _iRequiredCount–.

3. it is obsolete. New application should use sap.m.BusyDialog instead.

Take the process to open Opportunity tile as example.

1. The bindAggregation in S2.controller.js will trigger the Odata request sent to backend:

request url:

And connectionManager is responsible to call requireBusyDialog:

iRequiredCount changed from 0 to 1:

2. OpportunityAttachment data is requested. ConnectionManager calls another requireBusyDialog, iRequiredCount changed from 1 tp 2:

3. in detail view, ETAG refresh operations makes iRequiredCount changed from 2 to 3:

4. At this time, the response of request in step1 has been returned to frontend, ConnectionManager calls releaseBusyDialog:

iRequiredCount changes from 3 to 2:

Since now iRequiredCount still > 0, the busyDialog will not be closed.

5. the response for request in step2 is returnd, iRequiredCount changes from 2 to 1:

6. the ETAG request sent in step3 has response now, iRequiredCount changes from 1 to 0:

now busy dialog is closed:

要获取更多Jerry的原创文章，请关注公众号"汪子熙":