来自sapcloud平台中的neo环境，所谓的目的地支持在运行时代理HTTP请求。这不仅满足了基于浏览器的场景中的CORS需求，还允许从本地系统查询SAPCP应用程序中的数据。尽管在sapcpccloudfoundry（cf）环境中，目的地的名称是相同的，但它的用法是完全不同的。让我们详细说明一下。

目的地在混合应用程序体系结构中具有重要价值，云应用程序希望通过云连接器从本地系统检索数据。

在neo中，调用

将在中配置的服务器上执行proxy/path/to/resource（可以是本地系统！）运行的应用程序https://myapp-4711.dispatcher.hana.ondemand.com–代理请求完全满足CORS要求的非常方便的方法。

在cf中实现这一点，有必要

创建目的地（子帐户级别）创建目标实例（空间级别）创建连接实例（空间级别）创建一个xsuaa实例（空间级）

然后，连接实例作为一个通用的反向代理，计算机大数据，作为目的地实例，人工智能知识体系，只不过是一个组织代理目标（包括本地系统）的目录。

xsuaa实例作为凭证授权，企业大数据分析，发布JWT（通过`oauth2.0）以允许

查询目标实例中的条目使用反向代理（aka connectivity instance）实际代理请求

那么在cf中：

？

有两个主要的博客/教程描述了如何在nodejs中使用目的地/连接：

https://blogs.sap.com/2018/10/08/using-the-destination-service-in-the-cloud-foundry-environment/很好地概述了整个过程，但没有使用实际的代理来查询资源https://blogs.sap.com/2018/10/16/call-sap-cloud-platform-cloud-foundry-destinations-from-your-node.js-application很好地解释了命令行cf以及服务、绑定和实例的概念，但也没有提到任何代理，很难重用

剧透警报这就是为什么我将整个过程包装在一个节点模块sap cf destination（super alpha pre release，yada yada）中的原因。

我冒昧地阅读了参考Java实施地点https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/313b215066a8400db461b311ebd99b.html并将其移植到一个可重用的JavaScript节点模块中。

总体用法（以下代码均为风味洋泾浜代码）：

引擎盖下，大数据，OAuth 2.0客户机用于从连接实例和目标实例检索令牌，企业开发软件，并封装在一个承诺中：

使用cf代理是通过npm请求承诺http客户机模块完成的：

代码结束于https://github.com/vobu/sap-cf-destination.git–欢迎合作！

当然，它有"Geschmäckle"的"为什么SAP不提供这个呢？！"–但是，嘿，@SAPCP，你永远不知道谁会做出贡献，对吧。正确的？！？