- Erste Schritte
- Einstellung und Konfiguration (Setup and Configuration)
- Automationsprojekte
- Über die Veröffentlichung von Automatisierungsprojekten
- Entwerfen von Automatisierungen
- Verwalten von Aktivitätspaketen
- Konfigurieren von Aktivitätsprojekteinstellungen
- Signieren von Paketen
- Governance
- Importieren von Entitäten
- Verknüpfen eines Projekts mit einer Idee im Automation Hub
- Verwenden des Data Managers
- Lösungen
- Abhängigkeiten
- Workflow-Typen
- Kontrollfluss
- Dateivergleich
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Integration der Quellenkontrolle
- Informationen zur Versionskontrolle
- Verwalten von Projekten mit TFS
- Verwalten von Projekten mit SVN
- Workflow Diff
- Debugging
- Protokollierung
- Das Diagnose-Tool
- Workflow-Analyse
- Über die Workflow-Analyse
- ST-NMG-001 – Namenskonvention für Variablen
- ST-NMG-002 – Namenskonvention für Argumente
- ST-NMG-004 – Duplizierung des Anzeigenamens
- ST-NMG-005 – Variable überschreibt Variable
- ST-NMG-006 – Variable überschreibt Argument
- ST-NMG-008 – Variablenlänge überschritten
- ST-NMG-009: Datentabellenvariablen mit Präfix versehen
- ST-NMG-011 – Datentabellenargumente mit Präfix versehen
- ST-NMG-012 – Standardwerte für Argumente
- ST-NMG-016 – Argumentlänge überschritten
- ST-NMG-017 – Der Klassenname stimmt mit dem Standard-Namespace überein
- ST-DBP-002 – Hohe Anzahl von Argumenten
- ST-DBP-003 – Leerer Catch-Block
- ST-DBP-007 – Mehrere Flussdiagrammebenen
- ST-DPB-010 – Mehrere Instanzen von [Workflow] oder [Testfall]
- ST-DBP-020 – Nicht definierte Ausgabeeigenschaften
- ST-DBP-021 – Hartcodiertes Timeout
- ST-DBP-023 – Leerer Workflow
- ST-DBP-024 – Prüfung der Persistenzaktivität
- ST-DBP-025 – Voraussetzung für Variablenserialisierung
- ST-DBP-027 – Bewährte Methode für Persistenz
- ST-DBP-028 – Voraussetzung für Argumentenserialisierung
- ST-USG-005 – Hartcodierte Aktivitätsargumente
- ST-USG-009 – Nicht verwendete Variablen
- ST-USG-010 – Nicht verwendete Abhängigkeiten
- ST-USG-014 – Paketbeschränkungen
- ST-USG-017 – Ungültiger Parametermodifizierer
- ST-USG-020 – Minimale Protokollmeldungen
- ST-USG-024 – Nicht verwendet, gespeichert für später
- ST-USG-025 – Missbrauch gespeicherter Werte
- ST-USG-026 – Aktivitätseinschränkungen
- ST-USG-027 – Erforderliche Pakete
- ST-USG-028 – Aufruf von Dateivorlagen einschränken
- ST-USG-032 – Erforderliche Tags
- ST-USG-034 – Automation Hub-URL
- Variablen
- Argumente
- Importierte Namespaces
- Codierte Automatisierungen
- Einleitung
- Registrieren von benutzerdefinierten Diensten
- „Vor“- und „Nach“-Kontexte
- Generieren von Code
- Generieren eines codierten Testfalls aus manuellen Testfällen
- Integrieren von OpenAI in codierte Workflows
- Beantragen eines Kredits bei der UiBank
- Warteschlangengenerierung mit codierten Workflows und Orchestrator-APIs
- Verwenden importierter Bibliotheksprojekte in codierten Automatisierungen
- Verwenden der zweistufigen Authentifizierung in codierten Automatisierungen
- Fehlersuche und ‑behebung
- Triggerbasierte Attended-Automatisierung
- Objekt-Repository
- Über Object-Repository
- Erstellen eines Repositorys durch Erfassen von Elementen
- Erstellen eines Repositorys im Bereich „Object-Repository“
- Verwenden des Object Repository mit Recordern
- Hinzufügen von Elementen aus Aktivitäten zu einem Repository
- Verwenden von Objekten im aktuellen Projekt
- Deskriptoren bearbeiten
- Auflösen von UI-Deskriptoren
- Wiederverwenden von Objekten und UI-Bibliotheken
- Tool „Object Repository synchronisieren“
- Das Tool ScreenScrapeJavaSupport
- Erweiterungen
- Über Erweiterungen
- SetupExtensions-Tool
- Hard- und Softwareanforderungen
- Taskplaner
- Parallele Unterstützung
- Hinzufügen von Remote-Runtime-Abhängigkeiten
- UiPath Remote Runtime blockiert das Schließen der Citrix-Sitzung
- UiPath Remote Runtime verursacht Speicherverlust
- Versionen von UiPath.UIAutomation.Activities-Paket und UiPath Remote Runtime stimmen nicht überein
- Die erforderliche UiPath-Erweiterung ist auf der Remotemaschine nicht installiert
- Einstellungen für die Bildschirmauflösung
- Neue Erweiterungsfunktionen
- Die Chrome-Erweiterung wird automatisch entfernt
- Überprüfen Sie, ob die Erweiterung für Chrome installiert und aktiviert ist
- Überprüfen Sie, ob ChromeNativeMessaging.exe ausgeführt wird
- Überprüfen der korrekten Definition der ComSpec-Variablen
- Aktivieren Sie den Zugriff auf Datei-URLs und den Inkognito-Modus
- Mehrere Browser-Profile
- Group Policy conflict
- Spezifische bekannte Probleme für MV3-Erweiterungen
- Liste der Erweiterungen für Chrome
- Edge-Versionsanforderungen
- Gruppenrichtlinien
- Kommunikation mit Browser nicht möglich
- Die Edge-Erweiterung wird automatisch entfernt
- Möglicherweise ist die Erweiterung beschädigt
- Überprüfen, ob die Erweiterung für Microsoft Edge installiert und aktiviert ist
- Überprüfen Sie, ob ChromeNativeMessaging.exe ausgeführt wird
- Überprüfen der korrekten Definition der ComSpec-Variablen
- Aktivieren des Zugriffs auf Datei-URLs und den InPrivate-Modus
- Mehrere Browser-Profile
- Group Policy conflict
- Liste der Erweiterungen für Edge
- Erweiterung für Citrix
- Erweiterung für Amazon WorkSpaces
- SAP Solution Manager-Plugin
- Excel-Add-in
- Studio Testing
- Fehlersuche und ‑behebung
- Informationen zur Fehlerbehebung
- Fehler bei der Assembly-Kompilierung
- Microsoft App-V – Unterstützung und Einschränkungen
- Fehlerbehebung bei Internet Explorer x64
- Probleme in Microsoft Office
- Erkennen von UI-Elementen in PDF mit Zugriffsoptionen.
- Reparieren der Active Accessibility-Unterstützung
- Die Validierung großer Windows-Legacy-Projekte dauert länger als erwartet

