Postman Learning Center

To get a bit further in Postman, check out the Postman Learning Center. Especially valuable for professional test automation including scripts.

https://learning.postman.com/docs/getting-started/introduction/

 

Test Automation in Postman

You can use Postman to write test scripts for REST services. The free version of Postman contains all the functionality you need. The number of API calls per month (1000) could be a limitation when testing intensively.

I’ll skip the basics of manual testing via Postman. As you can see in the screenprint below, additional tests can be added via the Tests tab. This way we can automate our test effort.

In this case we called a get method on an API Management endpoint. We entered a test to see if we received a response within 200 milliseconds. This is a standard test that we can drag and drop from the window on the right-hand side. This way we could also add a test to check if we actually received a successful Http 200 response. In tab Test Results of our output, we see that our test has passed. Simple, but powerful.

More interesting tests are the JSON Value Check and Schema Validation. Below is an example of the JSON Value check and the relevant part of the response.

pm.test("Test Administration", function () 
{    var jsonData = pm.response.json();   
pm.expect(jsonData.customers[0].administration.administrationId).to.eql('CitoBV');});

To perform a schema validation, we first need to add an Environment (for example Test) and then add a variable CustomerSchema. We don’t want to add the Customer schema to each individual test. That’s why we add a variable first. We can use multiple environments so that we can – as an example – define different addresses for Test, Accept and Prod. To be able to select the variable in a testcase, we will have to select the environment from the drop-down box at the top right hand side of the Postman window. Now we can reference the variable in the test script:

The last tip is to add multiple tests to a collection and then run all tests within the collection to see the test results. If you use a Team Collection, you can even share the test scripts with your fellow test team members.

Test Soap Service via Postman

I found an interesting post on the Postman Blog, which was almost correct. For easy reference, I give the correct approach here:

You can easily make any HTTP SOAP request using Postman by following these simple steps:

1. Give the SOAP endpoint (not necessarily the WSDL) as the URL. If you use a WCF service hosted on Azure that would be a .svc endpoint like https://dsponrampservice.azurewebsites.net/DSPOnRampService.svc
2. Set the request method to POST.
3. Add Authorization as required.
4. On the Body tab, select Raw and body type “text/xml”
5. Now go to the header tab. You will allready see two headers: Authorization and Content-Type. You will have to add a header named SoapAction manually. You can get the Soap Header of the operation from the WSDL. For Instance: http://sap.com/xi/WebService/soap1.1.
6. Click [Send] to call the operation.

Example Request message (note the header and body nodes)

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/&#8221; xmlns:sim=”http://SimpleDataGateway.MessageRequest”&gt;
<soapenv:Header/>
<soapenv:Body>
<sim:MessageRequest>
<Name>Paul</Name>
</sim:MessageRequest>
</soapenv:Body>
</soapenv:Envelope>

In the above mentioned post, it’s indicated that you should specify the name of the operation in the body. In my case I had a service with just one operation, so maybe that’s the reason I didn’t have to. As a side note. After adding the operation in the message, I got a serialization exception. So, I still think you should add the operation name in the body.

Azure AD support in browser and Postman

I have been struggling a bit with Azure Active Directory authentication of WebApps. First I tried to access the service via Chrome. The idea was to use the so-called Developer Tools to obtain the security token.

I tried the following address:
https://archibusgatewayservice.azurewebsites.net/api/serviceorders
And I get the error:
<Error>
<Message>Authorization has been denied for this request.</Message>
</Error>

Then I developed a custom client to get the token. The relevant code fragment is shown below:

authContext = new AuthenticationContext(authority);
AuthenticationResult authResult = authContext.AcquireToken(apiResourceId, clientId, redirectUri);

HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(“application/json”));
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(“Bearer”, authResult.AccessToken);

string postBody = “{‘ServiceNumber’: ‘TEST001’}”;

HttpResponseMessage response = await client.PostAsync(apiBaseAddress + “api/serviceorders”, new StringContent(postBody, Encoding.UTF8, “application/json”));
response.EnsureSuccessStatusCode();
string responseString = await response.Content.ReadAsStringAsync();

If you do a quickwatch on the client created you actually see the authorization header:
Bearer eyJ0e…

