Regeln in Pega-Anwendungen
Wenn Sie Schach spielen, verständigen Sie und Ihr Gegner sich darauf, bestimmte Anweisungen zu befolgen. Hierbei handelt es sich um die Spielregeln, z. B. wie sich jede Figur auf dem Spielbrett bewegt. Zum Beispiel kann der Bauer bei seinem ersten Zug ein oder zwei Felder vorrücken. Diese Basisanweisungen sind die Schachregeln.
Ähnlich funktioniert das Modellieren eines Case-Typs bei einer Pega-Plattform-Anwendung, wenn Sie die Anwendung mit Anweisungen zum Erstellen, Bearbeiten oder Abschließen eines Cases konfigurieren. Diese Anweisungen sind die Regeln des Case-Typs.
Regeln sind die Grundbausteine einer Pega-Anwendung. Sie werden vom Projektteam konfiguriert, um eine Geschäftslösung für den Kunden und dessen Endkunden zu erstellen. Die Pega-Plattform verwendet Regeln, um Java-Anwendungscode im Hintergrund zu generieren. Pega-Plattform-Anwendungen enthalten viele Regeltypen für unterschiedlichste Arten von Anwendungsverhalten. Regeln sind flexibel und wiederverwendbar. Dadurch kann das Projektteam Anwendungs-Features effizienter entwerfen und sie über mehrere Case-Typen und Anwendungen hinweg implementieren.
In diesem Lerninhalt werden Regeln ausführlicher untersucht.
Automatisierte Regelerstellung in App Studio
Der Low-Code-Ansatz von Pega bedeutet, dass Benutzer einen Großteil der Anwendungsentwicklung in App Studio erledigen können, insbesondere zu Beginn des Anwendungsentwicklungsprozesses. Durch das Hinzufügen einer Workflow-Automatisierung in App Studio erstellt und verwaltet die Pega-Plattform automatisch die zugrunde liegenden Regeln in Dev Studio. Wenn Sie z. B. einen Case-Typ in App Studio konfigurieren, verwenden Sie den Case Life Cycle Designer und Konfigurationspanels, um eine Ansicht zu einem Step „Collect Information“ hinzuzufügen. Im Hintergrund erstellt und verwaltet die Pega-Plattform die Regeln, mit denen die Prozessabläufe und Aufgaben sowie die Benutzeroberfläche (UI) definiert werden.
Ziehen Sie in der Mitte der folgenden Abbildung die vertikale Linie, um den Case-Life-Cycle mit einem in App Studio erstellten Prozess und die im Hintergrund vom System erstellte Ablaufregel des Prozesses anzuzeigen:
Hinweis: Jeder Step im Case-Life-Cycle entspricht einer Shape in der Ablaufregel (auch als „Flow Rule“ bezeichnet). Ein Flow-Konnektor verknüpft eine Shape mit einer anderen und stellt die Aufgabe oder das Assignment dar, die bzw. das Benutzer abschließen müssen, um von einer Shape (Step) zur nächsten zu gelangen.
Das Erstellen komplexer Regeln mit der benutzerfreundlichen Oberfläche von App Studio ist das Besondere der Low-Code-Funktionalität, die die Pega-Plattform bietet.
Während Entwickler mit unterschiedlichsten technischen Qualifikationen mit der visuellen Low-Code-Modellierung Workflow-Automatisierungen App Studio erstellen, übernimmt die Pega-Plattform im Hintergrund die „Schwerstarbeit“ und erstellt die technischen Regeln, die diesen Automatisierungen entsprechen. Dadurch können sich Business Architects und andere weniger technisch versierte Entwickler im Projektteam wie Citizen Developer auf die Definition von Geschäftsaufgaben konzentrieren statt auf die Programmierung.
Hinweis: Die technischen Regeln sind für fortgeschrittenere, technische Entwickler über Dev Studio zugänglich. Diese stärker technischen Regeln, die Entwickler in Dev Studio erstellen, können den Benutzern in App Studio zur Verfügung gestellt werden.
Prüfen Sie mit der folgenden Interaktion Ihr Wissen:
Anwendungsmodularität mit Regeln
Durch die Verwendung individueller Regeln wird eine Anwendung modular. Durch die Beschreibung des Case-Verhaltens mit modularen, aufgabenorientierten Regeln können Regeln kombiniert und wiederverwendet werden. So können Sie beispielsweise eine Regel zur Beschreibung des Inhalts einer Kunden-E-Mail zum Status einer Adressänderung erstellen. Indem Sie die E-Mail-Nachricht als separate Regel erstellen, statt die Nachricht in den Case-Life-Cycle einzubetten, können Sie den Inhalt der E-Mail aktualisieren, ohne den Rest des Business-Prozesses zu beeinträchtigen.
Diese Modularität bietet drei entscheidende Vorteile: Versionierung, Delegierung und Wiederverwendung.
| Versionierung | Entwickler erstellen eine neue Version einer Regel, sobald das Case-Verhalten geändert werden muss. Die Pega-Plattform speichert eine Chronik der Regeländerungen, sodass Entwickler sich diesen Verlauf ansehen und gegebenenfalls Änderungen rückgängig machen können. Da jede Regel ein bestimmtes Case-Verhalten beschreibt, bleibt der restliche Case davon unberührt. | Ein Entwickler aktualisiert beispielsweise ein UI-Formular mit Anweisungen und entfernt dabei ein wichtiges Feld. Mithilfe der Chronik des Formulars können Sie dann die Version vor diesen Änderungen wiederherstellen, ohne weitere Regeln in der Anwendung zu ändern. |
|---|---|---|
| Delegierung | Entwickler delegieren Regeln an Geschäftsanwender, damit diese das Case-Verhalten an veränderte geschäftliche Bedingungen anpassen können. Der Geschäftsanwender aktualisiert die delegierte Regel, während andere Teile der Anwendung unverändert bleiben. | Beispielsweise würden Spesenabrechnungen bis zu 25 USD weiterhin automatisch genehmigt. Sie erstellen eine Regel, um festzustellen, ob eine Spesenabrechnung 25 USD oder weniger beträgt, und delegieren die Regel an die Buchhaltungsabteilung. Die Buchhaltungsabteilung kann dann die Regel aktualisieren, um beispielsweise die Grenze für automatische Genehmigung auf 50 USD zu erhöhen, ohne eine Änderungsanfrage für die Anwendung einreichen zu müssen. |
| Wiederverwendung | Entwickler verwenden Regeln wieder, wenn bestehende Case-Verhaltensweisen in eine Anwendung integriert werden sollen. Andernfalls muss das Verhalten jedes Mal neu konfiguriert werden, sobald Sie dieses Verhalten benötigen. | Sie können z. B. ein UI-Formular zur Erfassung von Informationen über Versicherungsnehmer bei Fahrzeugversicherungsfällen erstellen. Dieses UI-Formular können Sie dann für Versicherungsfälle bei Immobilien oder Seetransportversicherungen wiederverwenden. |
Hinweis: Informationen zum Delegieren einer Regel finden Sie unter Regel oder Datentyp delegieren. Für eine höhere Wiederverwendbarkeit einer Regel verwenden Sie die Parametrisierung, um die Logik der Regel auf der Grundlage des als Parameter übergebenen Werts zu steuern, anstatt festprogrammierter Daten. Die Parametrisierung hilft, die Duplizierung von Code und die Implementierungszeit von Regelspezialisierungen zu reduzieren. Weitere Informationen zur Parametrisierung finden Sie unter Eingabeparameter für eine Regel definieren.
Organisation von Regeln
Obwohl Sie keine Anwendungsregeln direkt in Dev Studio festlegen, ist es unerlässlich, dass Sie mit Ihrem Lead System Architect zusammenarbeiten, um die Organisation der Regeln für Ihre Anwendung zu verstehen.
In Dev Studio werden Regeln in Klassen und Rulesets gruppiert, damit sie leicht für die Entwicklung von Anwendungen verwendet werden können.
Klassen
In Pega beschreibt eine Class (Klasse) eine Sammlung von Regeln, die das System nach Wiederverwendbarkeit gruppiert. Jede Anwendung besteht aus den folgenden drei Arten von Klassen:
- Work: Diese Klasse für Aufgaben enthält die Regeln, die die gesamte Case-Bearbeitung von Anfang bis Ende definieren, z. B. die nötigen Prozesse, Datenelementen und Benutzeroberflächen.
- Data: Diese Datenklasse enthält die Regeln zur Definition der Datenobjekte, die von Ihrer Anwendung verwendet werden.
- Integration: Diese Klasse gilt für Integrationen und enthält Regeln zur Definition der Interaktionen zwischen der Anwendung und externen Datenbeständen, z. B. einer vom Kunden verwalteten externen Datenbank.
Übergeordnete und untergeordnete Klassen
Eine Klasse kann auch weitere Klassen enthalten. Eine Klasse, die eine andere Klasse enthält, ist eine übergeordnete Klasse, eine Parent Class. Eine Klasse, die in einer anderen Klasse enthalten ist, wird dagegen als untergeordnete Klasse oder Child Class bezeichnet. Eine untergeordnete Klasse kann alle für ihre übergeordnete Klasse definierten Regeln wiederverwenden oder übernehmen.
Klicken Sie in der folgenden Abbildung auf die Pluszeichen (+), um Details zu den über- und untergeordneten Klassen anzuzeigen:
Hinweis: Weitere Informationen zu Klassen in Pega-Anwendungen finden Sie unter Regeln in Klassen organisieren.
Prüfen Sie mit der folgenden Interaktion Ihr Wissen:
Rulesets
Regeln sind in Rulesets organisiert, um den vollständigen Satz von Regeln, die eine Anwendung definieren, zu identifizieren, zu speichern und zu verwalten. Rulesets enthalten wiederverwendbare Funktionen, die Sie von einer Pega-Anwendung zu einer anderen migrieren können. Sie können z. B. ein Ruleset erstellen, um Regeln für Service-Level-Vereinbarungen (SLA) zu speichern. Sie können das SLA-Ruleset in jeder Anwendung wiederverwenden, die zur Bearbeitung von Cases mit denselben SLAs dient. Die Möglichkeit, Rulesets zu speichern und wiederzuverwenden, beschleunigt die Entwicklung von Anwendungen für den Kunden und senkt die Kosten.
Jedes Ruleset hat einen Namen (wahrscheinlich den Namen Ihrer Anwendung) und eine Versionsnummer. Wenn Sie ein neues Ruleset erstellen, lautet die Standardversion: 01-01-01. Die Kombination aus Ruleset-Name und Version könnte z. B. so aussehen: GoGoRoad 01-01-01.
Die Versionsnummer ist in drei Segmente unterteilt: eine Hauptversion (Major Version), eine Nebenversion (Minor Version) und eine Patch-Version. Jedes Segment entspricht einer zweistelligen Zahl, die mit 01 beginnt und bis 99 ansteigt. Die Nummerierung der Ruleset-Version beginnt bei 01-01-01 und wird jeweils um 1 erhöht.
Klicken Sie in der folgenden Abbildung auf die Pluszeichen (+), um mehr über die Versionierungskonvention für Rulesets zu erfahren:
Ab 2023 folgen Pega Infinity-Produktversionen dem Format Year.Minor.Patch. Für Pega Infinity '23 lautet die Produktversion 23.1.1. Die semantische Versionierung des Pega Ruleset folgt dem Format Major-Minor-Patch. Für Pega Infinity '23 lautet die Ruleset-Version 08-23-02.
Hinweis: Pega Infinity '23 ist die neueste Nebenversion. Weitere Informationen zur Namenskonvention für Pega Infinity-Produkte finden Sie unter Pega-Software-Wartungsprogramm.
Gesperrte und entsperrte Rulesets
Wenn ein Ruleset erstellt wird, ist es entweder gesperrt oder entsperrt. Entwickler arbeiten in entsperrten Rulesets. Das Sperren von Rulesets verhindern, dass Entwickler versehentlich Änderungen vornehmen. Entwickler müssen ein Passwort eingeben, bevor sie ein gesperrtes Ruleset bearbeiten können.
Hinweis: Weitere Informationen zu Rulesets in Pega-Anwendungen finden Sie unter Regeln in Rulesets organisieren.
Der Lead System Architect (LSA) ist während des Entwicklungsprozesses sowohl für die Versionierung als auch die Ruleset-Sperrung für eine Anwendung zuständig. Wenden Sie sich an den LSA Ihres Projekts, sollten Fragen zu Regeln und Rulesets auftreten.
Prüfen Sie mit der folgenden Interaktion Ihr Wissen:
Dieses Thema ist im folgenden Modul verfügbar:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Möchten Sie uns dabei helfen, diesen Inhalt zu verbessern?