I am trying to make a REST POST request in SoapUI.. The XML contract for the same is
<Login>
<Email>admin</Email>
<Password>123456</Password>
</Login>
I have passed the values as follows in the REST request in SoapUI to the URL http://localhost:8080/SalesPropeller/rest/api/restLogin
Name Value Style level
Email admin Query Resource
Password 123456 Query Resource
How do I pass the parameters in SoapUI?
Should the root tag name be included?If yes, How?
It is based on how your backend expects the payload.
From XML Contract, Your request payload should be like this
<Login>
<Email>admin</Email>
<Password>123456</Password>
</Login>
If you want to add properties, to send variables as field values
<Login>
<Email>${propertyName}</Email>
<Password>${propertyName}</Password>
</Login>
For creating properties, refer http://www.soapui.org/functional-testing/properties/working-with-properties.html
Related
I am using AWS API Gateway and I want to set my Integration type to http. I have the integrated url as https:// xxxxxx.com which takes a header "apikey". I am not expecting the end user to pass the header rather I want to set the apikey to some constant value.
I see that there is a way to force the user to make him pass the header(by making header required under the Method Request section. However, I want to set it to default.
For example in all the requests which are internally calling the URL inside the API gateway should pass the header value as "12345".
You can add/remove/override headers with an Integration Request Mapping Template.
In the API Gateway console, chose the relevant api/resourece/method. Go to Integration Request > Mapping Templates and chose your Content-Type (if requests are going to be received without a Content-Type header, set the Content-Type for the mapping template to application/json, which is the default behaviour).
Then in the actual mapping template add the following:
{
#set($context.requestOverride.header.apikey= "testMe")
}
This will add (or overwrite if it already exists) a header called apikey with the value "testMe" to all http requests downstream.
If you take this route, then you will need to also map over any other headers, path parameters, query parameters or body that you wish to pass through.
You could loop through the headers and query parameters like this.
## First set the header you are adding
#set($context.requestOverride.header.apikey= "testMe")
## Loop through all incoming headers and set them for downstream request
#foreach($param in $input.params().header.keySet())
#set($context.requestOverride.header[$param]= $input.params().header.get($param))
#if($foreach.hasNext) #end
#end
## Loop through all incoming query parameters and set them for downstream request
#foreach($param in $input.params().querystring.keySet())
#set($context.requestOverride.querystring[$param]= $input.params().querystring.get($param))
#if($foreach.hasNext) #end
#end
As you need to ensure that the header apikey is set to a default value, you should set the override for apikey before looping through the rest of the headers as only the first override will take effect.
The relevant AWS documentation can be found here.
The other alternative would be to point your API Gateway at a Lambda and make the call from the Lambda instead.
Firstly thanks to #KMO for his help. The following is the solution:-
Enable Http Proxy Integration.
Add the headers apikey=xxxx and Accept-Encoding=identity under the same Integration
Request -> Http Headers.
Under Settings -> Binary Media Types set the following as separate Binary Media Types
'*', */*. I mean as two different lines.This step is needed to resolve the Gzip action while returning the response.
Add the Query parameter country in the URL Query String Parameters section.
In the Integration Request map the country parameter to ctry by adding the value under mapped from as method.request.querystring.country. This will ensure that the query parameter country you passed in the main URL will be fed to the downstream url as parameter ctry.
The advantage of this apporoach is that, even if you override the header apikey, the one set under the Http Headers will take the precedence.
When trying to execute following robotscript, it added additional element to the login element..
Library Selenium2Library
Library Collections
Library String
Library uuid
Library Dialogs
Library SudsLibrary
Create Soap Client http://xxxxxxxxx:18080/xxxxx_b/xxx?wsdl
${dbl array}= Create Wsdl Object logIn
Set Wsdl Object Attribute ${dbl array} username xxx
Set Wsdl Object Attribute ${dbl array} password xxxx
${result}= Call Soap Method logIn ${dbl array}
log to consol ${result}
original request format
<soapenv:Envelope xmlns:soapenv="http://xxxxxxxxxxxxx/x/x/" xmlns:ws="http://xxxxxxxxxxxxxxx/">
<soapenv:Header/>
<soapenv:Body>
<ws:logIn>
<!--Optional:-->
<username>xxx</username>
<!--Optional:-->
<password>xxx</password>
</ws:logIn>
</soapenv:Body>
</soapenv:Envelope>
Generated code :
<SOAP-ENV:Envelope xmlns:ns0="http://xxxxxxxxxxxxxx/" xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="h
ttp://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<ns1:Body>
<ns0:logIn>
<username>
<username>xxx</username>
<password>xxx</password>
</username>
</ns0:logIn>
</ns1:Body>
</SOAP-ENV:Envelope>
How to remove additional username tag?
<username>
<username>xxx</username>
<password>xxx</password>
</username>
Very likely the problem is that the login method does not take its arguments wrapped in an object, but directly. Suds creates types for all methods, but these are not needed to call the methods.
If you look in the output from Create Soap Client you will probably see something like logIn(username, password). That means you pass the arguments directly and not in some object.
Library Selenium2Library
Library Collections
Library String
Library uuid
Library Dialogs
Library SudsLibrary
Create Soap Client http://xxxxxxxxx:18080/xxxxx_b/xxx?wsdl
${result}= Call Soap Method logIn some_username some_password
log to console ${result}
I have tried to find a solution in this community in different threads but yet to find one that I am looking for.
I am using SoapUI version 5.3.0 My Application have a couple of RESTful APIs. Initially I am sending json request to a WebService and getting back the following XML Response:
<StartDataExtractResult xmlns="http://schemas.datacontract.org/2004/07/AriaTechCore" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<StatusCode>1</StatusCode>
<StatusText>success</StatusText>
<RequestNumber>397</RequestNumber>
</StartDataExtractResult>
As soon as RequestNumber tag is generated. I have to access to 2 more XML EndPoints (where the value of RequestNumber is appended) to know the Status as below:
A. http://quickextract.quickaudit.in/webs/quickextract.svc/GetExtractionDetails/396
B.
http://quickextract.quickaudit.in/webs/quickextract.svc/GetRequestStatus/396
As of now, I have created the 2 seperateTestSteps for the above mentioned XML Endpoints:
A. http://quickextract.quickaudit.in/webs/quickextract.svc/GetExtractionDetails/
B. http://quickextract.quickaudit.in/webs/quickextract.svc/GetRequestStatus/
Now I need to append the value within tag in the GET Request to get back a response from the WebServices.
Update:
I have created a 'Property Transfer' at Testsuite level as "TSreqNum". This 'Property Transfer' is getting updated as per the initial Response. But I am not sure how would I append "TSreqNum" to construct the complete GET Request as:
http://quickextract.quickaudit.in/webs/quickextract.svc/GetExtractionDetails/TSreqNum
Can anyone help me out please?
You can use the property within the URL of the GET request:
http://host:port/path/${#TestSuite#TSreqNum}
The URL gets updated with the property value.
I am a newbie to the apigility code-connected service & was able to create a RESTful service with fetch and fetchall class method on the mapper file.
Can someone point me a good sample for insert (POST) data via REST service ?
Thank you,
Kevin
POST is going to be used for creating a new resource typically. This means that in your request you're going to want the following headers:
Accept: application/json
Content-Type: application/json
The first tells Apigility what sort of a response it is expecting. The second says that the data you'll be providing to the API will be in json format.
Apigility uses json or json+hal by default for a return and expects json for the incoming data.
When you're creating a new resource, typically you'll be persisting it in a database and as such the id of the resource will be generated by your code or database. The rest of the resource will be provided by the caller to the API. Example:
POST /api/user
{
"username": "kevin voyce",
"firstname": "kevin",
"lastname":" "voyce"
}
If you do this, you should see a response of something like
405 - Method Not Allowed
The body of the error should indicate that the method has not been defined. The error message is coming from the create method in the resource. Inside this method, you'll see an argument called $data which at this point will consist of a PHP stdClass with fields matching the stuff you passed in via the JSON body.
This is where the fields part of configuring your API in Apigility comes in. If you set up the names of the fields and put validators on the fields, Apigility will make sure that the fields that are passed in conform to and are valid according to these validators before the call is made into your API. The same applies to not just POST, but PATCH and PUT as well. This means that within your methods you don't have to worry that the input hasn't been validated (as long as you correctly configured your validators).
My question is similar to this. How To Pass Soap Header When WSDL Doesn't Define It? But is different.
For a web service I use, all methods need authentication which is sent in cleartext inside a SOAP header. However, my WSDL doesn't include any soap header information. I have a custom platform tool which I must use to generate code from the WSDL. Since the header info is not available, am unable to use the generated class directly - I do not want to manually modify the code to accommodate the header.
I tried specifying the SOAP header in the WSDL but I failed to get the correct namespaces. The WSDL is here https://stage.totalcheck.sensis.com.au/service/webservice?wsdl and the SOAP header is as follows:
<soapenv:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>username</wsse:Username>
<wsse:Password>password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
Can someone help me? Thanks!
From a conceptual point of view, WSDL is not supposed to define headers. WSDL is only for defining the functional aspects of a service, like operations, messages, binding and endpoints. Messages and bindings define how the payload of messages should be encoded and formatted.
The headers of SOAP messages however do not belong to the payload. They are typically used for configuring non-functional properties of a SOAP processor. Security is such a non-functional property. The functional aspect of the payload is not affected. It is only assured that the communication is secured and the WS tool stack, not the service implementation, should take care of that.
So the missing piece is now a standard that allows for attaching some non-functional requirements to WSDL services, so that code generators can automatically derive which headers need to be sent and/or understand in order to fulfill the non-functional property as desired -- without having to manually deal with header fields. This standard exists and is called WS-Policy. A policy contains typically a set of alternatives that expose a set of requirements that both, provider and consumer should be able to fulfill. When two services are supposed to interact with each other, both policies are taken and a so called "effective policy" is calculated. It defines the common non-functional requirements. Using this information, provider and consumer can configure themselves to add required headers, like the WS-Security headers. WS-SecurityPolicy also defines a set of policies that can be used. WS-PolicyAttachment defines how such policies can be attached to a WSDL.
There are code generators that can deal with WS-Policies, e.g. Metro or Axis2
You can add soap header information to method calls by decorating the methods in the proxy class generated from the wsdl with the SoapHeader attribute.
For example wsdl.exe will generate client proxy class Reference.cs for the web service reference when you "Add Web Reference". In the link mentioned above https://stage.totalcheck.sensis.com.au/service/webservice?wsdl there is a message suggestAddress which will translate to a method in the generated reference.cs client proxy code file when you add a web reference from visual studio. By default when this method is called there will be no Header in the soap envelope. To add a SoapHeader to the envelope for this request add a [SoapHeader("Security")] attribute to the top of the SuggestAddress method in the Reference.cs generated class, where "Security" is a class that inherits from SoapHeader base class.
Example for the above required Security SoapHeader you would create the following classes,
public partial class Security : SoapHeader
{
public UserNameToken UserNameToken { get; set; }
}
public partial class UserNameToken
{
public string UserName { get; set; }
public string Password { get; set; }
}
Then you would decorate the SuggestAddress method in the reference.cs like followed,
[SoapHeader("Security")]
public suggestAddressesResult suggestAddresses([System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] addressSearch search) {
object[] results = this.Invoke("suggestAddresses", new object[] {search});
return ((suggestAddressesResult)(results[0]));
}
This will ensure that every envelope created when method suggestAddress is invoked contains a security header that looks like the one mentioned above,
<soapenv:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>username</wsse:Username>
<wsse:Password>password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
Key for me in using this question to help myself was recognizing (as some pointed out) that the headers in question are those of WS-Security standard.
If your proxy generating tool is "custom" it seems logical that you might have a switch to automatically add the headers for WS-Security. However, if you're using WSDL.exe ("Add Web Reference" in Visual Studio), consider svcutil.exe instead ("Add Service Reference").
If you use a WCF proxy, you can override the given config and allow WCF to add the headers for you:
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
From there you can specify the password:
RemoteSvcProxy.TheirClient client = new RemoteSvcProxy.TheirClient();
client.ClientCredentials.UserName.UserName = "uname";
client.ClientCredentials.UserName.Password = "pwd";
I don't know what your custom tool is, but perhaps the framework it's based on also has similar configuration options.