Archiv

Archive for August 2010

301 Redirect mit Oracle Apex?

Warum der 301-Redirect?

Wird eine Web-Anwendung im Internet veröffentlicht tauchen ganz neue Aspekte auf, die im Intranet keine Rolle spielen. Ein zentraler Aspekt ist der Umgang der Anwendung mit Google & Co.

Ist zum Beispiel eine veraltete URL nach einer Zeit nicht mehr in der Anwendung verfügbar, muss man davon ausgehen, dass Suchmaschinen die Seite trotzdem noch indiziert haben. Dies muss noch nicht einmal eine komplette Page sein, sondern kann auch nur ein Produkt sein, das nicht mehr im Stock des Onlineshops vorhanden ist. Dabei hilft es auch nicht die sitemap.xml zu aktualisieren. Das Sperren der URL über die robots.txt ist zwar im Prinzip möglich, allerdings auch sehr schwerfällig.

In solchen Fällen rät Google & Co dem Webmaster, einen 301-Redirect für die URL (moved permenantly) einzurichten. Dies geschieht zum Beispiel über eine mod_rewrite-Regel im Apache. Im Falle einer Oracle Apex-Anwendung ist dies allerdings auch zu unflexibel. Besser ist ein 301 Redirect aus der Anwendung heraus.

Kein 301 Redirect mit owa_util

Im Prinzip sollte ein 301 Redirect über owa_util möglich sein, dies scheitert aber an der aktuellen Implementierung:

Verschiedene Quellen in Web schlagen folgendes Coding vor

owa_util.status_line(301, null,FALSE);
owa_util.redirect_url('https://apextipps.wordpress.com', TRUE);

Erzeugt man einen entsprechenden Page-Prozess als „before header“-Prozess, zeigt sich beim Aufruf der Seite , dass trotzdem ein 302 Redirect (Moved Temporarily) zum Client gesendet wird. Ein schönes Tool, um das Redirect-Verhalten zu kontrollieren ist z.B. das Firfox-Plugin Tampa Data

Dieses Verhalten zeigt sich sowohl in der Kombination Oracle XE + Apex 3.2.1 als auch mit Oracle 11g + Apex 4

Die Alternative: 410er Get mit Meta-Redirect

Als Alternative zum 301-Redirect gibt es folgenden Workaround, der in beiden Oracle/Apex – Kombinationen funktioniert hat und den gleichen Effekt für Google & Co hat:

  1. Die URL, die aus dem Google-Index gelöscht werden soll, schickt den Status-Code 410 (Gone) zurück. Eine 410er-Seite muss zum Glück keinen bestimmten Aufbau haben. Das erleichtert die Programmierung in Apex
  2. Um trotzdem einen Redirect zum Client zu senden, falls die URL noch nicht aus dem Index gelöscht wurde wird ein Meta-Redirect verwendet.

Folgendes Coding kann für den Page-Prozess (wieder Before-Header) dafür verwendet werden:

-- 410 instead of 200 indicates that the page should be dropped
-- from any crawler index:
owa_util.status_line(410, 'Gone',FALSE);
-- send a meta-redirect in case a client still ends up on the page:
htp.p('Refresh: 0; url=https://apextipps.wordpress.com');
owa_util.http_header_close;


Kleiner Schönheitsfehler: Der Meta-Redirect hat immer eine Latenzzeit von 1 Sek. Der Client bekommt also kurz die 410er Seite angezeigt.

Advertisements
Kategorien:APEX 3, APEX 4, Oracle 11g, Oracle XE Schlagwörter:

Probleme beim Anlegen einer Websheet application

August 12, 2010 5 Kommentare

Wenn Sie versuchen, im Application Builder über „Create“ -> „Websheet“ eine neue Application vom Typ „Websheet“ anzulegen, kann es zu folgender Fehlermeldung kommen:

The database objects required to create Websheet applications are either invalid or do not exist. Please contact your Workspace Administrator.

Ursache

Um ein Websheet erzeugen zu können, werden einige spezielle neue APEX Datenbank-Objekte benötigt.

Ob diese installiert sind, können Sie prüfen, indem Sie wenn o.g. Meldung angezeigt wird, auf „Manage Websheet Database Objects“ klicken und dann den Link „Validate Websheet Database Objects“ benutzen. Hier werden Ihnen nun die benötigten Websheet Objekte angezeigt. Die Spalte „Exists“ ist hierbei wichtig! Wird hier nun bei einigen Objekten „No“ angezeigt, fehlen wichtige Websheet Objekte und es kann kein Websheet erzeugt werden.

Leider hab ich bisher noch keine Möglichkeit gefunden, diese Objekte nachinstallieren zu können.

Lösung

