Develop a Full-Stack CAP Application Following SAP BTP Developer’s Guide

[js1972]

Group: https://developers.sap.com/group.cap-application-full-stack.html

Write here how you think we can improve the tutorial ...

1. cds add data adds all files into the db/data folder. It should be shown that this can be dangerous and will lead to overwrites of data in production. Should only be used for master data or config data. This tutorial should be clear and explain that any test transactional data should be moved to the test/data folder for safety.
2. Use Local Launchpad - convoluted. Is this even necessary. I don't know any developers that do this. It used to be necessary for the SAPUI5 OPA5 test library because the launchpad back button was the only way to navback. Thi sis however fixed in recent versions of sapui5 where you can access the browser back button via OPA5. So why even show this in the tutorial? The only practical use-case would be cross-app navigation when you have multiple linked sapui5 apps in the same project. FI this is the only use-case then it should be shown in this tutorial - else point to a different tutorial which shows it. Also it would be better to use this instead: cds-launchpad-plugin
3. Messy authorization config. When running cds add auth it will create the xs-security.json file without the xsappname and tenant-mode parameters. Then later in the deployment tutorial when cds add mta is run it adds the auth section to the mta-yaml file with the xsappname and tenant-mode parameters and its dodgy - because if your cf org or cf space has space characters or - characters then mbt build will fail. Best would be to move these properties to the xs-security.json file.
4. Role Collections. Why are they created manually in the BTP cockpit. We want to remove as much manual cockpit effort as possible - these role collection can be created from the xs-security.json file and this should be shown in this tutorial.
5. cds add workzone-standard did not add the title and subTitle properties to the inbound navigation in manifest.json
6. Lots of manual mta.yaml changes. This is bad. Makes the tooling look clunky and half-finished. For example - having to remove the forward slash in the odata service path. Surely that must be automated by the tooling. Manual changes to the build path: /resources as well.
7. The manual changes for the CDM to get the app into workzone standard are nasty. Surely this can be automated by the cds add workzone-standard command?

[slavipande]

Hi @js1972,

Thanks for the detailed feedback!

These are all great points, I'll bring them up for discussion with the team and get back to you.

Best regards,
Sveto

[js1972]

Hello. Another issue I have noted is that the generators used in this tutorial are placing some dev time dependencies into the deps section of the package.json. Such as:

    "@sap/eslint-plugin-ui5-jsdocs": "^2.0.8",
    "@sapui5/ts-types": "^1.131.1",

Would also be good to add logging to the tutorial which is an absolute must for any real app.

[gopalanand333]

Would also be good to add logging to the tutorial which is an absolute must for any real app.

@js1972
we have a dedicated section for logging, metrics and traces. https://github.com/SAP-samples/btp-developer-guide-cap/tree/main/documentation/observability

[slavipande]

@js1972,

With regard to your point 1 above:

1. cds add data adds all files into the db/data folder. It should be shown that this can be dangerous and will lead to overwrites of data in production. Should only be used for master data or config data. This tutorial should be clear and explain that any test transactional data should be moved to the test/data folder for safety.

• We've added a note in Step 5: Fill in test data to make clear that test files should not be deployed to prod. In addition, we are looking at ways to improve the steps of the tutorial so that test data is placed in the right folder.

We're also working on your other points and will keep updating this thread with our progress.

Thanks and regards,
Sveto