05. Unbound actions

Adding another action

Let's create a second file with the name on-promoteCustomer.js in the folder srv/ProcesorService/Incidents.

It should look like this:

module.exports = async function (req) {

    await this.update('CustomersProjection').with({ status: 'Gold' }).where({ ID: req.data.Customer_ID })

    await this.update('Incidents').with({ urgency_code: 'H' }).where({ 
        customer_ID: req.data.Customer_ID,
        and : { not: { status_code: 'C' } }
    })

}

What are we doing here?

Our first action was entity bound, meaning there is no req.data available. The target entity is encoded within the (OData) parameters of the request, explaining why we used req.subject to manipulate the action target directly. In a collection bound entity, we now have real input parameters, which are part of req.data. Unbound actions operate also like this.

Our first update statement utilizes the helper view we created in Exercise 3, in order to update the Customers Entity. In addition, we also need to update all incidents for this customer to status high, which happens in the second statement. You can observe, how we construct a more complex where-clause here to not update already closed incidents.

Please note, how we use unqualified entity names in these statements. In CDS-Oyster, the QL is limited only to service entities of the service the handler was registered to. Calls to database entities or to other services will be blocked. Also, authorization is enforced with the user of the request being passed to the query context.

Note

If you get an error message 'Can't modify a closed incident!' then you forgot to switch the cloned Incidents to the reCAP25 branch. Simply check out the branch, or modifiy srv/processor-service.js to include the line if (!req.subject.ref?.where) return at the beginning of the before update handler

Playing around

You can try to modify your queries to see how the QL limitations are enforced. Changing the update statement of the first query e.g. to Customers (auto-exposed, read-only entity) or AdminService.Customers (entity outside of service) or sap.capire.incidents.Customers (database entity) should give different errors. You could also use console.log to dump environment variables like req.data, instead of employing the debugger.

In the Sixth exercise — CRUD event handlers, we dig a bit deeper into what is possible