© Excellent backgrounds/Shutterstock.com
Java Magazin
Continuous Integration für automatisierte Geschäftsprozesse mit Maven und Jenkins

Geschäftsprozesse vom Fließband

Während in Java-Projekten ein automatisierter Build heutzutage Standard ist, wird dies in Projekten, die auf BPEL oder BPMN aufsetzen, oftmals versäumt. Die Modellierungsumgebungen, wie in unserem Fall ActiveVOS, bieten nur rudimentäre Unterstützung für Build-Werkzeuge. Zudem gilt es viele Abhängigkeiten zu WSDL- und Schemadateien zu verwalten, die nicht in Maven, sondern in anderen Repositories versioniert sind. Wir stellen die Projektstruktur vor, die sich im Laufe unseres Projekts entwickelt hat, und die es uns erlaubt, automatisiert alle Projektartefakte inklusive unserer ausführbaren Geschäftsprozesse zu paketieren und zu verteilen.

Martin Heinrich, Daniel Lübke


Geschäftsprozesse, die mittels BPMN2 oder BPEL modelliert und ausgeführt werden, finden immer mehr Anklang. Die schnelle Entwicklung von prozessbasierten Anwendungen durch die Nutzung von Geschäftsprozess-Engines sowie die Möglichkeit, Prozesse besser zu verwalten und zu kontrollieren, sind wichtige Vorteile dieser Technologie.

Was viele Marketingprospekte jedoch verschweigen, ist die Tatsache, dass die Modellierung ausführbarer Geschäftsprozesse ebenfalls Programmierung ist. Somit treten dort ähnliche (Qualitäts-)Probleme auf wie in anderen Softwareprojekten. Neben Unit Tests sind also vollautomatisierte Builds und Deployments ein Thema. Aufbauend auf diesen ist es auch möglich, Nightly Builds und Continuous Integration aufzubauen, die nochmals die Qualitäts- durch stabile Software-Builds steigern können.

Die meisten Werkzeuge sind jedoch auf eine Programmiersprache wie Java, C# oder Ruby ausgerichtet. Daher ist es nötig, sich Gedanken zu machen, wie man mit möglichst wenig Aufwand die Geschäftsprozesse wie alle anderen Komponenten in dem Projekt handhaben und in die Build-Umgebung integrieren kann.

Beispielprojekt

In unserem aktuellen Projekt standen wir schnell vor der Herausforderung, ein komplexes Softwareprojekt zur Prozessintegration von mehreren Hundert Partnersystemen effizient zu entwickeln und mit hoher Qualität in die Produktion zu überführen. Der Prozessteil dieses Projekts besteht aktuell aus:

12 Prozessen, die mittels ActiveVOS modelliert und ausgeführt werdenzwei Java-Bibliotheken, um weitere XPath-Funktionen auf dem Server zur Verfügung zu stellen18 BPELUnit-Test-Suiten, die Unit und Integrationstests abdecken

Daneben gibt es noch weitere Java-Webanwendungen und Web Services, die aber klassische Java-Komponenten sind und somit aus Maven- und Jenkins-Sicht nicht interessant.

Im Folgenden wollen wir demonstrieren, wie das komplette Build und Deployment in diesem Projekt mittels Apache Maven und Jenkins automatisiert werden konnte.

Build-Automatisierung mit Apache Maven

Im ersten Schritt musste das komplette Projekt automatisiert erstellt und paketiert werden. Da neben den ausführbaren Prozessen ausschließlich Java-Komponenten entwickelt wurden, fiel die Wahl für das Build-System auf Apache Maven [1].

Damit wollten wir standardisierte Builds und Deployments etablieren, die nicht abhängig vom Entwickler sind, sondern – egal von wo, von wem und zu welchem Zeitpunkt – einheitlich gemacht werden. Neben den Java-Projekten gibt es im Wesentlichen zwei Mav...

Java Magazin
Continuous Integration für automatisierte Geschäftsprozesse mit Maven und Jenkins

Geschäftsprozesse vom Fließband

Während in Java-Projekten ein automatisierter Build heutzutage Standard ist, wird dies in Projekten, die auf BPEL oder BPMN aufsetzen, oftmals versäumt. Die Modellierungsumgebungen, wie in unserem Fall ActiveVOS, bieten nur rudimentäre Unterstützung für Build-Werkzeuge. Zudem gilt es viele Abhängigkeiten zu WSDL- und Schemadateien zu verwalten, die nicht in Maven, sondern in anderen Repositories versioniert sind. Wir stellen die Projektstruktur vor, die sich im Laufe unseres Projekts entwickelt hat, und die es uns erlaubt, automatisiert alle Projektartefakte inklusive unserer ausführbaren Geschäftsprozesse zu paketieren und zu verteilen.

Martin Heinrich, Daniel Lübke


Geschäftsprozesse, die mittels BPMN2 oder BPEL modelliert und ausgeführt werden, finden immer mehr Anklang. Die schnelle Entwicklung von prozessbasierten Anwendungen durch die Nutzung von Geschäftsprozess-Engines sowie die Möglichkeit, Prozesse besser zu verwalten und zu kontrollieren, sind wichtige Vorteile dieser Technologie.

Was viele Marketingprospekte jedoch verschweigen, ist die Tatsache, dass die Modellierung ausführbarer Geschäftsprozesse ebenfalls Programmierung ist. Somit treten dort ähnliche (Qualitäts-)Probleme auf wie in anderen Softwareprojekten. Neben Unit Tests sind also vollautomatisierte Builds und Deployments ein Thema. Aufbauend auf diesen ist es auch möglich, Nightly Builds und Continuous Integration aufzubauen, die nochmals die Qualitäts- durch stabile Software-Builds steigern können.

Die meisten Werkzeuge sind jedoch auf eine Programmiersprache wie Java, C# oder Ruby ausgerichtet. Daher ist es nötig, sich Gedanken zu machen, wie man mit möglichst wenig Aufwand die Geschäftsprozesse wie alle anderen Komponenten in dem Projekt handhaben und in die Build-Umgebung integrieren kann.

Beispielprojekt

In unserem aktuellen Projekt standen wir schnell vor der Herausforderung, ein komplexes Softwareprojekt zur Prozessintegration von mehreren Hundert Partnersystemen effizient zu entwickeln und mit hoher Qualität in die Produktion zu überführen. Der Prozessteil dieses Projekts besteht aktuell aus:

12 Prozessen, die mittels ActiveVOS modelliert und ausgeführt werdenzwei Java-Bibliotheken, um weitere XPath-Funktionen auf dem Server zur Verfügung zu stellen18 BPELUnit-Test-Suiten, die Unit und Integrationstests abdecken

Daneben gibt es noch weitere Java-Webanwendungen und Web Services, die aber klassische Java-Komponenten sind und somit aus Maven- und Jenkins-Sicht nicht interessant.

Im Folgenden wollen wir demonstrieren, wie das komplette Build und Deployment in diesem Projekt mittels Apache Maven und Jenkins automatisiert werden konnte.

Build-Automatisierung mit Apache Maven

Im ersten Schritt musste das komplette Projekt automatisiert erstellt und paketiert werden. Da neben den ausführbaren Prozessen ausschließlich Java-Komponenten entwickelt wurden, fiel die Wahl für das Build-System auf Apache Maven [1].

Damit wollten wir standardisierte Builds und Deployments etablieren, die nicht abhängig vom Entwickler sind, sondern – egal von wo, von wem und zu welchem Zeitpunkt – einheitlich gemacht werden. Neben den Java-Projekten gibt es im Wesentlichen zwei Mav...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang