Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 
A New Home in the New Year for SAP Community!

SAP Developer Challenge - Full-Stack - Back-end Development – API Exposure (Week 2)


Welcome to the second week of this month’s SAP Developer Challenge. If you have not yet read the initial blog post, please do so and complete the first week’s task as we will build upon it. 

Task Description 

With a robust back-end architecture and initial data records in place, we proceed to automatically update our models with data. In week one, we modeled our database and manually added records to our entities using csv files.  

We now want to implement an API endpoint that will allow a user to provide the number of questions they wish to associate with a test, from the browser. We will then process that by selecting the given number of questions (yet to be associated with a test) from our currently existing questions model and associate/link them to a test automatically.  

Note: A question cannot be used in more than one test. 

Below is a process flow diagram of the API endpoint to be implemented: 

Api endpoint process flow(2).png

Task Outline 

Our goal is to implement an API layer that will later connect our back-end to the front-end. After implementation, we need to expose the API to allow front-end components seamlessly access it.  

What is an action? 

An action can be defined as an operation to be performed on one or several entities within a service, which allows for definition of custom behavior or functionality based on the business rules. There are two main types of actions in OData: Bound and Unbound 

Difference between bound and unbound actions 

Bound actions are associated with a specific entity type and can only be invoked on instances of that entity type. Unbound actions on the other hand are not tied to any specific entity type and can be invoked independently on any particular entity instance. Unbound actions are mostly used to perform operations that do not require a specific entity context. 

We are therefore interested in a bound action as we would like to perform operations related to the Tests entity instance.  



  1. In the srv directory, create a file named cat-service.js. Copy the following lines of code and paste them in the file: 




const cds = require('@sap/cds') 

module.exports = class DevChallengeService extends cds.ApplicationService { 
    init() { 
        return super.init() 

    // TODO: Implement the bound action: assignQuestionsToTest  




   2. Implement a bound action named assignQuestionsToTest in the cat-service.js file we just created. This action should contain the logic explained and illustrated in the API endpoint Process Flow diagram above.   

    Note: the questionsCount value is passed as a parameter to the assignQuestionsToTest action. 

  3. In the action implementation, return a string with the message you want conveyed to the user based on the result of the action execution. Example: “2 questions successfully added to the test”. 

 4. Define the bound action - assignQuestionsToTest in srv/cat-service.cds file. 



Bound vs Unbound 

Read more on bound and unbound actions ( Invoking an Action) 

Modeling in CDS 

Querying in JavaScript


Task Checklist – post screenshot in the reply section 

Create a file named test.http in the root directory of our project. Copy and paste the following code that will enable you to make an API call. Feel free to use other tools to test the endpoint. 

Replace YOUR_TEST_ID in the link with one of the test IDs you manually populated in week 1. 




POST http://localhost:4004/dev-challenge/Tests(ID=YOUR_TEST_ID,IsActiveEntity=true)/DevChallengeService.assignQuestionsToTest 
Content-Type: application/json 





Click on Send Request to make a call to the implemented endpoint. The response should return a HTTP 200 status code with a message (the message can vary depending on the number of questions requested, the state of your data and validation status). 






Galactic 3
Galactic 3


This blog post helped a lot on how to do select and update,

I think you guys should have provide more resources honestly, for someone that never did something like this, I still don't know how to return an error if I wanted instead of a string like in that blog post.

If you want to return an error instead of the message:


        if (!questionsCount || questionsCount < 1){
            throw new Error(`You asked for zero questions. Nothing to do.`)

You ask a valuable question about throwing the error.  Just this little change in handler code (throwing instead of returning the message) will later impact the UI.  Returning a message will result in an informational dialog:


Whereas throwing the message as an error will result in an error dialog on the frontend. 



0 Kudos

Really cool! 🤘 Thanks

0 Kudos

well I am  using req.reject() to return error. Will that also have the similar impact on UI ??

Yes that will result in the same. req.reject (or req.error) Events and Requests | CAPire ( - will result in the error dialog in the Fiori UI as well.  When you throw any error from within a handler the CAP framework will catch that and build the request for you the same as directly calling req.reject or req.error. 

If you inhert from cds.Service or cds.ApplicationService you can directly hook your handlers without having the the whole this.on... construct.  Then you don't use the req... calls but just throw or return the results. 
Events and Requests | CAPire (


Data Setup : 5 Q's available for assignment


Linking - 3 Q's


Trying to Link 3 more Q's


Again, trying to add 3 Q's






Galactic 2
Galactic 2

Galactic 3
Galactic 3

Galactic 2
Galactic 2

Galactic 2
Galactic 2

Hi Dinah, my submission for week 2.







Galactic 1
Galactic 1

1. negative Test: Test not found


2. negative Test: invalid input


3. negative Test: no request covered, no free Questions left


4. positive Test: all requests covered


5. positive Test: requests partially covered



Galactic 2
Galactic 2

Galactic 2
Galactic 2