Hi,
I am using the CAP model to expose a bunch of entities including attachments. These attachments are physically stored in back-end ECC and so I am using handlers to redirect the stream requests to back-end oData services. As a reference I used this guide cap-media-node which works well in reading and possibly writing entities. However my requirement is for oData v2 hence I am using the cds-odata-v2-adapter-proxy to redirect v2 requests to v4.
Read scenarios work well.
When trying to create a new attachment, oData v2 just requires a POST with binary stream and slug header with the required data. The proxy now takes this POST request and fires off:
1. a POST with json payload to create what i assume is a placeholder
2. a PUT/update request with the media stream to update the entity from 1 with the binary data.
Although this works okay in principle, my specific problem is that my back-end oData is the one that will create the entity for me and generate the required keys. And to do this create on back-end i need the binary stream which I only get from point 2 above. On point 1, I can mock return a success with some random keys which will take me to step 2 but then on the final success these random keys will be returned as opposed to the keys generated by my back-end oData service. Furthermore, if step 2 fails for any reason, the overall response is still a success as step 1 was a success. This of course is a problem as the user will assume both steps where completed successfully.
Looking at the v2 proxy code, maybe this could be enhanced to take into account the PUT request response? Also as the PUT request can technically return a response, use this response payload to overwrite the original create payload? Or any other idea to get around this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.