Functions

ROMA Connect

ROMA Connect is a full-stack application & data integration platform. It integrates data, APIs, messages, and devices to allow interconnection between cloud and on-premises applications, helping enterprises achieve digital transformation. You can use different ROMA Connect functions based on different integration scenarios.

• Data integration: connects data sources from the source to destination.
• Service integration: encapsulates APIs, data sources, and custom functions into RESTful APIs and makes them accessible to external systems.

• Message integration: creates message topics through which different systems interconnect with each other to send and receive messages.
• Device integration: defines device models and registers devices in the cloud. Devices are connected to the cloud through SDKs to send and receive messages.

For details, see Data Integration Guide, Service Integration Guide, Message Integration Guide, and Device Integration Guide.

Integration Application

ROMA Connect isolates resources of different users in the same instance using integration applications. All resources (such as data sources, APIs, topics, and products) created in a ROMA Connect instance belong to an integration application. By default, IAM users can view and manage only the integration applications and resources created by themselves, while a primary account can view and manage all the resources created by its IAM users.

To share resources created by yourself with other IAM users, authorize the integration applications to other IAM users.

For details, see Creating an Integration Application and Configuring Integration Application Authorization.

Data Integration Task

ROMA Connect supports access of multiple types of data sources and uses data integration tasks to integrate data from source to destination.

A data integration task defines detailed rules for data integration from the source to destination. The rules include data source types at both ends, mapping rules of data fields, and integration filters. ROMA Connect supports common and composite tasks for data integration:

• Common: supports all default data source types, in scheduled or real-time mode. Database data sources support integration of a single data table in each task.
  • Scheduled: obtains data from the source and integrates the data to the destination based on a schedule.
  • Real-time: obtains data from the source and integrates the data to the destination in real time.
• Composite: uses the Change Data Capture (CDC) mechanism to implement real-time and incremental synchronization of data from the source to the destination. Multiple data tables at the source can be synchronized to multiple data tables at the destination. Only a limited number of data types are supported.

• Flow: creates tasks on the console easily with low threshold for users with different backgrounds. The following functions are provided:
  • A processor node can collect data from one data source to multiple destinations.
  • Tasks can be configured simply by dragging and dropping nodes.
  • Data conversion modes include the mapping and script modes. With JavaScript scripts, you can read data from the source, process the data, and then write the data to the destination.

For details, see Data Sources Supported by Data Integration Task, Creating a Common Data Integration Task, Creating a Composite Data Integration Task, and Creating a Flow Data Integration Task.

Custom Data Source

ROMA Connect supports common data source types, including relational databases, big data storage, semi-structured storage, and message systems. You can also develop a data source read/write plug-in and connect it to ROMA Connect through a RESTful API to read and write custom data sources. Such data source plug-ins are also called connectors, and the data sources read or written through these connectors are custom data sources.

To ensure that ROMA Connect can read and write data properly, the RESTful APIs provided by the connectors must comply with the API specifications defined by ROMA Connect.

For details, see Connecting to a Custom Data Source, Creating a Connector, and Publishing Connectors.

Load Balance Channel

This channel allows ROMA Connect to access backend services deployed on servers in load balancing mode (direct access to ECSs in the same VPC, or to ECSs in other VPCs and private servers by specifying IP addresses).

For example, six ECSs deployed in a VPC have a load balance channel to reach ECS 1 and ECS 4. ROMA Connect can access these two ECSs through the channel.

For details, see Creating a Load Balance Channel.

Custom Backend

ROMA Connect allows you to customize backends as the backend services of open APIs. Custom backends are classified into data backends and function backends.

• Data backend: encapsulates data sources into RESTful APIs for calling to obtain data from data sources.
• Function backend: encapsulates custom functions into RESTful APIs for calling to use functions.

For details, see Creating a Data Backend and Creating a Function Backend.

Environment and Environment Variable

An API can be called only after it is published in an environment. An API can be published in different custom environments, such as environments for development and testing. RELEASE is the system default environment for publishing APIs.

Environment variables are specific to environments. You can add variables in different environments to call different backend services using the same API.