Then I went to Postman, entered the authorization header and voila: it works!

Now back to the browser. What I found out is that it makes a difference how you configure Authentication / Authorization for the Web App in the Azure Preview Portal. If you switch Authentication/Authorization off in the Preview Portal, both the client application and Postman work, but the browser doesn’t work. If you switch it on, it’s just the other way around. The browser redirects you to a login page when you enter the following address:
http://archibusgatewayservice.azurewebsites.net

Now you can do a get call via the browser (posts are not possible) and then you will find out that you still can’t find the security token. That makes sense. Active Directory credentials are never sent with the request, so you will never find them via the Developer Tools. I think if you use a MicroSoft account to authenticate that you will find a so-called zumo token (specify a X-ZUMO-AUTH header).

Logic App

To design a Logic App, click the link Triggers and Actions.

Below is an example of a Logic App. The Logic App receives a Http Request via a Http Listener. The Http Listener acts as a trigger. The other API Apps in the Logic App are what we call actions. Note that the API Apps like the Http Listener and the BizTalk XML validator are created before creating the Logic App. You can use multiple instances of an API App in one Logic App. In this example you can see that multiple instances of the same Http Listener are used.

Before we go on, I’d like to add a little note. When you create a Logic App a list of available triggers, actions and connectors will be added to a toolbox which is available on the right hand side of the Logic App designer. The list of API Apps is limited to those already provisioned in your App Service Plan. I once noticed this toolbox was minimalized. Only after looking very close I noticed there is a maximize icon in the right hand corner of the toolbox. Take a close look at the screenprint below to show it again in full size. By the way, when you use an API App in a Logic App and you change it’s design afterwards, you don’t have to remove the API App and add it again to the Logic App. It simply gets updated without being added again.

Now let’s zoom in to the different triggers and actions. The Http Listener gives subsequent actions access to the body of the message. As a little side note. You can see the name you specified for the Http Listener (or any other API App) only after you click the information (i) button after the text Receive Http Request. It would have been more intuitive if you had seen the name in the red banner.

After receiving the request, the request is first validated. Note that the input xml is retrieved from the trigger: @{triggers().outputs.body.content}. The @ simply means you are referring to a function. The function is expressed in the Workflow Definition Language. For a helpful link, see: WDL. The validation result is not returned to the caller immediately. The flow is further executed and only later an http response is returned to the caller based on the validation result. You can specify different schemas in one validation step. That means you can receive different kinds of xml documents via the http listener.

The next step is the BizTalk Transform Service. The BizTalk Transform Service maps the incoming xml document to the schema required by the SQL Connector. After insert in BizTalk the different xml messages are assembled into one big xml file. That means that the different xml messages are not assembled via a map in the BizTalk Transform Service. The BizTalk Transform makes use of a so-called .trfm file, not from a BizTalk .btm file or an xslt file. The trfm file can be assembled via a visual mapper similar to the BizTalk mapper. The Mapper can be accessed in Visual Studio after you have installed the BizTalk Services (or MABS) SDK. Note that you can add different maps to a BizTalk Transform shape. The correct map is selected based on the input xml document. Add a condition like: @equals(body(‘xmlvalidatorperson’).Result,bool(‘True’))

The next step is the SQL Connector. The SQL Connector takes the input from the transform step. If you want to insert into two different tables, than you need two SQL Connectors. To select the correct SQL Connector you need to specify a condition. The condition refers to the schema name property of the validate step. Finally be aware that the action Insert Into Person (XML) is selected when you add the SQL Connector to the Logic App Designer.

The last action you need is a Http Listener to return the result of the REST call. Notice that an Http 500 is returned when the result of the validation is false: @equals(body(‘xmlvalidatorsampleschemas’).Result,bool(‘False’)). The RequestId is taken from the Http Listener that acts as a trigger. The content is set to the error description that is the result of the validation: @{body(‘xmlvalidatorsampleschemas’).ErrorDescription}. The configuration of the Http 200 Listener is similar. Only note that you have to add the Http Listener twice, that is, once after each successful insert. Also the content can’t be set to the error description, but in this case to the output : @{body(‘sqlconempgateway’).OutputXml}

Logic Apps with an Http trigger can be tested via Postman: