2020-08-31 16:01发布
点击此处---> 群内免费提供SAP练习系统（在群公告中）加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）嗨！ 我一直在SEGW中开发O... 显示全部
加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）
嗨！
我一直在SEGW中开发OData服务，遇到过Function导入。 我经历了
https://help.sap.com/saphelp_nw74/ helpdata/zh-CN/c5/dc22512c312314e10000000a44176d/content.htm
我仍然不清楚。 有人可以帮我吗？
谁能解释-
嗨，Manvitha，
如其他答复所述，在CRUD不适合的地方可以使用函数导入，但是存在一些缺点。
过度使用会开始使ODATA协议更像SOAP，而将重点放在业务功能而不是数据上。
它们当前未与特定实体相关联，它们会随处可见。 服务定义。 如果我正确理解Odata 4规范，那么这种情况将会改变。
大多数转换为功能导入的操作都可以在CRUD下以正确的设计实现，例如使用"别名"实体（I ''不确定该技术是否有正式术语）。
别名的一个示例是基于"销售订单"业务对象的一组实体。 您可能有订单，未确认订单和已确认订单。
对Orders的完整查询将导致所有三个可能集合的并集，而对其他两个完整查询将导致两个互斥的集合。 如果我想确认CRUD下的订单，我只需从UnconfirmedOrders获取订单并将其放入ConfirmedOrders。 源实体和目标实体向后端指示正在发生的事情，因此逻辑可以运行确认过程。 在PUT之后，我会发现订单的"位置"已更改； 它仍然在订单中，但是现在在ConfirmedOrders中，而不是UnconfirmedOrders中。
我实际上更喜欢这种设计模式，因为它符合使用URI和导航的REST原则。 通过将URI"移动"到可导航的点，我设法更改了业务对象的状态。
使用功能导入或别名实体的主要困难是将使用模式传达给消费者。 假设消费者并不了解您服务中的所有细微皱纹。 是的，您正在为自己的获奖应用程序苦苦地编写它，但是OData是关于可能需要向全球社区公开的已发布服务的，它们不应该过时！
我将尝试使用任何需要的服务 最简单的URI形式，最易于传达用法。
关于
Ron。
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','http://www.easysap.com/data/attach/logo/logo.png', '推荐 空代码 的问题《函数导入-USE》','https://www.easysap.com/answer/43987/122766.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
嗨，Manvitha，
如其他答复所述，在CRUD不适合的地方可以使用函数导入，但是存在一些缺点。
过度使用会开始使ODATA协议更像SOAP，而将重点放在业务功能而不是数据上。
它们当前未与特定实体相关联，它们会随处可见。 服务定义。 如果我正确理解Odata 4规范，那么这种情况将会改变。
大多数转换为功能导入的操作都可以在CRUD下以正确的设计实现，例如使用"别名"实体（I ''不确定该技术是否有正式术语）。
别名的一个示例是基于"销售订单"业务对象的一组实体。 您可能有订单，未确认订单和已确认订单。
对Orders的完整查询将导致所有三个可能集合的并集，而对其他两个完整查询将导致两个互斥的集合。 如果我想确认CRUD下的订单，我只需从UnconfirmedOrders获取订单并将其放入ConfirmedOrders。 源实体和目标实体向后端指示正在发生的事情，因此逻辑可以运行确认过程。 在PUT之后，我会发现订单的"位置"已更改； 它仍然在订单中，但是现在在ConfirmedOrders中，而不是UnconfirmedOrders中。
我实际上更喜欢这种设计模式，因为它符合使用URI和导航的REST原则。 通过将URI"移动"到可导航的点，我设法更改了业务对象的状态。
使用功能导入或别名实体的主要困难是将使用模式传达给消费者。 假设消费者并不了解您服务中的所有细微皱纹。 是的，您正在为自己的获奖应用程序苦苦地编写它，但是OData是关于可能需要向全球社区公开的已发布服务的，它们不应该过时！
我将尝试使用任何需要的服务 最简单的URI形式，最易于传达用法。
关于
Ron。
一周热门 更多>