viadee Process Application Validator
Continuous Integration auch für Prozessanwendungen auf Basis von Camunda
Jetzt kostenlos testenStatische Validierung von Prozessanwendungen auf Basis von Camunda
Der viadee Process Application Validator (vPAV) steht seit 2018 als OpenSource-Projekt auf GitHub zur Verfügung. Er setzt die Idee einer Continuous Integration auch für Prozessanwendungen auf Basis von Camunda um: Jede Änderung führt zu einer automatischen Prüfung. Angetrieben durch positives Feedback, wurde vPAV stetig um wichtige Funktionalitäten erweitert, um Kund:innen in der Qualitätssicherung ihrer Prozessanwendungen zu unterstützen.
Softwarequalität – Jetzt auch für Prozessanwendungen
Entwickler:innen von Prozessanwendungen stehen vor der besonderen Herausforderung eine Anwendung zu entwickeln die aus einer graphischen und einer textuellen Komponente besteht. Das Zusammenspiel zwischen Prozessmodell und der referenzierten Implementierung erschweren den Einsatz gängiger Verfahren zur Sicherstellung von Softwarequalität. vPAV schließt diese Lücke und hilft Ihnen die Prozessanwendung in ihrer Gänze zu validieren.
Standards – Konventionen durchsetzen
Die Ergänzung gängiger Softwarequalitätswerkzeuge bietet die Möglichkeit einen ganzheitlichen Blick auf Prozessanwendungen zu werfen. So können
Konventionen für Namensschemata für das ganze Prozessmodell frei konfigurierbar vorgegeben werden. Ebenso ist eine Prüfung auf die Verwendung von Skripten möglich, die aus Architekturüberlegungen meist unerwünscht sind, durch die verschmelzende Trennung von Steuerung auf Prozessebene und Fachlogik in Fachsystemen. Solche Konventionen können projektspezifisch angepasst oder als übergeordneter Standard für alle Projekte forciert werden.
Continuous Integration – Erweiterung der CI/CI Pipeline
Die Integration in eine bestehende Java-Prozessanwendung ist sehr einfach: Mittels einer Maven-Dependency und einem Ein-Zeiler im JUnit-Test können sie bereits starten. Durch die Verwendung vom vPAV im Test-Scope bleiben ihre Build-Artefakte stets unberührt. Jegliche Änderungen am Prozessmodell oder der referenzierten Implementierung können als Teil einer CI/CD Pipeline ausgeführt werden. Abweichungen von Konventionen oder technische Fehler werden frühzeitig aufgedeckt und führen zum Abbruch des Build-Vorgangs. So wird sichergestellt, dass Sie stets hochwertige Softwareinkremente ausliefern und sparen sich Stress und Kopfschmerzen kurz vor Release.
Inkonsistenzen – Überblick der Ergebnisse
Nachdem vPAV eingebunden und auf die individuellen Bedürfnisse angepasst ist, kann das Zielprojekt auf Inkonsistenzen geprüft werden. Nach jedem Durchlauf werden die Ergebnisse neu generiert und können im maschinen-lesbaren Format (JSON und XML) exportiert werden. Zusätzlich wird eine Visualisierung mit genauen Fehlermeldungen erstellt und bietet dem:der Nutzer:in dabei sowohl eine Übersicht als auch die konkrete Fehlerquelle.
Ihr Mehrwert
-
Als Unternehmen
- Steigern Sie die Qualität Ihrer Software nachhaltig
- Fokussieren Sie sich auf das Wesentliche: Reduzierter Zeitaufwand für Bug Fixes erlaubt Schaffung von Mehrwert
-
Als Architekt:in
- Führen Sie Konventionen ein, sowohl projektspezifisch als auch projektübergreifend
- Konsistenzprüfungen stellen Standards bereits während der Entwicklung sicher
-
Als Entwickler:in
- Finden Sie frühzeitig Fehler statt nach dem Release
- Minimal invasive und leichte Einbindung als Unit Test
- Resultierende Artefakte bleiben unberührt
-
Als Anwender:in
- Erweiterte Qualitätssicherung reduziert Ausfallzeiten und unerwünschtes Verhalten
- Reibungsloser Ablauf der Prozessanwendung sorgt für hohe Nutzer:innen-Zufriedenheit
Features
- Sind Implementierungen korrekt referenziert und aktuell?
- Sind eingebundene Groovyskripte korrekt?
- Ist die Nutzung der Prozessvariablen fehlerfrei?
- Entspricht die Benennung von Prozessvariablen der Konvention?
- Entspricht die Benennung von Tasks der Konvention?
- Entspricht die Benennung von Task-Ids der Konvention?
- Endet die Benennung von XOR-Gateways mit „?“ und existiert ein default-Pfad?
- Wird im Prozessmodel Skript referenziert oder genutzt?
- Sind Zeitangaben ISO 8601 konform?
- Sind MessageEvents korrekt eingebunden?
- Sind SignalEvents korrekt eingebunden?
- Gibt es überlappende Sequenzflüsse?
- Entspricht die Nutzung von Prozessvariablen den konfigurierbaren Regeln?
- Werden BpmnError-Codes im Prozessmodell referenziert?
- Werden Expressions entgegen Best-Practices genutzt?
- Folgen die eingetragenen Extension-Werte der Konvention?
Ansprechperson
Sascha Di Bernardo
Tel: +49 251 777 77 0
Agile Methoden 
Business Process Management 
Clean Code 
Cloud 
IT-Sicherheit 
Java & Architektur 
Legacy IT 
Frontend-Entwicklung 
Robotic Process Automation 
Software-Qualitätssicherung