3 weeks ago
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
75 | |
9 | |
9 | |
8 | |
8 | |
7 | |
7 | |
6 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.