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:
Touchstone first looks for
USER_KEYin 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_KEYas 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_KEYmatching 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.
Touchstone then looks for
ORG_KEYin the request header (if
USER_KEYis 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_KEYmatching 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_REQUESTfor the entire organization. Use of USER_KEY does not have this limitation. When using
USER_KEY, multiple test executions can be in
WAITING_FOR_REQUESTstatus for the organization but each user can still have only one test execution in
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.
ORG_KEYare 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 Requeststatus. 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:
Origin IPas 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.