SAPWebIDEOData下拉菜单里的Destination是怎么来的
这篇文章主要讲解了“SAP WebIDE OData下拉菜单里的Destination是怎么来的”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“SAP WebIDE OData下拉菜单里的Destination是怎么来的”吧!
创新互联建站专注于揭东企业网站建设,响应式网站开发,商城开发。揭东网站建设公司,为揭东等地区提供建站服务。全流程按需定制开发,专业设计,全程项目跟踪,创新互联建站专业和态度为您提供的服务
我今天做开发遇到一个问题:
我有trial和正式的SAP Cloud Platform账号各一个:
其中trial账号的webIDE连接到productive的CloudFoundry:
productive账号的WebIDE也连接到productive的CloudFoundry:
我发现在我新建OData服务时,从Service url的下拉菜单里,选择不到我在SAP云平台里创建的Destination.
怎么感觉trial WebIDE取的Destination来自trial neo环境创建的?
而productive的WebIDE,system下拉菜单里的Destination也来自productive Neo环境的Destination.
似乎CloudFoundry环境的Destination根本没有被考虑。
再检查我使用的webIDE的url.
trial:
https:///
后来发现了一个github issue:
Create a Destination within the Cloud Foundry Environment · Issue #3398 · SAPDocuments/Tutorials
得知如果在SAP WebIDE里创建UI5应用,需要用Destination连结第三方服务时,需要在Neo环境里创建Destination,而不是在CloudFoundry环境里。
为了验证,我再次在Neo环境里创建一个Destination:
然后果然在WebIDE里看到了这个创建于Neo环境的Destination.
WebIDE Preferences里维护的CloudFoundry endpoint只是开发好的UI5应用部署的目的地。
那么问题又来了,既然这个UI5应用最终部署在SAP云平台的CloudFoundry环境下,如果CloudFoundry环境没有对应的Destination,运行时的表现是怎样的?
经过我实际测试,发现取不到OData服务的metadata,报500 Internal Server Error的错误。
于是我把Neo环境里创建的Destination导出,再倒入到CloudFoundry环境,这次发现OData metadata终于能够成功返回了:
感谢各位的阅读,以上就是“SAP WebIDE OData下拉菜单里的Destination是怎么来的”的内容了,经过本文的学习后,相信大家对SAP WebIDE OData下拉菜单里的Destination是怎么来的这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
本文题目:SAPWebIDEOData下拉菜单里的Destination是怎么来的
文章URL:http://scyanting.com/article/iihhgj.html