我的客户需要一个带有检查表的UI5表单，检查表必须是动态生成的，部分、问题和可能的答案都将作为S/4HANA云中的自定义业务对象条目进行维护，什么大数据，有一个层次结构，每个部分包含一个或多个问题，每个问题都有一个或多个答案，通常（但并非总是）是或否。他们希望能够添加新问题而无需更改代码。

该应用程序将在SAP Cloud Platform的Cloud Foundry环境中运行，我使用SAP Cloud Application Programming Model（APM）和SAP S/4HANA Cloud SDK（S4SDK）的组合来组合SAP提供的各种API，自定义业务对象和自定义CD视图到UI5应用程序可以使用的单个OData服务中。

如果通过Netweaver网关服务器访问后端，我可能会编写OData服务以支持"双扩展"。url如下：

……/ChecklistSections？$expand=toQuestions/toAnswers

这样我就可以一次完成整个层次结构（Sections->Questions->Answers），然后我就可以将UI控件绑定到OData模型上。

遗憾的是，我使用的APM/S4SDK组合还不支持这种请求。看起来我可以在单个部分上展开来获取问题，比如，但不是一次就得到全部。如果可能的话，它是没有文件记录的！

我能做的就是独立检索这3个实体，也就是说我可以打电话获取所有的部分，另一个是获取所有问题，最后是问题的所有可能答案。然后我可以使用JavaScript（在UI5应用程序中）构建层次结构。

在我上面描述的场景中，我们希望构建层次结构，但我们只能在有节、问题和答案的情况下进行。我们不在乎它们返回的顺序，但我们需要所有这些都可用。

在每次OData读取的成功回调中，我们可以设置一个标志，表示"我们完成了"。然后我们可以检查其他调用的标志，看看他们是否也这样做了。只有在最后的回调（无论哪一个碰巧是），我们将继续建立层次结构。我不喜欢这种模式，因为它是混乱和容易出现错误。

我们可以运行串行调用，而不是并行调用（即节回调触发读取问题），但显然这将是很多更慢。

如果你熟悉传递成功和错误回调函数（例如v2.OdataModel read方法），那么你就知道异步调用的"旧方法"。使用promises（"新方法"），你在进行异步调用时不会传递回调函数。相反，该调用返回一个Promise对象（同步），您将回调附加到该对象上。

UI5也使用promises（而且它们越来越普遍）。

有关promises的完整解释，请参阅MDN或Google。promises相对于旧模式的一些优点是：

它们可以链接在一起即使是在异步调用结束后添加的回调，也保证会运行（！）它们很容易阅读回调函数不需要考虑下一个调用哪个函数错误处理更复杂

另一个优点是答应我。好的方法是如此的酷和有用，网站云服务器，它得到了自己的博客（这一个）。这个方法返回一种"超级承诺"，只有当它的每个"子承诺"解决（即成功完成）时才会解决。

在我们的例子中，大数据现状，我们可以返回三个承诺，对于部分、问题和回答电话。然后我们编写逻辑，将所有结果组合在一起（并构建层次结构）答应我。好的成功回电。

在此期间，我们可以坐下来放松，安全地知道，当所有回电完成时，我们会得到通知！

我们使用一个read函数（readChecklistEntity）并调用它三次，淘客怎么赚钱，传入entityset名称。该函数在每种情况下都返回一个promise，我们把这三个承诺传递给答应我。好的方法。然后我们将成功和错误回调函数附加到答应我。好的返回

请注意，这种方法允许我们在通话中使用承诺，尽管如前所述，v2.ODataModel使用"旧样式"回调。

当所有三个读取都成功返回时，将调用我们的buildChecklist函数。我们不在乎哪个先返回，哪个最后返回。结果集的顺序与我们传递三个承诺的顺序相匹配答应我。好的是的，云计算大数据，也不是取决于哪个读取首先完成。

如果任何读取失败，我们的handleChecklistError函数将被调用。

在默认设置下，我们的三次读取将合并为一个批处理请求。我们可以在v2.ODataModel上使用attachBatchRequestCompleted方法，它将为我们提供一个在批处理请求返回时调用的事件处理程序。另外，我们可能希望合并来自不同OData服务的读取，而这些读取显然不会合并到单个批处理中。

想了解更多有关将promises与UI5和OData一起使用的信息吗？查看Wouter Lemaire的这个博客，它概述了一个使用承诺构建的"核心服务"方法

nathand已经开始了一个关于使用UI5承诺的博客系列