|
<< Click to Display Table of Contents >> ODS Operational Data Store |
There are business scenarios in which you may want to expand the features integrated with Bizagi using business report tools such as report generated with Tableau, PowerBI, and SQL Server reporting services, among others.
To expose the data for reporting tools with the most updated information Bizagi features ODS.
Bizagi's ODS creates a separate replica of the Production, Test and Development database with read-only capabilities for custom reporting purposes. This allows you to execute queries without affecting the performance of your processes within the main transactional database.
For each environment, a distinct server and database is set up to maintain data segregation and is deployed within the same region to minimize latency.
The replicated database is accessed through a connection string provided in the Onboarding process by Bizagi, with a SQL name, a user and a password.
There are two options to access the ODS:
Through Private access, or through Public access.
1.Private access:
a.VPN access: Establishes a private, secure connection to the ODS from the customer's network.
b.VNet peering: Ideal for customers with Azure resources that need to access the ODS from Azure.
2.Public access: Offered when the customer opts not to use a VPN due to internal policies or preferences.
The following table can help you identify the best option to access your ODS:
Criteria |
Private Access (VPN/VNet Peering) |
Public Access |
|---|---|---|
Architecture (use cases) |
Applicable when all applications (e.g., Power BI, SQL Server, MS) can route requests through the customer network (via VPN or VNet peering) and there are no use cases that require external ODS access. |
Applicable when external access from outside the customer network is required, and it is not possible or not optimal to use a gateway service acting as a bridge to traverse the customer VPN or VNet peering. |
Infrastructure security (network access controls) |
Access is enabled by the customer through explicit firewall rules, considering the customer origins (IP segments or specific addresses) from the internal network. |
Access is enabled in Bizagi configuration, defining customer specified IP origins (IP whitelist, either by IP ranges or specific addresses). |
Setup complexity |
Setup depends on VPN or VNet peering as a prerequisite. |
Easier and faster setup. |
Maintainability complexity |
Maintenance of allowed origin definitions is handled entirely by the customer by updating firewall rules. A Bizagi support ticket is only required when updates to the VPN encryption domain are needed, such as adding new origins outside of a previously enabled network segment. |
IP whitelist change control, required when updates are needed, must be requested to Bizagi through a support ticket and is not self service. |
Performance variables |
VPN over the internet is affected by latency, bandwidth, and overall availability of the VPN connection, which are directly dependent on the customer internet connectivity and internet service provider.
If a gateway service is evaluated as a bridge from SaaS origins, for example a cloud based Tableau service, latency impacts introduced by the gateway service must be considered. |
Affected by internet characteristics and availability, including bandwidth and fluctuations, and directly dependent on the customer internet service provider. |
Recommended setup |
When using VPN, enable a sufficiently broad network segment as the encryption domain so that new origins requiring ODS access, whose IPs fall within that segment, do not require configuration changes. |
Rely on fixed public outbound IPs or ranges, unified through a proxy or middleware such as Netskope or Zscaler, to minimize whitelist updates and simplify maintenance. |
Last Updated 4/15/2026 4:43:57 PM