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:
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
|
Clicking the public container opens the container and displays its contents. public is a predefined container containing sample design files (solutions) that are delivered with the program. Click a solution's URL to run it.
|
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 Data button appears in this column if data has been changed while running the solution. Click the button if you wish to undo the changes. •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.
PermissionsIn 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.
|
