Die Dokumentation für Stripes Unit tests beschreibt sehr ausführlich, wie man mit Hilfe des MockServletContext eine Testinfrastruktur aufbaut, die es ermöglicht die ActionBeans ausserhalb des JEE-Containers zu testen. Dies funktioniert für klassische ActionBeans ganz wunderbar. Doch beim schreiben von Tests für ActionBeans im Wizard Mode fiel auf, dass die Simulation eines Submits nicht funktionierte. Im Wizard Modus erzeugt das Stripes FormTag ein zusätzliches verstecktes Formularfeld mit dem Namen “__fp”, welches alle Feldnamen des aktuellen Formulars in verschlüsselter Form enthält. Ohne dieses Feld verweigert der Stripes Dispatcher die Arbeit! Nimmt man nun einen beliebigen Wert und legt ihn in diesem Feld ab, so erzeugt das ebenfalls einen Fehler:(Der Rechtschreibfehler ist tatsächlich aus dem Framework.)

Stripes attmpted and failed to decrypt the non-null value in the 'fields present' field.

Auch ist es nicht sinnvoll, einen beliebigen Text mit Hilfe des CryptoUtil zu verschlüsseln. Der Submit kann dann zwar erfolgreich simuliert werden, jedoch werden sämtliche Validierungsregel ignoriert. Mit folgenden Zeilen Code, kann ein korrekter Wert für das “__fp” Feld erzeugt werden:

// Alle Feldnamen des aktuellen Formulars in eine Liste aufnehmen
   List fields = new ArrayList();
   fields.add("username");
   fields.add("password");
// Alle Feldnamen mit Trennzeichen zusammenfassen
   String hiddenFieldValue = HtmlUtil.combineValues(fields);
// servlet engine configurieren
   MockServletContext ctx = TestFixture.getServletContext();
   MockRoundtrip trip = new MockRoundtrip(this.ctx, YourCustomActionBean.class);
   HttpServletRequest request = (HttpServletRequest) trip.getRequest();
   hiddenFieldValue = CryptoUtil.encrypt(hiddenFieldValue, request);
   trip.setParameter(StripesConstants.URL_KEY_FIELDS_PRESENT, hiddenFieldValue);

Für das Testen der Feldvalidierung ist es wichtig, dass die Feldnamen mit dem Wert des <input name="" /> Name Attributes in dem jeweiligen Formular übereinstimmen. Denn es werden tatsächlich nur die Felder validiert, die aus dem decodiertem Inhalt des “__fp” Feldes ausgelesen werden können.

Angenommen der oben abgebildete Code wird in der setup() Methode eines Unit Tests ausgeführt und speichert das MockRoundtrip Object in einem privaten Member, könnte ein Beispieltest könnte dann so aussehen:

@Test
public void testLogin() throws Exception {
	trip.setParameter("username", "christophbuente");
	trip.setParameter("password", "secret");
	trip.execute("login");
	YourCustomActionBean bean = trip.getActionBean(YourCustomActionBean.class);
	Assert.assertTrue("Destination", "/account", trip.getDestination());
}

Ich hoffe, dass diese Informationen ausreichen, um sinnvolle Unit Tests für ActionBeans im Wizard Modus zu schreiben. Bei Fragen helfe ich gerne weiter. Und wie immer sind Kommentare sehr willkommen.