APEX generiert die benötigten Objekte in das zugehörige DB-Schema, wenn ein neues Workspace angelegt wird!

VORSICHT!

Wenn Sie ein neues Workspace erzeugen und ein existierendes DB-Schema wiederverwenden (re-use=YES), dann bekommen Sie einen Fehler.

ORA-20001: table error:APEX$_WS_ROWS ORA-01031: insufficient privileges

Erzeugen Sie also ein neues Workspace und lassen Sie von APEX ein neues DB-Schema anlegen (re-use existing=NO). In diesem Falle werden alle benötigten Websheet Database Objekte automatisch im jeweiligen DB-Schema erzeugt.

Nun sollte das Anlegen einer Websheet Application einwandfrei funktionieren.

Prüfen Datenbank Objekte

Bevor Sie nun ein Websheet anlegen, können Sie noch prüfen, ob alle benötigten Datenbank Objekte vorhanden und validierbar sind.

  1. Melden Sie sich in Ihrem neuen Workspace an und klicken auf „Administration“.
  2. Klicken Sie nun in der rechten Sidebar „Tasks“ auf „Websheet Objects“ und dann auf „Validate Websheet Database Objects“.

In dieser tabellarischen Anzeige sollten nun alle Objekte als existierend und valide angezeigt werden.

Unterschiede von APEX 4.0 und 3.x bei Mehrsprachigkeit

In diesem Beitrag möchte ich die Unterschiede zwischen APEX 4.0 und 3.x im Umgang mit der Mehrsprachigkeit von Oracle Application Express darstellen.

Den Gesamtbeitragm zum Thema „Mehrsprachigkeit mit Oracle APEX“ finden Sie hier.


Übersetzungen durchführen und veröffentlichen

Beim Durchführen und Veröffentlichen von Übersetzungen gibt es lediglich ein paar kleine Änderungen zu APEX 3.2.1. Generell ist alles gleich geblieben und mein alter Beitrag zu diesem Thema behält somit für Version 4.0 seine Gültigkeit.

Dynamic Translation Messages nun über „Shared Components“ -> “Globalization” -> “Translate Application” -> “Translation Utilities” zu erreichen.

– Download XLIFF Funktion nun als eigenständigen Menüpunkt verfügbar

Die Download-Funktion für das XLIFF-File war bisher nur aus dem Formular „Seed translatable text to translation repository“ verfügbar. Diese Funktion ist nun im Translation-Menü als eigenständiger Punkt verfügbar. Dies hat den Vorteil, dass die Translation-Text Vorbereitung („Seed translatable text to translation repository“) nicht unbedingt vorher durchgeführt werden muss. Man kann nun bei Bedarf einfach das exportieren wiederholen.

Alle anderen Translation-Funktionen sind im Wesentlichen identisch zu denen in V3.2.1.


Localisation (L10n)

Bei der Lokalisierung (Oracle nennt es „Globalization“) hat Oracle ein paar Features nachgelegt. Es gibt nun die Möglichkeit, lokale Zeitformatierungen zentral zu definieren (die folgenden Einstellungen finden Sie über „Edit Application Properties“ -> „Globalization“ (Tab)):

– Application Timestamp Format

Hier kann ein Format für Timestamp Felder definiert werden. Intern wird beim Erzeugen einer neuen APEX Session der Parameter NLS_TIMESTAMP_FORMAT umgesetzt.

Diese Einstellung wird von APEX automatisch gezogen, sobald man ein Feld definiert, das über eine „TO_TIMESTAMP“ Funktion oder eine Datenbankspalte vom Typ „TIMESTAMP“ befüllt wird.

Um diese Einstellung dynamisch zu ändern, kann man ein Application Item (z.B. MY_TIMESTAMP FORMAT) definieren und diesen Wert zur Laufzeit (z.B. wenn die Browsersprache und das Territorium geändert wird) umswitchen. Auf diese Weise kann man z.B. wenn sich ein User mit einer anderen Sprache anmeldet, das Timestamp-Format dynamisch ändern.

Einstellung unter Globalization

Neues Application Item mit Computation

– Application Timestamp Time Zone Format

Hier kann ein Format für Timestamp Felder  mit Time Zone definiert werden. Intern wird beim Erzeugen einer neuen APEX Session der Parameter NLS_TIMESTAMP_TZ_FORMAT.

Zum allgemeinen Umgang mit Timestamp Funktionen gibt es auch einen sehr guten Artikel von Carsten Czarski.

http://sql-plsql-de.blogspot.com/2009/11/date-timestamp-und-zeitzonen-in-sql-und.html

Weiter Informationen zu Änderungen und new Features der Version APEX 4.0 finden Sie unter

http://www.oracle.com/technology/products/database/application_express/html/4.0_new_features.html