28. Jan. 2011

Viel Zeit verbraten, viel Neues lernen.

Geht nicht - gibt nicht!

Eine 4D-Lösung, von Anfang an mit Frontend zum Web konzipiert, kommt ins Probiert-mal-aus-Stadium. Mit dem Browser an die Datenbank andocken klappt inzw. zufriedenstellend, wenn ich es selber auf meinem Rechner gegen die 4D Developer Professional teste. Nun bin ich auf Rückmeldungen von den Kollegen gespannt.

Ehe ich den 4D Web-Server live schalte, soll ein Kollege gegen die Version auf meinem Rechner testen. Im Büro habe ich DSL mit einer dynamischen IP. Daraus wird über

DynDns

eine quasi statische realisiert. Die DynDNS-Url ist schnell beschafft. Mehr Zicken macht der Speedport der Telekom*. Schließlich habe ich den Speedport doch zur Port-Umleitung überredet. Parallel läuft auf dem Mac DynDNS Updater, weil dieser mit mehr als nur dyndns.com zurechtkommt.

Vom eigenen Rechner raus aus dem lokalen Netz und über DynDNS wieder zurück ins lokale klappt nicht. Also einen Kollegen im iChat gekapert und ihn um den Gefallen gebeten, meinen Rechner anzupingen und die DynDNS-URL zu laden. Nach einigen Versuchen und den richtigen Firewall-Einstellungen klappt es schließlich, die Datenbank aus der Ferne über den Browser anzusurfen.

Dem Kollegen 400 km entfernt hatte ich die Anleitung per eMail geschickt und gebeten den Test zu beginnen.

Wenig hilfreiche Fehlermeldung

Sein Rückmeldung kam ziemlich flott: Zeitüberschreitung - kein Zugriff auf den 4D WebServer.

Inzw. hatte ich bessere Idee, als erneut den 4Dwerkstatt-Kollegen im iChat auf die Nerven zu gehen. Ich kann das selber von einem Server testen, den ich über iChat-Screensharing im Zugriff habe.

Anpingen klappte, URL laden nicht. Wieso funktionierte das gestern und wieso heute nicht?

Lizenzen

Meine Fehlermeldung im Browser war eine andere als vom Kollegen übermittelte: die WebServer-Lizenz der 4D Developer Professional erlaubt nur lokale Anmeldungen, nicht von anderen IP-Adressen.

Die V12 ist ein halbes Jahr im Markt, der 4D-Store funktioniere ganz gut, also sollte eine WebServer-Lizenz zur Developer-Edition auch am Freitag vormittag zu erwerben sein. Denkste, Pustekuchen!

Nein, geht nicht. Will 4D nicht. Du sollst den „4D WebApplication Server“ (Runtime Classic mit WebExtension) nehmen. Der kann aber nur kompiliert.
… nicht mich schlagen, ich bringe nur die Nachricht!

Und nun? Kaum habe ich mich in ein Lizenzsystem eingearbeitet, gilt es schon nicht mehr. Wenn das neue wenigstens den Fortschritt brächte, von mal zu mal narrensicherer zu werden, wäre das Klasse. Doch noch ein Pustekuchen!

Wie soll ich die Anwendung compiliert debuggen? Ich brauche direkten Zugriff, von jetzt auf sofort: Fehler entdecken, Ursache finden, Ursache beheben und weiter gehts. Nicht so mit dem „4D WebApplication Server“. Dort kämen diese Arbeitsschritte hinzu: compilieren, Anwendung erstellen, die Anwendung starten und erst dann testen. In der Zeit fließt 'ne Menge Wasser unnütz vorbei. Im Produktiveinsatz ist mir der Umstand „4D WebApplication Server“ nur kompiliert wumpe, aber in dieser Situation wäre ich mit dem @-Affen gepudert.

Der Indianer

Also den Apache vorschalten, dann wird der Indianer der einzige Kunde am 4D WebServer und der 4D WebServer serviert nur mehr im Lokal, nicht mehr im Garten. Aber wie schalte ich den Apache so um, daß er die Anfragen aus dem Web an 4D durchreicht? Google hilft sofort und findet TN 09-38_mod_proxy bei kb.4D.com. Klasse, da hat jemand bei 4D die gleichen Erfahrungen wie ich jetzt gemacht und eine Lösung beschrieben:

This Technical Note discusses how to use Apache HTTP Server as a front end to 4D’s Web Server. This is achieved through the use of the mod_proxy module. Various sample configurations are given and their options are discussed. This information should give the 4D Developer the knowledge necessary to provide an Apache front end to their 4D Web Server if their clients request it.

Die TechNote ist 'ne Perle, die ich mir archivieren sollte.

Es läuft darauf hinaus, in die httpd.conf des Apache – exakt beschrieben wo Sie die finden – eine Zwischen-URL einzutragen und Apache somit für bestimmte URL-Teile umzulenken auf einen anderen WebServer**. Die gelb hinterlegten Teile sind zu ersetzen mit den jeweils gültigen:
# start
<IfModule mod_proxy.c>
  ProxyRequests Off
  <Location /URL/>
    ProxyPass http://realIP:port/
    ProxyPassReverse http://realIP:port/
  </Location>
</IfModule>
# end
und mod_proxy ist falls noch nicht geschehen zu ent-kommentieren, also # rausnehmen.

Wäre zu schön gewesen, es liefe sofort perfekt. Die HTML-Seite wird geliefert, doch es fehlen referenzierte Daten. So werden die CSS-Dateien werden nicht geladen, ebenso fehlen die statischen Bilder. Die Objekte werden nicht gefunden weil die URLs nicht stimmen. Da muß ich nachbessern.

Mit einem zusätzlichen Pfad-Element, der den relativen vorangestellt wird, ist das Problem behoben. Gleich als Einstellung angelegt, ist das hin&her nicht so umständlich, denn auf dem localhost braucht es das zusätzliche Pfad-Element nicht.

Resumee: läuft prima und wir kriegen richtig was geschafft, viel gelernt und manche 4D TechNotes sind mehr als hilfreich.