I am developing an application using SAP Hana studio and I am confused on why I would use XSODATA and why I would use XSJS. Why can't I just use a XSODATA file to perform all of my database transactions? I get XSJS is server-side, but if I am doing basic CRUD operations could I just use XSODATA?
A related question, would the XSODATA file be create in SAP Hana studio and work fine from there? The reason I ask is because before I had to create a service in Gateway service builder and provide the URL to the application to access it. But now I am assuming everything is done on hana studio and there's no need to do anything beside this.
For CRUD operations XSOData would be ideal when you are on HANA. Since XSOData implements the OData protocol, most of the heavy lifting is done by the underlying XS Engine. So once you provide the service definition you can expect everything to work out of the box. You also get the feature set of OData v2.0.
However with XSJS, you will have to implement all CRUD operations. This can be useful for complicated scenarios like when you are trying to send/recieve data from external services, identifying session users, running some dynamic sql, file upload, emails and the like. If XSOData does not fulfill you needs in such cases, XSJS is the way to go.
Also, if you are developing UI5 applications, XSOData is a better choice as it will be much easier to use OData services in UI5 compared to other REST services like XSJS.
You are right. If all you need is CRUDQ on the database, then XSODATA is the way to go. XSJS should be used for non-CRUD operations (e.g. custom processing operations, file uploads, etc).
And yes, you can create it directly in the HANA studio or in the Web Based Workbench. The Gateway is used when you have a Netweaver system (not necessarily a HANA system) and you want to expose some business entities from there. They are two distinct technologies (Netweaver vs HANA XS Classic) with different usage scenarios (albeit you can combine them in some cases).
Related
We are using EasyNetQ(RabbitMQ) with a data layer that uses EF6.1
We are developing a WPF client that will request data via the Message Bus. We would love to be able to use Breeze.Sharp to manage the data on the client but the only DataServices that are currently available are for WebApi/web(HttpClient) services.
Is it possible to introduce an interface so that we can provide a custom DataService that will communicate with the EasyNetQ message bus?
This is absolutely possible, the breeze.sharp product is intended to be able to talk to all of the same data services that our breeze.js product does.
Take a look at the breeze.dataService.mongo adapter ( part of the breeze.js product). It is used to talk to a mongoDB database running on Node with Express. ( i.e. no WebApi and actually no .NET on the server at all. )
That said, we have not yet built other adapters for the breeze.sharp product, although we plan to, as well as provide documentation on how to do this yourself. No timeframes yet unfortunately, we have a lot on our plate.
Another alternative to waiting, is to contact breeze#ideablade.com to build the adapter for you.
Need pointers on how to make a data provider/service ADO-compatible. This requirement is quite similar to how we use classic ado to query an LDAP server (active directory). Here is an e.g. of the same --> http://www.4guysfromrolla.com/webtech/041800-1.shtm
However the stuff I am expecting this provider would do is, actually talk to a WCF service underneath, and somehow generate a recordset for downstream consumption.
If you're looking to make the data you are extracting available via an ADO interface, you might take a look at the article here - its a bit dated, but I suspect the basic concepts are still valid.
ADO Providers
I am building a new applications architecture and I need your advice. We have a central MSSQL server database hosted as SQL Azure. This database needs to be accessed from many different applications, most of them are web applications hosted in windows azure and couple of them are winforms apps.
Accessing database for web application is straight forward with ADO.Net. For winforms applications, the wcf data services technology seems impressive along with client authentication services for security.
I need to know whether this mixed mode of database access will work? In other words, will database integrity will be maintained if it is being hit by applications using a mix of ADO.Net and Entity framework.
Thanks in advance.
If you query the database using EntityFramework it will cache the data until you call SaveChanges(). If the database is modified (e.g. using plain old ADO.NET) in the meantime there is a risk of the data from the database being overriden by the application that is using Entity Framework. To prevent from this you need to use Concurrency Token. You can find some details here: http://social.technet.microsoft.com/wiki/contents/articles/3866.aspx
Note that when you start using concurrency tokens you need to be aware of possible concurrency exceptions which you need to handle. You can take a look at this blog post http://blogs.msdn.com/b/rickandy/archive/2011/02/17/handling-optimistic-concurrency-exception-with-ef-and-mvc-3.aspx for some ideas. WCF Data Services uses ETags for concurrency (http://blogs.msdn.com/b/astoriateam/archive/2008/04/22/optimistic-concurrency-data-services.aspx) but you may not need to do anything here if you setup concurrency in the EF model for the database that is exposed via WCF Data Services.
We are going with WCF RIA services. They seem to work well with multiple client types providing out of the box data access layer.
I'm looking at leveraging an existing Microsoft SQL Server Analysis Service (SSAS) instance for a reporting project. The goal is to have the data compiled in SSAS, then a web front-end that allows the user change time-periods, while building graphics (using D3 or the like).
Google has not been my friend in finding a solution for this...
Is there a gem or other way to connect SSAS to a Rails front-end?
Thanks
JSON, no, not that I know of. However if you are willing to use XML, then yes. XMLA (documented here) is the client API language for SSAS.
One approach would be to build a web service with .NET, and then have your Rails front-end call the web service.
I suppose you could use XMLA directly, but it's painful.
Say I have the following model
I would like to present a unified front for these OData feeds to my clients.
Is there a nice way with OData to do this? Or should I just take IQueryables from the OData feeds and make a reflection endpoint on top of these?
If I use the reflection stuff on top of the OData that talks to the database (via Entity Framework) what kind of problems am I going to encounter?
I would not use the reflection provider over the client library, mainly because the client library LINQ provider doesn't support all the constructs used by the server. As a result some queries would simply not work at all (projections and expansions usually get broken).
Assuming you don't want to create any associations between the databases, you should be able to simply point the users at the right service. You can still expose something which looks like a unified endpoint without the need of having the same URL for all of them.
The main idea is that you unify the $metadata (if your model is static you can do this manually, if not you should be able to write some kind of "merge" tool pretty easily) and then provide a service document which points to the respective URLs for each entity set. In the WCF Data Services client, there's now support for these kind of services through entity set resolver: http://blogs.msdn.com/b/astoriateam/archive/2010/11/29/entity-set-resolver.aspx
The latest CTP with that support is here: http://blogs.msdn.com/b/astoriateam/archive/2011/06/30/announcing-wcf-data-services-june-2011-ctp-for-net4-amp-sl4.aspx
Not happy with the current accepted answer for this question, for me it's more of an anti-answer, of what not to do. My solution here applies as much today as it did in '11
To support a tenancy scenario, where each user/client data will always reside on the same Database, and the data schemas all match then all you need to do is change the connection string when the data context is instantiated.
Another term for this concept is Sharding, MS have some tools and APIs that can help, This is a simple enough walkthrough: Azure SQL Database Elastic database tools: Shard Elasticity but you can do this pretty easily from first principals.
If swapping out the connection string will work for your scenario we need to identify the mechanism that you will use to determine the connection string, there are two common solutions to this:
The simple way out is to use fixed host headers, a route or token in each request to the service, then you can hardcode the logic for determining the connection string without complicated mapping logic.
Use a master / header / mapping DB to store your configuration.
This database has a separate schema that's primary purpose is for retrieving the correct connection string for each request.
In most cases we combine this with the Authentication process, in which case
you keep the authentication in this central database, not in the individual databases.
In terms of the OData Controller, even with WCF Data Services, you just need to implement your logic for retrieving the connection string and use that when you instantiate your data context.
Of course, this doesn't help you if your client's data is spread across multiple databases, but it is a pretty common pattern for sclaing out large databases withough having to deploy a new farm of services for each database.