Connecting a system inside your own network

Some systems — SAP Business One is the one we support today — run on your own hardware rather than on a vendor’s cloud. Connecting one takes a little work from two different people: somebody who runs your network, and an administrator of your workspace. This page is written for both, and each half says which.

Who does what

Neither half works on its own, and the order matters — the firewall rule has to exist before the connection can be made.

Part 1 — for your IT or network team

Five steps. Nothing is installed on your servers, and we need no access to the SAP client, its database, or the machine it runs on.

1. Publish the Service Layer, or confirm it already is

   We talk to SAP Business One through its Service Layer, the web interface that ships with it. That interface has to be reachable from the public internet. If a hosting partner runs the system for you, they very likely publish it already — ask them for the Service Layer URL and skip to step 3. Otherwise, give it a public host name and forward to the internal machine, the same way you would publish any other web service.

2. Give it a certificate from a public authority

   HTTPS is required, and the certificate must chain to a public root. A self-signed certificate is rejected, which is worth knowing in advance because internal installs very often have one. A free certificate from Let’s Encrypt for the public host name is enough.

3. Restrict inbound to our single fixed address

   You will not want to open the Service Layer to the whole internet, and you do not have to. Allow inbound connections from the one address below, and nothing else needs to reach it.

4. Confirm the exact address, including port and version

   The value we need is the full Service Layer root, not just the host. It normally listens on port 50000 and ends in a version segment. Both /b1s/v1 and /b1s/v2 work.

5. Create a dedicated user for us

   Please make a Business One user for this connection rather than reusing one that belongs to a person. Everything we do is then attributable to that user in the system’s own logs, you can revoke our access by disabling one account, and it does not break when somebody changes their password or leaves. Give it only the permissions you want us to have — anything not granted simply refuses, which is the correct outcome rather than a fault.

Every request we make to a system inside a customer network leaves from that one address, so it is the only one you need to open. If that constraint matters to you, tell us before you build the rule.

The same address is shown inside the product, on the connect form and in Settings › Integrations › Private-network destinations, so nobody has to copy it out of this page.

Checking the rule really works

Run this from a machine outside your network — not from the office LAN, which is the mistake that makes a closed port look open:

curl -sS -o /dev/null -w "%{http_code} %{ssl_verify_result}\n" \
  https://sap.yourcompany.com:50000/b1s/v1/

Any HTTP status at all means the route works. A second number of 0 means the certificate verified. A hang or a connection refusal means the rule is not doing what it looks like it is doing.

Part 2 — for the workspace administrator

Do this once your IT team has finished part one. It takes a couple of minutes and needs no technical knowledge — but you do need to be an administrator of the workspace for the first step.

1. Tell us which server we are allowed to call

   In Settings › Integrations › Private-network destinations, add the server’s host name — just the host, with no port and no path, for example sap.yourcompany.com. This list starts empty and nothing is allowed until you add it.

2. Connect it

   Open Integrations, find SAP Business One, and press Connect. You will be asked for four values: the full Service Layer URL, the company database name, and a user name and password.

3. Choose what it may do

   After it connects, open Integrations › SAP Business One to see every action it offers and switch individual ones on or off. Actions that change data are marked, and you can require somebody to confirm before any of them run.

What you will need when you press Connect

Two lists, pointing in opposite directions

The firewall rule in part one says which address may reach your system. The setting in part two says which of your systems we may reach. They are not the same list and neither replaces the other.

The second one exists because the Service Layer address is a value somebody types, and the machine that fetches it sits inside our own network. Without the list, one mistyped or malicious value could aim our infrastructure at an address nobody chose. Every change to it is written to your audit log, and removing a host stops the connections pointed at it straight away rather than at their next renewal.

If it refuses, this is what the message means