Altova MobileTogether Designer

The Lock/Unlock Clients action is useful if you want to lock the clients of a solution from accessing the server. This might be the case, for example, if you want to update a database on the server with new data. In such cases, you can lock off the server for all clients of the solution, carry out the server-side actions that the locking client initiates without interruption from other clients, and then (when done) unlock the server for all clients of the solution.

Lock Clients

The Lock Clients action (screenshot below) locks clients of the current solution from server access.

The following settings are available:

•Acquire Timeout: Specifies the maximum amount of time in seconds before the server is locked for clients of the current solution. If no client of the solution is currently accessing the server, then the server is locked immediately. If clients are currently accessing the solution, then a lock is attempted when the timeout period expires. If the server cannot be locked, an error will be returned. You can set up actions to deal with such an error (see Error processing below).

•Lock Message: This is the message that will be displayed to clients that try to connect to the server while it is locked.

Unlock Clients

The Unlock Clients action (screenshot below) enables clients that have been locked from server access to access the server again. You can specify whether other clients must be restarted or not (the default value for this setting is true). Restarting other clients of the solution would enable them to receive the latest changes on the server.

Typically, you should set an Unlock Clients action as the final action in the set of server actions that are carried out after locking the server. However, even if you do not set an Unlock Clients action, the server will still be unlocked for clients after all the server actions have been carried out. In this case, an error will be reported and all clients are restarted.

Error processing

The On Error option lets you define what should be done if an error occurs. Since the error handling can be precisely defined for this action, errors on such actions (that provide error handling) are treated as warnings—and not errors. The advantage is that you do not need to check errors on actions for which error handling has already been defined. The following error handling options are available:

•Abort Script: After an error occurs, all subsequent actions of the triggered event are terminated. This is the default action if an error occurs. If you wish to continue despite an error, select either the Continue or Throw option.

•Continue: Actions are not terminated. Instead, you can select what to do in either event: when there is no error (On Success), or when there is an error (On Error). For example, you might want to display a message box saying whether a page load was successful or not.

•Throw: If an error is detected, this option throws an exception that is stored in the Try/Catch action's variable. The Catch part of the Try/Catch action is used to specify what action to take if an error occurs. If no error occurs, then the next action is processed. See the section Try/Catch action for details.

MobileTogether extension functions

MobileTogether provides a range of XPath extension functions that have been specifically created for use in MobileTogether designs. Some functions can be particularly useful with specific actions. For example, mt-available-languages() returns the languages in which the solution is available and could, for example, be used with the Message Box action. If a function is especially relevant to this action, it is listed below. For a full list of extension functions and their descriptions, see the topic MobileTogether Extension Functions.