Report Manager Web Server

Report Manager Web Server

Docker (self-hosted)

The quickest way to run the Web Report Server is the published Docker image. The container runs repwebexe -selfhosted and serves the report server on port 8080. Start the service directly with:

docker run -d \
  -p 8080:8080 \
  -e REPORTMAN_HTTP_PORT=8080 \
  -v repweb_etc:/usr/local/etc \
  -v repweb_home:/var/lib/reportman \
  -v repweb_logs:/var/log/reportman \
  --name reportman-web \
  --restart unless-stopped \
  tonimartir/reportman-web:latest

Docker pulls the image on the first run. Then open the administration panel at http://localhost:8080/admin/login. On the first run use the bootstrap form to create the first administrator.

Persistent named volumes keep your configuration and data between restarts:

The HTTP port is controlled by REPORTMAN_HTTP_PORT (default 8080); publish the same port with -p. The image bundles the free database client libraries (PostgreSQL, MySQL/MariaDB, Firebird/Interbase, SQLite, MS SQL Server/Sybase through FreeTDS and ODBC); proprietary clients (Oracle, Db2) are added in a derived image. Image: tonimartir/reportman-web.

For TLS, routing or perimeter authentication, place a reverse proxy in front of the container.

What the web server does

The Report Manager Web Server is a multithreaded application that lets any number of HTML client machines execute reports and obtain ready to print Adobe PDF files — or CSV, plain text, SVG and native Report Manager metafiles. The client only needs a web browser, and no cookies are required.

The server holds the database connections and the report definitions, so the heavy query and rendering work happens on the server and only the result travels to the client. This lets you distribute the load: an Internet-facing report server can run process-intensive queries against a high-performance database server on a separate machine and then send only the finished report to the client. The server is optimized to use very little bandwidth and runs on Windows, Linux (Apache) and Docker.

The administration panel

The self-hosted server includes a built-in administration panel at /admin. Everything is managed through the browser, no file editing required:

Database connections

Open Connections in the admin panel (/admin/connections) to create and administer the database connections used by your reports. You can add a new connection, edit its parameters, run a connection test, delete it, or edit the raw definition. Connections are stored in dbxconnections.conf and use the FireDAC/Zeos drivers bundled in the image. A report references a connection by its alias, so you can change the database without changing the report.

Adding proprietary database drivers

The Docker image bundles the free client libraries (PostgreSQL, MySQL/MariaDB, Firebird/Interbase, SQLite, MS SQL Server/Sybase through FreeTDS and ODBC), so those backends work out of the box. Proprietary clients are not shipped because they require a manual download and/or accepting a license. You add them in a derived image built FROM tonimartir/reportman-web: switch to the root user, install the driver, then switch back to the reportman user. FireDAC and Zeos share the same native .so libraries, so installing the backend client enables both engines.

Ready-made examples live in server/docker/web/examples/ (Microsoft ODBC 18, Oracle Instant Client, IBM Db2 CLI and Progress DataDirect). Build a derived image like this — the build context is the examples folder, where you drop any downloaded package:

# Pull the base image first if it is not local:
#   docker pull tonimartir/reportman-web:latest
docker build -f server/docker/web/examples/Dockerfile.oracle \
  -t reportman-web-oracle:latest \
  server/docker/web/examples

Run the derived image with the same ports, environment variables and volumes as the base image. If your base image has another name/tag, pass it with --build-arg BASE_IMAGE=reportman-web:latest.

Oracle Instant Client. Download instantclient-basiclite-linux.x64-*.zip from Oracle (license required) and place it in the examples folder as instantclient.zip:

