The safest pattern is to keep the office database private. Put a small connector service near the database, reach that service through a private VPN, and expose only the business operations the cloud application needs.
Why it happens
A cloud application should not connect directly to an office database over the public internet. Opening a database port creates a large security risk and couples the cloud application to internal tables that may change.
A connector is a small service that sits on the office network. It uses the accounting or business system’s supported SDK when possible, then offers a narrow API to approved cloud applications.
A safer architecture
- Keep the database private. Allow database traffic only from trusted machines on the office network.
- Run the connector close to the database. A background service can use the vendor SDK and apply the system’s normal business rules.
- Connect networks with a VPN. The cloud application calls a private connector address instead of a public database port.
-
Expose specific operations. Prefer endpoints such as “find customer” or “create invoice” over unrestricted SQL access.
-
Authenticate every request. Use short-lived credentials, encrypted transport, least-privilege accounts, and audit logs.
Why the official SDK matters
Direct database writes can bypass validation, numbering, tax logic, stock rules, and audit behavior. A supported SDK or API is usually safer because it preserves the application’s business rules.
The SDK files and the API licence may also be separate. Confirm the exact software version, development rights, production licence, and unattended-service support before building the connector.
Handle unreliable connections
Office internet and computers can go offline. The cloud application should queue work, use timeouts, and retry carefully.
Give every write request a unique idempotency key. Idempotency means that repeating the same request does not create a second invoice or payment. If a timeout happens after the office system may have saved the record, check the result before retrying.
Common mistakes
- Cause: Publishing the database port. Fix: Use a private VPN and allow only the connector to reach the database.
-
Cause: Writing directly to tables. Fix: Use the supported SDK or API for business operations.
-
Cause: Retrying writes blindly. Fix: Store a unique request key and reconcile uncertain results.
-
Cause: Giving the connector full privileges. Fix: Grant only the permissions required for its endpoints.
Treat a VPN as transport, not authorization
The connector still needs request authentication, operation-level permissions, validation, and replay protection. Store the idempotency key alongside the outcome of each write so a reconnect can retrieve the original result. A network connection alone should never grant unrestricted access to business operations.
A private connector creates a clean boundary between a cloud application and an office system. The next action is to confirm the supported SDK and licence, then prototype one read-only endpoint before adding writes.