camunda cdi and multiple datasources

Ich durfte mich die letzten Tage mit einem ziemlich fiesen Fehler rum ärgern.

Wir optimieren unsere Bestellungen und vor allem automatisieren wir unseren gesamten Verarbeitungsprozess mit dem Backend.

Der gesamte Bestand und Bestellverfahren wird automatisch mit dem Shop, dem Backend und dem Versender abgeglichen.

Der Prozess zur Bestellübergabe wurde in camunda definiert. Die Service Tasks greifen auf CDI Beans zu. Diese Beans greifen auf JPA Ressourcen zurück.

Es wurden Projektbedingt 2 Resourceprojekte mit verschiedenen JTA- Resources definiert, die aber aufgrund der Architektur auf die gleiche Datenbank zugreifen.

 

Durch die schnelle Verarbeitung des Prozesses kommt  der Application Server durcheinander und Crasht bei der Verarbeitung der Transaktionen.  Einer der Ressourcenmanager lockt die Tabelle und verhindert das weitere verarbeiten der Daten.

Leider ist es mir nicht gelungen eine andere Lösung zu finden als beiden JPA Projekten der gleichen JNDI- Resource zu geben.  🙁

Jemand noch eine andere Idee?

JEE + Microservices, ein neuer IT- Kosmus

Wie man des öfteren ließt werden Micro-Services so etwas wie das nächste größere Ding sein für Moderne IT- Infrastruktur. Weg von großen Anwendungen die viele Daten zentralisiert speichern und nur im eigenen Universum zur Verfügung stellen. Es werden immer mehr Artikel über Micro-Services veröffentlicht. Kleine Datenmengen die sehr schnell zur Verfügung gestellt werden können. Dabei wird die Infrastruktur ziemlich zerrissen – und meiner Meinung nach – eine Art gewollte Unübersichtlichkeit geschaffen.

Da ich mich stetig mit der Entwicklung im JEE Umfeld beschäftige und eigentlich nur über Podcasts, Tutorials und Do-It-Yourself Lerne und meinen Wissensstand erweitere finde ich es nur fair, euch das leben an dieser Stelle etwas einfacher zu machen 😉

Im JEE7 Umfeld und der Verbindung von CDI- Beans ist es sehr einfach JAX-RS Web- Services zu erstellen. Ich werde die Tage ein Tutorial schreiben um euch zeigen zu können, wie einfach man die Kombination von

  • Maven
  • JEE7
  • JAX-RS

funktioniert.

Bis dahin.

WildFly HttpServlet Alternative zu glassfish alternatedocroot_1

Glassfish bietet die Möglichkeit einfach und schnell neue Ordner ins System einzubinden und diese per URL- Pattern anzusprechen.

Die Parameter werden in der: glassfish-web.xml angegeben. Für mehr Details können sie gerne bei Oracle in die Details gehen.

<property name="alternatedocroot_1" value="from=/my.jpg dir=/srv/images/jpg"/>
<property name="alternatedocroot_2" value="from=*.jpg dir=/srv/images/jpg"/>
<property name="alternatedocroot_3" value="from=/jpg/* dir=/src/images"/>

Leider unterstützt jboss seit einigen Versionen eine ähnliche Funktion nicht mehr. Dafür kann per HttpServlet ein Ordner eingebunden werden der ebenfalls per Pattern angesprochen wird.

package de.kuw.jee.kuwbid.servlet;

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.net.URLDecoder;

import javax.inject.Inject;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebInitParam;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import de.kuw.jee.core.ejb.ParameterBean;
import de.kuw.jee.kuwbid.mb.ApplicationBean;

@WebServlet(urlPatterns = "/images/*", initParams = { 
		@WebInitParam(name = "basePath", value = "/home/jskoeber/server/wildfly/uploads/documents") }
)
public class ImageServlet extends HttpServlet {
	private static final long serialVersionUID = -3522881745170031638L;
	private String basePath = "";
	
	@Inject
	private ApplicationBean app;
	
	@Inject
	private ParameterBean parameter;
    
    public void init() throws ServletException {
        this.basePath = getInitParameter("basePath");
        
        if(!parameter.getParameter("uri.images", app.getMandant()).getWert().isEmpty()) {
        	basePath = parameter.getParameter("uri.images", app.getMandant()).getWert(); 
        }
        
        // Validate base path.
        if (this.basePath == null) {
            throw new ServletException("FileServlet init param 'basePath' is required.");
        } else {
            File path = new File(this.basePath);
            if (!path.exists()) {
                throw new ServletException("FileServlet init param 'basePath' value '" + this.basePath + "' does actually not exist in file system.");
            } else if (!path.isDirectory()) {
                throw new ServletException("FileServlet init param 'basePath' value '" + this.basePath + "' is actually not a directory in file system.");
            } else if (!path.canRead()) {
                throw new ServletException("FileServlet init param 'basePath' value '" + this.basePath + "' is actually not readable in file system.");
            }
        }
    }
    

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		String requestedFile = request.getPathInfo();
		
		File file = new File(basePath, URLDecoder.decode(requestedFile, "UTF-8"));
		if (!file.exists()) {
            // Throw 404, redirect to error page may is another selection
            response.sendError(HttpServletResponse.SC_NOT_FOUND);
            return;
        }
		
		// write via response's OutputStream
		FileInputStream inputStream = null;

		try {
			inputStream = new FileInputStream(file);
			byte[] buffer = new byte[1024];
			int bytesRead = 0;

			do {
				bytesRead = inputStream.read(buffer, 0, buffer.length);
				response.getOutputStream().write(buffer, 0, bytesRead);
			} while (bytesRead == buffer.length);

			response.getOutputStream().flush();
		} finally {
			if (inputStream != null)
				inputStream.close();
		}
	}
}

osRetail – Primefaces 4 Upgrade

Wir sind wieder einen Schritt weiter. osRetail in der finalen Primefaces 4.0 Version. Und als Maven Projekt. osRetail das erste open Source ERP System für den Handel. Wir versuchen das starre Korsett eines fertigen ERP System aufzubrechen. Dem Kunden eine möglichst große Vielfalt an Standardfunktionalität zu bieten und auch kostspielige Funktionen wie der Katalogerstellung frei Haus mitzuliefern.

Vor ca. einem Jahr haben wir uns dazu entschlossen ein großes Refactoring der Software durchzuführen. So haben wir nicht nur die Entwicklungsumgebung von Netbeans auf Eclipse geändert. Wir haben auch IceFaces ausgetauscht und – mit dem leistungsstarken Framework – Primefaces einen weiteren Schritt zu einer moderneren Arbeitoberfläche geebnet.

jee7-standard

Ebenso wurde der Code überarbeitet. Derzeit verwenden wir den JEE7 Standard um den aktuellsten Stand der Enterprise Entwicklung von Java nutzen zu können. Autodeployments über Jenkins erleichtern uns die Arbeit erheblich da wir alle Code Commits und Änderungen auf den Testsystem schnellst möglich dem publishen können.

maven-overview-plugin

Maven unterstützt uns bei der Library Auswahl. Mit einfachsten Mitteln ist es möglich neue oder ältere Bibliotheken auszuwählen und automatisch in der Entwicklung und beim Deployment zu verwenden.

Glassfish 4 bietet uns einen schnellen Application- Server der leicht zu handeln ist. Skalierbarkeit, effizientes Arbeiten und schnelle Deployments standen dabei im Vordergrund. Durch einfache Erweiterbarkeit ist es uns möglich schnell auf Kundenwünsche zu reagieren.

JEE Anwendung: QUAT

Es ist ein attraktives Entwicklungsumfeld im JEE Bereich. Webapplications mit EJB3 Anbindung und Managed- Beans.

Im Standard JEE6 wurde viel Aufmerksamkeit auf Annotations gelenkt und die vereinfachte Kommunikations der Beans mit dem Frontend. Der neue JEE7 Standard, erst ein paar Wochen alt wird jetzt speziell die Ausrichtung im Bereich Ajax im Blick haben. Light- Weight Communication mit dem Backend wenn man so will. Wenige Daten die geliefert werden und somit die Performance von Applikationen beschleunigt.

Ich werde euch hier ein kleines Beispiel für eine JEE Anwendung erstellen inkl. der aktuellen Version von Eclipse Kepler und Glassfish 4.

Die JEE Anwendung wird mit dem Plugin von Primefaces 3.5 laufen. Einem leistungsstarken Ajax- Framework das basierend auf jQuery UI viel interaktive Bearbeitungsmöglichkeiten bietet.

Nachteil von Primefaces. Die jQuery UI hat, meines erachtens nicht gerade ein business orientiertes Interfaces Design. Die Buttons und Eingabemasken wirken sehr groß und für ein schlankeres Aussehen müssen einige CSS Classes überarbeitet werden.

Auch muss man sich vor Augen führen das durch den zusätzlichen CSS und Javascript Aufwand die einzelnen Seiten etwas Content- lastiger werden und somit die Ladezeit im Gegensatz zu reinem JSF2 länger sein können. Da man aber sehr viele Daten nachladen kann wird nur der Erstaufruf etwas länger benötigen. Sobald alle Daten Clientseitig gecached wurden wird die Performance deutlich besser sein.

Maven wird in diesem kleinen Projekt eine weiter Rolle spielen. Um möglichst einfach alle Komponenten bauen zu lassen ohne sich um die Libraries kümmern zu müssen oder die Libraries im SVN bereit zu stellen werde ich mich darum kümmern das das Projekt mit Maven gebaut werden kann.

Vorteile:

  • Versionierung des Projektes anhand von Maven- einstellungen.
  • Einfaches Updaten von Libraries
  • Schnelles Bauen von Projekten

Nachteil:

Langwieriges einstellen der Maven Poms um einen erfolgreichen Build zu generieren. Mittlerweile habe ich auch festgestellt das nicht alle POM Einstellungen Plattformunabhängig sind. Es kann sein das Builds teilweise unter Windows laufen und auf dem Mac Fehler verursachen weil Abhängigkeiten fehlen.