Take an API whose variable Path is defined in the backend request path as an example. Two variables with the same name are respectively created and assigned values /Stage/test and /Stage/AA in environments 1 and 2. If the API is published and called in environment 1, the path /Stage/test is used. If the API is published and called in environment 2, the path /Stage/AA is used.

For details, see Creating an Environment and Variable and Publishing an API.

Cross-Domain Access

For security purposes, a browser restricts cross-domain requests initiated from scripts. That is, only resources from the same domain can be requested. However, CORS allows a browser to send XMLHttpRequest requests to a server in a different domain.

CORS requests are classified into two types: simple requests and non-simple requests.

• Simple requests must meet both of the following conditions:
  • The request method is HEAD, GET, or POST.
  • The HTTP header can contain only the following fields: Accept, Accept-Language, Content-Language, Last-Event-ID, and Content-Type (only three values are allowed: application/x-www-form-urlencoded, multipart/form-data, and text/plain).

  In the header of a simple request, browsers automatically add the Origin field to specify the origin (including the protocol, domain, and port) of the request. After receiving such a request, the target server determines based on the origin whether the request is safe and can be accepted. If the server sends a response containing the Access-Control-Allow-Origin field, the server accepts the request.

• Non-simple requests do not meet the preceding two conditions.

  Before sending a non-simple request, a browser first sends an HTTP request to the target server to determine whether the origin the web page is loaded from is in the allowed origin list, and which HTTP request methods and header fields can be used. Once the HTTP request is successfully preflighted, the browser then sends a simple request to the server.

For details, see Configuring CORS for APIs and Configuring CORS.

Request Throttling

Request throttling limits the number of times an API can be called within a period to ensure that the API can provide stable services. ROMA Connect can limit the number of API calls by user, application, and source IP address.

A request throttling policy is independent of an API and takes effect only if it has been bound to APIs.

For details, see Configuring API Request Throttling.

Access Control

Access control restricts the sources of API calls to protect API security. Access control allows you to set a blacklist or whitelist of IP addresses or accounts that can access an API.

An access control policy is independent of an API and takes effect only if it has been bound to APIs.

For details, see Configuring API Access Control.

Topic

A topic is a model for publishing and subscribing to messages in a message queue. Message production, retrieval, and management are performed based on message topics. A producer publishes a message to a topic. Multiple consumers subscribe to the topic. The producer does not have a direct relationship with the consumers.

For details, see Creating a Topic, Connecting to a Topic Using CLI, and Viewing Message Body.

Producer and Consumer

A producer publishes a message to a topic. The messages are then delivered to other systems for processing as agreed.

A consumer subscribes to and processes messages from a topic. For example, in a log integration scenario, the monitoring and alarm platform functions as a consumer to subscribe to log messages from topics, identify alarm logs, and send alarm messages or emails.

For details, see Connecting to a Topic Using CLI.

Product

A product is a collection of devices with the same capabilities or features. Each device belongs to a product, and device properties can be configured by defining the product.

For details, see Creating a Product and Creating a Product Template.

Rule Engine

ROMA Connect does not directly store data reported by devices. Use the rule engine to configure rules to forward device data to other cloud services for storage or for further analysis.

For details, see Configuring Data Forwarding Rules and Importing and Exporting Rules.

Device Notifications

ROMA Connect provides the device change notification function. When the status of a subscribed device changes, for example, the device goes online, goes offline, or is deleted, ROMA Connect sends a message about the real-time device status to the corresponding message integration topic.

For details, see Subscribing to Device Notifications.

Composite Application

A composite application integrates multiple business flows into a sophisticated automation solution, enabling end-to-end service process automation across systems and services to meet diverse requirements.

For example, you can connect business flows, such as data collection, processing, storage, and notification, to create a complete data processing pipeline. Composite applications offer flexibility and scalability, allowing you to adjust or extend workflows as service needs evolve. They also support data sharing and collaboration between workflows, enhancing operational efficiency.

A composite application can contain multiple service flows. You can edit, start, stop, and debug these flows.

For details, see Creating a Composite Application, Connectors, and Processors.