Studio-Benutzerhandbuch
BeforeRunContext(Einrichten): Die „Vor“-Ausführung wird verwendet, um Aktionen vor der Hauptausführung des Testfalls auszuführen. Sie wird häufig zum Einrichten des Ausgangszustands der Testumgebung und zum Vorbereiten von Ressourcen verwendet. Einige häufige Anwendungsfälle für den „Vor“-Kontext:- Initialisieren von Variablen oder Daten, die für den Test erforderlich sind.
- Einrichten von Verbindungen zu externen Systemen oder Datenbanken.
- Protokollieren des Beginns der Testausführung.
- Öffnen von Anwendungen oder Webseiten, mit denen der Test interagiert.
- Einrichten von spezifischen Ausnahmen vor der Ausführung des Testfalls.
AfterRunContext(Entfernen): Die „Nach“-Ausführung wird verwendet, um Aktionen nach Abschluss der Hauptausführung des Testfalls auszuführen. Sie wird normalerweise zum Bereinigen von Ressourcen, Abschließen von Vorgängen und Aufzeichnen der Testergebnisse verwendet. Einige häufige Anwendungsfälle für den „Nach“-Kontext:- Schließen von Anwendungen oder Webseiten, die während des Tests verwendet werden.
- Freigeben von Ressourcen, z. B. Datenbankverbindungen oder Netzwerkressourcen.
- Abfangen und Ausgeben von Ausnahmen, die im „Vor“-Kontext und in der Hauptausführung aufgezeichnet wurden.
IBeforeAfterRun-Schnittstelle neben der Hauptklasse deklarieren und dann Ihre eigene benutzerdefinierte Logik für diese Aktionen implementieren.
BeforeRunContext finden Sie
das folgende Code-
Snippet:// Context of the run before the execution.
public class BeforeRunContext
{
// The relative path of the workflow.
public string RelativeFilePath { get; set; }
}// Context of the run before the execution.
public class BeforeRunContext
{
// The relative path of the workflow.
public string RelativeFilePath { get; set; }
}Dieser Kontext entspricht dem Status vor der Ausführung der Automatisierung. Er enthält Informationen über den relativen Pfad des ausgeführten Workflows. Sie können hier Ausnahmen entsprechend Ihrem Anwendungsfall einrichten.
AfterRunContext finden Sie
das folgende Code-
Snippet:// Context of the run after the execution.
public class AfterRunContext
{
// The relative path of the workflow.
public string RelativeFilePath { get; set; }
// The exception caught in execution if any.
public Exception Exception { get; set; }
}// Context of the run after the execution.
public class AfterRunContext
{
// The relative path of the workflow.
public string RelativeFilePath { get; set; }
// The exception caught in execution if any.
public Exception Exception { get; set; }
}Dieser Kontext entspricht dem Status nach der Ausführung der Automatisierung. Er enthält Details zum relativen Pfad des ausgeführten Workflows und jegliche Ausnahmen, die vor und während der Ausführung abgefangen wurden.
Before- und Hauptausführungen werden gleichzeitig ausgeführt und es werden Ausnahmen erfasst, die während der Ausführung auftreten. Alle Ausnahmen, die während dieser Phasen ausgelöst werden, werden erfasst und in AfterRunContext gespeichert. Wenn keine Ausnahmen auftreten, bleibt der Wert null.
Before- und Hauptausführungen wird die After-Methode ausgeführt. Wenn während der After-Ausführung eine Ausnahme ausgelöst wird, wird die Ausführung beendet und die entsprechende Ausnahme ausgelöst.
Before- sowie After-Ausführungen auftreten, werden sie in einer AggregateException zusammengefasst.
Implementieren in einem codierten Testfall
Sie können die Schnittstelle für „Vor“- und „Nach“-Ausführungen direkt in Ihren codierten Testfall implementieren.
- Fügen Sie in der öffentlichen Klasse, in der sich
Ihr codierter Testfall befindet, die Schnittstelle
IBeforeAfterRunhinzu. Dies wird rot hervorgehoben, um auf mögliche Korrekturen hinzuweisen.public class MyTest : CodedWorkflow, IBeforeAfterRunpublic class MyTest : CodedWorkflow, IBeforeAfterRun - Wählen Sie Mögliche Korrekturen anzeigen aus oder drücken Sie
Ctrl + .und wählen Sie Schnittstelle implementieren aus.Dadurch wird eine Standardschnittstelle wie folgt generiert:public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); }public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); } - Ändern Sie die Implementierung nach Ihren Anforderungen.
Im angegebenen Codebeispiel protokolliert der Kontext eine Meldung vor der Ausführung und prüft danach auf Ausnahmen.
public void After(AfterRunContext context) { if (context.Exception != null) { Log(context.Exception.Message); } } public void Before(BeforeRunContext context) { Log("this is before"); }public void After(AfterRunContext context) { if (context.Exception != null) { Log(context.Exception.Message); } } public void Before(BeforeRunContext context) { Log("this is before"); }
Implementieren mit einer benutzerdefinierten partiellen Klasse
.cs-Dateien in Ihrem Projekt implementieren, indem Sie eine benutzerdefinierte partielle Klasse verwenden.
- Erstellen Sie eine Codequelldatei. Hier implementieren Sie die Schnittstelle für „Vor“- und „Nach“-Ausführungen. Benennen Sie die Datei in diesem Beispiel
TestCaseBase.- Fügen Sie die
IBeforeAfterRun-Schnittstelle neben der öffentlichen Klasse hinzu. Sie wird rot hervorgehoben, um auf mögliche Korrekturen hinzuweisen.Hinweis: Die benutzerdefinierte partielle Klasse (in diesem BeispielTestCaseBase) muss die KlasseCodedWorkflowerben. Dadurch können anderecs-Dateien, die die benutzerdefinierte partielle Klasse erben, wie erwartet ausgeführt werden.public class TestCaseBase : CodedWorkflow, IBeforeAfterRunpublic class TestCaseBase : CodedWorkflow, IBeforeAfterRun - Wählen Sie Mögliche Korrekturen anzeigen aus oder drücken Sie
Ctrl + .und wählen Sie Schnittstelle implementieren aus.Dadurch wird eine Standardschnittstelle wie folgt generiert:public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); }public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); } - Ändern Sie die Implementierung nach Ihren Anforderungen.
Im angegebenen Beispiel protokolliert der Kontext eine Meldung vor der Ausführung und prüft danach auf Ausnahmen.
public void After(AfterRunContext context) { if (context.Exception != null) { throw context.Exception; } else { Log("Test " + context.RelativeFilePath + " finished with no exception."); } } public void Before(BeforeRunContext context) { Log("Execution started for " + context.RelativeFilePath); }public void After(AfterRunContext context) { if (context.Exception != null) { throw context.Exception; } else { Log("Test " + context.RelativeFilePath + " finished with no exception."); } } public void Before(BeforeRunContext context) { Log("Execution started for " + context.RelativeFilePath); }
Sie können jetzt diese benutzerdefinierte partielle Klasse verwenden, um die gleiche Schnittstelle für „Vor“- und „Nach“-Ausführungen nur für die.cs-Dateien zu verwenden, die sie erben. - Fügen Sie die
- Erstellen Sie eine codierte Automatisierung. Erstellen
Sie in diesem Beispiel einen codierten Testfall namens
TestCase. Um die gleiche Schnittstelle für „Vor“- und „Nach“-Ausführungen von der benutzerdefinierten partiellen Klasse zu verwenden, stellen Sie sicher, dass der codierte Testfall von dieser partiellen Klasse erbt.public class TestCase : TestCaseBase { [TestCase] public void Execute() { Log("Executing the test..."); }public class TestCase : TestCaseBase { [TestCase] public void Execute() { Log("Executing the test..."); }
Execution started for file: TestCase.cs
[Info] IBeforeAfterRunExamples execution started
[Info] Execution started for TestCase.cs
[Info] Executing the test...
[Info] Test TestCase.cs finished with no exception.
[Info] IBeforeAfterRunExamples execution ended in: 00:00:00 Execution started for file: TestCase.cs
[Info] IBeforeAfterRunExamples execution started
[Info] Execution started for TestCase.cs
[Info] Executing the test...
[Info] Test TestCase.cs finished with no exception.
[Info] IBeforeAfterRunExamples execution ended in: 00:00:00Implementieren mit der partiellen Klasse CodedWorkflow
CodedWorkflow implementieren, die jeder andere codierte Testfall oder codierte Workflow in Ihrem Projekt erben kann. Diese Implementierung gilt für alle codierten Testfälle und codierten Workflows in Ihrem Projekt.
- Erstellen Sie eine Codequelldatei und benennen Sie sie anders als
CodedWorkflow.cs, da sonst ein Konflikt zwischen der partiellen Klasse und der vorhandenen schreibgeschütztenCodedWorkflow-Klasse auftritt. - Erstellen Sie eine partielle Klasse, welche die benutzerdefinierte Schnittstelle für „Vor“- und „Nach“-Kontexte implementiert.
- Benennen Sie die Klasse in
CodedWorkflowum. Andernfalls können Sie die verfügbaren Dienste nicht nutzen. - Stellen Sie sicher, dass die Klasse in Ihrer codierten Quelldatei die Klasse
CodedWorkflowBaseerbt. - Fügen Sie den
UiPath.CodedWorkflows-Namespace am Anfang Ihrer Codequelldatei hinzu.using System; using System.Collections.Generic; using UiPath.CodedWorkflows;using System; using System.Collections.Generic; using UiPath.CodedWorkflows; - Fügen Sie in die Klasse Ihrer
Codequelldatei
IBeforeAfterRunein.namespace TestAutomationProject1 { public partial class CodedWorkflow : CodedWorkflowBase, IBeforeAfterRunnamespace TestAutomationProject1 { public partial class CodedWorkflow : CodedWorkflowBase, IBeforeAfterRun - Zeigen Sie mit der Maus auf
IBeforeAfterRunund wählen Sie Mögliche Korrekturen anzeigen aus oder wählen Sie das Element aus und drücken SieCtrl + .. - Wählen Sie Schnittstelle implementieren aus.
Dadurch wird die nachfolgende Standardimplementierung erstellt:
public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); }public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); } - Optional können Sie die Schnittstelle weiter an Ihren Anwendungsfall anpassen. Im folgenden Codebeispiel gibt der Kontext vor der Ausführung eine Meldung aus. Nach der Ausführung prüft er, ob eine Ausnahme ausgelöst wurde, und gibt diese erneut aus.
public void After(AfterRunContext context) { if (context.Exception != null) { Log(context.Exception.Message); } } public void Before(BeforeRunContext context) { Log("this is before"); }public void After(AfterRunContext context) { if (context.Exception != null) { Log(context.Exception.Message); } } public void Before(BeforeRunContext context) { Log("this is before"); }