Ich habe das Vergnügen für meinen aktuellen Kunden DaWanda ein Gadget für StudiVZ zu entwickeln. Ein Gadget besteht aus einer XML Datei, die definiert, um welche Anwendung es sich handelt, wer der Author ist usw. Dazu gehören wahlweise mehrere CSS und Javascript Dateien. Nachdem man alles in eine Zip Datei, die den gleichen namen wie die XML Datei trägt, gepackt hat, kann man die Anwendung in die Sandbox hochladen und ausprobieren. Eine Beispiel Datei könnte so aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs
    title="Example StudiVZ Gadget"
    title_url="http://www.christophbuente.de"
    author="Christoph Bünte"
    author_email="info@christophbuente.de"
    description="Example description"
    screenshot="http://www.christophbuente.de/images/screenshot.jpg"
    thumbnail="http://www.christophbuente.de/images/thumbnail.jpg">
    <Require feature="opensocial-0.8" />
    <Require feature="views" />
  </ModulePrefs>
  <Content type="html" >
    <![CDATA[
      <script>
        function init() {
          // Put initialization code here
        }
        gadgets.util.registerOnLoadHandler(init);
      </script>
    <div id='container'></div>
    ]]>
  </Content>
</Module>

Jede Interaktion des Benutzers mit der Anwendung wird mit Hilfe weiterer Javascript Funktionen behandelt. Dazu stehen eine Reihe eingebauter Funktionen aus dem Opensocial Container bereit. Darüber hinaus haben die Entwickler von StudiVZ eine API Beschreibung der zusätzlichen Funktionen bereit gestellt. Was aber, wenn man nun nicht mit Javascript entwickeln möchte bzw. kann? Es besteht die Möglichkeit Flash Content einzubinden. Man kann aber auch ein beliebiges Backend einbinden. Dieses Backend muss nur 2 Bedingungen erfüllen:

• Es muss auf HTTP Requests reagieren können und beliebiges HTML,CSS und JavaScript zurück liefern
• Es muss im Namen des Applikationsbenutzers einen OAuth signierten Request an die StudiVZ REST API schicken können.

Wie im Schema zu sehen, sendet der User einen Request, um die Applikation zu benutzen. Der Container liest darauf hin den Inhalt der XML Datei aus. Dort ist neben einem DIV Container lediglich ein externes Javascript referenziert. In dem Javascript sind einfache Methoden zum Navigieren und Interagieren definiert. Das rendern des HTML übernimmt ein Ruby Backend. Das braucht zum Render unter Umständen noch zusätzliche Informationen wie zum Beispiel Name und Foto des Benuter usw. Diese Informationen holt es sich mit einem OAuth signierten Request von der abgebildeten REST API. Das vom Ruby Backend erzeugte HTML rendert der Opensocial Container in einem IFrame im Browser des Benutzers. Für eine bessere Übersicht definieren wir im XML einzelne Views, die jeweils einen eigenen Endpunkt im Backend haben. Eine einfache gadget.xml mit 2 definierten Views für Profil und Vollansicht mit Backend Anbindung:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs
    title="Spitzenmässiges StudiVZ Gadget mit Backendanbindung"
    title_url="http://www.christophbuente.de"
    author="Christoph Bünte"
    author_email="info@christophbuente.de">
    <Require feature="opensocial-0.8" />
    <Require feature="views" />
  </ModulePrefs>
  <Content type="html" view="profile" >
    <![CDATA[
      <script type="text/javascript" src="http://www.yourbackend.com/profile.js" ></script>
      <div id='profile'></div>
    ]]>
  </Content>
  <Content type="html" view="canvas" >
    <![CDATA[
      <script type="text/javascript" src="http://www.yourbackend.com/canvas.js" ></script>
      <div id='canvas'></div>
    ]]>
  </Content>
</Module>

Das referenzierte Javascript ist ebenfalls sehr schlank. Darin wird lediglich eine Backend URL aufgerufen und deren Response Body in das profile bzw. canvas div geschrieben.

function init{
  var url = 'http://www.yourbackend.com/profile/'
  var params = {};
  params[gadgets.io.RequestParameters.AUTHORIZATION]=gadgets.io.AuthorizationType.SIGNED;
  gadgets.io.makeRequest(url, requestCallback, params);

}

