The Testing tab of the end point Editor lets you send requests to your end point and inspect the response from it.
You can test your end point against any selected target end point worker, using any valid API Server and supply authentication credentials if the worker is secured.
The test request parameters can be automatically generated from your schema (if you have one) or be set as any valid JSON object structure. Tests can also be saved for future use.
Performing a Test
The test configuration section will be automatically populated with sensible defaults. If you want to change these, see the documentation at the end of this article.
Request Parameters
If your end point does not expect to receive any parameters, pass it an empty object, like this:
{}
Otherwise, construct a JSON object of name/value pairs. In this example the end point is expecting params.articleID to perform a get request on an article ID passed to it:
{
"articleID": 1
}
If you have created a parameters schema, click "Get request parameters JSON" in the action panel. This will provide a valid JSON structure with some example values that meet the schema's requirements.
The Test Button - What Happens?
When you press the test button, iCM does several things, depending on the current state of the end point and the changes that have been made.
Changes to Published End Points
If your end point is already published and you have made changes to the script, target information, schema or name, iCM will enable development mode and republish before performing the test.
This means your end point won't be cached and you can disable version history (which you might like to do if you are carrying out lots of tests).
The call made by iCM will also include the current version number, for example
Testing Without Changes
If you haven't made any changes to the end point, other than the test request parameters, it will not be republished. This means you can safely check that an end point is behaving without disrupting anything else that calls it and without adding to the version history.
Understanding the Response
Hopefully your response contains the result you were expecting. If not, there are several tools you can use to help track down any errors.
The first step should be to enable additional tracing in the Target tab.This will write the trace output of any
The test request action panel includes a link to the API Server Console (if your user has enough privileges to access it). The console displays the trace information mentioned above and can also be used to enable additional tracing for the Ajax/Server library workers and any other workers your end point is communicating with.
Saved Tests
You can save a test so it can be re-run later. Click the "Add to list" button at the far right of the "Available tests" configuration section. You'll be prompted to give it a name. Your end point will need to be saved/published for the tests to be available next time you edit the end point.
Saved tests can be loaded by selecting them from the drop-down list.
The "Update in list" button can be used to update or overwrite a currently saved test. "Remove from list" deletes a test. Remember to save/publish your end point too.
Saved tests save all of the configuration settings and parameters you define.
Test API Server
By default the API Server local to your iCM installation will be used for testing. If your iCM is in a clustered environment, or you have a remote API Server deployed in a different network (typically accessed over a VPN), you can select it here.
This list is populated with the API Servers configured in iCM/API Servers.
Test Worker
The workers listed here are those selected on the Target tab.
Request Authentication
Before you can test an end point, the authentication requirements for the worker being used for testing need to be honoured. In most cases, authentication will not be needed. API key and user authentication are configured in the API Server Security section.
iCM will automatically populate the list of API keys when a test worker is selected (ie any keys your chosen worker is bound to will be listed). If key access is enabled, select the unique API Key that should be provided when testing the end point. A "No key" option will be included in the list if keyless access is permitted.
If user authentication is enabled, the name and password for an iCM or Site user can optionally be provided. It is important that you only use credentials that you are happy for other users to see as these will be saved with your test.
Share this page
