8.5 KiB
SAP-ERP Portal — Publishing Guide (Local Windows Server)
How to run this portal permanently on a local Windows machine so everyone on your network can use it, it starts automatically with Windows, and restarts itself if it ever crashes. No extra software is needed beyond Node.js — everything uses built-in Windows features (Task Scheduler).
1. What you are deploying
| Piece | What it is |
|---|---|
server.js |
The Node/Express app — serves the web UI (public/) and all APIs on port 5000 |
.env |
ALL configuration: SQL Server, SAP Service Layer, company DB, JWT secret, port |
services/SapDiConsole/ |
Compiled DI-API console exe (Purchase Requests). Built once with build.bat |
deploy/ |
The publish scripts described below |
logs/ |
Created automatically — server output + supervisor log |
The app needs live network access to the SQL Server (192.9.205.132:1433)
and the SAP Service Layer (https://192.9.205.132:50000), and the SAP
DI API v10.00.331 installed locally for the Purchase Request feature.
2. One-time setup on the server machine
-
Install Node.js LTS (v18 or newer) from https://nodejs.org — use the default installer options ("Add to PATH" must stay ticked, it is by default). Verify in a new Command Prompt:
node -v -
Copy the whole project folder to its permanent home, e.g.
D:\sap-erp(scripts work from any folder — they always operate on their own parent folder). -
Install dependencies (only needed if
node_moduleswas not copied):cd /d D:\sap-erp npm install -
Configure
.env— copy it from the current machine or review every key (SQL host/user/password,SAP_B1_SERVER,SAP_B1_COMPANY,SAP_B1_USER/PASSWORD,JWT_SECRET, optionalPORT). Never commit or share this file — it holds passwords. -
Build the DI console (Purchase Requests) if
services\SapDiConsole\bin\Release\net472\SapDiConsole.exedoesn't exist yet:cd /d D:\sap-erp\services\SapDiConsole build.batRequires the SAP B1 DI API (build ≥ 331) installed on this machine.
-
Open the firewall so other PCs can reach the portal (right-click → Run as administrator):
deploy\open-firewall.bat -
Test it manually first — double-click
deploy\start-server.bat. A console window opens; browse to http://localhost:5000 and log in. Close the window when done testing (or leave it — step 3 below replaces it).
3. Publish — auto-start with Windows
Right-click → Run as administrator:
deploy\install-autostart.bat
This registers a Task-Scheduler task "SAP-ERP-Portal" that:
- starts the portal at every Windows boot (no user login needed, runs as SYSTEM),
- runs it hidden (no console window),
- and because the task runs the supervisor loop, the server is restarted automatically within 5 seconds if it ever crashes.
It also starts the portal immediately, so you're live as soon as it finishes.
4. Daily operations
| Action | How |
|---|---|
| Check it's running | deploy\status.bat |
| Stop | deploy\stop-server.bat |
| Start (background) | schtasks /Run /TN "SAP-ERP-Portal" — or reboot |
| Start (visible console, for debugging) | deploy\start-server.bat |
| View logs | logs\server.log (app output) · logs\supervisor.log (start/crash history) |
| Remove autostart | deploy\uninstall-autostart.bat (as administrator) |
Users access the portal at: http://<server-ip>:5000
(find the IP with ipconfig — give users that address, e.g. http://192.9.205.50:5000).
Optionally add a DNS/hosts entry like erp.mitra.local pointing to that IP.
5. Updating the application
deploy\stop-server.bat- Copy the new/changed files over the folder (keep your
.env!) - If
package.jsonchanged:npm install - If
services/SapDiConsolechanged: re-run itsbuild.bat schtasks /Run /TN "SAP-ERP-Portal"(or reboot)- Users press Ctrl+F5 in the browser once (pages are cache-busted, but a hard refresh guarantees the newest files)
6. Changing the port (e.g. if 5000 is taken)
- Add to
.env:(any free port — check withPORT=8080netstat -ano | findstr :8080that nothing is on it) - Re-run
deploy\open-firewall.bat(as administrator) — it reads the port from.envautomatically and replaces the old rule. - Restart the portal (
deploy\stop-server.bat, thenschtasks /Run /TN "SAP-ERP-Portal").
deploy\status.bat also reads the port from .env, so it always checks the
right one. Users then browse to http://<server-ip>:8080.
7. Troubleshooting
| Symptom | Check |
|---|---|
| Page won't open from another PC but works on the server | Firewall — re-run deploy\open-firewall.bat; confirm with deploy\status.bat that port 5000 is LISTENING |
| "NOT RUNNING" in status | logs\server.log tail — usually a bad .env value (SQL/SAP unreachable) or port already in use |
| Starts then dies repeatedly | logs\supervisor.log shows exit codes; fix the cause in logs\server.log — the loop keeps retrying every 5 s |
| Task exists but nothing runs after reboot | Node not on the SYSTEM PATH — reinstall Node.js with defaults, or edit deploy\start-server.bat to use the full path "C:\Program Files\nodejs\node.exe" |
| Purchase Request errors (DI API) | DI API build must be ≥ 331 and Interop.SAPbobsCOM.dll regenerated — see the comment inside services\SapDiConsole\build.bat |
| SAP/SQL password changed | Update .env, then stop + start the portal |
8. Compiled deployment — ship NO source code to the server (recommended)
Instead of copying the project, build a dist package on your development
machine and copy only that. The server then holds no readable source and no
node_modules at all.
On the development machine:
deploy\build-dist.bat
This produces dist\ containing only:
server.js |
the ENTIRE backend (server + routes + services + all npm packages) bundled & minified into one ~4 MB file — variable names crushed, comments stripped, no project structure |
public\ |
the frontend (browsers download this anyway) |
deploy\ |
the run/install scripts from section 3–4 |
SapDiConsole\… + sap-di-pr.ps1 |
the DI-API console for Purchase Requests |
uploads\, logs\ |
empty runtime folders |
Then on the server:
- Copy the contents of
dist\to the app folder (e.g.D:\sap-erp-portal) - Place the real
.envthere (it is deliberately never part of the build) - Run
deploy\open-firewall.batanddeploy\install-autostart.batas admin — same as section 3 - Only Node.js needs to be installed on the server — no
npm install, no node_modules
Updating: rebuild on the dev machine, stop the portal, copy the new
dist\server.js (and public\ if the frontend changed) over, start again.
Honest limits: minified JS deters reading and copying but is not
encryption — combine it with deploy\protect-folder.bat (section 9) and a
short server-admin list for real protection. The .env is still plain text
on the server; the ACL lock is what protects it.
9. Protecting the source code & passwords on the server
Browser users can never see the backend. Express serves only public/ and
API responses — server.js, routes/, services/ and .env are unreachable
over the network. (Frontend HTML/JS is visible in every web app by nature.)
The real risk is people who log into the server machine — they could open
the folder and read the code and, worse, the passwords in .env. Protect it:
-
Run (as administrator):
deploy\protect-folder.batThis strips folder permissions down to SYSTEM + Administrators only. Standard Windows users on the machine get "Access denied", while the portal keeps running because its scheduled task runs as SYSTEM. Undo anytime:
icacls "<app folder>" /reset /T -
Don't hand out admin/RDP access to the server — that is the actual security boundary. Anyone who is a Windows administrator on the box can always get to the files, no tool can prevent that.
-
Use the compiled deployment (section 8) so no readable source is on the server in the first place.
10. Good practices
- Back up
.envand the app DB (SAP-ERPdatabase on the SQL server) regularly. - Keep the server on a UPS and set Windows power settings to never sleep.
- The
logs\folder grows over time — delete or archive old logs occasionally.