克里斯，你好，

似乎您在一年多以前就解决了与我们产品（SAP Cloud for Real Estate）相同的问题。 根据我的经验，不可能在两个环境中都运行相同的应用程序，但是您可以将业务逻辑封装在与平台无关的模块中，并在两个应用程序中使用它们。

在我们的案例中，这是一个经典的3层应用程序（Web API-服务-持久性），我们不是从SAP Cloud SDK原型创建的，也没有遵循您提到的教程，但是很可能您将能够应用 即使您做了同样的策略。

所以对我们来说，这两个应用程序都是基于Spring的：

• NEO应用程序是Spring WebMVC应用程序，我们将其打包为.war文件，然后在NEO上部署到Tomcat 8运行时
• CF应用程序是Spring Boot应用程序，我们打包到一个可执行的jar中并推送到CF

在这两个库和业务逻辑模块之间对齐Spring库版本很重要。

项目结构如下：

• application-cf
• application-neo
• web-api
• 服务
• 持久性

在后3个位置中，您将没有任何平台特定的代码或依赖项。 这是SAP Cloud SDK变得非常方便的地方，因为它提供了与底层平台进行通信的抽象方法。 例如，要检索当前的租户，将执行以下调用：

 Tenant currentTenant = TenantAccessor.getCurrentTenant（）; 

Tenant是平台独立的界面，因此您可以在两个应用程序都包含的业务逻辑模块中自由使用它。 该接口的实际实现将取决于执行此代码行的应用程序。 例如，在application-cf模块的pom.xml中，您可以将其作为依赖项：

 
      com.sap.cloud.sdk.cloudplatform 
      tenant-scp-cf 
      $ {sap.cloud.sdk.version} 
  

而application-neo的pom.xml将包含：

 
      com.sap.cloud.sdk.cloudplatform 
      tenant-scp-neo 
      $ {sap.cloud.sdk.version} 
  

除了依赖关系外，这些模块还应包含Spring必需的@Configuration类（对于NEO至少应包含WebConfig和RootConfig类，对于CF至少应包含SpringBootApplication类）。

当然，您将无法消除所有的双重维护工作，例如，不同的包装也意味着不同的CI管道，但至少所有编码都将在同一项目中进行。

希望这会有所帮助。

致谢，伊万

感谢伊万的回答。 Neo和Cloud Foundry特定的模块，以及同时为这两个模块提供服务的通用模块，无疑是必经之路。 为避免在使用SAP Cloud SDK时类加载异常，请确保您的通用模块仅包含抽象SDK模块作为依赖项。 例如，如果使用目的地，则包括cloudplatform-connectivity或cloudplatform-connectivity-scp，但不包括cloudplatform-connectivity-scp-cf或cloudplatform-connectivity-scp-neo。 仅特定于平台的项目可以包括cloudplatform-connectivity-scp-cf或cloudplatform-connectivity-scp-neo。

最好的问候，
巴勃罗