SAP Cloud SDK: Neo and Cloud Foundry in a single project

[christoffer_fuss]

Hi Experts,

we are working with SAP Cloud Platform for more than 4 years now. We have developed several JAVA applications in the Neo enviroment which are live for many customers. Therefore we used the Java Web Tomcat 8 version of the SAP Coud Platform SDK.

Now we are planing to move to the Cloud Foudry enviorment and the new SAP Cloud SDK. So I have created a new project following this tutorial for Cloud Foundry. I thought, I can publish the application on the Neo enviorment as well but there is another tutorial for the Neo enviorment.

So I have created 2 new projects to deal with both enviorments.

Is there no way to handle both enviroments in a single project? I would like to have one code basis which works on both enviormets instead of having to different applictions.

The plan is to keep our productive customers on the Neo enviorment and to bring new customers to the Cloud Foundry enviorment.

Best Regards and many thanks in advance,

Chris

[former_member270971 · Accepted solution]

Hi Chris,

seems you are solving the same problem as we did for our product (SAP Cloud for Real Estate) a bit more than a year ago. According to my experience it is not possible to run the same application in both environments, however you can encapsulate your business logic in a platform independent modules and use them in both applications.

In our case it is a classical 3 tier application (web API - services - persistence) that we did not create from SAP Cloud SDK archetypes, neither we followed the tutorials that you mention, but most likely you will be able to apply the same strategy even after you did.

So for us both applications are Spring based:

• NEO app is Spring WebMVC application that we package to a .war file and then deploy to the Tomcat 8 runtime on NEO
• CF app is Spring Boot application that we package to a self executable jar and push to CF

It is important that Spring library versions are aligned between these two and the business logic modules.

The project structure may then look as following:

• application-cf
• application-neo
• web-api
• services
• persistence

where in the latter 3 you won't have any platform specific code or dependencies. This is where SAP Cloud SDK becomes quite handy as it offers an abstract way for communicating with underlying platform. For example, to retrieve current tenant one would do the following call:

Tenant currentTenant = TenantAccessor.getCurrentTenant();

Where Tenant is a platform independent interface, so you can freely use it in you business logic modules that are included to both applications. The actual implementation of this interface will depend on the application that is executing this line of code. For example, in the pom.xml of your application-cf module you would put as a dependency:

<dependency>
    <groupId>com.sap.cloud.sdk.cloudplatform</groupId>
    <artifactId>tenant-scp-cf</artifactId>
    <version>${sap.cloud.sdk.version}</version>
</dependency>

while pom.xml of application-neo would contain:

<dependency>
    <groupId>com.sap.cloud.sdk.cloudplatform</groupId>
    <artifactId>tenant-scp-neo</artifactId>
    <version>${sap.cloud.sdk.version}</version>
</dependency>

Besides dependencies, these modules should also contain necessary @Configuration classes for Spring (at least WebConfig and RootConfig classes for NEO and SpringBootApplication class for CF).

Of course, you won't be able to eliminate all of the double maintenance effort, for example different packaging also means different CI pipelines, but at least all the coding will happen in the same project.

Hope this helps.

Regards, Ivan

[christoffer_fuss · Accepted solution]

Hi Ivan,

thank you very much. This would be a great topic for a blog bost, a tutorial or a sample github project 😉 I would really love to read more about that topic.

Can you give some details about the separation between web-api, services and persistence? We want to implement an OData Service on SCP. Therefore we use

<dependency>
   <groupId>com.sap.cloud.servicesdk.prov</groupId>
   <artifactId>odatav4</artifactId>
</dependency>

which runs in neo as well. For Cloud Foundry we could use the new CAP model. The implementation of the service is then done in the web-api project and the database accesses in the persistence project?

Best regards,

Chris

[former_member306557 · Accepted solution]

Thank you Ivan for answering. The Neo and Cloud Foundry specific modules plus common module(s) that serve both is certainly the way to go. To avoid class loading exceptions while using the SAP Cloud SDK, ensure that your common modules have only the abstract SDK modules included as dependencies. For example, if you use destinations then include cloudplatform-connectivity or cloudplatform-connectivity-scp, but not cloudplatform-connectivity-scp-cf nor cloudplatform-connectivity-scp-neo. Only the platform specific projects can include cloudplatform-connectivity-scp-cf or cloudplatform-connectivity-scp-neo.

Best regards,
Pablo