The CALL OTHER PROJECT operator allows another GRAVITY project to be invoked as part of the current data-processing workflow. The selected project is launched from within the operator, and its resulting data stream is fed into the operator’s output data bus.
The operator enables:
- a modular design approach enabling reuse of previously defined processing logic,
- multi-layer data processing, by invoking child projects as part of a larger process,
- parameter passing and result integration, allowing the operator to use data bus bits and parameters from the parent project as inputs to the invoked project.
The project invoked by the operator should be prepared to function as an independent processing component that meets the expectations of the parent project.
The CALL OTHER PROJECT operator is a counterpart to the 
INPUT OTHER PROJECT operator, and its configuration and functionality are largely similar.
An example of a project using the CALL OTHER PROJECT operator:
OPERATOR CONFIGURATION
By default, the child project is invoked for each record of the input data bus, and input parameter mapping is performed based on the record currently being processed.
By enabling Single execution mode, you decide to change both how the child project is invoked and how its input parameters are created.
In this mode, the child project is invoked only once for all records of the data bus. As a result, to allow data bus values to be passed, each data bus bit is converted into an array type containing the values of that bit from all records. To ensure that the child project can accept array data, its parameters that receive values from the data bus must also be defined as array types (Array integer, Array String, etc.)
In the OTHER PROJECT CALL operator, you must declare the GRAVITY project to be invoked as a child project using the Concept model to call field.
You must also specify an OUTPUT operator—the output operator of the invoked project—whose output data will be sent to the output data bus of the calling operator.
Additionally, you can decide how to handle the child project’s output data by choosing the appropriate option in the RESULT TARGET field (depending on which output operator is selected in the child project).
Available options:
- Value from first row to the existing columns – this option allows the values of the bits from the first record returned by the child project to be inserted into the already existing bits of the currently processed record on the input data bus.
- Create busbar from the result – this option creates a new output data bus based on the data bus of the selected output operator (the Output field) of the child project.
- Add to the busbar the data from the result – this option adds bits originating from the child project’s Output operator to the existing data bus.
- Ignore result – the result of the child project’s execution is ignored, and the output data bus remains identical to the input data bus.
After selecting this option, you will see an additional Column matching tab, where you can map the input data bus bits to the bits returned by the child project.
The number of records on the operator’s output data bus will be the sum of the records returned by all invocations of the child project.
The number of records on the operator’s output data bus will be the sum of the records returned by all invocations of the child project, and the values of the input data bus bits will be duplicated as many times as the number of records returned by the child project for the currently processed input record.
The Transaction mode field allows you to determine how transactions are created for the database connections used in the projects.
- Use transaction from main project → passes all transactions started in the parent process to the child process, and all transactions started in the child process are propagated back to the parent process. All transactions are committed after the parent process completes successfully and rolled back if it ends with an error.
- Use separate transaction → the invoked process manages its own transactions. It opens transactions for all database connections, which are committed if the process completes successfully or rolled back if an error occurs.
PARAMETER MAPPING
The invoked project may define parameters required for its execution. These parameters may have different names or may not exist in the calling project. You need to map the parameters of the invoked project to parameters or data bus bits of the main project.
Note that when Single execution mode is used, data bus bits are converted to an array type. Therefore, pay close attention to the parameter definitions of the child project.
To map parameters, select the Parameters mapping tab.
In the Called parameter name field, select an input parameter of the invoked project from the list and in the Source field, select the corresponding parameter or data bus bit from the main project.
Remember that parameter types must match. Otherwise, the system indicates a type mismatch with an exclamation mark.
Entries can be removed by right-clicking the record.
STOP PROCESS, operator, rather than at the operator specified in the Output field, the main project will continue, and the result of the child project invocation will be passed to the data bus only in the following cases:
- the Transaction mode field of the calling operator is set to Use separate transaction, and the Action field on the STOP PROCESS (in the invoked project) is set to Stop processing with success and commit or Stop processing with error and rollback.
- the Transaction mode field of the calling operator is set to Use transaction from main project and the Action field on the STOP PROCESS operator (in the invoked project) is set to Stop processing with success and commit.
- in all other cases, the calling project will be interrupted, and the execution result returned will follow the Action setting of the STOP PROCESS operator.