Local Development Issue Once Multi-tenancy Added

[Steven-Mason]

We are updating our applications to the latest versions of cds and cds-mtxs.  We have run into an issue that we did not seem to have with earlier version of cds-mtxs.  The issue is that once we run the command "cds add multitenancy --for production", the application no longer works locally using "cds watch".

I have recreated this issue in this public repo that has a stripped down CAP application with Fiori App.  Very little has been done on this repository.  It has a simple database schema/service projection with draft enabled.  It then has a Fiori Elements application associated with it.  I also ran the following commands against it as outlined by the CF Deployment guide in the official documentation:

cds add hana --for production
cds add xsuaa --for production
cds add mta

If you clone the main branch and run "cds watch", the application runs, you can navigate to the Fiori App, view the test data, and create new data if desired:

Running CAP serverGET from EntityRunning Fiori app

Now when we move to the next step of the deployment guide related to adding multi-tenancy, it has us run the following command:

cds add multitenancy --for production
npm install

If this is done to the repo linked earlier and "cds watch" is run, the application will no longer run locally.  Here, if you run a GET command against the lone Customers entity, you get the following error:

GET on CAP entity no longer working

As expected, the associated Fiori Elements app errors out in similar fashion:

Fiori App errors on initial loadFiori App errors on Create

To be clear, we are not trying to test multi-tenancy locally.  We want the application to run as a single-tenant application locally.  This has worked in the past when integrating "@sap/cds-mtxs", but this seems to no longer be the case.

When looking at cds.requires environment via "cds env requires" command, we see the following:

db: {
    impl: '@cap-js/sqlite',
    credentials: { url: 'db.sqlite' },
    kind: 'sqlite',
    schema_evolution: 'auto'
  }

We do not want a local "db.sqlite" database, but still want the database to run in memory locally.  To try to overcome this issue, the following was added this "development" specific config to the cds.requires section of our package.json:

  "cds": {
    "sql": {
      "native_hana_associations": false
    },
    "requires": {
      "[production]": {
        "db": "hana",
        "auth": "xsuaa",
        "multitenancy": true
      },
      "[development]": {
        "db": { "kind": "sqlite", "impl": "@cap-js/sqlite", "credentials": { "url": "memory" } },
        "multitenancy": false
      }
    },
    "profile": "with-mtx-sidecar"
  }

While this did force the database to load in memory, the issues we were witnessing persisted with the application.  What changes can I make to my application so that I can add multi-tenancy, but not run into the local dev issue I am seeing above?  All help on this would be greatly appreciated!

For reference, this is the "cds -v" output when running into the issue above:

-js/asyncapi: 1.0.2
@cap-js/cds-types: 0.6.5
@cap-js/db-service: 1.12.1
@cap-js/hana: 1.2.0
@cap-js/openapi: 1.0.5
@cap-js/sqlite: 1.7.3
@sap/cds: 8.2.3
@sap/cds-compiler: 5.2.0
@sap/cds-dk: 8.2.3
@sap/cds-dk (global): 8.2.3
@sap/cds-fiori: 1.2.7
@sap/cds-foss: 5.0.1
@sap/cds-mtxs: 2.1.0
@sap/eslint-plugin-cds: 3.0.5
Node.js: v18.20.3
cap-local-dev-issue: 1.0.0
home: /workspaces/cap-local-dev-issue/node_modules/@sap/cds

And here is my "npm ls" output:

cap-local-dev-issue@1.0.0 /workspaces/cap-local-dev-issue
├── -js/cds-types@0.6.5
├── -js/hana@1.2.0
├── -js/sqlite@1.7.3
├── /cds-dk@8.2.3
├── /cds-mtxs@2.1.0
├── /cds@8.2.3
├── /ux-specification@1.124.1
├── /xssec@4.2.4
└── express@4.21.0

[Steven-Mason · Accepted solution]

We were able to answer this issue ourselves.  In order to continue working locally in memory as a single-tenant application, all we had to do was add this to cds.requires:

"[development]": {
        "db": {
          "credentials": {
            "url": ":memory:"
          }
        }
      }

We had tried something similar before, but had the url value wrong for memory.

[KalpeshHirdekar · Accepted solution]

Hi Steven-Mason,

I have created a Multi tenant SAAS application (Non-CAP NodeJS based) and have deployed this app to SAP BTP in the Provider subaccount. Along with the application I have the saas-registry instance and xsuaa instance created in my Provider subaccount. I am also able to subscribe to this application from the Consumer subaccount.

Current Status: So far, I have successfully implemented application subscription from tenant subaccounts using the saas-registry and an xsuaa instance. I’ve also implemented the necessary logic for subscribe and unsubscribe events in the backend.

Note: This is a pure backend application, and I am not using an Approuter, as there is no frontend component involved. The application is intended to be consumed by tenant-specific backend or frontend apps via API calls.

Problems:

1. When I subscribe app in consumer subaccount, the xsuaa instance (using tenant-mode as "shared in provider subaccount) is not automatically created in consumer subaccount.
2. To address this, I added event for getting dependencies while subscribing in backend the code is shown in below picture.
3. Also added "url" for "getDependencies" in "appUrls" and dependencies detail in SaaS configuration file as shown below.
4. After these changes, I tried subscribing to the app again from the consumer subaccount got an error shown below.

Asking for Suggestions:

1. How can I achieve the automatic creation of an XSUAA instance in the consumer subaccount when subscribing to the app, to ensure full isolation between consumer subaccounts?
2. If not then how can I achieve independent OAuth 2.0 Authentication for tenants specific to their subaccount?