function requestCallback(obj) {
	document.getElementById('profile').innerHTML = obj.data;
}

Damit die REST API benutzt werden kann, muss man sich an ihr Authentifizieren. Da das Backend aber dumm ist, hat es keine Userdaten, um sich dort anzumelden. Glücklicherweise ist der Request aus dem Javascript mit dem verschlüsselten Authentifierungsdaten des angemeldeten Anwendungsbenutzers signiert. Mit deren Hilfe können wir einen neuen, signierten Request erzeugen, den die API akzeptieren wird. Doch zuerst muss die Glültigkeit der Signatur überprüft werden:

sudo gem install oauth --source http://gemcutter.org

require 'oauth'
require 'oauth/consumer'
require 'oauth/request_proxy/action_controller_request'
require 'oauth/signature/rsa/sha1'
require 'oauth/signature/hmac/sha1'

class ApplicationController < ActionController::Base

  before_filter  auth_required

  def oauth_required
    cert_file = File.join(RAILS_ROOT, 'public', 'public.cer')
    cert_str = File.read(cert_file)
    consumer = OAuth::Consumer.new(ConsumerToken, cert_str)

    begin
      pass = OAuth::Signature.build(request, :consumer => consumer).verify
      logger.info "Signature verification returned: #{pass}"
    rescue OAuth::Signature::UnknownSignatureMethod => e
      logger.error "ERROR "+ e.message
    end

    render :text => "OAuth access denied", :status => :unauthorized  unless pass
  end

Die URL für das öffentliche Zertifikat wird mit jedem Request mit geschickt. Einmal runterladen sollte reichen. Ich denke, man muss es nicht bei jedem Request erneut vom StudiVZ Server laden. Den Consumer Token findet ihr in der OAuth Section eurer Gadget Sandbox (http://www.meinvz.net/GadgetDeveloper/GadgetOAuth/xxx). xxx ist deine Gadget ID.

Sollte der before_filter nicht abbrechen war die Signatur korrekt und der Request kann bearbeitet werden. Aus einem mir nicht bekannten Grund ist der Request des Containers an das Backend mit der RSA-SHA1 Methode signiert. Dafür wird das Zertifikat benötigt. Für den Request an die API muss die HMAC-SHA1 Methode verwendet werden. Dafür wird ein neuer Consumer benötigt:

def get_owner
  consumer = OAuth::Consumer.new(ConsumerToken, ConsumerSecret,
      :signature_method => 'HMAC-SHA1',
      :site => "http://sandbox.gadgets.apivz.net",
      :scheme => :query_string,
      :http_method => :get)
  requestor_param = {:xoauth_requestor_id => params[:opensocial_owner_id]}.to_param
  access_token = OAuth::AccessToken.new(consumer)
  response = access_token.get("/social/rest/people/#{params[:opensocial_owner_id]}/@self?#{requestor_param}")
  owner_attributes = JSON.parse(response.body)['entry']
end

Feedback, Fragen und Kritik sind immer gerne willkommen.

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]

