Also published on the product site: publish-scenario-sla-citratest-apm-continuous-watch.aspx
How a glass-level script becomes scheduled monitoring with SLA limits on the steps users actually feel.
Direct answer: CitraTest APM® turns an on-the-glass scenario into a continuous watch by publishing the script to the APM Web Console, attaching it to a Scenario (schedule + groups + monitors), and scoring WaitForImage timer steps against SLA response-time limits. Playback uses real mouse and keyboard on Citrix, Microsoft RDS, Azure Virtual Desktop, browsers, and thick Windows clients – with no CitraTest agents on production session hosts for the glass path.
Host CPU looks calm. The gateway answered. The workbook is green. None of that proves that today’s login-to-shell, published-app first paint, or in-session transaction still lands on screen inside the SLA your shift agreed to.
A continuous watch answers a different question than a one-off lab run: is the end-user path still true under the limits we published? That is the operational lifecycle behind CitraTest APM – Publish → Scenario → SLA – described in the CitraTest Quick Start APM Web Console chapter and User Guide timer guidance.
What Publish → Scenario → SLA means
Building the script is necessary. Operations still needs a fleet path. In CitraTest APM the path is concrete:
| Step | What happens |
|---|---|
| Publish | Tools → Publish Script sends the executable and baseline images to the APM Web Console (optional versioned publish and parameter files). |
| Scenario | A Scenario = Schedule + Group(s) + Monitor(s). CitraTestAPMAgent playback machines pick up work on the next check-in. |
| SLA | Dashboards and reports score up to four SLA response-time limits per Monitor/Timer. Alerts fire when a glass step breaches the band you set. |
Availability for summary reporting can track successful iterations (Monitor Required Availability) separately from response-time bands. Screenshots on failure give ops on-glass proof instead of another abstract counter. Failover agents can stand by when a primary is silent for an extended period; they still need Group/Scenario membership.
Illustrative fleet flow based on the Quick Start APM Web Console chapter – not customer results.
Build the glass scenario first
Before you publish, define success the way a user would recognize it. A practical APM scenario usually covers:
- Login-to-shell (or equivalent first useful desktop / client chrome)
- Published-app or thick-client first paint – the window or workspace that means work can start
- One or two key in-session steps – open chart, submit order, post invoice, run payroll step – whatever the shift cannot skip
Per User Guide / Quick Start measurement guidance:
- Scripts encode the workflow on a Windows desktop.
- Playback sees the UI with bitmap images (and OCR when text is dynamic).
- Playback acts with real mouse and keyboard.
- WaitForImage synchronizes and verifies expected screen state before the next step.
- StartTimer / StopTimer capture on-screen response: StartTimer immediately after the initiating action; StopTimer immediately after WaitForImage confirms completion.
Prefer static bitmaps for sync cues that do not change. Reserve OCR for values that are unknown ahead of time. OCR is not a wait/sync – confirm readiness with image functions first, then read or assert dynamic text if needed. Keep baseline images small and unique; match display properties (resolution, color depth, theme, font smoothing) between capture and playback machines so "image not found" failures are real application delays, not environment drift.
Illustrative method diagram – not customer results. That pipeline is the measurement contract inside every published monitor.
Turn the scenario into a continuous watch
Once the glass path is honest in interactive playback, publish it and attach operational shape:
- Schedule – how often the path must prove itself (shift cadence, overnight, or tighter intervals for critical transactions).
- Groups and monitors – which published script (and which timers) each agent runs.
- Playback endpoints – Windows machines running CitraTestAPMAgent with access to the real client path (Citrix Workspace, RDS/AVD client, thick client, browser).
- SLA limits – response-time bands per Monitor/Timer (up to four limits) that match what the business already treats as acceptable.
- Alerting – notify when a glass step breaches or iterations fail; use failure screenshots as the first evidence pack.
Operational hygiene keeps the watch trustworthy: restore a clean desktop between iterations, use script versioning for phased rollout (avoid assigning conflicting versions of the same script to one agent), and publish cleanup scripts as standalone monitors when leftover windows would poison the next run.
Illustrative method diagram – not customer results. Geo shapes are example scenario layouts, not benchmarks.
What to measure (without inventing numbers)
Name timers after moments of truth, not after protocol hop labels:
- First useful pixel / login-to-shell – when the desktop or client chrome is actually usable
- App or workspace ready – published app or thick client first paint
- Key transaction ready – the screen state that means the business step completed for the user
Set SLA bands from agreed operational limits – what the shift already treats as too slow – then let the watches report whether today’s path still meets them. Do not invent accuracy percentages or fictional ROI. The value of the watch is honesty: successive iterations either prove the glass path or surface the screenshot that shows where it stopped.
If you already sized concurrency with CitraTest VU, reuse the same visual definition of success in APM. VU answers "how many?" under load; APM answers "is it still true this hour?" Related: Director Watches Brokers. APM Watches the Screen., What is on-the-glass APM?, Advanced OCR for Automated Testing.
Closing: keep production honest on the glass
Publish → Scenario → SLA is how CitraTest APM becomes a continuous watch rather than a script that only runs when someone remembers. Encode the path with WaitForImage and timers, publish it, schedule it across playback endpoints, and score the steps users feel. Infrastructure metrics still matter for hosts and brokers – they do not replace a scheduled proof that the business screen appeared on time.
FAQ
What does Publish → Scenario → SLA mean in CitraTest APM?
Publish sends the script exe and images to the APM Web Console. A Scenario combines schedule, groups, and monitors so CitraTestAPMAgent playback machines run the glass path. SLA response-time limits score each Monitor/Timer against thresholds you define.
How should timers be placed in an APM glass scenario?
Place StartTimer immediately after the initiating action. Confirm readiness with WaitForImage (prefer static bitmaps for sync). Place StopTimer after that wait succeeds. OCR may read or assert dynamic text afterward; OCR is not a wait/sync.
What should a continuous APM watch measure?
Time moments of truth on the glass: login-to-shell or first useful pixel, published-app first paint, and the key in-session transactions your shift depends on. Score those timers against SLA limits; availability can be tracked separately via successful iterations.
Do CitraTest APM agents run on production session hosts?
No. For the glass path, CitraTestAPMAgent runs on playback machines with Windows access to the client path. No CitraTest agents are required on production session hosts.
How does APM relate to CitraTest VU for the same path?
VU can size the path under concurrency in the lab. APM watches the same glass definition of success on a schedule against production SLAs. Same WaitForImage and timer contract; different operational question.
When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.
Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.