No-code services

There are two ways to define your application business logic in Altogic. You can either define no-code services or full-code functions. No-code services define your applications' business logic graphically and are composed of nodes (actions) and relations (links) between these nodes.

The run of service is actually the run of the constituting nodes in a logical flow. By using relations, besides the general flow of the service, the flow of data between the nodes is modeled.

In Altogic, a node is depicted as a rectangle. The name of the node is written on the top portion of the rectangle. In the lower portion of the rectangle, a small user-specified description regarding the specific usage of the node in that particular setting is shown.

Input link points and output link points are shown as small circles attached to the node rectangles. Input link points are attached to the top of the rectangles, while output link points are attached to the bottom. The symbols placed into the link point circle represent the type of the link point.

Relations are shown as solid lines extending from an output link point to an input link point.

Service components

Nodes

Nodes are the building blocks of the service, and they perform the activities on the input data to produce the output data controlled by the user through parameter settings. Example activities of nodes are creating an object in the database, getting a list of objects from the database, sending an email, sorting a list of objects, etc.

Required input data for a node is represented using input link points, while the output data of the node is represented using output link points.

Input link points can get data from output link points through relations with connected output link points. They have special methods for getting and filling their data objects. The following are the different types of input link points used in services.

• Input trigger link point, it is used for evaluating the node readiness
• Input value link point is capable of containing either a list of the same type of data objects or a single data object
• Input list link point contains a list of the same type of data objects
• Input object link point contains a single data object

Output link point is capable of transferring the processed data of the node. The node containing the output link point has a list of relations. This list keeps the connections from the output link point of the node to the input link points of other nodes. Using the list of relations, output link points pass the processed data of the node to the connected input link points.

• Output trigger link point is used for triggering the connected input link points
• Output value link point is capable of containing either a list of the same type of data objects or a single data object
• Output list link point contains a list of the same type of data objects
• Output object link point, it contains a single data object

Each input link point type has a corresponding output link point, which is also true for output link points. These pairwise type similarities are needed to exchange similar data objects between output and input data sources.

Graphically, trigger link points are represented as an empty circle. Object link points are represented as a circle with a single horizontal line inside, and list link points are represented as a circle with two parallel horizontal lines inside. Finally, value link points are represented as a circle with a filled circle inside.

Some nodes have a fixed number of input and/or output link points with specific types, whereas some other nodes are flexible in the number and type of input and/or output link points. For nodes with dynamic input and/or output link points, the number and type of their link points are determined during service design, and you can add as many input and/or output link points to these nodes.

Nodes with dynamic input and/or output link points are represented with thick blue top or bottom borders. In the below example, the "Create Email Message" node has one fixed input object link point and can accept multiple additional input link points. Similarly, the "If-Else Condition" node can have multiple input and output link points.

Relations

Relations are constructed between an input link point and an output link point. They are used for transferring the data represented by the output link point to the input link point, i.e., transferring the output data of a node to another node as input data. If we think of a node as a function, input link points can be viewed as the function's parameters, while output link points as the return values. Not all output link points can be linked to an input link point through a relation. The compatibility of relations between output link points and input link points is summarized below.

Output link point type	Input link point type
Trigger	Trigger
Object	Object, value, trigger
List	List, value, trigger
Value	List, object, value, trigger

There are also specific cases where the data type might also impact the compatibility of relations between output and input link points. As an example, some file management node input link points can only be connected to output link points that contain file objects, similarly some email nodes can only be connected to output link points that contain email objects.

Service types

You can model three different services in Altogic.

Endpoint service

Endpoint services are always associated with an endpoint. When one of the RESTful API endpoints of your application is called, then the associated service is executed. All endpoint request (RESTful API request) parameters and more are passed to the Start node of the service. The input parameters passed include;

• Object identifiers in the URL path
• Query string parameters
• Request headers
• Request body
• Uploaded file(s)
• Client device type (e.g., tablet, desktop) and IP information
• Client session object (if the endpoint is session enabled)
• Application parameters
• General application information (e.g., app name, service execution start datetime, environment name and type, base URL)

Messaging service

Messaging services are used to process messages submitted to a message queue. These services are mainly called from an endpoint service or a task service through the "Submit Message to Queue" node.

Whenever the "Submit Message to Queue" node in an endpoint or task service is run, the inputs passed to this node are wrapped into a message, and the message is sent to the message queue for asynchronous processing. When the queue receives the message, the first eligible message worker picks the message and starts executing the associated service using the message contents as the input to its start node.

Task service

Task services are associated with tasks (scheduled jobs). Tasks run periodically at fixed times, dates, or intervals. Whenever a task is triggered for execution, the associated service is run. Task services do not have any additional input parameters besides app params, and general app info, and their Start node has an output object link point to activate the execution of connected nodes.

Service execution

Running a service corresponds to the sequential activation of nodes and the data flow between nodes. Hence, the major concern in constructing the service running mechanism is the correct timing of node executions.

Input link points hold ON-OFF state information. An input link point is in OFF state if an output link point connected to this input link point by a relation has not served any data yet. Likewise, an input link point's state flag is set ON as soon as an output link point serves data through their relation. A node is called Ready-To-Run if all of its input link points are in ON state and all required node parameters are set.

Each service has a special node called the Start. This node is automatically added to the service, and its task is to trigger (start) the running of the service and provide initial input parameters. Start node has no input link points and one or more output link points.

When the service is run initially, the Start node is executed. Following the start node, nodes connected to the output link point of the Start node and in the Ready-To-Run state are run. The service is run until there are no Ready-To-Run nodes or an error has occurred preventing service execution.

info

Since you can model loops (iterations) in your services, there are limitations in the total number of node executions and duration of service execution to prevent infinite loops. If the total number of nodes executed exceeds a threshold (100K node executions for endpoint and messaging services and 200M node executions for task services) or if the duration of the service execution exceeds a set limit (30 seconds for endpoint and messaging services and 3 hours for task services) then the service execution stops and an error message is returned.