i have built web api service which expose OData how ever it seems that currently there are problems when using Batch commands. i wanted to know if i can use BreezeJS without the Batch commands
Not easily, but doable.
In the breeze source on GitHub, take a look at the file "b00_breeze.dataService.odata.js". This is where we prepare the OData save. You can create your own dataService patterned on this one that does not do batching, but... you will lose all transaction guarantees if you do this.
If you think an 'unbatched OData save' would be useful please add a vote for it on the Breeze User Voice here ->: breezejs.uservoice.com/forums/173093-breeze-feature-suggestions
Related
I'm quite new to the Odata topic and try to understand what is the best practice scenario when working with OData service.
Sceanrio 1:
I have an complex application with several EntitySets coming from an remote Odata model, which is loaded from SAP Backend. I can read data and bind it to UI controls, thats not the problem, but what I am confused about is how I can/should write back data to the backend.
First assumption Odata is One-Way Binding:
The user manipulates inputFields , dropdowns ,tables and so on, and all data is writen to the Odata Model with createEntry() or setProperty(). Right? Or should i use another JSONModel and collect all user changes ?
Question : How do i transfer now this changes made on the Odata model to backend ? What is the best practive I have read something about batchprocessing or having an own service and trigger this one with the create() function ? Can someone just give some hints or some kind of a recipe.
Sceanrio 2:
Odata in Two-Way Binding ?
How does that work ? Which prerequisite must the backend provide in the OdataServices ? I read something that it's experimental.
YOu see I'm quite a little bit confused.
It's important to know what you will be getting if you use one-way or two-way binding. None of these binding actually involve writing data back to the back-end OData service.
In short:
One-way binding means that the model (e.g. ODataModel) only keeps your UI controls in sync. Changes made to the model, will also be cascaded to the UI controls bound to the model. However, when you change values in your UI controls, the updated value will not automatically be written back to the model.
Two-way binding means that the model keeps your UI in sync (similar to one-way binding), but on top of that, changes in your UI controls will also cascade back to the model. Two-way binding
In the one-way model, you would indeed need to programmatically update the model using createEntry and setProperty methods. Using two-way binding, this will be done automatically for you.
If you want changes to your model to be written back to your OData service on the server, you could run the 'submitChanges' method. This method will look at all changes made in the ODataModel and will send corresponding OData requests to the server to synchronise the changes with the back-end.
To make sure this is done in a consistent fashion, the ODataModel will wrap the required changes into a so-called change-set. The back-end then knows which requests belong together and will be able to roll-back all changes in a change-set whenever one of the changes fails. In ABAP you would call this a logical unit of work (LUW).
Because it may be necessary to send multiple requests to the server (e.g. if the change set change multiple entities), the ODataModel (v2) groups as many requests as possible in one batch. When this is switched on (which is the default), only one request is sent to the server instead of multiple requests, which increases performance. It would be advisable to only switch batching off for debugging purposes.
Please note that two way binding in sap.ui.model.odata.ODataModel used to be experimental, but please don't use that class anymore as it's old. Use sap.ui.model.odata.v2.ODataModel instead, as it is way better and supports lots more OData features (such as batches and two-way binding).
That's actually multiple answers in one, but I hope it clarifies some of the confusion.
I am using Breeze JS and would like to implement a server with full CRUD functionality using Progress Openedge. The Breeze website talks a lot about being able to write your own server implementation but I can find no information describing the format of a save bundle that Breeze sends to the server. Does anyone know of any documentation or schema?
The documentation for this is buried in the DataServiceAdapters page. Look about halfway down, under the heading saveChanges (saveContext, saveBundle) -> promise.
There's an example of what the JSON looks like in this SO answer.
The SaveBundle is not documented for a very good reason: it has no definition in BreezeJS!
It could be any serialized object that your server requires to satisfy yoursaveChanges work flow. You can see that this is true by examining the a60_abstractDataServiceAdapter.js source in github:
proto._prepareSaveBundle = function (/*saveContext, saveBundle*/) {
...
throw new Error("Need a concrete implementation of _prepareSaveBundle");
};
Breeze does ship with an implementation b00_breeze.dataService.webApi that satisfies the expectations of the companion Breeze ASP.NET Web API helper classes such as ContextProvider. This implementation is worth studying if you decide to write your own server support code.
But it is only one of many possible implementations. An OData web server, for example, requires an entirely different package and format for "$batch" change-set saves. Only you know what's right for your "Progress Openedge" server.
All that said, we do delve into some critical aspects of the SaveBundle destined for Breeze Web API services in the documentation for "ContextProvider".
Feel free to follow-up with more specific questions after you've read that.
Im new to breeze js, I understand that breeze has it's own query language related to OData
But I am trying to get breeze js working with a custom query language, as an example FIQL is
one of the form to make queries to backend, can we get breeze run with this type of query language.
Overview of FIQL :-
http://jaxenter.com/tutorial-smarter-search-with-fiql-and-apache-cxf-46876.html
(this is not a technical answer, at the very most it's an advice)
As mentionned from their website documentation :
Today, out of the box, the Breeze product ships with adapters for the
ASP.NET Web API and for OData. It also ships with .NET components that
interface with the Entity Framework and that generate Breeze metadata
from an Entity Framework model; that EF model could be developed code
first or database first. The Breeze client is in no way limited to
these technologies; they are merely the first backend components
available; we’d be thrilled to help you adapt Breeze to your preferred
server stack.
First question is whether
1) you want breeze to actually create FICL queries on the client and send them to a FICL service. This involves translating a client side breeze EntityQuery into FICL url syntax. If so you would need to create a new a 'uriBuilder' adapter.
2) you want to translate a breeze query already sent to your service into FIQL syntax on the server so that you can further refine the query and then send it on to your FICL service. If so you would need to create a breeze DataService endpoint.
Both of these are certainly possible.
If you are looking at the 1st option, take a look at the 'b000_uriBuilder.xxx' files in the breeze GitHub repo under the 'src' directory. There should be two 'uriBuilder.xxx' files, one which translates an EntityQuery into OData syntax and another that translates the EntityQuery into a new 'json' query syntax. There is also additional information on this 2nd syntax here:
http://www.getbreezenow.com/documentation/query-using-json
Both of these 'uriBuilder's make use an internal 'visitor' framework that we have not yet documented but should be reasonably understandable by looking at the source.
If you are looking at the 2nd option, I would recommend looking at the link mentioned above and then taking a look at the 'breeze.node.js' repo and the 'breeze-sequelize' subdir within it. In this repo we take a serialized server side breeze EntityQuery and translate it into a 'Node' Sequelize query that we can apply to a variety of backends.
Another option is to contact our professional services arm, at breeze#ideablade.com and ask them to assist in building the adapters for you or to ask for more detailed technical help.
I'm looking for a starting point on how to extend BreezeJS (or if it's even possible!) to support sending JSON data using the Badgerfish notation to the server from BreezeJS.
I see that BreezeJS has the JsonResultsAdapter - to take a response from the server and transform it - which would work to allow Breeze to walk through a Badgerfish JSON result set and instantiate entities.
I need the other way - a JsonRequestAdapter (or something like it) - to take the JSON that Breeze has created and about to send to the server, and modify to the Badgerfish notation.
Any guidance for this problem? thanks!
Update: June 2013
I've gone with the approach of implementing a custom Breeze DataService adapter that I pass into an EntityManager instance. This approach is not for the faint of heart to be honest, and took some work to really understand what needed to happen. I took the provided Web API DataService adapter and 'adapted' it to work for a generic RESTful service.
Adam, this is a great question.
We are trying to come up with a standard mechanism analagous to the 'JsonResultsAdapter' to be used to intecept http 'puts' but really want to understand the most common use cases first. We'd love any feedback on suggestions and use cases.
Please add a 'feature request' for this to the Breeze User Voice. We take these suggestions very seriously and this is a topic that we think is important as well, but really want to get some feedback from our community on its priority.
I'm very new with breezejs and having a few questions.
I think that breezejs has very nice features so I can replace my own datacontext. However, I don't want breezejs to interact directly with the dbcontext layer. In fact, in my application, the Service layer only exposes ViewModels - not even the real Business models - to the Controllers . So i'm not so sure whether I can use Breeze or not, since in few Breeze's examples, I only saw Breeze interact directly with DBContext.
Thanks.
=========================================
Thanks Ward for the answer,
About the features that I like from Breeze is that it will help to reduce a lot of time to build my own client-side view models. And to build a SPA, maintaining client-side view models is really painful for me, especially my application have desktop app client and other hand-held device's apps as well. Also, to handle the mapping from a JSon object to Knockout - which means with each view models, I will need a mapper as well.
Currently, my architecture is like this:
Server-side:
Repository layer <=> Service layer <=> Controllers (with the Web API that exposes to Client-side)
Controllers only can get the data (in format of a View Model) by sending request through Service.
So, my question is whether it is possible to make use of Breeze to query and also its integration with knockout.
Breeze never works directly with your DbContext; it works with the service model that you expose through endpoints on your service (e.g., Web API controller methods). But you certainly get the most value from Breeze when the client can query and save entities that are structurally the same as entities on the server.
You can retrieve ViewModels with Breeze - you can call almost any HTTP service method with Breeze. It's not clear to me how Breeze would help you manage those ViewModels on the client once you had retrieved them.
What features of Breeze seem "very nice" to you? Your answer to that question will help you determine if Breeze can be helpful with your preferred architectural style.
Querying data through Breeze without API controllers using DBContext directly should be no problem, saving might be harder but still manageable. I think the most complicated part is to get metadata to the client.
According to this SO answer, samples for exposing metadata from other sources that DBContext directly should be out in a week or so.
Meanwhile, check BreezeJS spa-template sample as there is repository pattern involved on the server side which makes it similar to your data access setup.