Table of Contents
Hello Newman
So given the STAR method on how to introduce Newman with this effort, here it goes.
SITUATION
We are facing a Production implementation of a FHIRIS® Resource Server, fronted with a robust API Manager, Web Gateways for speed and availability, though not entirely relevant, the implementation is on Public Cloud, namely, Amazon Web Services.
TASK
Considering the implementation we introduced, and all types of optimizations through the layers for the requests, make sure the API doesn't go "Casters Up" for general use and that we didn't introduce any latency we cant tolerate.
ACTION
Build out a repeatable process for checking our production FHIRIS® implementation work, paying attention to two parts:
- Latency between the client and then again to the integration layer, leading up to the durable persisted store, do they look comparable?
- We've introduced an auto-scale group, some load balancing is going on with the web gateways and we implemented an Integration Lambda. Can we identify a breaking point where we throw 502's, more importantly, make sure we don't get any of those nasty 502's ?
RESULT
We'll write a Postman collection, in full disclosure, steal one as a starting point from an ISC Webinar, that can be run interactively for Engineers to tune a production implementation of FHIRIS® and run the same exact suite in CI/CD pipelines with the CLI of Postman, Newman over time as the solution matures.
Features
- Prebaked Collection for use against
r4. - Lots of cool metrics and math to argue about.
- Helps dial in the performance and reliability of your API, and a possible integration layer leading up to the FHIRIS® durable persisted store.
Built With
Getting Started
To get a local copy up and running follow these simple steps.
Prerequisites
Head out and grab Newman in your shell, Newman is a nodejs module.
npm install -g newman
Installation
- Clone the repo
git clone https://github.com/sween/fhirmarshall.git
- Park yourself in this episode
cd episodes/fhirmarhsall_hello_newman
Quick Start
If you just happen to have and endpoint out there and want to get use the collection in this repo, you can run this collection out of the box.
newman run 'hello_newman_fhir_f4_collection.json' -n 5 --verbose --env-var "x-api-key:1UgyzYouHaveBeenRickRolledX1gcqPrjA" --env-var "fhir-endpoint:https://1l17san3dk.execute-api.us-east-2.amazonaws.com/fhir"
If your endpoint is not secured, the apikey var will be ignored anyway and you do not need it.
Also, if you want to turn up the heat a bit and start a tire FHIRIS® on your system, you can spawn some processes and call them "USERS" like this and multiply things with your Newman iterator.
NUMUSERS=5
set -m # Enable Job Control
# Hello Newman.
for i in `seq $NUMUSERS`; do
newman run 'hello_newman_fhir_f4_collection.json' -n 5 --verbose --env-var "x-api-key:1UgyzYouHaveBeenRickRolledX1gcqPrjA" --env-var "fhir-endpoint:https://1l17san3dk.execute-api.us-east-2.amazonaws.com/fhir"
done
while [ 1 ]; do fg 2> /dev/null; [ $? == 1 ] && break; done
Usage
https://www.youtube.com/embed/-Am6Jx6m5oI?controls=0
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
I boiled the usage into an 11 minute stream, but here are the highlights below without the ads.
Create a Collection
Create a Postman collection of FHIRIS® requests, using collection variables for things you use in all the requests, like connectivity and security information, and make use of the awesome dynamic variables to generate random data.
Run a Collection
Run your collection in Postman to tune your implementation interactively, or test the collection for use against a CI/CD pipeline.
Export your Collection
Export your work.
Run the same collection with Newman:
Hello, Newman.
Argue, tune, repeat
Go out and get the metrics generated from your traffic, argue about it, tune and repeat in a process.
