When we work with OneStream Cloud, one of the common requirements is to bring financial data from ERP systems or other databases.
Now, the ERP system may be running inside the company network, while OneStream is hosted in the cloud.
So how does OneStream connect to that internal database?
This is where Smart Integration Connector, or SIC, comes into the picture.
OneStream provides SIC to connect the cloud application with supported data sources inside the customer network. Instead of establishing a direct VPN connection, SIC uses a local gateway and Azure Relay to handle the communication.
Let’s understand how this works and what we need to consider when designing the integration.
What Is Smart Integration Connector in OneStream?
Smart Integration Connector is a OneStream capability that allows the cloud application to communicate with designated data sources in a customer-managed environment.
For example, let’s say we have financial actuals in an internal SQL Server database.
We want to bring those actuals into OneStream for consolidation and reporting.
We can configure SIC to establish the connection between OneStream Cloud and that database.
The important part is that SIC provides connectivity. We still need to configure how the data is extracted, mapped, validated, and loaded into the application.
How OneStream SIC Architecture Works
There are four main components we need to understand.
1. OneStream Cloud Application Server
This is where the OneStream application runs.
The application server communicates with Azure Relay when accessing a source through SIC.
2. Azure Relay
Azure Relay provides the communication path between OneStream Cloud and the local gateway.
It allows the cloud application to communicate with the customer environment without requiring a direct VPN connection for this integration.
3. SIC Local Gateway Server
We install the local gateway in the customer-managed environment.
The gateway runs as a Windows service and connects to the data sources configured for that gateway.
It uses outbound port 443 to communicate through Azure Relay, with TLS encryption protecting the communication.
4. Source System
This is where the data actually resides.
Depending on the integration requirements, we may connect to a SQL Server database, PostgreSQL database, an Oracle database through a supported provider, or another supported resource.
The available connectivity depends on the provider, gateway configuration, and source requirements.
Example of SIC Data Flow
Let’s take a simple example.
We have an ERP system that stores financial actuals in a database. The finance team needs this data in OneStream every month.
The integration works as follows.
- OneStream initiates a request through the configured integration.
- The application server communicates through Azure Relay.
- The local gateway receives the request and connects to the configured data source.
- The requested data is returned through the gateway communication path.
- OneStream processes the returned data using the integration configuration.
This is the basic flow.
Now, there is an important point here.
Just because SIC retrieves data successfully does not mean the data is ready for financial reporting.
We still need to check the account mappings, entity mappings, periods, amounts, and other validation requirements.
SIC handles connectivity. The overall data integration design handles the financial data processing.
How Do We Configure SIC in OneStream?
There are two sides to the configuration.
First, we configure the gateway connection in OneStream.
The documented administration location is:
System > Administration > Smart Integration Connector
This is where the gateway configuration is managed.
Next, we configure the local gateway using the OneStream Local Gateway Configuration Utility.
Here, we define the data source, connection string, and database provider.
For database integrations, we also configure the appropriate Custom Database Connection in OneStream.
The gateway configuration on both sides must match. If the names or connection keys do not match, the connection may not work.
OneStream also provides security roles to control access to these administration areas.
What Should We Check Before Implementing SIC?
When we design this integration, we normally need to review a few things.
Source connectivity
Can the gateway server access the database or source endpoint? We need to confirm the network path, database permissions, and authentication.
Network configuration
Can the gateway establish the required outbound communication through port 443?
We also need to consider firewall rules and TLS inspection. OneStream documents specific requirements for communication with Azure Relay.
Gateway configuration
Does the local gateway configuration match the connection defined in OneStream?
We need to verify the gateway settings, connection keys, and configured data source.
Version compatibility
The SIC Local Gateway version needs to be compatible with the OneStream platform version.
OneStream recommends keeping the versions aligned. We should always review this when upgrading the platform.
Financial data validation
Once the connection works, we need to validate the actual data.
For example, if we bring general ledger balances from an ERP system, we should reconcile the loaded amounts with the source balances before using the data for consolidation.
What Happens When the Gateway Is Not Available?
This is another area we need to consider during production design.
The SIC administration page provides connection status information, including whether a connection is online or offline.
If the local gateway service stops, or the required network connectivity fails, the affected integration may not be able to access its source.
So for a production implementation, we need to define who monitors the gateway and who investigates connectivity issues.
OneStream also documents options for multiple gateway instances to support high availability.
Whether we need that configuration depends on our availability requirements.
SIC and the Overall OneStream Integration Design
One point we should keep clear is that SIC is only one part of the architecture.
A typical financial integration also needs source extraction logic, mapping rules, data validation, workflow processing, and reconciliation controls.
For example, we may successfully retrieve 50,000 records from a source database.
But that does not tell us whether every record belongs to the correct entity, account, or reporting period.
Those checks belong to the integration and financial application design.
This is why we should validate both the technical connection and the financial results.
Conclusion
Smart Integration Connector helps OneStream Cloud connect to supported data sources inside a customer-managed environment.
It uses a local gateway and Azure Relay for secure communication between the environments.
When we implement SIC, we need to understand the network configuration, gateway settings, source connectivity, version compatibility, and the integration process that consumes the data.
Getting the connection working is the first part. The next part is making sure the financial data is complete, correctly mapped, and reconciled before it is used in OneStream reporting.
Frequently Asked Questions
What is SIC in OneStream?
SIC stands for Smart Integration Connector. It supports connectivity between OneStream Cloud and designated data sources through a local gateway and Azure Relay.
Does SIC require a VPN?
SIC provides an indirect connection through Azure Relay, so a direct VPN connection is not required for that supported connectivity path.
Which port does OneStream SIC use?
The local gateway communicates with Azure Relay using outbound port 443.
Can SIC connect to Oracle and PostgreSQL databases?
Yes. OneStream documents PostgreSQL, ODBC, OleDb, SQL Server, and custom database provider options. Actual connectivity depends on the required provider and configuration.
Does SIC load data directly into a OneStream cube?
SIC provides the connection to the source. The configured OneStream integration process determines how data is retrieved, transformed, validated, and loaded.