Developer Documentation

You have your test users set up on the Developer Cloud Backoffice site for yourself and for the User A - User B scenario to test your workflow script. It's the system engineer's job to make sure that there is an account on the Production Cloud for every real-life user who will be using the forms that you developed.

The Production Cloud Backoffice site works just like the Development Cloud one, you can add all the necessary user accounts you need on the Users tab using the New user link. However, with the hundreds, or even with the few dozen user accounts in a corporate environment, this can get very tedious very fast.

The Mobilengine SDK offers a handy option for setting up lots of mobile form user accounts in a single step. An administrator-level Backoffice user can access the Bulk import option on the Users tab. The User import dialog that pops up when she clicks the Bulk import option, Mira Jansen can first download the Excel template for the new user accounts, and then import the filled-in template file when she has added all the users she needs.

Figure 145. The Users → Bulk import feature lets administrators and devs download the user accounts template and upload the details of their mobile workflow users

The template spreadsheet behind the Download template link has 9 columns, of which 4 are required for mobile users. The column names are mostly self-descriptive, but you'll find everything there is to know about the user import template in the reference library.

Figure 146. The header of the empty user import template

Select the Send download link in SMS option to send the new users, via text message, a download link to the .apk file for their Android app, or the direct link to the Apple Store for iOS users .

Assuming that Mira needs to set up accounts for the 9 users included in this user import spreadsheet, this is what the Users tab of her Backoffice site will look like after she imports:

Figure 147. The list of freshly created users on the Rocky Jupiter Backoffice site

As you can see, virtually all the columns in the user list are empty, because these users are brand spanking new: none of them has any forms assigned to them (remember, there are no forms to assign yet), and none of them has signed in to the Mobilengine mobile client app.

The Rocky Jupiter Backoffice is now ready for a workflow solution.

When she receives the compiled solution (the .mes file from the previous section) from you, the system engineer needs to add the actual real-life reference data that the solution will work with. This is probably some sensitive company-specific data that she doesn't want an outside developer to have access to. She has to do this herself, using the mebt tool and the package command.

To bundle the reference data up with the RockyJupiter.mes file, Mira Jansen needs to run the packagemebt command on it from the command line, after she has navigated to the directory where she saved the compiled Rocky Jupiter solution.

The template for the package command that she needs to use after setting up the mebt is mebt package mes-file [xlsx-file].

The client's system engineer will use the mebt only when a new (or updated) solution needs to be published, so she does not need to have her instance-specific data added to the environment variables. This means that she'll need to enter the URL, her username and the code that her company has been assigned in the SDK every time she uses the publishmebt command.

The Excel spreadsheet with worksheets that correspond to all the necessary reference tables for the solution is optional, since not every workflow solution will use reference data, and sometimes the forms in a solution change and need re-publishing while the reference data stays the same.

c:\RockyJupiter>mebt package RockyJupiter.mes database.xlsx
mobilengine srv 22.0 (Release) v22.0.157.14908
Executing package (build dpkg package from a mes and an optional xlsx with reference data):
Done.

The output of the command is a solution deployment package with the .dpkg extension, ready for publishing to the Production Cloud.

The standard way to publish a packaged solution to the Production Cloud is to use the publish command. The template for the command is mebt publish <options> dpkgFile, where the <options> are

.

When you created the forms, you used the runmebt command to publish your forms to the Developer Cloud. This command is a one-stop shop for publishing to the cloud, since it's compile, package, and publish all in one.

It will work on the Production Cloud too, but it isn't recommended, because not only does it publish the solution artifacts in the specified folder, but it also automatically assigns them to all of the users currently set up on the Backoffice site. It is highly unlikely that each and every registered user of the Mobilengine app needs to have all of the forms of a published solution on their mobile device - in the present case, Vehicle Inspection and Driver Task List should be deployed only to the truck driver employees.

The other disadvantage of the run command is that there is no way to do a test run before actually publishing the solution to the live Production Cloud.

publish has a --preview option that is a dry run of a real publish process. If it is included in the publish command, the mebt lists every step that it would perform but does not in fact make any changes. The system engineer is able to review all the files that would be modified, created, or deleted as part of the real publishing process and notice if anything's fishy before committing to the live server.

c:\RockyJupiter>mebt publish -s:https://rockyjupiter.mobilengine.com
-u:mirajansen@rockyjupiter.com --preview RockyJupiter.dpkg
mobilengine srv 22.0 (Release) v22.0.157.14908
Executing publish (upload a dpkg to the server):
Service url: https://rockyjupiter.mobilengine.com
User: mirajansen@rockyjupiter.com
Password:**********
Create reference table 'assignments'
Create reference table 'cargoTypes'
Create reference table 'contact'
Create reference table 'parts'
Create reference table 'vehicles'
Reset integration settings
Import form contacts
Import form workflowDashboard
Import form load
Import form unload
Import form vehicleInspection
Import rfs confirm
Import rfs load
Import rfs unload
Import reference tables
Done.

Great. Nothing is missing, the solution can be published. The very same command, with the --preview option deleted, this time, is all that the system engineer needs to call.

c:\RockyJupiter>mebt publish -s https://rockyjupiter.mobilengine.com
-u mirajansen@rockyjupiter.com RockyJupiter.dpkg
mobilengine srv 22.0 (Release) v22.0.157.14908
Executing publish (upload a dpkg to the server):
Service url: https://rockyjupiter.mobilengine.com
User: mirajansen@rockyjupiter.com
Password:**********
Create reference table 'assignments'
Create reference table 'cargoTypes'
Create reference table 'contact'
Create reference table 'parts'
Create reference table 'vehicles'
Reset integration settings
Import form contacts
Import form taskList
Import form load
Import form unload
Import form vehicleInspection
Import rfs confirm
Import rfs load
Import rfs unload
Import reference tables
Processing table 'assignments'
Rows added: 25, deleted: 0, modified: 0, empty: 0.
Processing table 'cargoTypes'
Rows added: 5, deleted: 0, modified: 0, empty: 0.
Processing table 'contact'
Rows added: 15, deleted: 0, modified: 0, empty: 0.
Processing table 'parts'
Rows added: 22, deleted: 0, modified: 0, empty: 0.
Processing table 'vehicles'
Rows added: 6, deleted: 0, modified: 0, empty: 0.
Done.

Don't take the mebt's word for it: if the admin now check the Input data or the Forms tab of the Backoffice, the reference tables and the forms for the solution will all be right there in the Cloud.

Figure 148. The Input data tab lists the reference tables that the published solution uses

The forms are also sitting pretty on the Forms tab, but alas, not a single user account is using any of them.

Deploying the forms to one or more users is, as mentioned earlier, not part of the publish command. The system engineer needs to deploy the forms to the users that need them separately.

Figure 149. The Forms tab lists all the forms that are part of the published solution

Tell Mira Jansen that all she needs to do at this point is click the number in the Users column on the Forms tab, and select the users that need the forms grouped into the driver form group. When she clicks OK in the Who will use this package? dialog, the forms in the group will be downloaded to the selected users' devices at the earliest opportunity.

Figure 150. Click the number listed in the Users column on the Forms tab to start deploying the forms to users

To recap, here's what the system engineer needs to do to get a Mobilengine workflow solution up and running: