Calling other projects

This chapter requires good understanding of project parameters explained in the previous chapter of this tutorial.

In EasyMorph one project can call (run) another project, which is similar to using subroutines in programming languages. It might be convenient in a number of cases:

  • Move out part of a calculation logic into another project to reduce calculation complexity.
  • Execute the same calculation logic required in different parts of a project.
  • Execute the same calculation logic in different projects.

Calling another project

Use the Call action to call another project (subproject). With this action you can assign parameters of the subproject (if needed). Parameters of the subproject can be assigned either as constants, or using parameters of the calling (parent) project. Note that parameters must already be created in the called project prior to their assignment in the Call action (see the previous chapter how to do it).

Returning a dataset from subproject

The Call action can run in one of the two modes:

  • Do not return result table — in this mode nothing is returned from subproject and the output of Call action is the same as its input. This mode is typically used when the subproject performs export operations or runs a Windows shell command (e.g. copies a file). A and B in the image below denote some parameters.
  • Return a table — in this mode a final dataset of particular table is returned from subproject. It becomes the output of Call action.

Advanced topics

The "Input" action (not available in the free edition)

It is possible not just return datasets from subprojects, but also pass datasets from parent projects into subprojects with the help of the "Input" action. This action should be inserted in the called subproject as a starting point of calculations. When inserted the action returns nothing. But when the subproject is executed, the Input action obtains the input dataset of the Call action of the calling (parent) project.

With the help of the "Input" action it is possible to arrange two more ways of calling subprojects:

To simplify development and debugging, it is possible to copy a dataset from one project and paste it into an Input action (similarly to Sandboxes).

Reusable projects and custom actions

The ability to encapsulate a calculation logic into a subproject that can be used in many other projects enables creating reusable projects (which are effectively custom actions). Such reusable projects can be convenient in various scenarios. For instance:

  • File operations: copying, deleting, renaming, archiving, etc. In this case subprojects run respective Windows shell commands generated using project parameters.
  • Common data quality checks. In this case subprojects frequently contain a Halt action to abort execution if some data quality checks are not passed.
  • 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.

Read next: Iterations