Altova MobileTogether Server Advanced Edition

Workflows

The Workflows tab (screenshot below, showing the Advanced edition) provides an interface for managing the container structure of the root folder of MobileTogether Server and the access rights (permissions) for each container. Containers are folders that contain sub-containers and/or solutions (also called design files or .mtd files). MTD files cannot be added to a container via the server's Web UI, but are deployed to the server from MobileTogether Designer. At deployment, the exact path to a container must be specified; this is facilitated by being able to browse, in MobileTogether Designer, to the required container.

•The Workflows tab initially displays the root container, which is denoted by the "/" character.

•Click the Down arrows next to a container's name to display the sub-containers of that container; click a sub-container in the pop-up list to go to that sub-container.

•To go to a container, click it.

•Every level that you descend in the hierarchy of containers is displayed at the top of the window as a "breadcrumbs" path. The Down arrow of each level displays the sub-containers of that container, so you can navigate easily to different containers.

•To select a container, click the container's check box. Selections are used for renaming, moving, and deleting containers (see Functionality below).

The buttons of the tab provide the following functionality:

Create Container	Creates a container in the current folder. Click a container to open it
Save	Saves changes such as a modification of descriptions
Change	Enabled when a single object is selected. It opens the Change Object dialog, in which you can change the name of the object, assign an icon, and set input parameters (see below). You can also open this dialog by clicking the gear icon to the right of the solution's name.
Move	If multiple objects are selected, opens the Move dialog, in which you can move the object to another container. If only one object is selected, you can, additionally to moving, also rename the object.
Create Link	Enabled when a single object is selected. It opens the Create Link dialog, in which you can change the name of the object, assign an icon, set input parameters, and create a shortcut link for the solution in a different container (see description below).
Delete	Deletes the selected container or file
Lock Selected	A locked solution cannot be overwritten by a new deployment. If attempted, an error message is displayed in MobileTogether Designer
Unlock Selected	Unlocks a locked solution
Permissions	Sets which users/roles can access individual containers, and their level of access
Search	Searches for the term submitted. Check Recursive to search in descendant containers

Other available actions:

•To navigate up the container hierarchy, click the required ancestor folder in the path at the top of the Workflows tab

•To navigate down the container hierarchy, click a container to open it

•Click a solution file's URL to run the solution

Input parameters

You can specify input parameters in the form "Key1=Value1;Key2=Value2;...;KeyN=ValueN". If a value has spaces, use quotes around it. These parameter values are passed to the solution when the solution is started and stored in the solution's MT_InputParameters global variable (for information about which, see the MobileTogether Designer user manual). Input parameters can then be used inside the solution to achieve different goals. For example, if you specify the input parameter "Department=Sales", then it would be possible to filter your database to only show records of the department named Sales.

Note: The MT_InputParameters global variable of a solution can receive input parameters not only from this MobileTogether Server entry point, but also from design-related originating points (see the MobileTogether Designer user manual). In such cases, the input parameters are merged. If the key name is the same, then the value defined for shortcuts in MobileTogether Server wins and will be the value that is assigned to the key.

Create shortcut link

You can create a shortcut link to a solution and place the shortcut link in a container that is not the same as the one containing the solution. This enables a solution to be accessed from different containers. The advantage of this is that by using different input parameters for each shortcut link, you can cause the solution to appear in different ways when opened via different shortcut links. For example, you could create a shortcut link in a container named Sales and give it an input parameter "Department=Sales". In the solution, you can specify that when the solution is opened it will be filtered on the value of the department name in its input parameter. So, when the solution is opened via the shortcut link in the Sales container, the solution's records will be filtered to show, because of its input parameter, only the records of the Sales department. You could create other shortcut links in other containers (say, fro Accounts or Legal), and set corresponding input parameters for them. When the solution is opened via these links, the records that are displayed would then be filtered for the appropriate department. The solution that is opened in all these cases would be the original solution. The shortcut link feature enables you to present and process the solution in different ways according to the input parameters corresponding to the shortcut link.

Alternatively to the example case described above, the availability of parameters enables various other scenarios. For example, one powerful use case would be the possibility of using an alternative database for the solution.

Note, however, that in all these cases, what happens when the parameter value is passed to the solution depends entirely on how the parameter is handled in the design.

Note:

If, after a shortcut link has been created, you remove one of its parameters or change the value of any parameter in the dialog above, then you might also need to remove the solution's persistent data in order for the parameter modification to take effect. You can remove a solution's persistent data by clicking the Clear button in the solution's Persistent data column (see below: The display of a container's contents).

Whether it is necessary to remove persistent data or not depends on what has been defined to happen when the parameter value is passed to the solution. If the parameter value has a consequence that is stored as persistent data, then you might want to clear persistent data; otherwise, it is not necessary. Note also the converse effect of removing persistent data. In this case, the solution will not have access to persistent data. It will try to use data supplied via parameters and, if this data does not substitute well for the removed persistent data, then the solution could start with some data missing or with inappropriate data.

A container contains sub-containers and/or solutions (aka design files or .mtd files). The contents of each container are displayed as a tabular list. The columns of the table display the properties of solutions:

