I am doing web service testing by importing the WSDL using UFT API testing. I am placing request content in text mode and running the test and it returned a successful response.
How can I read an xml file and send as a request during run time using custom code. I tried the code below but when I ran the test the request being sent was blank and so the response failed.
I'm using the code below,
public void StServiceCallActivity4_OnBelowGenerateRequest(object sender, HP.ST.Ext.WebServicesActivities.ActivityProcessXmlMessageEventArgs args)
{
//TODO: Add your code here...
this.StServiceCallActivity4.InputEnvelope.LoadXml(#"C:\\TestRequest.xml");
}
I appreciate your help.
Thanks
Abhi
Have you tried the same code inside the AfterGenerateRequest event ?
Below is the article explaining this (Section Assign a specific request file to a test step)
http://uft-help.saas.hpe.com/en/12.54/UFT_Help/Content/User_Guide/task_API_coding_manipulate_WSC_properties.htm
Related
I have a web API, where I'm trying to support a PATCH request with a JSON Patch body to make changes to an object on the server.
I am using ASP Core with .Net 6, hosting using IIS on my web host.
This is the controller method:
public class BaseDataController<TEntity, TDetail, TNew> : ControllerBase
where TEntity : class, IIdentifiable
{
[HttpPatch("{id}")]
public virtual async Task<ActionResult<TDetail>> Patch(Guid id, [FromBody] JsonPatchDocument<TEntity> patch)
{
var item = await MainService.GetAsync(id);
if (item == null)
{
ControllerLogger.ItemNotFound();
return NotFound();
}
patch.ApplyTo(item, ModelState);
ValidationHelper.ValidatePatch(item, ModelState);
if (!ModelState.IsValid)
return BadRequest(ModelState);
await MainService.UpdateAsync(item);
return this.GuardResult(Mapper, item);
}
}
When I try to use this on my local machine, it works just fine. When I deploy to my web server, and make an identical request, I get a validation error and a 400 status code:
{"errors":{"":["A non-empty request body is required."],"patch":["The patch field is required."]}}
If I change HttpPatch to HttpPost and update the web request accordingly, it works fine.
Can anyone suggest what might be going wrong here? I'm assuming the server is baulking at the PATCH verb, but I can't work out how to make it happy. Googling is coming up with a load of WebDAV things, but the error codes don't match and ASP is clearly receiving the request (proven from the logs) when the description of the WebDAV issues suggests it wouldn't.
My working theory is that IIS is seeing the PATCH verb and doing something to the request body that ASP Core doesn't like, but I can't work out why or where to look to turn that sort of thing off.
When I try to use this on my local machine, it works just fine. When I
deploy to my web server, and make an identical request, I get a
validation error and a 400 status code: If I change HttpPatch to HttpPost and update the web request accordingly, it works fine
Well, your scenario is pretty obvious in context of IIS as you may know Http verb PATCH is not enabled as default accepted http verb on IIS Request Restrictions As you can see below:
Solution:
To resolve above incident, you outght to configure Request Restrictions on IIS and need to include ,PATCH so that it will allow http PATCH verb. On top of that, after that, please restart your application pool. You can follow below steps to implement that:
Step: 1
Select your app on IIS and then click on Handler Mappings Just as following
Step: 2
Select (Double click) ExtensionlessUrlHandler-Integrated-4.0
Step: 3
Click on Request Restrictions
Step: 4
Select VERB then include PATCH by comma seperated value as ,PATCH and click OK finally restart your application pool.
Note: For more details you can have a look on our official document here.
I will need to create a flow in Anypoint to download a .gz file from an external API source(through OAuth). I have created a listener -> Request -> Write flow. But I don't see the file saved in my local after I called the API. I have hardcoded Bearer token in the header and raw parameters in body, everything looks good. It doesn't show any error but when I tried to debug it and I'm seeing output and payload both are empty. I'm able to download the gz file with Postman. Am I in the right direction? I saw someone was using outbound endpoint but it is not showing in Mule 4.
Is there any way I can see what the external API returned(Success or failed)? And the content? Please advise.
Many thanks.
Regards,
Richard
Update 1:
Mule Flow
DEBUG
Added the Flow and the Debugging message. I have simplified the flow and just tried to make the POST rest call with Bearer token. It should return a json response. But still getting an empty response. Do we know what's that java.util.LinkedHashMap thing? Thanks.
Update 2:
Request Body
Request Header
XML Configuration:
XML Flow
You can add loggers to the application to trace the execution.
You could also enable HTTP wire logging to print requests/responses in the log too. To enable it you have to set the package org.mule.service.http.impl.service.HttpMessageLogger to DEBUG in the log4j2.xml or in the Runtime Manager console. Detailed instructions available at this KB article.
How would I capture with fiddler requests made during installation under an msi package?
I have an app that makes several http requests during its installation, through overriding the install method in a windows msi package.
I'd like to be able to capture these requests using fiddler, but cannot. MS Network Monitor 3.4 captures the requests though, so I know the activity is occurring.
I can start fiddler and capture the requests made in a browser, so fiddler itself is working, and I haven't set it, or my installer, to use any non-standard port.
I am simply creating a request and trying to get the response, for now:
var httpRequest = (HttpWebRequest)WebRequest.Create(url);
try
{
using (var httpResponse = (HttpWebResponse)httpRequest.GetResponse())
{
using (var responseStream = httpResponse.GetResponseStream())
{
if (responseStream != null)
responseStream.Close();
}
I've done some research, and concluded that fiddler should be able to capture this, so I am not sure what I am doing wrong. Any advice would be most appreciated, thanks.
Update: I've taken the code that I was using in the installer method, and put it in a standalone console app. Fiddler captures the request in that scenario. So what I am seeing, is that the installer cloaks the request somehow, so fiddler does not see it.
I haven't worked with Fiddler, so I don't know how you tell it what to watch, but most custom actions execute in a different process than the original msiexec process. Non-impersonated actions often execute in a completely different context (typically an administrative user).
I'm working on application tests and have found an issue.
My app. has an authenticate(email, password) action inside the
Security controller and when invoked, from the login page, with a
valid e-mail and invalid password it sends me back to the login page
with an error message, located in the flash scope.
The app. test code follows :
Response response =
GET("/security/authenticate?email=validUser&password=invalid", true);
String pattern = "invalid password";
assertContentMatch(pattern, response);
When this code is run throws the next exception :
A java.lang.RuntimeException has been caught,
java.net.MalformedURLException: no protocol: /login
Did some research and found that :
the exception is thrown when a new URL object creation is attempted,
to be able for redirection, using an invalid URL. In this case no
protocol is present
looking at app. test in samples apps. GET is used without
redirection, meaning that after GET only the http code is verified but
no attempt to follow the redirection
Has anyone had this same issue also ?
Any open bug to look for info or add my 2 cents ?
Here you can find a description of the problem as well as code snippet to work around the issue:
https://play.lighthouseapp.com/projects/57987/tickets/1553-functionaltestget-with-redirect-crashes
I am running a very simple Web application (Asp.Net MVC3) on Win 7 IIS.
I have a very simple HTTP GET API which returns hello world.
Calling:
http://localhost/helloworld
Returns:
Hello World!
This works perfectly over a browser.
But when I write an app which tries to pull this URL using a webclient, I get the following error:
{"Unable to read data from the transport connection: The connection was closed."}
My Code is as follows
WebClient web = new WebClient();
var response = web.DownloadString("http://localhost/helloworld");
My IIS Settings are as follows
What should I be looking at? I have been at this for hours and I have run out of options to try! Any help will be really appreciated!
Thanks.
I suspect it's because WebClient does not send some of the HTTP headers:
A WebClient instance does not send optional HTTP headers by default. If your request requires an optional header, you must add the header to the Headers collection. For example, to retain queries in the response, you must add a user-agent header. Also, servers may return 500 (Internal Server Error) if the user agent header is missing. http://msdn.microsoft.com/en-us/library/system.net.webclient(v=vs.80).aspx
Try using HttpWebRequest instead. http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.aspx
I finally figured out what the issue was and instead of it being an IIS specific issue - which I was leaning towards, it turned out to be an issue with the code that I wrote.
Adding details here incase someone else runs into a similar problem.
I had the following method in my code which I was using to send the response of the request as a JSON object.
private void sendJsonResult(string result) {
Response.StatusCode = 200;
Response.Headers.Add("Content-Type", "application/json; charset=utf-8");
Response.Flush();
Response.Write(result);
Response.End();
Response.Close(); // <-- This is the problem statement
}
On digging around a bit, I found out that we should not be doing a Response.Close().
A better explanation of this is here.
Once I removed that line, it started working perfectly - both in my consuming app as well as the web browser, etc.
If you will read the link above, you will clearly understand why we should not be using a Response.Close() - so I will not go into that description. Learnt a new thing today.