1

The scenario is simple: I have a list of products and on frontend I create a property on the fly in the oData model ("EditMode"). I use this property only for frontend to enable/disable some input fields.

When I perform an update(POST) the gateway request faild (400-bad request) because "EditMode" is not defined on the Product entity.

How can I configure the gateway to ignore the properties that are not defined and take only what it needs from the payload?

It would be an overhead to delete this property from the oData model before sending the request, it will also affect the UI... :(

Thanks!

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
gmodrogan
  • 323
  • 5
  • 14

1 Answers1

2

I think it's a very bad approach sending properties to the server that are not part of the data model. The OData 4.0 spec says (although SAP GW is still OData 2.0):

6.2 Payload Extensibility

OData supports extensibility in the payload, according to the specific format. Regardless of the format, additional content MUST NOT be present if it needs to be understood by the receiver in order to correctly interpret the payload according to the specified OData-Version header. Thus, clients and services MUST be prepared to handle or safely ignore any content not specifically defined in the version of the payload specified by the OData-Version header.

SAP GW "handles" unexpected properties by cancelling the request and sending a bad request response back. I believe there is no option to change this behavior and it would also kind of break "OData".

I assume you are using SAPUI5 on your frontend. There are many ways how you can achieve what you actually want - I'm very sure about this. But changing the "real" data, i.e. by adding an "additional" property was never needed in my cases. One way would be to bind the editable property of your controls to something like

"{view>/editmode}"

As you can guess this is a view model, also referred to as the "view model pattern". It only means you create a JSONModel in the controller (i.e. in the onInit) and and then call

this.getView().setModel(oModel, "view");

Whenever you want to disabled/enable editing to the set of controls just call this once:

var bEditable = ...;  // true or false
//...
this.getView().getModel("view").setProperty("/editMode", bEditable);

Another option would be to have 2 different views/targets, one for editMode and one for display mode. If you want to follow the Fiori guides I think you should use this option. It's up to you...

Those options assume that you use exactly one flag to make "all" controls either editable or not.

If you you need some additional advice make sure to post some code to better illustrate your issue.

Community
  • 1
  • 1
Nabi
  • 2,536
  • 1
  • 16
  • 18
  • Thanks for the clarification. Seems I break "a little" the Fiori pattern. I will use a second target (or perhaps a modal) to let the user edit the name and description of a product. I wanted just for learning and testing to simulate edit and update of an entity. Now I know how to do it better. Cheers!! – gmodrogan Jan 26 '16 at 22:55