This chapter requires understanding of parameters and groups explained earlier in this
tutorial.
Project modules
An EasyMorph project always has at least 1 module, and may consist of several modules. A project module is basically what you see when you are designing
a workflow. It consists of one or more groups (tabs) that contain tables and charts, and each table, in turn, contains one or more actions. Each module
has its own set of parameters. Data connectors in a project are the same for all modules in the project and can be used in any module.
Such a nested structure allows managing workflow complexity gradually. Simple workflows may have only a few tables in a couple of groups in one module.
Complex workflows may comprise multiple modules and groups, tens of tables, and hundreds (even thousands) of actions.
When a new project is created, it has by default one module that is called "Main". Additional modules can be created in the right sidebar, or in menu
"Design" of the ribbon toolbar. To select another module, click its name in the right sidebar. You can also press Ctrl+PgUp and Ctrl+PgDn to switch
between modules.
So far in this tutorial we used only one module. However, in EasyMorph one module can call (run) another module, which is similar to calling subroutines
in programming languages. It might be convenient in a number of cases:
Move out part of a calculation logic into another module in order to reduce calculation complexity and structure the calculation logic.
Encapsulate and execute the same calculation logic required in different parts of a project (e.g. cleansing data).
Perform a complex calculation/action as part of conditional branching (explained later).
The Call action is used to call (run) another module. With this action, you can assign parameters of the called module, if needed. Parameters of the
called module can be assigned either as constants, or using parameters of the calling (parent) module. Note that parameters must already be created in the
called module prior to their assignment in the Call action (see the previous chapter how to do it).
Returning a dataset from a called module
The Call action can run in one of the two modes:
"Do not return result table" — in this mode nothing is returned from the called module and the output of Call action is the same as its
input. This mode is typically used when the called module performs external operations such as exporting into a database or sending emails. A and B
in the image below denote some parameters.
"Return a table" — in this mode the final dataset of a specified table is returned from the called module. It becomes the output of the Call
action.
It is possible to not just return datasets from called modules, but also pass datasets to called modules with the help of the "Input"
action. This action should be inserted in a called module as a starting point of workflow. When inserted, the action initially returns nothing (i.e. empty
dataset). But when the module is called from another module, the "Input" action automatically produces the input dataset of the "Call" action of the
calling (parent) module. Since datasets are passed between modules in memory without copying or reading from disk, it may significantly improve
performance in some scenarios.
With the help of the "Input" action, it is possible to arrange two more ways of calling a module:
When just created, the "Input" action returns no data (it's also true when the project is just opened). Therefore, in order to design transformations of
data that comes through the "Input" action, the action has to be manually populated with some sample data. The easiest way to manually populate sample
data into the "Input" action is to press the "Populate automatically" button in the action properties (see screenshot below). When the button is pressed,
EasyMorph scans the project, finds a "Call" or "Iterate" action that calls the module, and copies its input dataset into the "Input" action. It is also
possible to copy a result dataset of an action and paste it into an Input action (similarly to Sandboxes), or read it from a dataset file.
Note that the sample data that is visible in the "Input" action is only used for designing a workflow. When a module with the "Input" action is called
from another module, under the hood a temporary clone of the called module and the action is created and executed. This keeps the sample data intact and
allows multiple modules to call the same module simultaneously.
Calling another project
The Call action can also call another project (subproject) in a similar fashion as it can call a module in the same project. As with modules, input
parameters and an input dataset can be assigned to the called project, and a result dataset can be received back from it. When another project is called,
it starts execution from the default module (marked with red flag). The ability to encapsulate a calculation logic into a subproject enables creating
reusable projects that can be used by multiple projects/users. Such reusable projects can be convenient in various scenarios. For instance:
Domain-specific data cleansing and validation.
Complex external actions such as exporting data into a web API.
Advanced calculations done with the help of an external application (e.g. written in Python or C#). The data exchange with the external application is
typically done through text files: the subproject generates a CSV file, triggers the external application which reads the file and produces another CSV
file with calculation results, which is then read back into the subproject. For a calling project, calling such subproject is effectively similar to
using a custom action.
Reusable projects tend to grow into libraries of reusable projects commonly used inside an organization. Note that it's also possible to use the
"EasyMorph Server Command" action in order to run projects (tasks) hosted on EasyMorph Server. Data can be uploaded and downloaded to/from Server using
the same action.
