Retargeting is accomplished through scripting, usually as a response to a button press or other component event. The system.util.retarget() function allows you to 'retarget' the Client to a different project and/or different Gateway. You can have it switch to another project on the same Gateway, or another Gateway entirely, even across a WAN. This feature makes the vision of a seamless, enterprise-wide SCADA application a reality.

The retarget feature will attempt to transfer the current user credentials over to the new project / Gateway. If the credentials fail on that project, the user will be prompted for a valid username and password. Once valid authentication has been achieved, the currently running project is shut down, and the new project is loaded.

You can pass any information to the other project through the parameters dictionary. All entries in this dictionary will be set in the global scripting namespace in the other project. Even if you don't specify any parameters, the system will set the variable _RETARGET_FROM_PROJECT to the name of the current project and _RETARGET_FROM_Gateway to the address of the current Gateway.

Retargeting can be as simple as 1 line of code, just make sure you are using the project name (no spaces allowed), and not the title. See the retarget function in the appendix for more information.

# retarget to another project on the same gateway
# this script can be run from any button in a project
system.util.retarget("My_Other_Project")

Testing Local Fallback

Testing local fallback is highly recommended before you start to depend on it in a production setting. The easiest way to test fallback is to simply unplug the network cable to the Client machine, or disable the network card on the machine. If the Fallback Project button is not visible on the Gateway Connection Lost window, check your local Gateway console and verify that the message Started Fallback Socket on port 6501 is present in the console. Any other error message related to the Fallback Socket Controller indicates that some other problem has occurred (most likely the port cannot be reserved) and local fallback is not available to Clients.

Reconnect to Central

In many circumstances, the communication loss to the central Gateway is only a temporary event. To minimize the amount of time that you need to run the local Client, you can add some functionality to the Client that allows you to check on the status of the central Gateway. One way to do this is to add a timer script to your local Client. The script calls the system.util.getGatewayStatus() function at regular intervals and updates an item such as a Client tag with the Gateway status. Then, you can bind an indicator component to the Client tag and get ongoing visual feedback on the central Gateway status. As soon as you can confirm that the central Gateway is running again, you can call the system.util.retarget() function in a button to seamlessly direct the Client back to the central Gateway.