cancel
Showing results for 
Search instead for 
Did you mean: 

Unsubscribing CAP application deletes tables created by other CAP application in the same container

lokesh_malik
Advisor
Advisor
0 Kudos
476

Your environment (run the following commands):

  • cds -v
  • @sap/cds: 5.6.4

    @sap/cds-compiler: 2.10.4

    @sap/cds-dk: 4.7.2

    @sap/cds-foss: 3.0.0

    @sap/cds-mtx: 2.5.1

    @sap/xssec: 3.2.11

    Node.js: v16.13.0

  • node -v

v16.13.0

  • java -version (if applicable)

Steps to reproduce:

I have created few CAP application which are subscribed by tenant. On first CAP application subscription, the DT and RT HDI containers and schema are created. Post that if I subscribe other CAP application then no new HDI container created. The CAP application uses the same HDI container and generates tables in same schema.

Now the issue is, if tenant unsubscribe any of CAP application then HDI container is also deleted and schema/ tables created by other CAP application is also deleted.

Does CAP framework not verify, if HDI container is shared by multiple CAP application?

Do We need to handle it in unsubscribe event?

Additional information (if applicable):

  • project files
  • logs
  • screenshots
  • ...

Accepted Solutions (0)

Answers (1)

Answers (1)

eckart_liemke
Advisor
Advisor
0 Kudos

Hi Lokesh,

by default, unsubscribing a tenant removes the container(s) that have been created on subscription.

Using a container for two applications is anyway dangerous as you have to make sure that you do not accidentally remove tables when updating the database tables of one of applications.

If you want to avoid the deletion of the containers, you can overwrite the 'DELETE' event of the handler for tenant subscription. See also https://pages.github.tools.sap/cap/docs/guides/deployment/as-saas#event-handlers-for-cds-mtx-apis .

Best regards,

Eckart

lokesh_malik
Advisor
Advisor
0 Kudos

Hi Eckart

Thanks for your comment. On subscribing, CAP applications are not creating separate container and using the already created container. We have not added any custom logic here. It is the default behaviour.

Is it because of same hana db schema provided in CAP application deployment yaml?

I will verify the delete event as you have mentioned.

Thanks and Regards,

Lokesh

eckart_liemke
Advisor
Advisor
0 Kudos

Hi Lokesh,

sorry for the delay.

If more than one application have a binding to the same service-manager service instance, the applications are all sharing the same containers for each tenant.

Unless intended (with the consequences outlined in my last comment), it is recommended to use a different service-manger service instance per application.

Regards,

Eckart

lokesh_malik
Advisor
Advisor
0 Kudos

Hi Eckart,

Thanks for reply.

If applications are using same DB schema then would it be ok to create different service manager?

Regards,

Lokesh

eckart_liemke
Advisor
Advisor
0 Kudos

Hi Lokesh,

no. If you plan to share tenant containers between different applications, you have to bind these applications to the same service manager. With the consequences for onboarding, offboarding and deployment:

- if you do not disable the offboarding via a handler or configuration (cds.env.mtx.api.provisioning = false), each application can delete the container that is potenially still needed by the other application

- if the applications use different models, the database deployment of one application potentially deletes the deployment of the other (e. g. when using auto-undeploy).

See also https://pages.github.tools.sap/cap/docs/guides/deployment/as-saas#advanced-deployment-scenarios

If possible, it is better to avoid sharing tenant containers between applications.


Regards,

Eckart

gregorw
Active Contributor
0 Kudos

Dear Eckart,

will the resource you're pointing to also available at https://cap.cloud.sap/docs/guides/deployment/as-saas#advanced ?

Best Regards
Gregor

eckart_liemke
Advisor
Advisor
0 Kudos

Hi Gregor,

it is intended to keep this as internal documentation. We are looking for less risky and less error prone solutions.

Regards,

Eckart