Projektname: QUAT

Das Projekt das ich seit längerem realisiere nennt sich QUAT. Mittlerweile stecken knappe 2 Jahre Entwicklung in dem System. Angefangen hat es mit einer einfachen PHP Anwendung die mittlerweile ihre Alter erreicht hat und dank unzähliger PHP Updates auch einiges an Funktionen nicht mehr unterstützen bzw. nur noch per Workaround laufen.

QUAT wird z.B. für ein Callcenter verwendet werden können das sich mit der Qualitätssicherung von Mitarbeiter beschäftigt. Überall wo die Leistung vom Mitarbeiter eine Bewertung benötigt und die Qualität in Gesprächen oder direkter Kommunikation am Telefon geprüft werden muss um den Erfolg der Firma zu steigern oder gezielt Schulungen für Mitarbeiter anzubieten.

Aber erstmal genug um den Nutzen der Software. Wir möchten uns die technische Seite etwas genauer ansehen und somit den Aufbau der Software.

[HIER WERDEN ALLE ZUKÜNFTIGEN ARTIKEL ZU QUAT GELISTET UND VERLINKT|

 

ManagedBean URL Parameter lesen

Vor kurzem musste ich mich fragen wie man ein paar einfache URL Parameter ausgelesen bekommt. Das ganze in der ManagedBean. Eigentlich ist die Lösung einfach wenn man einmal begriffen hat wozu ManagedProperties gedacht sind. Das schöne ist das es über eine einfach Annotation geht und in der faces-config.xml nur eine Kleinigkeit hinzugefügt werden muss.

In unserem fall ist es z.B. /faces/test/test.xhtml?test1=hurz&test2=gurz

 

<managed-bean>
    <managed-bean-name>bean</managed-bean-name>
    <managed-bean-class>com.example.Bean</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
    <managed-property>
        <property-name>test1</property-name>
        <value>#{param.test1}</value>
    </managed-property>
    <managed-property>
        <property-name>test2</property-name>
        <value>#{param.test2}</value>
    </managed-property>
</managed-bean>

Wichtig hierbei ist die Scope. Falls ihr die Scope auf Session belasst werdet ihr ein Instanziierungsproblem bekommen. Da der URL Aufruf wie der Name schon sagt ein einfacher und nur für den Moment geltender Aufruf ist ist der Scope ganz wichtig bei der Sache das auch die Parameter korrekt gelesen werden können. Somit achtet darauf das die Scope auf alle Fälle REQUEST enthält.

Anschließend könnt ihr in eurer ManagedProperty die zwei Parameter auslesen:

@ManagedProperty ("{test1}")
private String test1;
@ManagedProperty ("{test2}")
private String test2;

public void setTest1(String test1) {
 this.test1 = test1;
}
public void setTest2(String test2) {
 this.test2 = test2;
}

Primefaces, Tipps & Tricks

Primefaces ist ein super Werkzeug um schnell und zuverlässig Webplattformen zu erstellen auf Basis von JEE6 mit EJB3 und einem Glassfish.

Ich arbeite derzeit mit dem Glassfish 3.1 auf Eclipse IDE Indigo (mittlerweile gibt es neuere Releases)

Primefaces hat aber so seine Eigenheiten. Wer JSF2 gewohnt ist wird schnell auf ein paar  Unterschiede stoßen. Sei es die Parameterübergabe oder auch die Formen die man beachten muss wenn man mit Primefaces arbeitet. Der Mensch ist faul und wird daher oft selbst bestraft wenn er sich nicht alles durchließt. 😉

Ein Dialog z.B. bildet eine eigene Form und benötigt somit keine weitere Ummantelung eines form Tags.

<p:dialog id="basicDialog" header="Basic Dialog" widgetVar="dlg1">  
    <h:outputText value="Sample Dialog!" />  
</p:dialog> 

Eine weitere Besonderheit sind die wenn man sie richtig anwenen möchte muss man sich etwas konzentrieren. Direkte Parameterübergabe z.B. mit

geht nicht!

Korrekt hierfür wäre, wie im Primefaces Beispiel auch schon steht, aber natürlich von mir im ersten Moment nicht so angewandt wurde ein dieser kann im Button integriert werden und z.b. über einen Dialog verarbeitet werden.

<h:form prependId="false"> 
    <h:panelGrid columns="1" cellpadding="5">  
        <h:outputText id="msg" value="#{buttonBean.text}"/>  
          
        <p:commandButton id="showDialogButton" value="Destroy the World" onclick="myDialog.show()" type="button">
            <f:setPropertyListener value="blub" target="#{bean.property}" />
        </p:commandButton>
    </h:panelGrid>  
      
    <p:dialog id="myDialog" widgetVar="myDialog">  
        <f:outputText value="Hey, #{bean.property} would u really destroy the world?" />           
    </p:dialog >  
</h:form>