Introduction
Functions are the basic building blocks of the SimplyWork no-code rules, workflow and forms platform. Functions are used in tools around the SimplyWork platform, such as:
Like a spreadsheet, functions are generic in nature, can be nested for more complex multi-step calculations, and are fully extensible. You can feed any data from any application into a rule (usually by way of a form initiated workflow) in order to build out the steps of your business logic.
Many predefined functions are included in the Functions app, though you can extend or create new functions in most cases for lightweight tasks such as data formatting, common math/date operations, text transformations and other more common tasks.
More complicated functions rely on helper methods deeper within the platform which then handle more complicated tasks.
Functions are categorized into some of the following groups:
- Logical
- Math
- String
- Date & Time
- Calculated
- Analytics
- Database
Example Function Use
Lets look at a simple function to understand how they are used. In this case we'll use the CALC()
function to fetch some values (more on that later) then then the ADD()
function:
# fetch some existing values from a timecard; the hours_worked variables are defined in the CALC function_
num1 = CALC(hours_worked)
num2 = CALC(hours_worked.day)
# now add them
answer = ADD(num1, num2)
Like a spreadsheet, all functions are presented as:
FUNCTION(param1, param2, ... )
and the result of the function can be the nested input to another function, recursively:
FUNCTION(param1, FUNCTION2(param2, FUNCTION3(param3)), param4)
Implicitly the Rules Editor
will further nest your functions into one of several decision actions: START, IF, SET, DO and DONE. So a fully written rule statement might look more like this:
START()
# grab some calculated values
SET(num1, CALC(hours_worked))
SET(num2, CALC(hours_worked.day))
# combine them
SET(answer, ADD(num1, num2))
# now lets compare
IF(answer, >, 40) ->
# subtract 40 from answer to get the leftover
SET(OT, SUBTRACT(answer, 40))
DONE()
You'll notice that when building rule statements you'll never combine parameters and operators into a single cell (e.g. "a + b"), rather they are individually fed into a function: IF(value, operator, value)
results in a true statement, then SET(value, answer)
.
The Rules Editor
will help you manage the decision tree and authoring full collections of rule statements, so all we really want to do here is understand these lowest level building blocks and the types of things you might do with them. Each is covered in detail, along with a list of parameters in the next section.
If you just want to use functions to write rules, you don't have to worry much about the remaining details on this page; the rest is more about showing how a function is created and the underlying Code.
Viewing Function Definitions
Lets take a look at the Functions application, which you can use to review functions and their parameters, even perform interactive tests with sample data.
Open the Rule Functions app under Tools, or use the search tool to find it
Lets take a look at the function edit/builder form
Double click (or tap on mobile) to open any function
Here you can see the details behind the ADD
function. The following table summarizes the various components.
Section | Description |
---|---|
Name, Description | Functions usage name and additional description |
Category | The functional group |
Function return type | Normally this specifies the data type returned by the function, but in some cases it could be undetermined (so is technically optional) |
Code | This is the actual execution of the function. More on this in the next section Function Code |
Example Usage | These are pseudo code examples showing the general use; the Rules Editor will guide you through the specific syntax and usage |
Arguments | The list of arguments or parameters which you will feed into the function. Some arguments are optional, while others will have a list of choices. |
Test Function | An interactive testing tool to try the function |
Arguments
Arguments are generally "typed", meaning that by declaring a datatype
on the argument, the system can help manage the types of data you attempt to stuff into a function, or that what comes out fits nicely into the next function. For example, entering a constant value of 40 could be construed as the integer 40 int(40)
or a string str("40")
. To you and I these are indistinguishable in the app, so the datatype
is used by the rules parsing engine to help convert data between formats and also prevent incorrect parameter use.
While the order of the arguments in this list is not significant, it is best to keep them in the same order as they are presented in the Code
declaration above. The Rules Editor tool will present them to you in the natural order here, so it will be more logical to have the arguments flow in the same order as they are consumed.
Code
After completing the arguments, you're ready to add the actual script to perform the function.
x + y
That's pretty trivial, but a more practical function might be one such as STR_TO_DATE()
who's Code
fragment is:
datetime.strptime(value, mask).date()
The above uses the datetime
class to convert a string to datetime using mask
, then producing just the date component.
The next section, Function Code, covers the Code topic in more details.
Testing
Lastly, you can use the Test Function button to plug some sample data into the function and try it out. Here is the Test Function dialog giving the ADD function a quiz:
Many of the functions are fully testable (String, Logical, Date, Math) though some will fake a response as there isn't necessary live data to access while in the Functions app (e.g. anything DB, Calculated or Analytics related)