Function Overview

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 service scenarios.

• Data integration: Connects data sources at the source and destination. A data task can be used to integrate data from the source to the destination.
• Service integration: Encapsulates APIs, data sources, and custom functions into standard RESTful APIs and exposes them 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.

ROMA Connect uses integration applications to isolate resources of different users in the same instance. Resources (such as data sources, APIs, topics, and products) created in a ROMA Connect instance must belong to an integration application. By default, IAM users can view and manage only the integration applications and resources created by themselves and a primary account can view and manage all resources created by IAM users under it.

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

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 on both the source and destination, mapping rules of data fields, and filtering conditions for data integration. ROMA Connect supports the following types of data integration tasks:

• 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.

ROMA Connect supports common data source types, including relational databases, big data storage, semi-structured storage, and message systems. If the data source types supported by ROMA Connect cannot meet your data integration requirements, you can develop a data source read/write plug-in and connect it to ROMA Connect through a standard RESTful API to read and write such special data sources. This custom data source plug-in is called a connector, and a data source that is read and written through the connector is called a custom data source.

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

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.

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 so that users can call the APIs to obtain data from the data sources.
• Function backend: encapsulates custom functions into standard RESTful APIs so that users can call the APIs to use functions.

An environment refers to the restricted application scope of an API. An API can be called only after it is published in an environment. APIs can be published in different custom environments, such as the development environment and test environment. RELEASE is the default environment and the official release environment.

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

For example, variable Path is defined for an API, and 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.

Request throttling controls 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. It takes effect only for APIs bound to the policy.

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, allowing or denying access from specified IP addresses or accounts.

An access control policy is independent of an API. It takes effect only for APIs bound to the policy.

A topic is a model for publishing and subscribing to messages in a message queue. Message production, consumption, 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.

A producer publishes a message to a topic. The ultimate purpose of publishing a message is to transfer the message content to other systems so that the other systems can process the message as agreed.

A consumer subscribes to messages from a topic. The ultimate purpose of subscribing to a message is to process message content. For example, in the 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.

A product is a collection of devices with the same capabilities or features. Each device belongs to a product. You can define a product to determine the functions of a device.

ROMA Connect does not directly store data reported by devices. You can use the rule engine to configure forwarding rules for device data so that the data reported by devices can be forwarded to other cloud services for storage or further analysis.

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.