At our company we have a variety of microservices and web clients that make up our SaaS (software as a service) product.
When modifying the behavior of a specific service (usually written in C# WebApi). We would like to spot check the integration behavior against a client that makes calls to that service. As the developer working on a C# service locally, I would prefer not to have to clone and build that specific web client (with local settings to point to the local server) in order to see how it interacts with my local server changes. Ideally I could navigate to a deployed version of the client (develop, rc, prod) and redirect the requests that client is sending to the deployed version of my service to my local server instead.
I've attempted this with tools such as requestly. However this just results in a 307 response and the following error:
XMLHttpRequest cannot load http://localhost:59517/api/users. Response for preflight is invalid (redirect)
While we are verifying the correct behavior on the server via TDD unit tests. There are occasions where it would be nice to be able to use an already deployed client to test a local server to get a better feel for what might break in the integration tests during the automated build. Are there standard ways of doing this sort of microservice testing that does not involve local buildin/configuring of the web client?
Related
I have an API running on a Function App in Azure.
I want this API to only accept communications from two parties:
A blazor website
All copies of a piece of packaged software (a WPF application which will run on customer computers)
I want all other traffic to be rejected.
What is the best way to configure this networking scenario?
The ideal setup:
API should only be able to talk to the Blazor App as well as the client programs, not outside connections. The API can talk to the database which lays behind a virtual network. This Database VNET is already set up.
Any help is appreciated.
Use API Management in front of the API and require Ocp-Apim-Subscription-Key in the requests.
Also, add ip restrictions to avoid unauthorized access
this is my first questions on SO. Normaly I just wander the internet reading stuff until I can make up a solution.
So up until now we use HTTP Request and Response Model to communicate with Clients.
Using C# ASP.Net .Net Framework 4.0 hosted in IIS.
This way we are not able to forward information in real time to them from the server.
We would need to wait till the clients contact the server.
To solve this issue I think OWIN with SignalR V2 Middleware hosted in IIS would give us the ability to use Remote Procedure Calls, so whenever something happens that needs to be forwarded immediately to the Client, we can do so by calling that specific clients function or all clients.
For this of course the target Framework of the application needs to be .Net Framework 4.5 at least.
Now the problem I have is that in the Microsoft Documentation it says to use the IIS Express version, in order to enable the server to have more than 10 connections.
On the client side it would be no problem as ideally there would only be one connection at any given time.
But the Server should be able to have a whole lot more than just 10. As the Websocketconnections would stay open.
I am not an IIS expert, but why are there these limitations in the non Express version?
I would expect that one should be able to set the number of maximum connections despite the IIS version?
What are the gains of using IIS instead of self-hosting OWIN?
I would guess that I would need to implement some security features myself?
On my development PC a client Windows Service with SignalR V2 is able to communicate with an OWIN SignalR V2 hosted in IIS application.
At the moment I need to evaluate what needs to be considered to set this up on a server to ensure functionality.
I hope this all makes sense.
I am implementing Remote Procedure Calls in our Webservice, for real time communication with clients.
I read documentations about RPC, SignalR V2, OWIN and Katana.
At the moment I need to evaluate what needs to be considered to set this up on a server to ensure functionality.
The situation is that we have some SOAP (asmx) services that are version dependent upon a 3rd party software. These services reside on domainA.
We are in the process of migrating to a new version of the 3rd party software where the existing SOAP services will not be able to reside because of a version incompatibility. Currently the upgraded stuff lives on temp.domainA.
We are developing new services to replace the old SOAP services and will plug in wcf routing or something to save us from the next 3rd party version upgrade party.
Ideally, once temp.domainA is all ready to go we will switch that dns to be domainA and change the old domainA to be old.domainA there for breaking all existing applications referencing the soap services.
I've been fooling around with IIS and ARR matching on a common naming convention that the soap services have and trying to have those requests routed. This works very well for Get requests but not so well for POST requests which is what soap uses.
I set up a little test by having 2 identical services running, one on a test server and one on my local machine. The one on my local machine returns different data than the one on the test server so I can tell which one is being invoked.
I set up ARR's proxy in my local iis to be a reverse proxy to the service on the test server. I set up a url rewrite rule to inspect the incoming requests based on the naming convention of the soap service url.
If I browse to the soap endpoint via a browser and httpget's everything works as planned. I get a response from the remote test server with the request originating from localhost.
When I run the test app which makes the same call except as a post with soap I get this error
exception.message: There was no endpoint listening at http://localhost/webservice/Default.asmx that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
exception.InnerException: The remote server returned an error: (404) Not Found.
my settings
and then for Proxy Type i have
use url rewrite to inspect checked
enable ssl offloading checked
and reverse proxy: set to remote.test.server
The team I work with has recently migrated from a self hosted setup to IIS hosting of thier web services. The migration went 'smoothly' however we are now seeing some funny behaviour on our server.
If we make a simple request call from our client to our server to get some data from our DB everything works as expected. If we make a call from our client to our server and then the server makes a call to a 3rd party service (hosted off site) then we're seeing a massive increase in response time. A call like this used to take less than a few seconds, since migrating to IIS hosting the response time is over a few minutes.
Has anyone seen this behaviour before? Is it possible that we're having issues with credentials between the IIS hosted server and the 3rd party service?
As long as the bindings haven't changed and you are using the same service identity (i.e. Windows account) then you should get the same performance.
Have you checked whether the service is using static variables and/or multi-threading logic? You could be having resource contention problems with the proxy to the 3rd party service. You'll need to provide more detail about service to get a more specific recommendation.
I posted about this before to a degree, but after a few days of reading I have a better understanding of WCF and would like to get a bit of feedback before I start working on it.
I basically need to develop a server/client system. The "server" application (c# net console app) will be ran on a machine with a MySQL database, all software installation packages, and whatever else we need local to it. The "client" application (c# net console app) will be ran on the rest of our machines, and will maintain a direct connection to the server software. Using a web front-end, our administrators will be able to install software packages to the clients, create new services, etc.
Since we own all of the machines, and have to configure them anyways, Server Push is not a problem. We don't have to worry about firewalls or any sort of NAT settings as we can just go in and open the ports required for it to operate.
What initially confused me about WCF is I assocated a "WCF Service" with a server. However, since the majority of operations are actually going to be run on the "WCF Service", this is my logic.
1) Make the "client" application actually a "WCF Service" so that the exposed functions are actually ran on the proper machines.
2) Have the "server" application actually a "WCF Client", and issue all of the instructions/commands from here, and just use the return value to update the database/etc.
Would this be the proper method to go follow or should I look into WCF Duplex (Looked extremely confusing at first glance) or just start with raw sockets?
from what I gatther you're trying to do, you're correct. That is the client machines should really have a TCP/IP "server" running on them, and the centeral server machine would have the Tcp/IP "Client".
That way the TCP/IP client (The app running on your server machine) can initiate calls to each of the client machines.
Keep in mind also that a single application can be both a tcp/ip client and server. So your app that's running on the server machine could in turn also be a tcp/ip server that your admin uses to do stuff using a browser. Which effectively means that service is an HTTP service.
So, it is not a client/server thing. It is a hub-and-spoke arrangement of distributed computing. I think, WCF can very well be used. You have multiple servers and a coordinator (the client to all of these servers) that gets the work done from various servers and update the database.
So WCF is well-suited for you. The benefit of WCF is the easy configurability and handling the communication part. You don't have to take much pain for the management of sockets.