Authors: Ayush Kumar , Shreya Sinha and Vipul Khullar 

Previous Blogs in this series:

• [Blog Series] Extensibility in Multi-Tenant CAP-based Application
• General Guidelines for making application extensible

This is the third blog in the blog series End-to-End extensibility in Multi-Tenant CAP-based Application.

Perquisites:

1. Have subscribed to the MTA.
2. Assigned the roles to your user
   1. Create an extension
   2. Delete the extension

Note: The names of the roles will depend on the role names provided to you in the help documentation of that specific application.

3. Already know about the allow list and blocklist
4. Aware about the namespace<need to check on this>
5. Sap cds-dk should be greater than 6.3.0 or the latest, locally in the system where we are creating the extension locally.

Now let’s look at all the possible extension scenarios possible by extending your application.

To extend the subscribed solution use the following command

cds extend <app-url>/extend -s <subdomain> --force

example :
cds extend https://fp-subs-sandbox-agricultural-origination-portal.cfapps.eu10.hana.ondemand.com/extend -s fp-subs-sandbox --force

Once you have extended the solution you will see a project structure as follows:

• Db
• node_modules
• srv
• json

Create a .cds file in DB package where all the below scenarios can be created apart from extending the service.

Sample

Extension Package Structure

Note :

1. in your extension. cds create a namespace of your choice adhering to the prefix rule of your project. This namespace will reference the newly created entities when you try to extend your service.
2. In your service extension, create a namespace that will reference any new service you are trying to create other than extending your existing service.

Scenario 1: adding a new field in the existing entity

Field Level Extension

Scenario 2: adding a new entity in the extension project

Entity Level Extension

Metadata for Entity Level Extension

Scenario 3: extending the service with the new entity

Extending the current Service

Metadata for Extended Service

Scenario 4: creating a new service for the extension project

Create a new Service

Metadata for new Service

Scenario 5: Create a composition of an existing

Adding Entity as Composition

Metadata for the above Entity

Note: Associations can also be created in a similar fashion and can be directly consumed on the UI. The only challenge with the association will be to populate the data separately, whereas, in the case of composition, we can insert, and update the data in parent-child format.

Conclusion:

This concludes the end of the blog series on creating in-app field-level, entity-level, and service-level extensions.
Let us know if you have any other thoughts on the topics and if you want us to clarify any further points related to creating such extensions.
Happy reading!