TS Synthetic - Timeouts showing as Execution errors rather than Availability errors

Version 1

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    Borland Silk Performer Synthetic Transaction Monitoring


    Borland Silk Performer Synthetic Transaction Monitoring for BMC Software


    Synthetic Monitoring


    Sometimes Remedy is running slow and fails to respond. As a result the execution exceeds the 15 minute timeout period within TrueSight. This triggers an execution error within the system. Since the application is failing to respond it should return and availability error. If the 15 minute application timeout hadn't triggered the execution error we would have ended up with the correct type of error as the true log shows the error "WebEngine: 42 - Operation timed out!, RecvHeader second attempt" right before TMain timed out. Is there a way to prevent execution errors from being thrown when an application is timing out?
    Need to code the script to raise an availability error when an action times out.


    1) You can change the timeout within Silk Performer using the WebSetTimeout function. It can be configured for both sending and receiving timeouts.

    You might also want to have a look at Active Profile | Web (Protocol level) | Simulation | User tolerance.

    If you move the slider down, it enables the 'Customize' button. Here there is more control over how the user behaves in certain scenarios. Of course that is a profile-wide setting, so if WebSetTimeout works better then it's probably the best option.

    You also have the option of using ErrorAdd to control the severity of any error. You could potentially use this in an event handler:

    2) Remedy is just like other web applications in terms of using HTTP (it just uses its own XML structure). So if the server response is slow, changing the options in the user tolerance should work but that is script-wide (since it's the Active Profile).

    For a more controlled / targeted method, WebSetTimeout is best. The WebSetTimeout(WEB_TIMEOUT_RECV, 60000);  should go before the problematic call but you may want to change it back after the call so it doesn't apply to the rest of the script.

    Article Number:


    Article Type:


      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles