SAP Fiori Elements 应用 OData 元数据请求 url 里的模型名称决定逻辑

简介: SAP Fiori Elements 应用 OData 元数据请求 url 里的模型名称决定逻辑

问题

我用 yarn start 本地启动一个 SAP Fiori Elements 应用,在 Chrome 开发者工具 network 面板,观察到一个 OData metadata 请求的 url 如下:

http://localhost:8080/sap/opu/odata/sap/SEPMRA_PROD_MAN/$metadata?sap-value-list=none&sap-language=EN


这个 OData 服务名称 SEPMRA_PROD_MAN,运行时是如何决定出来的?

查看 Component.js 文件里的函数 Component._createManifestModels


我们查看变量 mModels, 发现有三个字段:


其中 ""字段的值,来自 manifest.json 文件的 models 区域的同名字段:

dataSource 的值指向 mainService,后者的 uri 字段就是 Fiori Elements 应用运行时,发起 OData 元数据请求的 url:


在 SAP UI5 应用中,manifest.json文件是一个重要的配置文件。它充当了应用的描述符,定义了应用的元数据、模型、服务、i18n(国际化)等等。我们可以将其看作是一个集中的配置中心,其中所有的配置都在一个地方,使得代码更容易维护,也更容易理解。


manifest.json文件中,dataSources部分是非常重要的一部分,它定义了应用如何连接到后端服务。这个区域可以声明一个或者多个数据源,每一个数据源对应一个后端服务。这些服务可以是 OData 服务,也可以是其他类型的服务。


当我们在manifest.json文件中定义了数据源后,我们可以在应用的其他部分通过这个数据源的名称来引用这个服务,而不需要记住具体的 URL。这样做的好处是,如果服务的 URL 发生变化,我们只需要在一个地方更新它,而不需要搜索整个代码库来找到所有使用这个服务的地方。


下面是一个manifest.json文件中dataSources区域的例子:

{
    "sap.app": {
        "dataSources": {
            "mainService": {
                "uri": "/sap/opu/odata/sap/ZMAIN_SRV/",
                "type": "OData",
                "settings": {
                    "odataVersion": "2.0"
                }
            },
            "secondService": {
                "uri": "/sap/opu/odata/sap/ZSECOND_SRV/",
                "type": "OData",
                "settings": {
                    "odataVersion": "2.0"
                }
            }
        }
    }
}


在上面的例子中,我们定义了两个数据源,它们的名字分别是mainServicesecondService。每个数据源都有一个uri属性,这个属性定义了服务的 URL。type属性定义了服务的类型,这里我们使用的是 OData 服务。settings对象包含了服务的其他配置,比如 OData 的版本。


定义了数据源之后,我们就可以在应用的其他部分使用这个数据源了。例如,我们可以在models区域定义一个模型,并且将这个模型关联到一个数据源:

{
    "sap.ui5": {
        "models": {
            "": {
                "dataSource": "mainService",
                "preload": true
            },
            "secondModel": {
                "dataSource": "secondService",
                "preload": true
            }
        }
    }
}

在上面的例子中,我们定义了两个模型,它们分别关联到了我们之前定义的两个数据源。这样,当我们在应用中使用这两个模型时,SAP UI5 会自动的使用对应的数据源连接到后端服务。


总结

总的来说,manifest.json文件中的dataSources区域是用来定义应用如何连接到后端服务的。它使得服务的配置集中在一个地方,使得代码更易于维护,也更易于理解。


相关文章
|
2月前
|
JavaScript 前端开发
试读版:如何找出 SAP 标准 Fiori 应用某个按钮点击后执行的 JavaScript 源代码
试读版:如何找出 SAP 标准 Fiori 应用某个按钮点击后执行的 JavaScript 源代码
关于 SAP ABAP OData 服务如何实现 Deep Insert 场景 - SAP 应用的标准行为试读版
关于 SAP ABAP OData 服务如何实现 Deep Insert 场景 - SAP 应用的标准行为试读版
|
2月前
|
前端开发 搜索推荐 开发者
SAP UI5 sap.m.Column 控件的 minScreenWidth 属性介绍
SAP UI5 sap.m.Column 控件的 minScreenWidth 属性介绍
|
2月前
|
JavaScript 前端开发 开发者
SAP UI5 控件 sap.m.ListBase 的 inset 属性的作用介绍
SAP UI5 控件 sap.m.ListBase 的 inset 属性的作用介绍
|
2月前
|
Web App开发 数据采集 前端开发
纯技术讨论:如何让 SAP UI5 应用无法被别人在浏览器里调试 - 这种做法不推荐试读版
纯技术讨论:如何让 SAP UI5 应用无法被别人在浏览器里调试 - 这种做法不推荐试读版
|
2月前
|
XML 存储 数据格式
SAP UI5 控件 customData 属性的应用介绍
SAP UI5 控件 customData 属性的应用介绍
|
2月前
|
前端开发 JavaScript API
SAP UI5 sap.ui.require.toUrl 的作用介绍
SAP UI5 sap.ui.require.toUrl 的作用介绍
|
2月前
|
搜索推荐
如何让 SAP UI5 Smart Table 支持多项选择(Multiple-Selection)试读版
如何让 SAP UI5 Smart Table 支持多项选择(Multiple-Selection)试读版
使用 SAP UI5 Event Bus 机制,修复 SAP UI5 分页显示数据的一个 bug 试读版
使用 SAP UI5 Event Bus 机制,修复 SAP UI5 分页显示数据的一个 bug 试读版
|
2月前
|
Web App开发 前端开发 JavaScript
乱花渐欲迷人眼 - 让 SAP UI5 应用的日志输出不再素面朝天
乱花渐欲迷人眼 - 让 SAP UI5 应用的日志输出不再素面朝天

热门文章

最新文章