Execution Matching

When the Touchstone Proxy receives a request from the client system, it has to associate the request to the user’s active test execution. There are three mechanisms in Touchstone to do that and they can be specified when editing the client/origin test system:

1. Touchstone first looks for USER_KEY in the request headers. If it finds it, then it stops looking any further. For client systems that can specify custom request headers, it is highly recommended to keep the default option of USER_KEY as the matching mechanism:

   

   Because each USER_KEY is unique to a user, Touchstone can find the matching active test execution even when there are multiple active test executions from users within your organization. This makes the USER_KEY matching the least error-prone of the three options.

   The instructions on the Test Script Execution’s waiting step are tailored for the matching mechanism chosen on the client test system. When USER_KEY is chosen as the matching mechanims, the instructions are as follows:

   

   You can regenerate your USER_KEY under My Settings if it has been compromised. You’ll know if it has been compromised if your Waiting test executions progress to completion without any action on your part.

   

2. Touchstone then looks for ORG_KEY in the request header (if USER_KEY is missing). If it finds it, then it stops looking any further.

   If it’s difficult for your client test system to specify distinct USER_KEY values for each user within your organization, then using ORG_KEY will probably be easier than using USER_KEY as the ORG_KEY will be the same for all users within the organization. You can select ORG_KEY matching mechanism on the client test system if that’s the case:

   

   The disadvantage of using ORG_KEY though is that only one test execution can be in WAITING_FOR_REQUEST for the entire organization. Use of USER_KEY does not have this limitation. When using USER_KEY, multiple test executions can be in WAITING_FOR_REQUEST status for the organization but each user can still have only one test execution in WAITING_FOR_REQUEST status.

   The instructions on the Test Script Execution’s waiting step are tailored for the matching mechanism chosen on the client test system. When ORG_KEY is chosen as the matching mechanims, the instructions are as follows:

   

   Each organization is assigned a unqiue ORG_KEY by Touchstone. It can be regenerated by the Org Rep on Edit Organization screen if it has been compromised. You’ll know if it has been compromised if your Waiting test executions progress to completion without any action on your part.

   

3. If both USER_KEY and ORG_KEY are absent in the request headers, then Touchstone tries to tie the request to the user’s test execution by matching the actual IP address of the request to the IP address entered for the test system in Touchstone.

   This mechanism has the same limitation as ORG_KEY in that only one user within the organization can execute client-tests at a time.

   This mechanism has a further disadvantage. If the IP address detected is unknown to Touchstone, then Touchstone will not be able to match the request message to the test execution and your operation execution will continue to stay in Waiting for Request status. To work around this, you will always need to keep your IP address up-to-date on the Test System screen:

   

   You can explicitly specify this mechanism as the matching mechanism when editing the client test system:

   

   Doing so will allow Touchstone to tailor the instructions on the Test Script Execution’s waiting step as follows:

   

   Specifying Origin IP as the matching mechanism on Edit Test System screen will also allow Touchstone to enforce constraints on concurrent launches of peer-to-peer test executions by users using the same client test system as the Origin system for the same test script and against the same destination.