INPUT OTHER PROJECT

The INPUT OTHER PROJECT operator allows you to invoke another GRAVITY project within the current process and place on the data bus the data stream produced as the output of the specified project. This operator runs once—at the start of processing—just like other input operators.

This operator enables:

Modular construction of complex processes by integrating supporting projects that act as independent processing blocks,
Reuse of logic by eliminating the need to duplicate configuration across multiple places, simplifying maintenance and development,
Initialization of the data bus with data generated by other projects that may first retrieve, aggregate, or validate data,
Logical separation of functionality—for example, checking whether a contractor with a given tax ID exists can be moved to a separate project and treated as a reusable function called from multiple locations.

In practice, the INPUT OTHER PROJECT operator, similar to OTHER PROJECT CALL , supports breaking large processes into smaller, reusable modules. This approach provides several project-level benefits, such as:

improved readability of the main process,
the ability to test and develop selected parts of the system independently,
centralized logic management — changes in the modularized project automatically take effect everywhere it is used.

Typical use cases include validating external data, checking user permissions, integrating with APIs, generating tokens, and transforming or aggregating data before it is used in the main process.

Example of using the INPUT OTHER PROJECT operator:

OPERATOR CONFIGURATION

In the INPUT OTHER PROJECT operator, you must specify another GRAVITY project in the Concept model to call.

This project will be executed automatically during the run of the current project to produce the initial data stream.

You have to also select an OUTPUT operator— the output operator of the called project whose output data will be passed to the calling operator’s output data bus. The data bus will be constructed from the exact same bits as those of the specified OUTPUT operator of the called project.

The Transaction mode field lets you define how transactions will be created for the database connections used in the projects.

Use transaction from main project → It passes all active transactions to the child process, and all transactions started in the child process are passed back to the parent process. All transactions are committed when the parent process completes successfully, and rolled back if it ends with an error.

If an error occurs in the parent process at any stage of its execution, any changes made to the databases by the child process will be rolled back.

Use separate transaction → The called process manages its own transactions. It creates transactions for all database connections and commits them when successful or rolls them back when an error occurs.

If an error occurs in the parent process after the child process has been called, the changes made to the database by the child process will not be rolled back.

For more information on transaction management, see the chapter Managing Database Transactions in a Project.

PARAMETER MAPPING

The called project may have parameters required for its execution.

These parameters may have different names or may not exist in the calling project. You must map the parameters of the called project to the parameters of the main project.

If the main project does not use parameters, but the data you want to pass as input to the child project is available on the data bus, you can use the

OUTPUT PARAMETERS operator to convert that data into parameters.

To map parameters, open the Parameters mapping tab.

In the Called parameter name field, select the input parameter of the called project, and in the Source field, select the corresponding parameter of the main project.

Remember that the parameter types must match. Otherwise, the system will indicate a type mismatch with an exclamation mark.

You can delete entries by right-clicking the record.

Unlike when using the

OTHER PROJECT CALL operator, the child project will be invoked only once.

If the child project ends with a

STOP PROCESS operator instead of the operator specified in the Output field, the main project will continue, and the result of the child project will be passed to the data bus only in the following cases:

The Transaction mode of the calling operator is set to Use separate transaction and the Action field of the STOP PROCESS operator (in the called project) is set to Stop processing with success and commit or Stop processing with error and rollback.
The Transaction mode of the calling operator is set to Use transaction from main project, and the Action field of the STOP PROCESS operator (in the called project) is set to Stop processing with success and commit.
In all other cases, the calling project will be terminated, and the result returned will match the Action field of the STOP PROCESS operator.