SAP CAP Node.js: Modify or Change OData Service (Add / Remove Entity) at Runtime

[jbibal-pdc]

Hello,

I am currently exploring the possibility of modifying / changing a CAP Node.js Service at RUNTIME using the Facade APIs such as cds.compile / cds.serve etc.

For example, given the service at DESIGN TIME:

// srv/design_time_srv.cds

@path: '/design-time-srv'<br>service MyDesignTimeService {
     @cds.persistence.skip
     entity Foo {
     // props here
     }
}

// OUTPUT:
The service MyDesignTimeService will have 1 entity Foo.

Is there any way to dynamically add / remove an entity to / from the same service, accessed through the same path at RUN TIME?

Something like:

// srv/design_time_srv.js

const { MyDesignTimeService } = cds.services;
// Create a new entity
let userEntity = `extend service MyDesignTimeService with {
                     @cds.persistence.skip
                     entity Bar {}
                 }`;

// Compile model
let cdsModel = cds.parse.cdl(userEntity);

// Serve
cds.serve(MyDesignTimeService).from(cdsModel).to('odata').at('/design-time-srv').in(cds.app).with(_srv => {
	_srv.on('READ', 'Bar', async req => {
		console.log("test")
	})
})

// DESIRED OUTPUT
The service MyDesignTimeService will now have 2 entities: Foo and Bar

Thank you,
John

[vansyckel · Accepted solution]

Hi John,

No, this is not possible in the fashion you envision, as there are several static objects that are instantiated during bootstrapping. But check out our cookbook on Extensibility.

Best,
Sebastian

[jbibal-pdc · Accepted solution]

Hi Sebastian,

Thanks for your reply.

I was actually able to achieve a somewhat "similar result" where I was able to extend the service at runtime; like adding new entities or modifying existing ones. But I unfortunately had problems with the "impl" or implementation function during cds.serve, particularly for new entities I would like to extend the service with.

So I had to switch up to the service level, rather than on an entity level; dynamically serving and deleting services instead.

But I agree that this approach should be avoided due to the sheer amount of static objects you mentioned which needs to be modified at runtime just to make it work. It was a huge pain to maintain.

Again thanks for your reply. Will accept your answer.

John