[ad#vert-banner]

Nachdem alle Schritte aus der Installationsanleitung befolgt wurden, sind folgende Komponenten auf dem System installiert:

• perl (Skriptsprache)
• asterisk (Telefonieserver)
• openVXI (Open Source VoiceXML Interpreter)
• flite (engl. TTS Engine)
• voiceglue (IVR Software)

Um tatsächlich Anrufe über das Telefon- oder auch VoIP Netz entgegen nehmen zu können, muss der asterisk Server konfiguriert werden. Eine vollständige Beschreibung der asterisk Konfiguration würde allerdings den Rahmen dieses Tutorials sprengen. Aus diesem Grund wird lediglich die Konfiguration erklärt, mit er es möglich ist, mit Hilfe eines sogenannten Softphones an der Sprachanwendung anzurufen. Für vielschichtige asterisk Konfigurationen findet man in Asterisk: The Future if Telephony ausreichend Hilfe.

Als erstes benötigen wir für die Annahme von Anrufen via SIP einen eigenen Kontext in der Datei: /etc/asterisk/manager.conf. Die folgenden Zeilen sollte man am besten am Ende der Datei einfügen:

[phoneglue]
secret=phoneglue
read = system,call,log,verbose,command,agent,user
write = system,call,log,verbose,command,agent,user

Ausserdem muss der Manager noch aktiviert werden. Deswegen sollte man sicherstellen, dass in der gleichen Datei die Variable enabled=yes gesetzt ist.

Danach wird asterisk so konfiguriert, dass alle angenommenen Anrufe per AGI an den Voicebrowser weitergeleitet werden. Durch die Verwendung von AGI ist es möglich, den Voicebrowser auch auf einem anderen Server zu betreiben und die Verbindung via Netzwerk herzustellen. Dies nimmt bei vielen Anrufen die Last vom System. Die Konfiguration wird in der Datei /etc/asterisk/extensions.conf vorgenommen. Auch hier ist es wieder sinnvoll einen neuem Kontext am Ende der Datei einzufügen:

[phoneglue]
exten => 1,1,Agi(agi://localhost)
exten => 1,2,Hangup

Die Einträge für die Extensions beginnen mit einer 1. Dies ist die Durchwahl für die Sprachanwendung. Der Aufruf “Agi(agi://localhost) verbindet nun den Voicebrowser mit dem Anrufer.

Möchte man nun alle eingehenden Anrufe, welche mit SIP initiiert werden, an die Sprachanwendung leiten, ist noch eine Änderung in der Datei /etc/asterisk/sip.conf nötig. Der Standard Kontext muss von default auf phoneglue gesetzt werden.

[general]
context=phoneglue

Damit ist die Konfiguration von asterisk schon abgeschlossen. Nun kann es mit der Konfiguration der Sprachanwendung weitergehen.

VoiceXML basierte Sprachanwendungen benötigen einen HTTP Server, welcher die statischen oder dynamisch erzeugten *.vxml Dateien ausliefert. Auch hier haben die Entwickler von VoiceGlue mitgedacht, indem das System so konfigurierbar ist, dass der VoiceXML Server auf einer separaten Maschine laufen kann. Zu Demonstrationszwecken genügt es hier allerdings, dass alle Dienste auf einer Maschine laufen. Die Konfiguration wird in der Datei /etc/voiceglue.conf vorgenommen. Hier genügt ein Eintrag, der auf die Einstiegsseite der Sprachanwendung zeigt.

 * http://localhost/index.vxml

Diese Datei muss vom lokalen Apache ausgeliefert werden. Falls noch nicht geschehen, sollte der Apache jetzt gestartet werden:

sudo service httpd start

Standardmässig liegen die HTML für den Apache unter Fedora im Verzeichnis /var/www/html. Genau an dieser Stelle legen wir eine klassische Hello World Anwendung in Form einer VoiceXML Datei mit folgendem Inhalt ab:

      Hello World. This is my first voiceglue application.

Damit ist die Konfiguration abgeschlossen. Alle Dienste sind vollständig konfiguriert und sollten jetzt gestartet werden.

sudo service asterisk start
sudo service phoneglue start
sudo service voiceglue start

Als letztes wollen wir überprüfen, ob die Komfiguration erfolgreich war. Dazu benötigen wir ein Softphone. Eine freie Version findet man bei SJLabs. Das Telefon ist für Windows, Linux und OS X verfügbar. Nach dem herunterladen muss im Menupunkt Phone->Services das SIP Protolkoll gewählt werden. Anschließend wählen wir unseren lokalen asterisk Dienst mit der Durchwahl 1@localhost an.

Basierend auf der gezeigten Konfiguration lassen sich beliebige Sprachanwendungen erstellen. Wie jedoch schon im Beitrag VoiceGlue Installation – Interactive Voice Response leicht gemacht beschrieben, fehlt die Intergration einer ASR Engine. Somit beschränken sich Anrufereingaben auf DTMF.[/lang_de]

Um mit Rails auf dem Mac zu beginnen, gibt es zwei Möglichkeiten:

1. Kompilieren und installieren aller benötigten Komponenten
2. Benutzen einer Applikation, die schon alles mitbringt.

Getreu dem Motto dieses Artikels, empfehle ich den schnellen, einfachen Weg Ryan Rauum stellt auf seiner Website eine Cocoa Anwendung zur Verfügung, die bereits alle Komponenten – bis auf die Datenbank – in einer Anwendung bündelt. Die Installation ist so einfach, wie bei jeder anderen Anwendung.

• Herunterladen
• DMG Datei doppelt anklicken
• Locomotive Symbol in das Programmverzeichnis ziehen

Als Datenbank empfehle ich für die ersten Schritte MySQL. Über den Produktiveinsatz von MySQL mag man streiten, aber um einfach mal anzufangen reicht MySQL völlig aus. Die Dateien für sehr viele Betriebsysteme stehen auf der download Seite bereit. Die Installation besteht eigentlich nur noch aus dem entpacken des tar.gz Archivs und starten der darin enthaltenen .pkg Datei. Eine Anleitung hat MySQL auch online gestellt.

Nachdem die Datenbank nun läuft ist es Zeit Locomotive zu starten. In der Applikation kann nun ein beliebiges Projekt erstellt werden (Apfel + N). Dazu gibt man den Namen und Pfad an, in dem das neue Projekt erstellt werden soll. Wer glücklicher Besitzer einer Textmate Lizens ist, klickt rechts auf das erstellt Projekt im Locomotive Fenster und wählt: “Edit in Textmate”. Es geht aber auch jeder andere Editor, um die wenigen Schritte zum laufenden Projekt zu gehen.

Die Datei config/database.yml im Projektverzeichnis enthält die Angaben, um Rails mit der Datenbank kommunizieren zu lassen. Hier sind in der bei der Verwendung von MySQL lediglich die Datenbanknamen für development, test und production anzugeben. Bei Bedarf kann hier auch der Benutzer, Passwort und Host bzw. Socket angepasst werden. Der schnellste Weg zu den drei Datenbanken ist mit Hilfe des Terminals:

mysql -uUser -pPasswort

In der geöffneten mysql shell sind die drei create Anweisungen nötig

create database projektname_development;
create database projektname_test;
create database projektname_production;

So, das war es eigentlich schon. Nachdem mit Hilfe von Locomotive der Server für das Projekt gestartet wurde, sollte man im Browser unter der Adresse: http://localhost:3000 eine Erfolgsmeldung sehen:

Welcome aboard. You’re riding the Rails!

Der grundlegende Mechanismus für Subscriptions ist denkbar einfach. An einer beliebigen Stelle in unserer Webapplikation wird der Benutzer per link oder submit button an die Paypal Seite geleitet. Alle relevanten Daten für die Zahlung werden entweder als GET Parameter (Link) oder POST Parameter (Button) übertragen. Dazu zählen vor allem folgende Angaben:

• Abonnementinterval (1 Tag, 4 Wochen oder 12 Monate)
• Betrag pro Abonnementinterval
• Währung
• Paypal Id des Verkäufers
• Rechnungsnummer
• Automatische Verlängerung (ja/nein)
• Beliebige zusätzliche Informationen

Sollte der Benutzer noch kein Paypal Kunde sein, muss er sich bei Paypal erst registrieren. Um dies so einfach wie möglich zu gestalten können wir zusätzlich Benutzerinformationen mitsenden, die Paypal in das Registrierungsformular einfügt.

• Name, Nachname
• Adress(Strasse, PLZ, Stadt, Land)
• Email Adresse

Damit wir zum Testen unserer Applikation kein Vermögen hinblättern müssen, stellt Paypal eine sogenannte Sandbox zur Verfügung. Eine eigene Developer Sandbox kann man sich hier einrichten. Diese Sandbox stellt die kompletten Funktionen von Paypal zur Verfügung. Mit zwei Unterschieden: Es fließt kein echtes Geld und es gibt nur die Benutzer, die wir selbst angelegt haben. Um also einen Zahlungsfluss zu simulieren müssen in der Sandbox mindestens zwei Benutzer angelegt sein (Verkäufer und Käufer). Zum Erzeugen eines einfachen Bezahlknopfes eignet sich die Paypal Button Factory, welche unter Merchant Services im Paypal Menü des Verkäufers erreichbar ist. Doch es gibt auch Gründe gegen einen statischen Bezahlknopf auf der Webseite. Angenommen wir wollen mehrere Abonnements verkaufen, die sich je nach Laufzeit im Preis unterscheiden. Wäre es da nicht besser ein eigenes Formular zu erstellen, welches dem Benutzer die komplette Auswahl unserer Produkte anzeigt? Nachdem sich der Benutzer für eines unserer Abonnements entschieden hat, überträgt er seine Auswahl per druck auf den Bezahlknopf. Unsere Webapplikation wertet diese Informationen aus und leitet den Benutzer per redirect auf die Paypal Seite um. Dazu muss die URL mit sämtlichen Zahlungsinformationen dynamisch erzeugt werden. Hier eine Beispielimplementierung:

public String getPurchaseUrl() throws EncoderException {
	StringBuffer urlBuffer = new StringBuffer("https://www.sandbox.paypal.com/cgi-bin/webscr");
	urlBuffer.append("?no_note=1"); // Abonnements unterstützen keine Notizen
	urlBuffer.append("&a3=9.99"); // Der Preis des Abonnements
	urlBuffer.append("&t3=M"); // Intervall Einheit = Monate
	urlBuffer.append("&p3=1"); // Intervall Länge = 1 (Monat)
	urlBuffer.append("&business=verkaeufer@deine.url.de"); // Die email adresse für den verkäufer account bei paypal
	urlBuffer.append("&cmd=_xclick-subscriptions"); // Wir wollen eine abonnement
	urlBuffer.append("&src=1"); // Abonnement verlängert sich automatisch
	urlBuffer.append("&currency_code=EUR"); // Wir nehmen Zahlungen in Euro entgegen
	urlBuffer.append("&invoice=Rechnungsnummer"); // Hier kann eine Rechnungsnummer vergeben werden
	urlBuffer.append("&lc=DE"); // Die Zielseite soll in deutscher Sprache angezeigt werden
	urlBuffer.append("&no_shipping=1"); // Wir brauchen keine Versandadresse, denn wir verkaufen virtuelle Güter oder Dienstleistungen
	URLCodec encoder = new URLCodec();
	return encoder.encode(urlBuffer.toString());
}

Für das URL Encoding, welches alle Sonderzeichen in übertragbare Zeichen umwandelt, verwende ich die commons-codec Bibliothek von Apache Commons.

Die geladene Paypal Seite enthält nun alle Zahlungsinformationen. Der Potentielle Käufer muss sich lediglich mit seinem Paypal Benutzernamen anmelden und die Zahlung bestätigen. Ist die Automatische Rückleitung aktiviert, landet der Benutzer danach wieder auf unserer Seite. Die Aktivierung kann im Paypal Menu des Verkäufers unter “Profile ->Website Payment Preferences” eingestellt werden. Dazu wählt man den Radiobutton “Auto Return ON” und trägt unter “Return URL” die entsprechende Url ein, an die der Benutzer weitergeleitet werden soll. Mit dieser URL überträgt Paypal eine Transaktions Id, wenn in den Einstellungen zusätzlich noch “Payment Data Transfer” auf “On” gesetzt wurde. Die Dokumentation für PDT finden man auf der Paypal Developer Seite. Paypal erwartet darauf hin, dass unsere Webapplikation folgende Informationen zurück sendet:

• TransaktionsId
• Identitätstoken
• Kommando

Die TransaktionsId ist die eben empfangene Id. Der Identitätstoken kann an der Stelle eingesehen werden, wo “Payment Data Transfer” angeschaltet wurde. Dies stellt sicher, dass Zahlungsinformationen nicht an unberechtigte Personen gesendet werden. Das Kommando muss den den Wert “_notify-synch” enthalten. Hier ein Beispiel, wie die Implementierung aussehen könnte. Für den Post Request zurück an Paypal habe ich die commons-httpclient Bibliothek von Apache Commons verwendet.

/**
 * Verabeitet Paypals Payment Data Transfer
 *
 * @param txId The transactionId
 * @return
 */
public void handleCallback(long txId) {
	Map<String,Object> params = new HashMap<String, Object>();
	params.put("cmd","_notify_synch");
	params.put("tx", txId);
	params.put("at", "IDENTITY_TOKEN");
	try {
		PostMethod method = doPostRequest("https://www.sandbox.paypal.com/cgi-bin/webscr", params);
		String responseBody = method.getResponseBodyAsString();
		if(responseBody != null) {
			if(responseBody.startsWith("SUCCESS")) {
				// Super, alles hat geklappt
				// Erfolgsnachricht anzeigen
			} else if(responseBody.startsWith("FAIL")) {
				// Die Zahlung war nicht korrekt durchgeführt
				// Fehlernachricht anzeigen
			} else {
				// Irgendwas ging richtig in die Hose
				// Fehlerbehandlung
			}
		} else {
 			// Das war auch nicht korrekt
	 		// Fehlerbehandlung
 		}
	} catch (HttpException e) {
		// Error sending PDT response
	} catch (IOException e) {
		// Error sending PDT response
	}
}
/**
 * Does a POST request to the given url and the given parameter map
 *
 * @param url
 * @param params
 * @return The method containing the response
 * @throws HttpException
 * @throws IOException
 */
public PostMethod doPostRequest(String url, Map<String, Object > params)
 	throws HttpException, IOException {
		HttpClient client = new HttpClient();
		HttpConnectionManager conManager = client.getHttpConnectionManager();
		HttpClientParams clientParams = client.getParams();
		clientParams.setConnectionManagerTimeout(2000);
		HttpConnectionManagerParams managerParams = conManager.getParams();
		managerParams.setConnectionTimeout(5000);
		managerParams.setSoTimeout(5000);
		PostMethod method = new PostMethod();
		method.setURI(new URI(url, false));
		HttpMethodParams paramsM = method.getParams(); // Wiederholungen unterdrücken
		paramsM.setParameter(HttpMethodParams.RETRY_HANDLER,
	 		new DefaultHttpMethodRetryHandler(0, false));
	Set<String> keys = params.keySet();
	for (String key : keys) {
		String value = (String) params.get(key);
		method.addParameter(key, value); // Setze Url Parameter
	}
	client.executeMethod(method); // Http Post ausführen
	return method;
}

Der Benutzer merkt vom Austausch der Zahlungsinformationen nichts, Es wird lediglich eine einfache Bestätigungsseite angezeigt. Auf dieser Seite wird dem Benutzer mitgeteilt wird, dass die Zahlung erfolgreich oder nicht erfolgreich war, und dass er von Paypal per Mail darüber benachrichtigt werden wird.

Paypal bietet zusätzlich die Möglichkeit, unsere Webapplikation asynchron über eingehende Zahlungen und/oder Kündigungen zu informieren. Die Mechanismus nennt sich IPN, was soviel bedeutet wie “sofortige Zahlungsavisierung”. Dieser Mechanismus ist deutlich robuster, als “Payment Data Transfer”. Doch dazu in später mehr.