您好，

您计划在2020年提供方向/工具/帮助，以将针对Fiori的ABAP编程模型（基于BOPF）的开发转移到RAP模型。

在您的自定义实体实现类中，您可以调用OData服务及其相关属性来获取数据或更新数据。 我希望这是您的问题。

操作方法，一个简单的示例：

https://developers.sap.com/mission.abap-env-connect-s4hana.html

可以将此逻辑扩展为 导航属性。

注意

GK

类似于Gaurav Karkara ，您现在没有转换支持。 还有一件事是，prem上的1909不支持最近发布的Trail ABAP云平台中可用的所有最新创新。这可能是在prem1909上找不到的情况（可能是这种情况） 。

因此，最初的问题是，我看到您有一些BOPF对象，但是它们是否基于Fiori的ABAP编程模型？ 还是只是BOPF对象？

您是否正在寻找一种通过执行自定义BOPF DAC方法从实体获取数据的方法？

嗨，Mahesh，

不，它不是"纯" Fiori ABAP编程模型。

实际的实施和工作方案如下：

>实施标准BOPF（bobx trx）

>为每个节点（继承自我们开发的基本类）实现DAC。 在这里，我们将CDS数据作为常规行为读取，但是（使用特定的DAC方法在子类中重写），我们还可以从任何其他来源（通过ABAP代码）获取它们，或者在从数据库CDS视图中选择之后完成它们。

>实现可能的关联：在此，如果未指定任何内容（并且该节点是BOPF的子节点），则数据选择由CDS关联（由ABAP代码管理，而不直接与CDS关联管理）进行，但我们 还可以实现完全自定义的BOPF关联类，在其中可以通过特定的ABAP代码读取（或生成）派生的数据。

>有关操作和查询的相同故事

在服务方面：我们使用的是odata V4（显然与BOPF模型的比例接近1：1），所以我们：

>我们创建了DPC/MPC的基本架构来发布服务

>我们创建了一些基类（假设是一个框架），以从BOPF元数据和CDS数据开始自动将BOPF公开为模型（在某种程度上类似于RAP的概念）

我们之所以采用这种方法，是因为我们想采用" API至上"的方法，但是不得不在大约一年半之前开始开发。 它运行良好，但我们一直期待着转向新的开发人员标准。 我们不需要"转换"工具（我不清楚）。 我希望通过新标准满足所有需求，以便将来开发新的API对象。

最后您的问题：

如前所述，在我们的实际方案中，如果需要，我们可以完全控制"读取"或选择数据。 显然，我们可以基于CDS直接访问（选择或关联），但是我们也可以从ABAP代码中完全自定义实现数据。 在当前的RAP中，我发现（很明显）有很多相似之处，并且对我们的需求有很多答案，特别是使用"自定义实体"。 我所缺少的是可以在自定义代码中读取关联数据的可能性（换句话说，很清楚如何在实体的数据选择上使用@QueryImplementedBy，而不是在所谓的"导航"过程中使用，或者，如果愿意，会发生什么情况 在odataV4服务的DPC类的READ_REF_TARGET_KEY_DATA_LIST中）。

我将检查博客，其中 Gaurav Karkara 放在ans下方，尤其是句子 ："也可以将此逻辑扩展到导航属性。"

希望很清楚