Engine settings

Tunes how patiently and how resiliently KPImailer talks to Qlik, and caps how large a single report’s output is allowed to get.

Permissions

Found in Settings → Engine (advanced), an administrator-only area. The same page’s third card, the UDP alerting listener, is covered separately.

These defaults work for most installations - this page matters most when reports are timing out, a flaky Qlik server needs more resilience, or a report is hitting an output cap.

Steps

Qlik connector

1. Open Settings → Engine (advanced).
2. Set timeouts, in seconds: Engine RPC timeout (default 300) for calls to the Qlik Engine, QRS/QPS HTTP timeout (default 20) for Qlik Repository/Proxy API calls, and Capture timeout (default 120) for rendering a single object.
3. Set retry counts: Capture retries (default 2), Engine retries (default 3), and QRS retries (default 3).
4. Tune the circuit breaker, which stops hammering a struggling Qlik server: Circuit-breaker failure ratio (default 0.5 - the fraction of calls that must fail to trip it), Circuit-breaker sampling (s) (default 30 - the window failures are measured over), Circuit-breaker min throughput (default 10 - calls needed in that window before the ratio is evaluated), and Circuit-breaker break (s) (default 30 - how long the breaker stays open before retrying).
5. Select Save changes.

Render limits

1. In the same Engine (advanced) page, scroll to Render limits - defensive caps on report body size and output volume.
2. Set Max grid cells (default 500), Max attachments (default 25), and Max SQL data exports (default 10) per report.
3. Set Max HTML length, Max image length, and Max thumbnail length, each in characters (defaults 262144, 4194304, and 1048576), and Max body size in bytes (default 8388608).
4. Select Save changes.

When to change this

• Reports against a large or slow Qlik app time out - raise Engine RPC timeout or Capture timeout before assuming the report itself is broken.
• A Qlik server is unreliable or under maintenance often - lower the circuit-breaker failure ratio or raise min throughput so KPImailer backs off sooner, protecting both sides from repeated failed calls.
• A report legitimately needs a very large grid, more attachments, or a bigger SQL export than the defaults allow - raise the relevant render limit rather than splitting the report unnecessarily.

Worked example

A report against an unusually large Qlik app started timing out after the app grew. An administrator raises Capture timeout from 120 to 240 seconds and Engine RPC timeout from 300 to 600, saves, and re-runs the report - it now completes instead of failing partway through rendering.

What can go wrong

Caution

Raising timeouts and retries too far can mask a genuinely broken Qlik connection - a report that should fail fast instead hangs for minutes before finally erroring. Tune incrementally and confirm the underlying Qlik server is healthy first.

Caution

Render limits exist to keep report emails deliverable - most mail servers reject very large messages outright. Raising Max body size or Max image length without checking your mail provider’s own message-size limit can produce reports that pass KPImailer’s check but still bounce at send time.