Glossary

Learn the key concepts and terminology definitions of the System Integration Platform.

This page summarizes the core terms of the System Integration Platform for concept reference. The term table is listed below, and detailed explanations for each term are in the corresponding sections.

The System Integration Platform is a unified platform for system integration, data synchronization, API calls, and business process orchestration.

In integration projects, the platform manages external system connections, authentication and authorization settings, Trigger conditions, Action execution, and integration flow orchestration. It also covers field mapping, data transformation, conditional logic, execution testing, run logs, exception troubleshooting, and production launch.

The platform’s core goal is to accumulate integration capabilities scattered across project code, API scripts, manual documents, and human experience into configurable, orchestratable, and reusable platform capabilities.

An integration flow describes how business data moves between multiple systems.

A typical integration flow consists of one Trigger and one or more Actions. The Trigger defines when the flow starts, and the Actions define what operations to perform after it starts.

A typical integration flow may include trigger method, data source, API calls, field mapping, and data transformation. It may also include conditional logic, branching, target system writes, exception handling, logging, and retry mechanisms.

Example flow:

CRM order approved → trigger integration flow → check whether the order exists in ERP. If not, create it; if it does, update it. Record the sync result on success, and log the exception and trigger a retry or manual handling on failure.

The value of an integration flow lies in abstracting complex integration logic away from code or scattered tasks, and managing it uniformly through visualization and configuration.

A connector is a capability wrapper for connecting to a specific type of external system.

A connector typically encapsulates a system’s authentication method, API rules, and executable actions. Implementation consultants or technical consultants can use the system’s standard capabilities directly on the platform, without re-starting from API authentication, request parameters, and response parsing for every project.

A connector typically includes authentication method, API address, request parameters, response structure, and available Actions. It may also include the object model, pagination rules, rate limits, and error code handling logic.

Connectors fall into two types:

A component is a reusable building block that can be orchestrated inside an integration flow.

Connectors generally target a specific system or application, while components target a general capability. Components can be placed into an integration flow and combined with connector Actions, conditional logic, and data transformation.

Common components include the HTTP component, conditional component, field mapping component, and data transformation component. There are also enumeration conversion, loop processing, exception handling, notification, and logging components.

Among these, the HTTP component is the most commonly used general-purpose API call component. It applies when the platform has no prebuilt connector, but the external system already provides an HTTP API and interface documentation.

The value of components lies in improving platform flexibility. When a project cannot be fully completed through prebuilt connectors, you can combine components to complete custom API calls, parameter handling, data transformation, and exception handling.

A Trigger is the trigger of an integration flow, defining when the flow starts. It answers the question of “when to start running the integration flow”.

An Action is an execution action within an integration flow, defining what operations to perform after the flow starts. It answers the question of “what to do after triggering”.

Actions can come from connectors or from the platform’s general components. Actions should follow the atomicity principle, meaning each Action performs only one clear operation. This makes future reuse, adjustment, troubleshooting, and maintenance easier.