MarkLogic Data Hub Service

Fast data integration + improved data governance and security, with no infrastructure to buy or manage.

Learn More


Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up


Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up


Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

Postman Test Scripting with XML

by Bob Starbird

As a MarkLogic developer, I often use Postman to send requests to the MarkLogic server. MarkLogic Server can fit into an architecture in a variety of ways. One way is as an Operational Data Hub. As an ODH it receives data from many data sources and stores them in a single accessible hub. MarkLogic's multi-model databases leverage the inherent structure of the data being stored. It provides native storage for JSON, XML, RDF, geospatial, and large binaries so it can easily consume and produce both JSON and XML. When integrating data from silos, the source data format can be preserved or transformed. Often these services are exposed as REST endpoints for an application tier. In order to test these services I often use Postman.

I had been working with Postman interactively testing endpoints with individual requests and getting responses. The new Postman app also supports collections of tests that can be run as a suite.

I needed to test the web services of an application with REST endpoints and XML request payloads and responses. The test orchestration needed dynamic payloads, dynamic parameters, and test routing. Here are some of the things I learned on this path which hopefully can save you some time.

To get started, download Postman App.

The product documentation is very helpful for a general introduction or if you are new to Postman.

Having used Postman interactively it was easy to build a sequence of requests, put them in a collection, and run the collection. Testing a XML REST web services was left as an exercise for the student.

While looking for answers, I found some helpful Postman testing tips.

For developing these scripts, I read that the Postman Sandbox is a JavaScript execution environment.

JavaScript code is often used for parsing JSON responses:

For XML responses I initially headed down a path using xml2Json. My general online searches led me to think this was the way. It wasn't since it did not solve the problem working with XML and producing XML. xml2Json did work for getting data from the XML payloads using JSON methods:


So then I tried to build a new XML payload and my progress came to a halt, until I found cheerio.

Postman with XML Request and Response Payloads

I wanted and needed to work with XML to get XML values and build new XML payloads.

As reported in a GitHub issue, cheerio became the new jQuery support in Postman.

Cheerio provides a fast and capable API. It relies on the familiar JQuery API.

This was the magic combination I needed:

and to update the XML:

I was off and running to develop my tests. It is certainly possible to create lots of folders with lots of tests and lots of cut and paste code. I was trying to avoid making tests, making duplicates, fixing my mistakes, and then having to maintain all of the changes I knew were coming as the requirements evolved. A combination of Postman features solved these challenges.

Postman Environments

With Postman environment variables, you can create dynamic behaviors. Postman stores the environments in dictionaries for Environment and Global. The keys and values are strings.

A special syntax {{key}} allows value access to these dictionaries outside of JavaScript tests such as in the request URL. The variable key is evaluated first in the Environment context and then in the Global context so a key in both will result in the value from the Environment.

Dynamic Requests

Postman supports dynamic values in the request with access to variables in the environment. This special syntax {{key}} allows you to use dynamically evaluated URLs, authentication usernames and passwords, and payloads. All of these can be configured to make accessing local, dev, and qa servers easier.

Setup a "Pre-request Script":

And then configure your test URL with something like:

Note: I had trouble separating the scheme, host, and port number into individual variables and found that when combined they worked.

By testing the environment with

you can override these values by creating and using named Postman environments for local, dev, and qa.

Storing and Evaling Functions with Environment Variables

Another powerful capability is storing JavaScripts or functions in environment variables to promote reuse. Place some code in a string and store it in an environment and use it with eval.

Creating a script to clean your variables at the start of your tests can help avoid unintended consequences of defined environment values in subsequent tests.

Credit goes to for the following:

Finally, if you like this sort of approach, this post might interest you: Writing a behaviour driven API testing environment within Postman.

Just Run a Script

The Postman echo server echoes the HTTP headers, request parameters, payload and the complete URI requested.

I find it useful to use the echo server to test and run scripts for routing and updating environment variables without calling the end-user application. When I just want to execute a script without calling an endpoint I create a test with a script and call:

Alternatively if you don't want to talk to an outside server, you can use an idempotent endpoint of the MarkLogic server such as a HEAD request to

or a GET request to your application port on NNNN

Routing Tables

Under the usual conditions, Postman runs the test requests in the order they exist in the folder. You can change this behavior by calling postman.setNextRequest("testName"). Postman has setNextRequest to route to a specific named next request. It is honored at the end of the current request execution.

Using an empty name halts execution.

You can mix the sequential execution of tests without routing directives with tests that include routing to create sophisticated workflows.

Note: Watch out for duplicate named tests. Postman picks the last one in the collection. Duplicate names can waste your time debugging and looking for the problem.

The benefit of setNextRequest is it provides the opportunity for looping and flow of control in request executions.

Combining the approaches

Look up the current routing step to find the next step, set the step, and proceed to the next request.

So I created individual tests for POST "create", GET "retrieve", and PUT "update". I read and updated XML payloads, made the query parameters dynamic using {{key}}, and lastly used routing to apply them to different endpoints.

As part of a team using Git I found this helpful to know: Postman: Effectively Storing and Using Tests in a Git Repository.


For some Postman versions F11 or View tab "Toggle Full Screen Mode" will cause app to enter the full screen and never be able to exit. A reinstall will correct this problem but will lose your collections and history. Editing the config can restore the view.

Further Reading

Stack Overflow iconStack Overflow: Get the most useful answers to questions from the MarkLogic community, or ask your own question.


The commenting feature on this page is enabled by a third party. Comments posted to this page are publicly visible.