Feedback
Thanks for taking a couple of minutes to give feedback, which will help me improve for next time.
Instructions
- Before doing anything else, hit the green button "Submit new issue" right now to save this issue content
- Then go through the questions and mark a single checkbox for each, to represent your answer
- Finally, in the empty comment box below this one, please describe what you liked and what you didn't like
What was your experience of SAP Build before this session?
- [x] Not much at all
- [ ] Basic knowledge
- [ ] Used it now and then
- [ ] Regular user
Did this session meet your expectations?
- [ ] Not really
- [ ] Somewhat
- [x] Mostly
Was the time allotted to each exercise enough for you to work through them?
- [ ] Not really
- [x] On the whole, yes
What did you think of the extra information, explanations and narratives in the exercises?
- [ ] Too much information
- [ ] Didn't really read it, didn't really bother me though
- [x] Found it helpful as context and background
How did you find the actual individual tasks in the exercises?
- [ ] Not relevant enough
- [ ] Hard to do
- [x] About right
- [ ] Helpful / informative
What is your feeling about SAP Build?
- [x] Still don't like it
- [ ] I'm going to investigate further
- [ ] I am suddenly a believer
- [ ] I am or will be using the SAP Build more now
If you have time, please add a comment below to write free-form what you liked and what you disliked about the session. Thanks!
The codejam was very interesting and was a good introduction of what SAP Build is, and can do.
All in all, I think SAP Build is a group of 3 stand-alone tools, with different target users. The CMS part seems quite nice, but I don't (yet) know what it would make it better than for example a CMS like Wordpress, since it requires an additional license.
The automation part was the most interesting, it resembles workflow / IFlows a lot and also has the most chance of actually being used by business users in terms of understandability. Though, I wouldn't want business users to create an additional place to look at, when analysing / debugging problems. It's already hard to analyse an issue when there is Fiori, middleware and a backend. Or a website, middleware and the backend. Also, I think these kind of developments require documentation. I also see this as a high risk of being skipped, having functional and technical IT or consultants not knowing that this hidden logic exists.
The application builder I found too difficult and tedious, where I think there was very little use of metadata exposed by OData services. For instance SAP RAP, or regular CDS generated Fiori applications would be a better way to go for developers and perhaps even for the business. It would generate the fields, instead of having to manually type case sensitive field names / mappings. For standard SAP entities, there will mostly already be a Fiori application. For other usecases with custom objects, you'd still need a developer to supply OData services.
Thank you for hosting / presenting the CodeJam. It was a nice day, with nicely presented information that was clear to understand and was fun to participate. Also it gave a good image of what SAP Build is. Well done.
Thanks @arnoterhorst-asics for your comments ... I appreciate the kind words as well as the honest appraisal of the tools.