I need to know how many requests I received through odata protocol. Is there any way I can keep track of this ? I need it for analytics purpose. (using a custom tool is not allowed, but nevertheless it could be great if you can point me to some).
Thanks, Ritwik
A few options you could consider:
If you need to capture the data into your own custom format/DB hook into the WCF Data Services ProcessingPipeline (there are general events there for pre and post processing queries and data change events) - CodeProject Example
If you need your own format but for specific entities, check out the Query and Change Interceptors - MSDN
If you can use another framework and need a quick, ready to go dashboard (built into IIS) check out AppFabric Monitoring (requires some install/setup on the server) WCF Data Service and AppFabric
Related
At the moment i still only have about 2 months of experience in UI5. i developed a little sample-app, used sap gateway builder to pass my requests to sap backend.
Now my employer asked me to research the possibility to access two different backends (one sap, one nonsap) via odata from the same app. After a little reading and thinking i came to the conclusion that it would be best to access both backends from a single gateway.
Since ive already worked with sap gateway, i wonder if there is a way to access nonsap backends with sap gateway? Are the better options?
Or is my current approach complete wrong and i should think about a whole other way?
It depends on your approach and the non-sap-system:
Is the non-sap-system accesible via Webservices? Then use second data model (e.g. JSON/ODATA) within SAPUI5 by loading data via webservices after initial loadup of your application.
Is the non-sap-system connected to SAP? E.g. via RFC or another technology, then you can read data from the other system during calling your initial Gateway service and simply call your RFC function module in your method.
From my opinion you will not achieve an 'easy' way to read both via one single SAP NetWeaver Gateway.
Not sure why you would want to access a non-SAP oData service via SAP Gateway. On the other hand you may want a router of some sort so that all services are exposed on the same network location and then incoming requests are routed to the appropriate backend for action.
You may also want to "mash-up" the SAP and non-SAP services into some sort of new service. In that case maybe look to some of the API management tools like Apigee to help you achieve that.
my first question on StackOverflow, so apologies if not perfect right from the beginning ...
My question is actually two-fold:
Can I have the LightSwitch ApplicationData service (or any other internally defined Data Source) define ODATA actions on the service level or entity set/entity level? If yes, how do I do that? (I cannot find the route information in the application where I could override/add that.)
How would I consume these actions from the client side (via the built-in MS JS object model in msls or via screen/entity)? Even, if LightSwitch itself could not create/would not support actions, I would still like to know how to consume them from the client side, as we are exposing external ODATA data sources via LightSwitch to the client (and these ODATA source have actions defined).
I know I can use jaydata from the client side to consume that and execute actions on an ODATA source, but I would like to know if LightSwitch has built-in support for that.
Further information: we are using VS/LS 2013. And Silverlight is not an option, we only use the HTML client.
Thank you very much for your support and hints!
Regards, Ronald
There is nothing built-in to LightSwitch that lets you define custom OData actions on the service side or consume them from the client side. You'd need to use standard web functionality like ASP.NET's WebAPI and your favorite JavaScript OData library, like JayData.
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.
I have an existing complex website built using ASP.NET MVC, including a database backend, data layer, as well as the Web UI layer. Rebuilding this website in another language is not a feasible option.
There are some UI elements on some views (client side) which would benefit from live interactivity, involving both push and pull, so rather than implement some kind of custom long polling or websocket server in asp.net, I am looking to leverage node.js for Windows, and Socket.io.
My problem is that I need two way communication between both applications. Each user should only be able to receive data once they are authorised on the ASP.NET website, so I first need communication for this. Secondly, once certain events occur on the ASP.NET website I want to immediately push this data to the Node server, to be broadcast to specific users or groups of users. Thirdly, I would like any data sent to the node.js server to be pushed to the ASP.NET website for processing, as this is where all our business logic lies. The sole reason for adding Node.js is to have the possibility to push data directly to the client, I do not want to build any business logic into it (or as little as possible).
I would like to know what the fastest method of two-way push communication is between Node.Js and ASP.NET. The only good option I'm aware of so far is to create a special listener on a specific port on the node.js server and connect to that, but I was wondering if there's a more elegant or more efficient method? I also know that you could use a database inbetween but surely this would need to be polled and would be less efficient? Both servers will be running on the same server under a Visual Studio project.
Many thanks for any help you can provide.
I'm not an ASP.NET expert, but I think there are multiple ways you can achieve this:
1) As you said, you could make Node listen on a specific port for data and then react based on the data received (TCP)
2) You can make POST requests to Node.js (HTTP) and also send an auth-key in the process to be extra-secure. Like on 1) Node would react to the data you send.
3) Use something like Redis for pub-sub, send messages from ASP.NET (pub) and get them on the Node.js part (sub). This is even better if you want to scale your app across multiple machines etc.
The only good option I'm aware of so far is to create a special
listener on a specific port on the node.js server and connect to that,
but I was wondering if there's a more elegant or more efficient
method?
You can try to look at redis pub/sub model where ASP.NET MVC application and node.js would communicate through separate channels in order to achieve full-duplex communication. Or you can also try to use CouchDB change nofitications.
I also know that you could use a database inbetween but surely this
would need to be polled and would be less efficient?
Former techniques do not require you to poll for changes, but instead they will notify you when the changes happens or channel message arrives.
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.