What it solves

In some configurations, Datagate applications running in the user's browser must access HTTP/HTTPS services that are not available directly from the user's network—internal services, isolated systems, or endpoints restricted by security policies or firewalls.

The self-proxy mechanism solves this situation: instead of the user's browser calling the target service directly (which would fail), the request goes through the Datagate server that makes the call on behalf of the user. The Datagate server has access to the internal network; The user's browser must not have.

How it works

The destination URL is passed as an encoded parameter to the Datagate proxy:

// URL-ul original — inaccesibil din browserul utilizatorului
let requestLink = `http://sap:8080/B1iXcellerator/exec/ipo/.DEV.SSI.ApiRequest
    ?documentSeries=ABC&documentNo=123&status=true`;

// Rutare prin proxy-ul Datagate
requestLink = `/datagate/proxy?url=${encodeURIComponent(requestLink)}`;

// Apelul trece prin serverul Datagate, care face cererea efectivă
return await HTTPRequestsGetData(requestLink);

The Datagate server receives the request, forwards it to the target service, receives the response, and returns it to the browser. From the perspective of the target service, the demand comes from the Datagate server, not from the user's browser.

When to use

Typical usage scenarios:

• Calling an internal ERP (SAP, Navision) running on an isolated network
• Accessing a document generation service that is not exposed on the Internet
• Integrations with legacy systems that don't support CORS or HTTPS

The proxy is transparent to the user — they interact with the Datagate interface without knowing that some requests go through an intermediary.