Developer Documentation

You can stop the execution of a workflow script with a specific string message by calling the Error(string-parameter) function anywhere in your script.

If you associate the following sample script with a Mobilengine form, the execution environment will throw an error when it hits the Error statement, and print its error-string parameter.

"This is just a safety drill."

If the script was triggered by a form submission, the data that was submitted in the form that triggered the script is accessible as submission-type structured data via the form variable.

For both webforms and mobile forms, the form submission data in the form variable is a series of nested map objects, one for each submitted form control with an id. The values of the nested map objects in the form object are accessible using their keys and the the dot operator. Here's an example:

A sample webform:

A workflow script that traces the user input in the sample form:

Mobile form submission data are accessible via the form variable in exactly the same way. When submitting the mobile form below,

you can access the submitted user input in the textbox control using the following workflow script statement.

If a workflow script was triggered by an integration message arriving at the server, the structured data in the triggering message is accessible in the script via the dacs built-in variable.

If a sample workflow script was triggered by a statements_rfsref integration message that conforms to the dacsInSchema integration message schema, shown below,

the following script:

could have the following console output:

{
  Foo: {Bar: "hovercraft!"}
}

If the workflow script was triggered by a synchronization event, the endsync variable is available to the script, which contains an event type field named event that represents the synchronization event that triggered the workflow script.

The db variable contains a map object with a reftable type item for each of the reference tables that the workflow script references with a using directive. Each reftable is accessible in the map via its name using dot notation. Each of the items in db is a reftable value: you can access the reference tables in the database by calling one or more reftable member functions on a db item. In the script snippet below, the db variable itself is first traced to the console, and then a row is inserted into the cat reference table. When the contents of the reference table is traced to the console, it now includes the freshly-inserted new row.

"The script has access to the following reference tables", {hovercraft: table, cat: table}
"These are the cats you've got filed away", [
  {name: "Fjord", age: 3, color: "ginger", weight: 2, sex: "female"},
  {name: "Pepper", age: 3, color: "chocolate", weight: 4, sex: "male"}
]

The forms variable contains a map object with a form type item for each of the mobile forms that the workflow script references with a using directive. Each form item in the map can be accessed via dot notation using its name or alias if the using directive assigned it one.

Using the forms variable to access a referenced mobile form in a workflow script, you can assign values to predefined parameters in the mobile form, and make a request to the server to send it to a specific user's mobile client. In the sample below, the popformSample script references the pop form and calls the Pop() method on it to populate its parameters.

Figure 315. The popform is displayed in the specified user's Mobilengine client with the assigned parameter values

See the section on the form.Pop() method for details.

The messages variable holds a map object with a dacstype item for each of the integration message schema (dacsem) that the workflow script referenced in a using directive. Access individual dacstype schema on the messages object using dot notation to create a new dacsout object, then populate and send it using the dacsout.Send() method.

In the sample below, the messages variable is used to create a new dacsInSchema integration message schema, set one of its attributes to a string, and send it to a system integrated to the company account on the Mobilengine Cloud.

The events variable contains a map object with an eventtab item for each of the synchronization events tables that the workflow script references with a using directive. Each eventtab is accessible in the map via its name or alias using dot notation. You can access the synchronization events by calling one or more methods on the events item, and define new events that will be triggered the next time the defined user's mobile client synchronizes its database with the server.

In the script snippet below, the events variable itself is first traced to the console, and then a new synchronization event is created. When the pending events are traced to the log, it now includes the newly-created events.

"Empty eventtab", {sampleEvents: evtabn sampleEvents}
  [
    {user: "petar.hoyt@gmail.com", item: "Water plants"},
    {user: "petar.hoyt@gmail.com", item: "Buy detergent"}
  ]

The company variable holds a map object that stores data about the company account that the workflow script is associated with in the Mobilengine Cloud. SDK client companies all have a private company account in the Cloud where all the user data, solution artifacts, and form submission data are available. company has two keys - the server-assigned unique id, and the full name of the company as it was registered on the Mobilengine Cloud.

"This is the name your company is registered at with us", {id: 102, name: "Rocky Jupiter Transport Company"}

null is a literal that represents an empty value.

undefined represents the absence of a specific value. It is automatically assigned to undeclared variables and missing or superfluous function parameters.