Cloud vs On-Premises (local)

The API Fortress platform was uniquely developed to function in our cloud, or from your own virtual private cloud. This was to allow for customers that have security constraints that don’t allow for use of the cloud version. The entire platform is containerized within a Docker and only takes minutes to deploy.

To trial cloud simply register an account. To trial on-premises please contact sales@apifortress.com to learn more.

Why On-Premises vs Cloud?

There are a few main benefits for choosing on-premises over cloud.

  • On-premises can have access to environments behind firewalls, like staging and preprod.
  • On-premises is unlimited in terms of tests and executions.
  • Load Testing and Mocking are currently only available on-premises.
  • More control over scheduling, database choices, etc…

An on-premises deployment is simple to do. Please contact sales@apifortress.com and we’ll help you get setup.

Easy Monitoring

We always suggest creating comprehensive functional tests, and then scheduling those tests for two reasons. First, it’s a much better monitor of functional uptime. Second, it’s efficient to reuse existing tests. With that said, we understand that some customers just want a simple monitor that validates a 200 is returned, and the performance is acceptable. So, we will show you how here.

For those looking for a written step-by-step guide:

  1. Login to API Fortress
  2. Click Create New Test
  3. Name the test
  4. Click Compose on the far left of the test interstitial page
  5. When in the platform close the tutorial wizard, and then click the HTTP Console button on the left.
  6. Enter the API call and click Send.
  7. Click Generate test.
  8. Click ok on the first two options, but click Skip on the third (create assertions)
  9. The GET call should have been created for you. Now, click Code View at the top right.
  10. Paste this code below the GET call.
    <assert-is expression="payload_response.statusCode=&apos;200&apos;" type="integer"/>
    <assert-less expression="payload_response.metrics.latency" value="350"/> <assert-less expression="payload_response.metrics.fetch" value="300"/> <assert-less expression="payload_response.metrics.overall" value="650"/>
  11. If you look carefully you’ll see that is it straightforward. Confirm the status code is 200, and make sure the latency, fetch (download), and overall timing is below those numbers (in milliseconds). Those are numbers we suggest, but you should adjust as you see fit.
  12. Run the test to confirm it works.
  13. Save and Exit
  14. Click Publish
  15. Click Schedule
  16. Schedule as you see fit. We’d suggest at least the east and west coast every 5mins.

That’s it! Please let us know if you have any questions.

Quick Start Guide – Easy Proof of Concept Steps

You should have received an email with your login credentials from the platform. If you haven’t, please email us at support@apifortress.com.

Note: a video playlist designed to get you started quickly can be found here. If you’d like to trial mocking and/or load testing, please contact support or your API Fortress representative.

3 Phase Evaluation

Phase 1

Phase 2

Phase 3

More Information

All Video Guides: Youtube or Vimeo

Example public APIs to play with:
Retail API
Uber API

Please let us know if there is anything else we can do to help with the evaluation process.

Schedule a Test

Introduction

Scheduling is another unique and powerful aspect of API Fortress. We make it simple to schedule a test to run as often as you’d like, from any location you choose (based on account type), and with granular control as to when it runs. Let’s take a look at how it works.

Step 1: Publish the Working Copy

API Fortress has a unique working copy/published copy system. This system allows you to edit a test without affecting the live, currently active version. You can learn more about it here. Step 1 is to publish your working copy. After you finish editing your Working Copy, click the “Publish” button (highlighted below) to publish it. The individual test should also execute it’s own I/O operations (GET, POST, PUT, DELETE). 

Step 2: Schedule

You can access the Scheduler from the Test Control Panel:

scheduleFromIntersitial

or from the Test List page:

schedulerFromTestList

Step 3: Create a New Schedule

Click + Create New Run on the left side of the screen to create a new scheduled run of your test. 

schedulerTopPageschedulerOverrides

 

Step 4: Fill Out the Fields

Name – This is how you will identify your scheduled test in the future. We’d recommend sticking to the “Test Name – Schedule” convention. A good name would be “Test 1 – Every 10 Minutes.”

Pause Toggle – This will prevent the run from triggering if clicked. 

Try Second Execution Toggle – When this checkbox is selected, another execution will be run after 2m 30s if the initial execution fails.

Downloader – This dropdown allows you to choose which datacenter the request will made from. You can select one or more than one.

Dedicated engine (On Premises Only): If you are using the On Premises version of API Fortress you can select a dedicated engine to run the test from.

Time configuration – This allows you to select when your tests will run. The time configuration system works via intersection. 

Minutes: The minutes of the hour the test is going to run. The minimum                 interval is every 5 minutes but the interval you can choose from                               depends on the account type.
               Hours: The hours of the day that the test is going to run.
               Days: The days of the month the test is going to run.
               Months: The months of the year the test is going to run.

Example: If we set minutes: 5, 15 and days: 1, 5. the test will run every hour at minute 5 and 15, only if the day is either the 1st or 5th.

Variable Override – This is another unique feature of API Fortress. This section allows you to override any variable that is defined in the Global or Data Set sections of the test. One example is to create a new run that executes in the morning and late afternoon where the variable you override is the domain. Therefore, twice a day the staging environment is tested.

At the top of the page:

schedulerGlobal

Test (drop down): The list of all available test for scheduling (all of the tests that are published). You can switch from one test schedule to another without exiting the scheduler page. The first item is the Global Scheduler option. See below for more details.
Pause All/Run All:  The buttons allow you to pause all or run all the scheduled runs with a single click.
Delete Run: Deletes the selected run.
Save Run: Save the run.

 

Global Scheduler

By selecting the Global option from the Test drop down you can schedule a unified run for all or some of the tests available in the project.

Unlike the scheduler for a single test, this one has an additional section where you can select the tests you want to schedule together.

globalSection

Note: The key/value pairs inserted in the overrides section at the bottom of the page will be used for all of the selected tests. If you need to add values for an individual test out of the collectively scheduled tests, you must add them for the single test. To do so, you have first save the scheduled run. Once the schedule is saved, the icon highlighted below will appear next to each individual test. You can add override values by clicking on this icon.

overrideGlobal

Create a Test Quickly

Introduction

API Fortress is focused on API Quality. That means performance, uptime and accuracy. That last part is where we really differentiate ourselves. The metrics of an API call are important, but what we do better than anyone else is help verify the business logic behind the API. It’s more than schema validation, and requires zero coding.

Below, we will show you how to quickly create a test using an e-commerce API.

Let’s get started!

Step 1: Create a Project

When you first log in, you are introduced to the Company Dashboard. The company already contains a project called Examples with some example tests. Click Create Project.

Step 2: Create a Test

Step 3: Choose Your Test Creation Method

Once you have named your test you will be redirected to the Interstitial page. There are two avenues that you may take in building a test. API Fortress is very capable of building a test draft for you. First, you must decide if you want to build a test manually. This can be done from a Spec File, an Apiary account, or using the tool we call Magic. Since this is a quick start guide, we will show you how to use Magic. To build using a Spec file see http://apifortress.com/doc/build-from-spec/, or from an Apiary account see http://apifortress.com/doc/build-from-apiary/.

Step 4: Create a Test Using Magic

Click on Compose.

Next, you will be presented with a tutorial on the Visual Composer. The final screen of the tutorial provides you with more instructions on how to create a test. Close the tutorial and open the Console by clicking on HTTP Client button in the left panel.

For this example we will use our own test API. It’s a simple GET, so you can leave the dropdown as it is and enter the following url:
http://mastiff.apifortress.com/app/api/examples/retail/product?id=611

Once done, click the Send button and the response payload will appear.
SendExample

Now, click the Generate Test icon at the top left corner of the Console to launch the Magic tool.

magicTestGeneration

The following screens will allow you to choose whether you want to create the input set based on the data provided in the request, and if you want Magic to generate the assertions. The final screen summarizes what was done. Press Continue on each screen.

generationProcess

 

At this stage, the test should be considered a draft. You should take a moment to verify each object, and/or add more logic to it. API Fortress has a lot of tools that allow for comprehensive continuous integration testing. Magic Test Generation is great at understanding datatypes and structure, which is often 90% of the work. For an example of adding more intelligence to a test, please see the Appendix at the bottom.

All done!

Learn how to schedule a test here.
Learn about data and notifications connectors here. Simple solutions to plug APIF into the systems you use today (like DataDog or New Relic).

Appendix: A Smarter Test

Furthermore, you may want to add more intelligence to a test to truly verify its accuracy. Let’s consider, for example, a scenario in which the following snippet of the payload is present only under certain conditions:

“shipping”: {
“modes”: [“fast”,”regular”],
“available”:true,
“zones”:”europe”
}

while the payload often contains this snippet:

“shipping”: {
        “available”: false
},

Since the “modes” and “zones” are present only when “available” is true, we could add an IF condition that differentiates the two different scenarios.


Select the assertion (as shown above), then click on the three green dots on the left of that assertion. Choose ‘add component after,’ select the ‘IF’ component, and then type in the “field” this code: payload.content.shipping.available==true

Then, drag and drop the following two assertions (“modes” and “zones”) inside the IF component. Now, these assertions will only be evaluated when “available” is true.


That is one of many examples of the flexibility and power of API Fortress. Nest GET statements together, use the WHILE or EACH component. Almost anything you can think of can be accomplished.

Build from Spec (Swagger / Open API / RAML)

This feature allows you to create a test starting with a specification file.

From the interstitial page, choose the ‘Build from SPEC’ icon.

Note: this process deletes your working copy. Keep this in mind if you are attempting to use a specification file with a test that has already been written.

The available specification files you can choose from are: RAML 0.8, RAML 1.0, Swagger, API Blueprint, I/O Docs, Soap WSDL and Postman Collections.

There are two ways to build a test from a specification file. The first would be uploading the specification file itself. The second would be providing the URL that points to the specification file. The dropdown on the top right of the screen allows you to select your mode.

The file can be uploaded by dragging it into the middle of the window or by clicking on the middle of the window and selecting the file from the popup.

You may also reference the specification file with a URL. Selecting the URL field in the dropdown will open the SPEC URL field.

Once you have chosen the file type and the method, click the Save button and you will be redirected to the next step where the available endpoints are listed in a dropdown. Choose the one that you wish to test and click “Continue.” The test will then be created. You can now make any further adjustments, save and publish it for later use and scheduling.

Note: For RAML, we suggest uploading the entire zip file. Here’s an example video of building tests from a RAML file.