Barcode service in SaaS and Universal Code
Purpose
This page describes service-based barcode generation in SaaS and Universal Code scenarios. It shows which fields in BE-Code Setup matter and how to validate the connection so that labels and reports can generate barcodes reliably later.
Why this setup is required
In a SaaS environment there is no local barcode-font installation and no classic DLL call. To generate barcodes anyway, a web-API-based service connection is required.
In addition, this setup model has become relevant for current on-premises scenarios in the context of Microsoft’s Universal Code direction. In practice this means:
- SaaS requires the service path,
- modern product versions should no longer be planned around local legacy mechanisms alone,
- barcode generation is a real integration topic, not just a layout parameter.
The BE-Code Setup page
The central working page for this configuration is BE-Code Setup. There you maintain the connection parameters and verify that the system can really reach the barcode service.
| Field | Meaning in daily work | Check question |
|---|---|---|
| Connection status | shows whether the server API is currently reachable | Is the connection stable or only briefly successful? |
| Service URL | target address of the barcode service | Is the correct test or live URL maintained? |
| Use basic authentication | currently intended operating mode | Is the authentication model aligned with the project setup? |
| Username | technical service user | Does the user match the target environment? |
| Password | related authentication value | Were the current project credentials stored? |
| API token | reserve field for future extensions | Is it intentionally empty or used by project design? |
| Timeout | maximum waiting time for the service | Is the value realistic for network quality and print load? |
| Legacy barcode generation active | enables the historical path in older on-premises scenarios | Is the field consciously set or consciously disabled? |
Safe project usage
The legacy wiki contained test credentials. In the new product documentation, concrete access data should not be carried over as a general working instruction. Always use:
- the project-specific test URL,
- the project-specific service user,
- the project-specific password or authentication method,
- separate documentation for test and production.
This prevents outdated or unsuitable credentials from being reused without review.
Recommended setup sequence
- Open BE-Code Setup.
- Maintain the service URL matching the environment.
- Activate the intended authentication mode.
- Enter user and password from the project context.
- Check the timeout value for realism.
- Run the connection test deliberately.
- Then test one real report or label with a barcode.
The key point is that a green connection alone is not enough. Only a real document test proves that format, data transfer, and response time work in the full process.
Typical error patterns
| Situation | Possible cause | Check |
|---|---|---|
| Connection status stays negative | URL, authentication, or network route is wrong | inspect service URL and project credentials |
| Connection works, but no barcode appears | service is reachable, but data transfer or document test is wrong | test with a real report or label |
| Timeouts happen repeatedly | timeout is too low or service responds too slowly | inspect timeout and service availability |
| On-premises behaves differently than expected | legacy barcode path is unintentionally active or inactive | inspect the legacy barcode generation flag |
Result
- You understand why barcode generation in SaaS and Universal Code must be treated as a service integration.
- You can configure and validate BE-Code Setup safely.
- You avoid typical failures caused by wrong URLs, unclear operating modes, or untested legacy mechanisms.
Links