测试
全部博文（931）
分类： 架构设计与优化
2019-04-19 12:06:19
我的前一篇文章 使用Java+SAP云平台+SAP Cloud Connector调用ABAP On-Premise系统里的函数介绍了在SAP云平台的Neo环境下如何通过SAP Cloud Connector消费ABAP On-Premise系统里的函数。在那篇文章demo程序的Java代码里，我们实际是通过JCO(Java Connector)来远程调用ABAP On-Premise系统里的函数。
今天我们换个环境，试试SAP云平台的CloudFoundry环境。
同时我们也试试换一种方式来消费ABAP On-Premise系统的服务。让我们开发一个Web应用，通过OData的方式显示ABAP On-Premise系统里的产品列表及价格信息。
该例子运行效果如下图所示。
同前一篇文章提到的在SAP云平台的Neo环境里消费ABAP On-Premise函数相比，在CloudFoundry环境里实现同样的需求，所需的步骤要复杂一些。
同Neo环境的部署相比，在CloudFoundry环境下最显著的架构区别就是多了个App Router。为什么CloudFoundry环境下需要这个东西？我的同事李贝宁在他的文章 SAP成都研究院李三郎：SCP Application Router简介 里做过详细阐述。
为了完成这个例子，我们需要部署两个应用到SAP云平台的CloudFoundry环境去，即App Router和Web应用本身。两个例子的完整代码在我的github上：
上图各模块间交互的简单阐述：
1. App Router作为用户访问Web应用的入口。
2. App Router将请求重定向到XSUAA实例，弹出登录界面。该实例负责完成登录认证，稍后会创建它。下图是登录界面在我手机上打开的效果。
3. 登录完成后，App Router将请求重定向到Web应用。
4. Web应用向XSUAA发起两个并行的请求，如图4a和4b所示，获取用于访问接下来第5，第6步的JSON Web Token。
5. Web应用访问Destination实例获取对应配置信息。
6. Web应用将请求发送给Connectivity实例。
7. Connectivity实例将请求通过Secure tunnel（安全隧道）转发给Cloud Connector。
8. Cloud Connector和On-Premise系统都位于Corporate Network里，直接调用其服务。
明白了原理，下面跟着Jerry一起做一做吧。
1. 我前一篇文章 使用Java+SAP云平台+SAP Cloud Connector调用ABAP On-Premise系统里的函数介绍了Cloud Connector的下载与安装，因此现在我们可以重用之前安装好的Cloud Connector。
点击Add Subaccount按钮，基于CloudFoundry Subaccount创建一个新的配置：
最重要的是维护CloudFoundry Subaccount的ID和用户名(登录邮箱)。
创建一个从Virtual Host到Internal Host的映射关系。Virtual Host的名称可以随便维护，我维护的是my-backend, 记住这个名称，以后会用到。Internal Host我维护的是提供OData服务的On-Premise系统的主机名和端口号。点击Check按钮，确保Cloud Connector能够成功连接On-Premise系统，状态为Reachable。
将On-Premise系统的下列4个ICF服务路径暴露出来：
/sap/bc/lrep
/sap/iwbep
/sap/opu/odata
/sap/public
至此Cloud Connector上的配置完成了。
2. 回顾我们之前介绍的模块交互图，Cloud Connector上的配置无法直接被部署在CloudFoundry上的应用消费。我们还需要在SAP云平台上创建三个不同类型的实例。
首先在SAP云平台Cockpit里创建一个新的Destination，URL字段指向前一步Cloud Connector里创建的Virtual Host。这个Destination的名称也得记录下来，后面会用到。
进入Service Marketplace，创建一个新的XSUAA实例：
这个connectivity-jerry-demo就是稍后我要部署到SAP云平台上的Web应用名称。
创建好的XSUAA实例：
connectivity和destination的实例创建的方式相同，不再赘述。下图是为了完成本文介绍的场景所需的三个不同类型的实例创建好之后的状态截图。
至此SAP云平台上的配置也全部完成。
3. 现在开始Web应用的开发。先看App Router的xs-app.json: 入口文件是index.html, 这个html文件其实就一行代码：
点击之后，会跳转到/app/, 而/app/的route配置如下，指向destination "dest-to-app":
而这个destination对应的真实url维护在App Router的manifest.yml文件中。同样需要在该yml文件的services字段里维护前一步创建的XSUAA实例：
再看Web应用的manifest.yml文件：需要将前一步骤依次创建的三种类型的实例名称分别维护如下图所示：
接下来我们需要进行Web应用里UI5部分的开发，指定产品列表的数据源基于哪一个OData服务。在UI5的controller文件里，指定OData模型的路径为相对路径data-eu。
针对这个相对路径data-eu，在neo-app.json里定义了一个路由，会被重定向到On-Premise系统的标准OData服务EPM_REF_APPS_SHOP_SRV。具体重定向到哪个On-Premise系统是由路由的target字段决定的。在我这个例子里是jerry-abap-backend, 它就是我们之前在SAP云平台Cockpit里创建的Destination。
这个Destination的URL字段指向Cloud Connector的Virtual host，该host又映射到On-Premise系统的主机名和端口号。至此大功告成了，SAP Cloud Connector上的配置，App Router，Web应用，SAP云平台上的connectivity，XSUAA和destination三个实例，这一系列模型犹如一台机器上的一个个零件，协同工作，实现了从Internet Network到Corporate Network的访问场景。
将两个应用部署到SAP云平台的CloudFoundry环境去，点击App Router作为访问的入口，能看到文章开头的产品列表页面。
并且Chrome开发者工具里观察到的网络请求的路径里仅仅包含前文提到的UI5应用的neo-app.json里配置的路由data-eu, 而On-Premise系统的主机名和端口号并未暴露到Cloud环境中。
当然，为了跑这个demo，您需要在On-Premise系统使用事务码/iwfnd/maint_service，为EPM_REF_APPS_SHOP_SRV这个标准的OData服务指定一个后台系统。在我下图的例子里，该服务的后台实现系统我指定成了AG3。
该url里的my-backend:80会被Cloud Connector替换成实际的On-Premise系统的地址并发送到On-Premise系统去。
要获取更多Jerry的原创技术文章，请关注公众号"汪子熙"或者扫描下面二维码:
