Verträge bzw. Angebote können nun mit Hilfe des Java Persistence API (JPA) direkt in einer Datenbank persistiert werden. Hierzu können die entsprechenden JPA Informationen direkt im Vertragsmodell hinterlegt werden. Der Codegenerator erzeugt daraus die entsprechenden JPA Annotationen. Modellinformationen wie beispielsweise die Art der Beziehung werden zur Generierung vernünftiger Defaultwerte verwendet. Im folgenden sind einige Screenshots von den Editoren / Dialogen zur Bearbeitung der JPA Informationen zu sehen. Ein ausführliches Tutorial ist in Vorbereitung.

Nach der Anlage eines neuen Java-Projektes kann nun im Dialog zum Hinzufügen der Faktor-IPS Nature die JPA-Unterstützung angewählt werden.


Der Editor für die Bearbeitung von Vertragsklassen enthält in diesem Fall nun einen Abschnitt für die JPA Informationen der Vertragsklasse.


Die Dialoge zur Bearbeitung von Attributen und Beziehungen enthalten jeweils eine neue Tabpage zur Bearbeitung der JPA Informationen. Diese zeigen die nächsten beiden Abbildungen.





Darüber hinaus enthält der Editor für Vertragsklassen eine neue Seite ‚Persistence‘, auf der die Persistenzeigenschaften der Klasse im Überblick dargestellt werden.

Um im JavaEE Umfeld eine neue Version der Produktdaten auszuliefern war es bisher notwendig die gesamte Applikation neu auszuliefern. Dies lag vor allem daran, dass die Produktdaten zusammen mit dem Programmcode in einem gemeinsamen EAR (Enterprise Archive) oder WAR (Web Application Archive) ausgeliefert wurden. Außerdem konnte nur durch einen Neustart des Services sicher gestellt werden, dass Caches geleert und bereits geladene Klassen verworfen wurden.

Durch das Getrennte Deployment von Produktdaten ist es möglich, die Produktdaten unabhängig vom Programmcode in einem separaten Service auszuliefern. Der Auslieferungszyklus von Produktdaten und Programmcode kann dadurch unabhängig voneinander gestaltet werden.

Eine Besonderheit stellten dabei die Formeln in Produktbausteinen dar. Bisher werden für Formeln Subklassen der Anpassungsstufen erzeugt, in denen die Formeln in Java-Code übersetzt enthalten sind. Dadurch enthalten die Produktdaten neben XML-Ressourcen auch Programmcode. Werden Produktdaten getrennt ausgeliefert würden sich damit in der Applikation auch Teile der Implementierung ändern. Um das zu vermeiden wird die Formel als Java-Code zusätzlich in die XML-Datei geschrieben. Zur Laufzeit wird die Formel mit Groovy ausgeführt.

Die Implementierung des ProductDataService als EJB 3.0 Stateless Session Bean sowie der Groovy-Formel-Interpreter können auf der Downloadsite mit dem Archiv faktorips-runtime-addons runtergeladen werden.

Eine ausführliche Dokumentation zum Thema Getrenntes Deployment von Produktdaten folgt in kürze.

Die Modell- und Produktinformationen können nun im HTML dargestellt werden. Für die Erstellung gibt es einen eignen Export-Wizard. Der Wizard kann über das Export-Menü von Eclipse gestartet werden. Hier finden sie als Bespiel den HTML-Export der Tutorial-Projekte.

Für die Umstellung von Faktor-IPS 2.x auf 3.0 ist eine Migration erforderlich, da für die JPA Generierung eine Umstellung des Codegenerators für Composite-Beziehungen erforderlich waren. Wenn Sie hierzu Detailinformationen benötigen, wenden Sie sich bitte an Faktor Zehn.