Triggers — Overview
🚀 Triggers Overview
Triggers are how your agent or workflow starts. In .NET + Semantic Kernel (SK), a trigger receives an event (HTTP call, webhook, schedule, file change, log entry), prepares context, and invokes SK functions/plugins.
Trigger types at a glance
| Trigger | Best for | Typical hosting | Notes |
|---|---|---|---|
| 🔹 HTTP Request | Interactive APIs/UX, synchronous responses | ASP.NET Core on Kestrel/IIS, container | Low latency; add auth, rate limits, retries to downstream calls. |
| 🔹 Webhook | Event-driven integrations from SaaS | ASP.NET Core, Functions, container | Verify signatures; idempotency; queue buffering for spikes. |
| 🔹 Timer (Schedule) | Periodic jobs, batch processing | Worker Service, Functions, Linux cron, container | Handle drift/overlap; use distributed locks if multi-instance. |
| 🔹 File System Watcher | ETL on new/changed files | Worker Service, container with mounted volume | Debounce/coalesce; fallback to directory scans for reliability. |
| 🔹 Windows Event Log | Ops/Compliance, endpoint signals | Windows Service (Worker Service) | Use EventLog/EventLogWatcher; plan service recovery/backoff. |
Hosting options
- 🖥️ Standalone executable (Console/Worker Service)
- Great for timers, FS watchers, and event log subscribers.
- Use
BackgroundService+ DI; add graceful shutdown and health checks.
- 🧩 Windows Service
- Long-running, auto-start, restart-on-failure; ideal for FS watcher and event log.
- Use the Worker Service template; configure recovery in Service Control Manager.
- 🌐 ASP.NET Core (Kestrel/IIS)
- Best for HTTP and webhooks. Hosts minimal APIs, controllers, and health endpoints.
- Works on Windows/Linux; put behind a reverse proxy or use IIS in Windows.
- 📦 Container (Docker/Kubernetes)
- Portable across environments; good for any trigger type.
- Add liveness/readiness probes; handle SIGTERM for graceful shutdown.
- 🐧 Linux cron / systemd timer
- Simple periodic execution for batch jobs.
- Prefer a single-entry console app; log to stdout/stderr with structured logs.
Based on your hosting choice, any trigger pattern is possible. Choose for your ops model: deployability, observability, HA, and cost.
Design guidelines
- DI lifetimes: prefer singleton for factories/clients, scoped for per-operation context, transient for stateless helpers. Create scopes inside background workers.
- Resiliency: use
IHttpClientFactory+ Polly (timeouts, retries, circuit breaker). Add dead-letter queues for webhook handling. - Idempotency: dedupe webhook deliveries; use idempotency keys and persistent state.
- Backpressure: debounce FS events; queue work and process with concurrency limits.
- Scheduling: avoid overlap (use distributed mutex), track last-success timestamp for catch-up.
- Observability: structured logs, OpenTelemetry tracing/metrics, health endpoints.
- Security: input validation, signature verification, least-privilege tokens, secret rotation.
What’s next
Deep dives for each trigger with patterns, code, and trade-offs: