Program header

The program header is required at the start of every workflow script. It consists of a required program declaration, which includes a required trigger declaration, and the optional using directives.

Program declaration

Workflow scripts must effectively start with a program declaration.

The program declaration needs to start by specifying the name of the workflow script, and whether it will run in the Mobilengine Cloud, in Mobilengine mobile clients, or in both environments.

The trigger declaration comes next, and specifies the event that starts the execution of the workflow script. Webform and mobile form submissions (using the form keyword), incoming integration messages (using the dacs keyword), and synchronization events (using the endsync keyword) can be trigger events. You cannot specify more than one trigger event for a workflow script.

server|client|(server client) program program-name
for form|dacs|endsync trigger-name

Parameter	Description
program-name (required)	The name of the script.
trigger-name (required)	The name of the mobile form, synchronization event, or incoming integration message, or the identifier of the webform that triggers the script.

server program indicates that the workflow script, when triggered, will run on the server only, and not on any users' Mobilengine mobile client application, and have direct access to referenced database tables.

client program indicates that the workflow script, when triggered, will run in the Mobilengine mobile client application of the user who submitted the triggering form. A limitation of client-only scripts is that they only have access to a snapshot of the database tables as they existed at the time of the most recent synchronization with the given user's mobile client application, possibly modified by previously executed client-only scripts. Another limitation is that client-only scripts cannot send integration messages, or a request to display a mobile form.

The database table data coming from the server always overwrites the database table snapshots that exist on a mobile client application during synchronization. Because of this, client-only workflow scripts practically have a server-only counterpart script that makes similar database changes. Otherwise, the database changes that the client-only script performs would be lost at the next synchronization with the server.

server client program indicates that the workflow script, when triggered, will first run in the Mobilengine mobile client application of the user who submitted the triggering form, and then in the Mobilengine Cloud also. The limitations that affect client-only workflow scripts also apply to server client workflow scripts.

confirm.rfs

client server program confirm for form taskList

using directives

The using directives specify the Mobilengine Cloud resources that the workflow script will have access to.

Workflow scripts may need access to external workflow solution resources to implement the business logic. A workflow script can access and modify one or more reference tables, instantiate, populate, and send outbound integration messages, send the server a request to display a mobile form on a mobile user's client program, or register synchronization events.

(using reftab|form|dacs|eventtab resource-name(as resource-alias)?;)*

Parameter	Description
resource-name	The identifier of the webform, or name of the mobile form, reference table, integration message schema, or synchronization event that the script references.
resource-alias	The optional alias for the referenced resource.

Resource reference directives must be included in the program header of a workflow script, each one on a separate line ending with a semicolon, just as regular statements.

To prevent prossible naming clashes, you can give aliases to the resources that you reference in a directive.

There is no limit to the number of server resources that you can reference in a workflow script directive.

builtInSample.rfs

server program builtInSample for form varSample
using reftab fruit as hovercraft;
using reftab cat;
using dacs dacsInSchema;
using eventtab sampleEvents;

Related links

Language basics

Comments