Ein Bot arbeitet eine Excel-Liste von oben nach unten ab, während weitere Runner kaum ausgelastet sind. Genau an diesem Punkt wird Workload Management in Automation Anywhere interessant: Das Verfahren, in Automation Anywhere 360 als WLM abgekürzt, zerlegt ein Volumen in einzelne Work Items und verteilt diese über Queues auf verfügbare Ausführungsressourcen. Dieser Beitrag beschreibt Automation Anywhere 360 mit Stand 09/2026 und ordnet ein, wann WLM trägt, welche Architekturentscheidungen früh fallen müssen und wo typische Fehlannahmen beginnen.
WLM ist kein Ersatz für jeden klassischen Bot-Lauf. Das Modell passt in Automation Anywhere 360 vor allem dann, wenn einzelne Datensätze unabhängig voneinander verarbeitet und auf mehrere Geräte verteilt werden können. Statt einer großen Datei als unteilbaren Auftrag behandelt WLM jede relevante Zeile oder jedes API-Payload als eigenes Work Item.
Die Produktdokumentation zu Workload Management nennt klare Signale für eine Prüfung:
Entscheidend ist die Granularität. Kann jeder Datensatz unabhängig verarbeitet werden, lässt sich Arbeit verteilen. Bestehen harte Abhängigkeiten zwischen den Datensätzen, muss die Prozessarchitektur diese zuerst auflösen. WLM stellt die Queue- und Ausführungsmechanik bereit, ersetzt aber keine fachliche Zerlegung des Prozesses.
Der Unterschied zum Batch-Scheduling liegt im Arbeitsmodell. Beim Scheduling sammelt sich Arbeit häufig bis zu einem geplanten Lauf. Im Queue-Modell steht ein Work Item zur Verarbeitung bereit, sobald es eingestellt wurde und geeignete Ressourcen verfügbar sind. Das macht WLM zu einem Hebel für kürzere Wartezeiten und bessere Ressourcennutzung, jedoch nicht zu einer Garantie für bestimmte Laufzeiten.
Eine Workload Queue ist der im Control Room verwaltete Container für Work Items. Ein Work Item repräsentiert einen unabhängig verarbeitbaren Datensatz, etwa eine CSV-Zeile oder ein API-Payload. Das Work Item Template definiert dessen Spalten und Datentypen und verbindet Queue und Bot über ein gemeinsames Schema.
Der grundlegende Ablauf bleibt überschaubar. Daten gelangen aus einer CSV, über eine API oder durch einen Bot in die Queue. Anschließend bestimmen Sortier- und Prioritätsregeln die Reihenfolge. Freie Devices ziehen Work Items und führen die gebundene Automatisierung aus. Das Ergebnis kann als Work Item Result an der Queue gespeichert werden.
Für die Ausführung sind zwei Modelle relevant. Beim klassischen Modell wird die Queue mit einem Device Pool, also einer logischen Gruppe gleichartiger unattended Bot-Runner-Maschinen, verbunden. Alternativ kann ein Deployment über Default Devices erfolgen. Diese Entscheidung ist nicht nur technisch, weil sie festlegt, wie Parallelität und Priorisierung später funktionieren.
Ein WLM-Bot muss an dasselbe Work Item Template wie die Queue gebunden sein. Für das reguläre Deployment muss er im Public Workspace eingecheckt sein und wird über „Run with queue“ gestartet. Der Test „Run with queue“ direkt im Bot Editor benötigt die Enterprise Platform License. Das gilt ebenso für ACC Monitoring, das Ausführungen mit Status und Logs zusammenführt.
Das Rollenmodell im Workload Management von Automation Anywhere ist einer der wichtigsten Unterschiede zu einfachen Bot-Deployments. Owner und Participant können Work Items hinzufügen. Nur der Consumer darf einen Bot mit der Queue ausführen. Diese Zuständigkeiten schließen sich für die jeweilige Funktion bewusst aus: Wer die Queue bestückt oder verwaltet, erhält dadurch nicht automatisch Ausführungsrechte.
Der Owner kann die Queue außerdem bearbeiten und Zugriffe verwalten. Participants und Consumers werden als Rollen zugewiesen, während Owner als User hinterlegt werden. Für „Run with queue“ benötigt die ausführende Rolle Consumer-Zugriff sowohl auf die Queue als auch auf den Device Pool.
Eine besonders schwer erkennbare Fehlkonfiguration betrifft den Run-as-User. Er muss in der Rollenkonfiguration in beiden Tabs stehen:
Fehlt der Run-as-User in nur einem dieser Tabs, kann das WLM-Deployment still scheitern. Historical Activity und Audit Log zeigen dabei keine verwertbare Fehlermeldung. Die Ursache erscheint nur in den Bot-Agent-Logs. Deshalb gehört diese Doppelzuordnung in jede technische Abnahmecheckliste für WLM.
Lizenzen bleiben von den Berechtigungen getrennt. Bot-Creator- und Bot-Runner-Lizenzen ersetzen keine Rollenrechte, und Rollenrechte ersetzen keine Lizenz. Ein belastbares Setup prüft daher Queue-Zugriff, Pool-Zugriff, Run-as-Zuordnung und Lizenz gemeinsam.
Die Struktur einer Queue ist keine beiläufige Konfiguration, sondern die folgenreichste Einzelentscheidung beim Workload Management in Automation Anywhere. Sie legt fest, welche Felder der Bot erhält, welche Datentypen gelten und wonach Work Items sortiert werden. Nach dem Anlegen lässt sich diese Struktur nicht mehr ändern. Ein Fehler führt damit nicht zu einer kleinen Korrektur, sondern zu einer neuen Queue.
Im Control Room können maximal 10 Spalten sichtbar sein. Diese Auswahl sollte den Betrieb unterstützen: Operatoren müssen ein Work Item einordnen können, ohne zunächst Daten zu exportieren. Für die Sortierung lassen sich bis zu drei Spalten festlegen, jeweils auf- oder absteigend.
Auch die Sortierlogik verlangt Aufmerksamkeit. Sie wirkt pro eingefügtem Batch, nicht global über alle bereits vorhandenen Work Items. Werden mehrere Batches nacheinander eingestellt, wird jeder Batch für sich sortiert. Außerdem zeigt die Oberfläche Work Items in Einfügereihenfolge, während die Verarbeitung der definierten Sortierung folgt.
Für produktive Queues ist deshalb ein kurzer Schema-Workshop sinnvoll. Dabei sollten Verantwortliche festlegen, welche Felder der Bot wirklich benötigt, welche Spalten im Betrieb sichtbar sein müssen und welche Attribute die fachliche Reihenfolge bestimmen. Diese Entscheidung gehört vor die technische Anlage der Queue, nicht in die Fehlerkorrektur nach dem Go-live.
WLM bietet drei Ebenen der Priorisierung. Diese Ebenen greifen nicht unabhängig voneinander, sondern bilden eine Rangfolge. Wer nur die Priorität einzelner Work Items betrachtet, kann deshalb im Betrieb eine andere Reihenfolge beobachten als erwartet.
| Ebene | Konfiguration | Wirkung |
|---|---|---|
| Automation | High, Medium oder Low beim Deployment | Ordnet wartende Automatisierungen für einen Bot-Runner-User ein |
| Queue am Device Pool | Round robin oder feste Priorität | Bestimmt, welche Queue im klassischen Pool-Modell bedient wird |
| Work Item | Sortierung über bis zu drei Spalten | Ordnet Work Items innerhalb der jeweiligen Queue |
Die entscheidende Regel lautet: Die Queue-Priorität am Device Pool schlägt die Work-Item-Priorität. Hat eine Queue am Pool Vorrang, wird sie vor der nachgeordneten Queue bedient. Ein fachlich hoch priorisiertes Work Item in der zweiten Queue wartet daher, solange die erste Queue nach der Pool-Regel an der Reihe ist.
Auch Automation-Priorität ist kein Preemption-Mechanismus. Wartet eine höher priorisierte Automatisierung, wird sie vor einer niedrigeren gestartet. Läuft die niedrigere Automatisierung bereits, unterbricht WLM sie nicht. Die höhere Priorität greift erst nach deren Abschluss.
Round robin verteilt Zeitfenster zwischen Automatisierungen. Die feste Priorität arbeitet dagegen die zuerst eingestufte Queue vollständig ab, bevor die nächste folgt. Damit ist die Pool-Konfiguration eine Betriebsentscheidung: Gleichmäßige Zeitscheiben und strikte Reihenfolge lösen unterschiedliche Anforderungen.
Parallelität ist der Punkt, an dem viele WLM-Architekturen in Automation Anywhere 360 an eine Grenze stoßen. Der häufigste Architekturirrtum betrifft mehrere Automatisierungen in einem gemeinsamen Device Pool. Im klassischen Pool-Modell ist immer nur eine Queue aktiv. Mehrere dort konfigurierte Automatisierungen laufen deshalb nicht gleichzeitig, selbst wenn das Design auf den ersten Blick ausreichend Runner und Benutzer vorsieht.
Automation Anywhere 360 adressiert diese Grenze mit Parallel Queue Processing ab Version 37. Dieses Modell verwendet Default Devices der Run-as-User und umgeht den Device Pool bewusst. Dadurch können mehrere Queues parallel verarbeitet werden, sofern die Ressourcen passend und getrennt zugeordnet sind. Round robin und feste Pool-Prioritäten gelten dort nicht, weil beide Funktionen an den Device Pool gebunden sind.
Mischbetrieb braucht klare Grenzen. Die Dokumentation empfiehlt, Run-as-User und Devices für Parallel-Queue- und Pool-Modus nicht zu mischen. Geteilte Benutzer können eine Automatisierung zuerst belegen und andere Verarbeitungen warten lassen. Auch eine höhere Priorität unterbricht eine bereits laufende Parallel-Queue nicht.
Neben dem Laufzeitverhalten müssen Architekten die Entity-Limits des Control Room berücksichtigen:
| Planungsgröße | Grenze |
|---|---|
| Queues pro Control Room | 100 |
| Device Pools pro Control Room | 100 |
| Work Items | 30 Millionen |
| Gleichzeitige Bot-Deployments beziehungsweise Ausführungen | 1.000 |
Diese Grenzen sind keine Hardwarekennzahlen. Zusätzliche CPU, Arbeitsspeicher oder weitere Maschinen heben sie nicht an. Wer in diese Größenordnung wächst, muss daher nicht nur Runner-Kapazität planen, sondern auch die Anzahl der Control-Room-Entitäten und parallelen Deployments.
Pooling spart zudem keine Lizenz pro aktivem Lauf. Jeder aktive Run auf einem Device benötigt eine unattended Lizenz, unabhängig vom Deployment-Modell. Pooling kann Leerlauf reduzieren, verändert aber nicht den Lizenzverbrauch der tatsächlich laufenden Ausführung.
Bei WLM entstehen falsche Erwartungen oft durch Begriffe aus älteren Produktständen oder durch zu weit gefasste Nutzenversprechen. Automation Anywhere 360 bietet konkrete Steuerungshebel, aber keine eigenständige Logik, die daraus automatisch betriebliche Zusagen ableitet.
Für die Bewertung sind fünf Abgrenzungen wichtig:
Diese Grenzen sprechen nicht gegen WLM. Sie zeigen vielmehr, welche Aufgaben bei Architektur und Betrieb verbleiben. Prioritäten müssen bewusst modelliert, Kapazitäten geplant und Berechtigungen vollständig getestet werden. Automation Anywhere fasst die betrieblichen Leitlinien dazu in seinen empfohlenen Praktiken für WLM zusammen. Wer WLM als Orchestrierungsmechanik versteht, kann die Funktion realistischer bewerten als mit pauschalen Skalierungsversprechen.
Workload Management in Automation Anywhere ist dann sinnvoll, wenn unabhängige Work Items verteilt, priorisiert und mit vorhandenen Runnern verarbeitet werden sollen. Besonders aussagekräftig sind eine Geräteauslastung unter 50 %, zeitkritische Volumina, Priorisierungsbedarf und das Risiko einer Single-Bot-Abhängigkeit.
Der Nutzen hängt jedoch an frühen Entscheidungen. Das Work Item Template ist nach der Anlage unveränderlich, die Pool-Priorität überstimmt die Sortierung einzelner Work Items, und das Rollenmodell trennt Bestückung von Ausführung. Parallelität über mehrere Queues erfordert ab Version 37 das dafür vorgesehene Default-Device-Modell statt eines klassischen Device Pools.
Für IT-Leiter und Automation-Verantwortliche ist WLM deshalb weniger eine zusätzliche Bot-Funktion als eine Architekturentscheidung. Wer Queue-Struktur, Rollen, Deployment-Modell, Kapazitätsgrenzen und Monitoring vorab festlegt, erhält belastbare Steuerungshebel. Wer diese Punkte offenlässt, verlagert die eigentliche Komplexität lediglich in den Betrieb.
Willkommen bei unserem exklusiven Support für Bestandskunden. Hier finden Sie alle nötigen Informationen, um schnell und unkompliziert Hilfe bei technischen Anfragen zu erhalten.
Für eine direkte Unterstützung per Fernwartung, laden Sie bitte unser TeamViewer-Modul herunter:
Bitte beachten Sie: Dieser Kanal ist speziell für technische Anfragen unserer Bestandskunden vorgesehen. Für allgemeine Anfragen, Informationen zu unseren Dienstleistungen oder eine Erstberatung nutzen Sie bitte unser Kontaktformular oder schreiben Sie eine E-Mail an [email protected].
