Exchanges Screen

This screen is applicable to both Touchstone-initiated and Client-initiated tests. It shows all the message exchanges (interactions) that have taken place between test systems.

For example, you can specify your destination test system and a filter value of >300, >400, or >500 for Response Code to see which exchanges caused your system to return these status codes:

../_images/exchanges_a4.png

Common Errors

Normally, when a client test system sends a request message to Touchstone Proxy, the Test Script Execution screen should progress from Waiting for Request status to Running, and then to Waiting for Response, and finally to Passed or Failed.

Sometimes, even though the request message has been sent to Touchstone Proxy, the Test Script Execution screen continues to stay in Waiting for Request status:

../_images/infinite_waiting.png

You can visit the Exchanges My Org and Exchanges Unmatched screens to look for an error message (in red) that would describe what happened.

Below are common errors that can be encountered:

Invalid origin IP ‘xxxxx’. If this is the IP address of one of your test systems, please register it on Test System screen.

../_images/exchange_unmatched_a3.png

This error can take place if USER_KEY and ORG_KEY request headers were not specified in the request and the IP address that the request came from is unknown to Touchstone. You can correct the IP address on the Edit Test System screen and resubmit the request:

../_images/pp_add_ipaddress_a3.png

Additionally, you can specify Origin IP as the matching mechanism if the client test system cannot specify custom headers (USER_KEY or ORG_KEY) in the request.

../_images/matching_origin_ip_a1.png

On the other hand, if the client test system can specify custom headers, then it is highly recommended to use the USER_KEY matching option and specify USER_KEY in the request header during submission.

../_images/matching_user_key_a1.png

The actual request origin IP ‘xxxxxxx’ does not match any of the IP addresses stored for test system ‘Test System 1’ in Touchstone. This test system was specified as the Origin in Test Setup. Please modify the Test Setup to use the right Origin or add ‘xxxxxxx’ to the list of IP addresses on the Test System screen for test system ‘Test System 1’ or uncheck its ‘Verify origin IP’ flag

This error can be encountered on the Test Script Execution screen after the request message has been successfully matched to the active test execution for the user:

../_images/pp_oper_failed_ipaddress_unknown_a3.png

It can take place if either USER_KEY or ORG_KEY header was specified in the request and the active test execution was successfully matched but the additional origin IP verification failed.

For added security, Touchstone verifies that the the actual IP address of the request matches the IP address of your test system in Touchstone. You get the error above if they don’t.

You can do one of the following to get around this error:

  1. Add the IP address indicated in the message above (10.0.75.1 for the case above) to the list of IP addresses of your test system:

../_images/pp_add_ipaddress_a3.png
  1. Uncheck this box on your test system.

../_images/pp_uncheck_verify_on_testsystem_a2.png

It is recommended to do option (a). If you do option (b), then other users can configure their test setups with your test system playing Origin and submit requests from their FHIR Clients. This will give the impression to end-users that the request came from your test system when in fact it came from another FHIR Client. If you don’t have such a concern (because you have marked your client test system as accessible/executable only by ‘My Org’), then option (b) is more convenient as you don’t have to change the test system’s IP Address in Touchstone every time the IP address of your FHIR Client changes.

No test execution was found with status ‘Waiting for Request’ for the user

../_images/error_no_test_exec_found_in_waiting_a1.png

This error can take place if the user submits a request but has not launched a peer-to-peer testscript execution.

You can launch the testscript execution and wait for it to reach Waiting for Request status before submitting the request again. It is highly recommeded to follow the instructions on the waiting step of the Test Script Execution screen as the URL port and other submission details could be different from what you are submitting:

../_images/submit_the_following_request_a1.png

FAQ

  1. When executing a client-side test script, I have submitted what the system asked me to but my operation execution is still stuck on `Waiting for Request` You can visit the Exchanges My Org and Exchanges Unmatched screens to look for an error message (in red) that would describe what happened. See Common Errors for some of the errors.

  2. When doing client-side testing, do I need to start all over if I submit the wrong USER_KEY accidently? It’s best to click the Execute Again button on your Test Execution screen and start from the beginning. The target system is no longer in the state that your operation execution expects it to be in. Multiple submissions of the request message are still forwarded to the target system and processed. Resource ids and versions would change. So it might seem like nothing happened (because your operation execution still says Waiting for Request), behind the scenes message exchanges are taking place with the target system.

    ../_images/execute_again_a1.png
  3. Why does Touchstone not support restart from a certain point in the test script? It’s painful (especially with client-side testing) to start from the beginning of the script. This is not a limitation in Touchstone. It’s the way the test script specification was designed (see http://hl7.org/fhir/testing.html#execution). The Setup section is executed only once per test script. The Setup section is what enables repeatable and reliable test results. It cleans up the target system from previous resource updates/creates/etc. before launching the tests within the script. If you were to restart from a certain point in the script and not the beginning, the target system will not be in the state that the point you want to restart from expects it to be in. So you’ll most likely get failed assertions and failed tests.