ARG BASE_IMAGE=tonimartir/reportman-web:latest
FROM ${BASE_IMAGE}
USER root
RUN apt-get update \
    && apt-get install -y --no-install-recommends libaio1 unzip \
    && rm -rf /var/lib/apt/lists/*
COPY instantclient.zip /tmp/instantclient.zip
RUN mkdir -p /opt/oracle \
    && unzip -q /tmp/instantclient.zip -d /opt/oracle \
    && rm /tmp/instantclient.zip \
    && sh -c 'echo /opt/oracle/instantclient* > /etc/ld.so.conf.d/oracle-instantclient.conf' \
    && ldconfig
USER reportman

Then, in the Connections screen, create a connection with the Oracle driver (FireDAC Ora or the Zeos oracle protocol). FireDAC and Zeos find the Instant Client through the loader path configured above.

Progress DataDirect Connect for ODBC. "DataDirect" is Progress's brand for its proprietary connectivity drivers (Progress acquired DataDirect Technologies in 2012); the ODBC product is Progress DataDirect Connect for ODBC (a.k.a. Connect64 for ODBC), a set of "Wire Protocol" drivers that need no database client libraries. It is a licensed, manually downloaded Linux 64-bit package (progress.com/odbc). The base image already includes the unixODBC driver manager, so the DataDirect .so drivers only need to be unpacked, put on the loader path and registered in /etc/odbcinst.ini. Place the downloaded package in the examples folder as datadirect-odbc.tar.gz and use:

ARG BASE_IMAGE=tonimartir/reportman-web:latest
FROM ${BASE_IMAGE}
ARG DD_HOME=/opt/progress/datadirect
USER root
RUN apt-get update \
    && apt-get install -y --no-install-recommends tar gzip \
    && rm -rf /var/lib/apt/lists/*
COPY datadirect-odbc.tar.gz /tmp/datadirect.tar.gz
RUN mkdir -p "${DD_HOME}" \
    && tar -xzf /tmp/datadirect.tar.gz -C "${DD_HOME}" --strip-components=1 \
    && rm /tmp/datadirect.tar.gz \
    # put the DataDirect driver libraries on the dynamic loader path
    && echo "${DD_HOME}/lib" > /etc/ld.so.conf.d/datadirect.conf \
    && ldconfig \
    # register the driver you need; the .so name depends on the backend, e.g.
    # ivora28.so (Oracle), ivmsss28.so (SQL Server), ivsqls28.so, ivinf28.so ...
    && printf '%s\n' \
       '[DataDirect Oracle Wire Protocol]' \
       'Description=Progress DataDirect Oracle Wire Protocol' \
       "Driver=${DD_HOME}/lib/ivora28.so" \
       >> /etc/odbcinst.ini
ENV ODBCHOME=/opt/progress/datadirect \
    ODBCINI=/usr/local/etc/odbc.ini
USER reportman

The package name, the unpack path and the driver .so depend on the DataDirect version you download — adjust them to your package (the DataDirect package also ships an installer and sample odbc.ini / odbcinst.ini files you can reuse). The driver libraries live in the install's lib/ folder and use a versioned name — for Oracle, for example, ivora28.so or DWora28.so depending on the release (the iv/DW/AR prefix and the version number vary), so check that folder for the exact file. Once the image is built, create an ODBC connection in the Connections screen: either reference the registered driver in a DSN-less connection string, or define a DSN in the odbc.ini pointed to by ODBCINI (the /usr/local/etc volume keeps it across restarts). Reportman reaches ODBC through the Zeos odbc protocol or the FireDAC ODBC driver. The same recipe covers any DataDirect Wire Protocol driver (SQL Server, Db2, Sybase, Informix — and the Progress OpenEdge database itself) by registering the matching .so.

Progress OpenEdge database. To connect to a Progress OpenEdge database, use its SQL Client Access ODBC driver, which is the DataDirect "OpenEdge Wire Protocol" driver. It ships with OpenEdge under $DLC/odbc/lib as pgoe<NN>.so (the number tracks the release, e.g. pgoe27.so or pgoe1025.so) and is also available as a standalone download (progress.com/odbc/openedge). In a derived image, copy the OpenEdge ODBC client files (from an OpenEdge install's $DLC/odbc and $DLC/lib, or the standalone package), put their lib folders on the loader path with ldconfig, and register the driver in /etc/odbcinst.ini:

[Progress OpenEdge]
Description=Progress OpenEdge Wire Protocol
Driver=/opt/openedge/odbc/lib/pgoe27.so
FileUsage=1

Then create an ODBC connection in the Connections screen that references this driver (directly, or through a DSN in the odbc.ini pointed to by ODBCINI), giving the OpenEdge host, the SQL broker port and the database name. As with the other ODBC backends, Reportman connects through the Zeos odbc protocol or the FireDAC ODBC driver.

API keys

Besides the classic user and password, the server accepts authentication with an API key sent in the HTTP header X-ReportmanServer-ApiKey. This is the recommended way to call the server from your own applications.

Manage keys under API keys (/admin/apikeys): each key has a logical name and is mapped to an existing internal user (configuration sections [SERVERAPIKEYS] and [SERVERAPIKEYUSERS]), so the key inherits that user's privileges over aliases and reports.

Two switches in the [SECURITY] configuration control access, both enabled by default: USER_ACCESS (classic user/password) and API_KEY_ACCESS (API key header). When a request carries a valid X-ReportmanServer-ApiKey it takes precedence over user/password. Because credentials and parameters can travel over HTTP, run the server behind TLS (a reverse proxy) in production.

Built-in API testing

The admin panel includes a Testing screen (/admin/testing) that builds and runs real HTTP calls to the server from the web interface itself — the fastest way to learn exactly how to invoke a report from the outside. The wizard lets you:

• choose host, port, authentication (user/password or API key) and method (GET or POST);
• pick an existing report and read its visible parameters;
• Build Request: see the exact URL, request headers and body the server expects;
• Test Request: execute it and see the status code, content type and response, with a Download button when the result is a PDF.

Because the wizard issues the same HTTP call the server accepts in production, you can copy the generated URL, headers and body straight into your own client or scripts.

Executing reports from a URL

Clients log in, choose a report group (alias) and a report, optionally change the report parameters, and execute it — all via HTML. See the web server operations page for the full list of request parameters (aliasname, reportname, metafile output format, language, and so on). By default parameters travel by POST; URL/query-string operation is kept as optional backwards compatibility, and when enabled the full execution URL can be bookmarked.

Use the /version command to check the deployment and to find the location of the configuration files.

Classic CGI/ISAPI installation

The server can also be deployed as a CGI/ISAPI module (repwebserver.dll / repwebexe) behind Apache or IIS. See the installation instructions for that setup and for configuration details.

Designing reports for the web server

Reports for the web server should be independent entities that only need user parameters to execute, and each concurrent execution uses its own database connection. Database clients are typically thread safe at the connection level: a single connection should be used by one thread at a time, while different connections run in parallel — which is exactly the per-request model the server uses.

The old advice to always connect to Firebird/InterBase over the network (hostname/localhost) because the local access method was not thread safe is now obsolete: since Firebird 2.5 the client library (fbclient) and the embedded engine are thread safe and allow multiple simultaneous connections, including local and embedded access. A client/server (TCP) connection to a shared Firebird server is still a valid choice if you want to centralize access, but it is no longer required for thread safety.