[ad#vert-banner]

Ein erster Blick auf die Installationsanleitung offenbart keine sehr ausführlichen Informationen. Lediglich ein paar Pakete installieren, und fertig. Nun, wir wollen sehen. Die Installation wurde mit Hilfe von Parallels Desktop 3.0 unter Mac OS X vorgenommen. Als Gastbetriebsystem haben wir, wie in der Anleitung empfohlen Fedora Core 8 verwendet.

Nach der Installation von Fedora Core 8 in der VM mit den Standard Optionen fehlen vor allem noch ein Compiler, ein paar Developer Pakete und jede Menge Perl Module. Der bereits installierte Paketmanager YUM wird also gleich bemüht, um alles Fehlende an den Start zu bringen.

sudo yum install perl gcc-c++ libstdc++-devel xerces-c-devel js-devel flite openssl-devel libxml2-devel expat-devel

Soweit noch nicht geschehen, sollte cpan installiert werden. Hiermit lassen sich benötigte Perl Pakete leicht installieren. Eine Anleitung findet man auf der cpan homepage. Es ist jedoch ratsam folgende Pakete gleich mit zu installieren: ncftp, wget

sudo yum install ncftp wget cpan

Nun fehlen noch folgende Perl Module: XML::LibXML, BSD::Resource, Module::Build. Während der Installation von cpan werden mehrere Fragen gestellt, die eigentlich alle, bis auf die Frage nach dem Ort und den Servern, mit “ENTER” bestätigt werden können. Aber genau lesen hat noch nie geschadet. Die Fragen, ob alle benötigten Pakete ebenfalls installiert werden sollen, kann man auch getrost mit “ja” beantworten. Aber man sollte gewarnt sein: Je nach dem, wie viel oder wenig Perl Module schon installiert sind, dauert es unter Umständen bis zu 10 Minuten. Wie sich allerdings herausstellt, gibt es für Module::Build zwei optionale Pakete, die zwar wichtig sind, aber nicht automatisch installiert werden. Aus diesem Grund wird ExtUtils::ParseXS und damit auch ExtUtils::CBuilder zusätzlich installiert.

cpan install Bundle::CPAN
cpan install XML::LibXML
cpan install BSD::Resource
cpan install ExtUtils::ParseXS
cpan install Module::Build

Wenn alle Module erfolgreich installiert wurden, fehlt nur noch der asterisk Dienst. Dieser ist jedoch nicht über das Fedora Repository erhältlich. Deswegen muss in die YUM Konfiguration ein weiteres Repository aufgenommen werden. Dazu wird die Datei /etc/yum.repos.d/atrpms.repo mit folgendem Inhalt angelegt:

[atrpms]
name=Fedora Core $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/f$releasever-$basearch/atrpms/stable
#enabled=1
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
gpgcheck=1

Anschließend muss noch der GPG Schlüssel für das neue Repository importiert werden:

sudo rpm --import http://ATrpms.net/RPM-GPG-KEY.atrpms

Jetzt kann der asterisk Dienst installiert werden. YUM wird vorschlagen, alle fehlenden Pakete ebenfalls zu installieren:

sudo yum install asterisk

Nachdem nun endlich alle Vorbereitungen für die Installation abgeschlossen sind, sollte das Voiceglue Paket heruntergeladen werden. Nachdem Download einfach entpacken, und los geht der Spass.

tar xvfz voiceglue_0.6.tar.gz
cd voiceglue_0.6
perl doc/install-voiceglue

Sollte das Installationsskript wider Erwarten nicht korrekt durchlaufen, müssen die einzelnen Komponenten per Hand in der richtigen Reihenfolge installiert werden:

• Cam-Scom
• dynlog
• libvglue
• openvxi
• phoneglue
• Satc
• SRGSDTMF
• voiceglue
• Vxglue

In jedem Unterverzeichnis sollte entweder eine Build.pl Datei oder ein build Skript liegen, welches ausgeführt werden muss. Bei Problemen kann ich gerne versuchen zu helfen.

Fazit: Mit der Original Anleitung war die Installation sehr mühsam, weil nicht alle Pakete aufgeführt sind, die benötigt werden. Nach mehrmaligem Zurücksetzen der Virtuellen Maschine konnte ich alle Paketabhängigkeiten herausfinden und auflösen. Die hier beschriebene Lösung funktionierte für mich ohne Probleme. Wie immer ist Feedback sehr willkommen. Für Hinweise und bei Problemen einfach einen Kommentar hinterlassen.

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.

[ad#vert-banner]

Mit einem einfachen Trick kann man Ausgaben von der Fehlerausgabe auf die Standardausgabe umleiten, um eben diese Ausgabe in anderen Programmen weiter zu verwenden.

$  2>&1 |  

Die Fehlerausgabe von “erstesKommando” wird auf die Standardausgabe umgelenkt. Als besonderes Beispiel sei hier SOX genannt. Es gilt als das Schweizer Taschenmesser der Audioverarbeitung auf der Kommandozeile.

$ sox beispiel.wav -e stat 2>&1 | grep Length | awk '{print $3}'

Diese Kommandofolge analysiert die Audiodatei beispiel.wav, filtert die Zeile aus dem Ergebnis, welche “Length” enthält, und gibt anschließend das dritte Wort aus. In diesem Fall handelt es sich dabei um die Länge in Sekunden.

Et voilà!