I have a suite of web tests created for a web service. I use it for testing a particular input method that updates a SQL Database. The web service doesn't have a way to retrieve the data, that's not its purpose, only to update it. I have a validator that validates the response XML that the web service generates for each request. All that works fine.
It was suggested by a teammate that I add data validation so that I check the database to see the data after the initial response validator runs and compare it with what was in the input request. We have a number of services and libraries that are separate from the web service I'm testing that I can use to get the data and compare it. The problem is that when I run the web test the data validation always fails even when the request succeeds. I've tried putting the thread to sleep between the response validation and the data validation but to no avail; It always gets the data from before the response validation. I can set a break point and visually see that the data has been updated in the DB, funny thing is when I step through it in debug with the breakpoint it does validate successfully.
Before I get too much more into this issue I have to ask; Is this the purpose of web tests? Should I be able to validate data through service calls in this manner or am I asking too much of a web test and the response validation is as far as I should go?
That is not asking too much of the test, just make sure the database test gets called after you yield the WebTestRequest for the WebService call.
So in that case, the database check is separate from the call.
Post code for your webtest if there are still issues.
Related
I have two Asp.Net web apps, App 1 and App 2. They both use the same database. I am trying to give command from App 1 and immediately run a bit of code in App 2.
The only way I can think of doing this is by inserting a command in the database and have App 2 poll the database every few minutes. But this means there may be a delay in running the code.
Is there a way to run code in App 2 immediately?
You can fire an HttpRequest from one app to another and the code will run almost immediately.
I don't know what language and platform you're using, so it's hard to give you concrete examples, but here are the outlines:
Create a page in App2. In standard ASP.Net, you can use a handler. In ASP Core, you can use an API controller. Both car return a single value or a full object in JSON or XML. Or you can use a standard page if you like to return HTML. The code behind is what you want to run. The rendered page or return value from the handler or controller is what you want App1 to get back in response.
Then from App1, issue an HttpRequest to that page in App2 and check the response to see how to continue (for example, if the code ran successfully or not).
The HttpRequest is in case you want to make the call from the server side of App1. If you want to make the call from the client side, then you use Ajax instead. In the case of Ajax, you have to pay attention to the security side, because you don't want to allow whoever to call that page from App2 unless it unless the code behind doesn't pose any security risk and doesn't return any sensitive data.
One last idea specific to your scenario, since both apps are using the same database, you can add the required values to the database as you were planning to do, and then issue a simple HttpRequest. This way, you don't need to worry about security or passing a any sensitive info. When App2 receives the request, it checks the database to see if the request was actually made from App1 and then processes it, otherwise ignores it.
Hi All BizTalk Developers,
I need some input and guidance on how to design an Orchestration that can take few parameters as Input and log them in SQL server table (tblTrackingData)
I want to start this orchestration at various points, for example when I am calling a webservice so I want to log the request in DB and when I get the response then I want to log the response xml also in the same table.
In case of any exception I want to log error message and other details in the same table for tracking purpose.
Can some one guide me, direct me to some existing blogs/posts on how to handle this generic tracking / exceptions etc by starting a new Orchestration.
The purpose of a new Orchestration is to call it from anywhere, please suggest if it could be handled in a better way also.
Thanks.
The best advice, don't do this.
The reason? Everything you describe is already done by BizTalk Server automatically by BizTalk Tracking and the Event Log.
I can tell you from experience, you will not need anything else beyond Tracking and the Event Log.
I do recommend you implement proper exception handling within you app and log custom events, but they would also be written to a Windows Event Log only as well.
I'm very new to Application Insights, and I'm thinking of using it for a set of services I plan on implementing with asp.net webapi. I was able to get the basic telemetry up and running very easily (right-clicking on a project on VS, Add Application Insights), but then I hit a block. I plan to have a correlation id set in the request headers for calls to downstream services, and I would like to tag all the telemetry related to one outside call with the same correlation id.
So far I've found that there is a way to configure a TelemetryInitializer, but if I understood correctly, this is run before I get to access the request, meaning I can't check if there is a correlation id that I should attach.
So I guess there might be 2 ways to solve this: 1) if I can somehow actually get access to the request headers before the initializer, that would obviously solver the problem, or 2) somehow get a hold of the TelemetryClient instance that is used to report the automatically generated telemetry.
Perhaps the last resort would be to turn off all of the automatic stuff and do all of it manually, when I could of course control what properties are set on the TelemetryClient. But this would be quite a lot more work, so I'd prefer to find some other solution.
You were rights saying that you should use TelemetryInitializer. All TelemetryInitializers are called when Track method is called on any telemetry item. Autogenerated request telemetry is "tracked" on request OnEnd, you should have all your custom headers available for you at that time.
Please also have a look at OperationId - this is part of the standard context managed by App Inisghts and is used exactly for the purpose of correlating requests with downstream execution. This is created and passed automatically, including traces (if you use trackTrace).
Moreover, we have built-in support in our UX for easily seeing all telemetry for a particular operation - it can be found in "Search->Details-->Related Items-->All telemetry for this operation"
I have a public web app that calls ASP.NET web method in an ASMX file, located in the same site folder in IIS. But, to prevent bots to ping the service directly, we'd like to secure the API so that only our HTML 5 client page can access it. Do you have a suggestion on how should I implement this kind of thing ? Not too much, just a simple mechanism that won't take a week of testing please. Doesn't have to be a 100% full proof method since it is public data and the API just pumps data out, not inserting anything. Just something to limit possibilities of DDOS attack on the API.
The way I've tackled this in the past is with a custom header.
Essentially if your web page is using some form of AJAX call to call back to your services layer, then you can use something like:
xhr.setRequestHeader('custom-header', 'value');
where 'xhr' is an XML Http request that you've built in Javascript
of course you could also take the much easier route of just adding a parameter to your calls query string, EG:
in your ajax call, request:
http://my.services/service.asmx?somesecretkey=foobar
instead of just
http://my.services/service.asmx
Then you can just use the request's query string collection server side to see if it's present or not, and refuse the connection if it's not.
You could even go so far as providing some seed value in the data passed to the page in the first place, then use that seed value to create a unique value (one the server can also calculate) that is returned back in your request to the server.
Doing it that way would provide a slightly higher level of security, as the values would be semi random and not easy for a bot to guess.
Bear in mind also, that if you control the calling page, and you are doing this by ajax, you can also put this key in your post variables collection too so it doesn't have to be visible in the get request.
I have a program in which it insert a raw in a table after certain operations. I wan to call a web service in code behind to do some special tasks by the using of info that there is in the inserted row.
How I can do that?
Is it good idea to invoke this web service from a stored procedure or not? What are the other options?
More Details: Actually, I have an operation in my web application that take a long time to be completed and it is seriously time consuming operation. I don't want client wait until this process finish. That is why I decide write a web service to do this process in the background.
Therefore, I think it may be a good idea that when client request receive I insert his request in a table and call a web service to handle it. Moreover, I do not want to wait until web service return the result, so I will aware client from its result through the report. I do not know what is the best solution to handle it.
I usually keep myself far away from table triggers(it sounds like you're about to use an on insert trigger for a table).
I don't know your specific situation but you could either :
Call the webservice before or after you call the stored procedure, this way the data layer(stored proc) only handles data and nothing more. You're logical layer will handle the logic of calling an extra webservice.
Write a service that will periodicly read a table and notify the webservice of the latest modifications. More messy but it resembles more the effect you're trying to achieve.
There are probably more solutions but i'd need more information on what it exactly is you're doing. Right now it's kinda vague :)
It is never a good idea to call webservice from Stored procs or other DB objects. You can call it from your code, just after you execute the insert and commit it.
The problem it sounds like is that you cannot guarantee that the web service will be called unless you call it before committing the transaction. However, it sounds like the web service needs to be called after commit. In this case, it sounds like you should use a message queue. You could either build one in your database or you could use one off the shelf (http://aws.amazon.com/sqs/ or http://www.windowsazure.com/en-us/home/features/messaging/).
The steps would be:
Insert message into queue (after this is success you can return the call, depending on what your contract with the caller is)
Read message
Insert into table
Call web service
Delete message
The downside is that you will need to make the operations (inserting into the table and calling the web service) idempotent.