•Name: Name of the solution file as saved in MobileTogether Designer.

•App, App version: The App and App Ver columns (see first screenshot at top of page) appear only if at least one AppStore App (see the MobileTogether Designer user manual) has been deployed to the server. They display, respectively, the name of the AppStore App and its version.

•Description: Short description of the solution.

•Design Version: Version of MobileTogether Designer in which the solution was created.

•Last Deployed On: The date and time of the solution's last deployment.

•Global Resource Configuration: The global resource that has been defined for that solution and deployed to the server. If no global resource is specified, Default is displayed.

•Language: If the solution is a service solution, then a button with dropdown options for selecting the solution's language is available. The items of the dropdown list are: Auto plus the names of the languages defined in the solution. Select the language you want to use. If you select Auto, then the language of MobileTogether Server (the server language) is used as the solution's language. If the solution has not been localized in the server language, then the default language of the solution is used as the solution language. If the default language of the solution was not explicitly given a name in the design, then it is represented in the dropdown list as Default.

•Persistent Data: A Clear button appears in this column if data has been changed while running the solution and persists in the solution. Click this button if you wish to undo the changes. Also see the note in the Functionality section above | Create Shortcut Link.

•Automated Test: A blue wheel indicates that at least one test run for automated testing of that solution is available, but is not active. A red wheel indicates that at least one test run of the available test runs is active. To activate a design's test run or configure how the test run is played back on the client, click the solution's wheel icon (shown in the screenshot above). This displays a page showing the automated tests of that solution (see next section below). Clicking the wheel in the column header filters the display to show only those solutions in the current folder and descendant folders that contain automated tests. For information about Automated Testing, see the MobileTogether Designer documentation.

•Run in Browser: The server URL where the solution file is deployed. Click to run the solution. If the solution defines server services, click the Service config button in this column to access the service's configuration interface. (For AppStore Apps, no URL is displayed because the AppStore App cannot be opened in a web browser.)

When you click the wheel icon in a solution's Automated Test column, a configuration page is displayed that shows the automated tests of that solution (screenshot below).

The Automated Tests page shows all the test runs that have been deployed for the selected solution. You can set up individual test runs for playback on client devices as follows:

1.In the Active column, check the test runs that you want to make active. These test runs can then be played back on the client. If multiple test runs are selected, then all the selected test runs will be played back when automated testing is started on the client. If any one of a solution's test runs has been activated, then, on the Workflows page, the wheel in the design's Automated Test column is displayed in red. If you want to play back a test run on the Web client, then on the Workflows page, click the Playback icon in the solution's Automated Test column.

2.Set the speed of the test run in the Run Type column. You can set the speed for all test runs at once by selecting the speed in the dropdown list of the column header.

3.Set the logging details you want during playback. Do this by checking the columns you want. See the Automated Testing section in the MobileTogether Designer documentation for information about these options.

4.Click Save to finish.

If you wish to delete a test run, select its check box in the leftmost column and click Delete Selected.

Permissions

In the lower part of the Automated Tests page (screenshot below), you can specify: (i) what users and roles can run automated tests for the selected solution (in the Security tab), and (ii) the devices on which test runs can be carried out (selected in the Devices tab).

•Users and roles are selected in the Security tab, devices are selected in the Devices tab (see screenshot above).

•To assign a user/role or device to the Allowed list, select it in the left pane and click Assign (see screenshot above).

•Remove a user/role or device from the Allowed list by selecting it and clicking Remove.

•You can assign or remove multiple selections at a time.

•If no device is assigned to the Allowed list, then test runs for that solution can be run on all devices.

Note: All automated tests that were deployed prior to an upgrade of the server to version 4.1 (released 27 February 2018) or later will get security permissions for all users/roles; that is, all users/roles can run automated tests, which is the same behavior as that prior to the upgrade. For automated tests that are deployed subsequent to an upgrade to version 4.1, security permissions are set for no user/role; that is, any user or role that may run automated tests must be explicitly specified.

Permissions are access rights, and they can be set for each container individually. Permissions determine which users or roles have access to that container, and what kind of access each user/role has (read, write, use). These access rights can be set for the container, its workflows (or solutions), and read/write security.

Permissions are checked for every user interaction. A user can only successfully access and/or edit when all required permissions are granted. Permissions are set for the following groups:

Container

•Read: The user can list the contents and find an object in the container.

•Read-Write: Additional to read, can create new (and delete existing) objects, depending on other permissions that may apply.

•Inherit: Inherit permissions from the parent container.

•No access: Access to the container is not granted.

Workflow

•Read-Use: The user can run solutions.

•Read-Write-Use: The user can additionally overwrite solutions, that is, deploy solutions.

•Inherit: Inherit permissions from the parent container.

•No access: Access to workflows is not granted.

Security

•Read: The user is permitted to read the permission list of any child object of the container.

•Read-Write: The user can additionally change the permissions list of any child object of the container.

•By default a user is permitted to read only permissions assigned to it or a role it is a member of. If the Read Users and Roles privilege is granted (see Users and Roles), users can read all permission entries.

•Inherit: Inherit permissions from the parent container.

•No access: Access to the permission list is not granted.