Operational Readiness

A service is only robust if it can be run and supported confidently in production: failures need to be diagnosable quickly, logs need to say something useful without drowning the signal, and releases need to be predictable.

A service is only truly robust if it can be operated confidently in production.

Helpful Operating Tools

Which Tool Answers Which Question?

Monitoring xUML Services with the xUML Service Monitor

The xUML Service Monitor catches every exception an xUML service throws and matches it against configurable error definitions, each identified by a signature of service, error category, error code, and error type. It then sends out notifications as configured.

• Start from the wildcard master template that catches everything by default, then add specific error definitions as you learn what matters — each field (service, category, code, type) accepts * as a wildcard.

• Set a threshold: how many occurrences must happen before you're notified.

• Choose Always notify to get an email on every threshold occurrence, or leave it off for the default of once per 24 hours per distinct signature.

• Configure recipients (To/CC) and a subject/description that tells the reader what actually happened and what to do next.

• Add a project-specific #hashtag to the subject line of monitoring alert emails so they can be filtered and routed automatically.

• Optionally activate Jira integration to create a ticket automatically instead of, or in addition to, an email.

• Once you've triaged an entry, set its state from "New" to "Checked" so the team can see what's already been looked at.

• Use Error Groups to bundle related error definitions and attach a shared downtime window, so planned maintenance doesn't spam everyone with alerts.

Retrying Failed Process Instances

When the xUML root state machine catches an error and a process instance is stuck, PAS operators can unstick it directly — no redeploy or CLI access needed.

• Retry Transitions: on a single persistent state object's details page, resend the last signal if the previous transition failed.

• Send Signal: send a specific signal, with optional JSON parameters, to a single object or — from the persistent state objects table — to every object currently in a chosen state at once.

• Both operations run asynchronously: a single object typically takes a few seconds, a bulk send across many instances can take several minutes.

This is exactly the retry path referenced from Integration of External Systems: fix the backend problem, then retry the stuck instances instead of asking the sender to resubmit.

Watching Resource Consumption with the Resource Monitor

The Resource Monitor is a Grafana-based, read-only dashboard reachable from a tile in the Scheer PAS Portal. It shows container metrics on Docker or pod metrics on Kubernetes, with 15 days of data retention.

Example: A service crashes periodically, or spikes load at certain times of day. Isolate it by clicking its name in the dashboard, inspect the underlying data behind a panel, and adjust its memory limit in PAS Administration based on what you see — without guessing from the outside.

Analyzing Logs with OpenSearch Dashboards

Your logs already land in OpenSearch indexes that the Log Analyzer's Discover view searches with DQL or Lucene syntax: xuml*, pas*, and fl* on Docker, or logs* on Kubernetes. Useful fields include log.domain, log.code (or level), message, and service (or workload.name).

• Click a field's "Top 5 Values" in the sidebar to filter by the most common values without writing a query.

• Discover keeps 30 days of documents.

• Pre-built PAS dashboards give an at-a-glance overview (charts, tables, heat maps); use Create dashboard to build a project-specific one, e.g. error rate by service over the last week.

• To attach evidence to a support request: save your search, then Reporting → Generate CSV.

Related Content