SAP CAP - Setting up Multitenancy & using Extensibility for API directory

[phips]

We are using SAP CAP (node.js) in the Business Application Studio and Cloud Foundry environment and would like to implement some kind of api/middleware. The most important features for our project are multitenancy and extensibility, which should be very similar to the example-project https://cap.cloud.sap/docs/get-started/samples#btp-saas-app - our main focus is on the API folder.

When setting up multitenancy according to the official documentation, the sidecar folder (mtx/sidecar) is auto-generated, but in the example-project this directory is missing / not being used - there is no explanation why.

Which is the correct way to implement multitenancy?

According to the btp-saas-app-sample there is no sidecar-directory used - according to the documentation you should use sidecar-directory.

Is there a way to use Extensibility in API directory?

In ui-directory you can use the extensibility-features, can you also use them in api-directory?

According to the known issues "Extensibility has been temporarily disabled for the CAP API Service".

How to use Hybrid Debug for a specific tenant in multitenancy?

Is there a way to do hybrid debugging using VS Code Debugger and Swagger as a single tenant in the multitenancy scenario? We would like to test specific api-endpoints for different tenants.

Thanks in advance.

[alperdedeoglu]

Hello @phips ,
SusaaS core contributor here 👋. Thank you very much for your interest in the repository!
Not using mtx/sidecar as a separate app was a design decision we took when we started developing the SusaaS sample.

The reason is, since it is not a big app, we did not need a separate application for just provisioning. There were 5-6 tenants expected for that application from the partner in a year. Since the application data model was not so big we did not have another workload under mtx/sidecar.

Which is the correct way to implement multitenancy?

If you want to have independent scalability, if you have a big data model and a complex application, I would strongly recommend to use the sidecar approach.
Otherwise, you can embed the sidecar into your main application, that was what we did for a smaller footprint.

How to use Hybrid Debug for a specific tenant in multitenancy?

You can get token on behalf of the tenant that you want to test and call the API's via client credentials. 
We also documented here the hybrid development here.

Is there a way to use Extensibility in API directory?
There was a very good reason for this from CAP side. @eckart_liemke can you please enlighten us? I do not know all the details of this.

In general if you have a feature request and bug report about the SusaaS sample, feel free to create issue on the repo, we appreciate any contribution.

[eckart_liemke]

How to use Hybrid Debug for a specific tenant in multitenancy?

Can you elaborate on that?

[eckart_liemke]

Which is the correct way to implement multitenancy?

We recommend to follow the documentation in Capire

The documentation describes using a separate sidecar for the deployment so that the main application is not affected by the load that additional subscriptions might create. As mentioned by @alperdedeoglu , you can skip it if you do not expect many subscriptions.

Is there a way to use Extensibility in API directory?

The SusaaS example implements a second microservice in the API directory that deploys its database tables to the same database container as the main application. This is possible if you can ensure that both deployments do not interfere with each other. If you can make sure that the model is consistent.

However, CAP MTXS currently has no support for "service dependent"  extensions, meaning different extensions for different applications deploying to the same database container.

In this case, this means that extensions created for the API service would be loaded for the main application as well. This could cause compile errors because the main application might not have all entities in its model that have been extended for the API service.