on 05-01-2012 11:19 AM
Hi,
I can find methods in the API's for create_deep_entity via POST, get_expanded_entityset for QUERY and get_expanded_entity for READ.
But I cannot find method update_deep_entity or something like this in any classes or interfaces. Is this correct?
Br,
Claus.
Hi Claus,
The odata specification does not support a deep update...strange I know, but there are some technical reasons for it. I'll let me development colleagues chime in on that one. That said, in SP4 (due out mid-May) we will support $batch which will allow for similar functionality. For now I suggest you read this info about $batch from the odata website:
http://www.odata.org/documentation/batch
Cheers,
Jeff
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Claus,
currently (as of SP3) you can not easily do an update to multiple line items and the sales header. That said, I have seen it done where a string is used to pass an XML representation of the line items...this works fine but requires more development.
That said, in SP4 with the Batch command you will be able to do this scenario.
Just to reiterate what I said above, the reason for Gateway not having a Deep Update is due to the OData standard.
SP4 is due out in Mid May if all goes well.
Cheers,
Jeff
Any update on UPDATE multiple line items for sales order? If you have any documentation that would really help. I could not find anything under
http://www.odata.org/documentation/batch
I tried updating both header & Item together and it gets updated together but only with single item. The Inline does not support for update but in Create.
Any help is highly appreciated.
Thanks,
Hello Joby,
You can update the item level details of a sales order with BATCH operation.
We cannot update multiple line items of a sales order in a single operation/body like how we fire our create_deep_entity. We cannot update like how we fire deep entity.
We need to fire multiple operations i.e., multiple update operations for a particular sales order in batch mode in a single request
Regards,
Ashwin
Well hi there,
It's over a year later and this method still has not been implemented.
Any updates?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Uwe,
I have a scenario.
I have a UI5 application, where user is given a grid like interface to update multiple line items. (Editing inside Grid). So I would like to update multiple line items in this case in addition to header.
I have seen a Fiori application, where this is done by a regular POST. (Not PUT) . If the record already exists then header and children are updated, else created.
regards
Krishna
Maybe they are using the batch function?
Or they use a flat string (XML with all items) -> but this is not OData, just a workaround
As far as I know (correct me if I'm wrong) with the OData standard it's still not possible to change multiple line (deep update) and therefore SAP will not implement this function into GW.
Yeah....I agree.
When SAP says that all its UI is converging towards FIori, then I guess we need something more than just OData. What do you think? Scenarios like this are very common.
I have started working with FIori, and see that FIori Apps are using OData/REST workarounds very often. I do not think it is limitation of the Fiori Developer, rather wanting to stick with OData at all costs including workarounds.
I don't think we need those deep updates and even deep inserts for that matter. In modern interfaces, including the ones built with UI5, I would recommend leaving the paradigm of only transferring data to the server when the user presses the save button. Instead, I think you should save as you type, and send updates to the server e.g. line by line. If there is still a need for a save button in your order form, it would be merely a confirmation or "commit" if you like.
When you build your applications this way, your users will love you. No more lost work when the browser (or something else) crashes after entering all those lines. Just fall back on the auto saved order that was progressively saved for them.
Just my $0.02.
Cheers,
Jan
I would love to have an UI like that but not convinced if that would work in all scenarios.
For example:
- I actually have a use case where Sales Order items is a hierarchy and we have a drag and drop feature planned to rearrange the hierarchy. That action would result in changing more than one items' hierarchy at a time.
- There is a feature to select more than one order items and update any of vendor/shipping-address/requested-delivery-date for all of them.
On the other note, Save button cannot be used for 'Commit' since each of these update calls will be stateless.
The examples you mentioned, are typical use cases of custom functions. I would use a custom function to perform the data transformation server side instead of pulling the entire order to the client, transforming it there and pushing it back again.
I think you misunderstood me when it came down to the save button. With the commit I wasn't referring to a database type commit, but to a functional commit. Perhaps "confirm" would be a better word.
Best,
Jan
Interesting thought. I currently have such a requirement. Currently I have used a deep insert as a deep update. (enhanced SAP's My quotation service)
How would you model such a "custom function"? or how would the URI look like?
Let us take example of: Updating 7 out of 10 Sales Order items with a new Shipping address.
Also, on another note, what would 'confirm' button do?
Both of these can be accomplished by $batch, so why subvert the protocol by doing it a non-standard way? Use the tools provided, even if it is a pain at times.
I agree with Jan, the whole "deep update" idea needs to go away, it's wrong thinking. OData is based on http, wherein you cannot navigate to more than one single entity at a time; the best you can manage is a collection of that entity. If you want associated entities or collections, you need to navigate to them too, probably collecting information along the way. So it seems long-winded because we are used to data contexts that are tightly coupled to the server. However anyone who has used WDA or similar that uses contexts will know how much bloody coding is needed to access a simple attribute In that context, batching is not really makiig life any harder, it's just relocating the load.
Trying to emulate another design paradigm is wrong - learn to do it with the current paradigm.
User | Count |
---|---|
84 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.