URL einer Web-Dynpro-Anwendung

Web-Dynpro-Anwendungen werden im Internet-Service-Baum des ICF unter der Pfadangabe/sap/bc/webdynpro/<Namensraum>/<Anwendungsname> abgelegt (siehe auchICF-Service anlegen und konfigurieren). Für den webdynpro-Knoten ist in der Handler-Liste der SICF der Handler CL_WDR_MAIN_TASK spezifiziert.

Ist nur der Component-Name angegeben, dann wird der Standard-Namensraum/SAP/ verwendet. SAP-Anwendungen werden immer im Namensraum/SAP/ ausgeliefert. Falls Sie Ihre Web-Anwendung in einem eigenen Namensraum anlegen, so muss in der URL dieser verwendet werden (siehe auch Namensraum für Entwicklungen einrichten). Dann werden Components in der Notation /<Namensraum>/<Anwendungsname> angegeben, z.B./TEST40P/MYFIRSTAPP.

Beispiele

In beiden Beispielen gehört die Web-Dynpro-ApplikationmySecondApp zu der Component myFirstApp.

Beachten Sie, dass Bilder immer über die Applikations-URL geladen werden (siehe unten).

Beispiele

FürmySecondApp/img.gif muss der eingehende Request derart geändert werden, dass er auf myFirstApp/img.gif zeigt, bevor der MIME-Handler aufgerufen wird.

Die Platzierung von Web-Dynpro-Applikationen unter/sap/bc/webdynpro im ICF ist der Standardfall, wenn keine weiteren Aktionen durchgeführt wurden. Verständlicherweise bevorzugen es viele Kunden, ihre Anwendungen an einem anderen Platz im URL-Raum zu platzieren, nicht unter/sap/bc.

Üblicherweise erstellen Kunden ihre eigenen Zweige im Internet-Service-Baum des ICF, damit ihre Anwendungen auch dort abgelegt sind. Beispielsweise hat die Firma XYZcorp einen registrierten Namensraum und hat entsprechend den folgenden Eintrag im ICF angelegt:/xyzcorp/webdynpro/. Der Web-Dynpro-Handler CL_WDR_MAIN_TASK wird unter diesem ICF-Knoten gespeichert, auf dem Tabreiter Handler-Liste des jeweiligen Service-Knotens. Dann kann der Kunde die Anwendung unter diesem ICF-Pfad erstellen.

Für eine neue Web-Dynpro-Component/XYZCORP/MYFIRSTAPP würde im ICF-Servicebaum der folgende Pfad zu finden sein: .../xyzcorp/webdynpro Wenn ein solcher Pfad existiert, wird die Applikation unter diesem Baum im ICF abgelegt, ebenso im MIME-Repository.

Beispiele

Siehe auch:

URLs und Namensräume

Wenn noch kein eigener Namensraumknoten unter dem Pfad/sap/bc/webdynpro angelegt wurde, wird der Elternknoten immer in dem gleichen Paket angelegt, dem auch die Anwendung im System zugeordnet ist. Sollte die Anwendung ein lokales Objekt sein ($TMP), dann wird bei der Paketzuordnung auch der Elternknoten automatisch auf $TMP gesetzt. Alle neuen ICF-Knoten, die für Anwendungen im gleichen Namensraum generiert werden, werden automatisch dem Paket des Elternknotens zugeordnet.

Wenn also der Elternknoten als lokales Objekt angelegt ist, kann der Knoten nicht transportiert werden. Wenn der Kindknoten nicht lokal ist, kann der Knoten zwar transportiert werden, aber im Zielsystem kann er nicht gefunden werden, denn der Anker (= der Elternknoten) ist dort nicht vorhanden.

Bei der URL einer Web-Dynpro-Applikation ist die Angabe des vollständig qualifizierten Domänennamen (FQDN) erforderlich. Weitere Informationen finden Sie unterVoll qualifizierte Domänennamen (FQDN).

In der Regel werden Bilder über die URL der jeweiligen Anwendung geladen. Für das Web Dynpro ABAP werden die Bilder imMIME-Repository abgespeichert. Meistens gibt es für jede Component eine entsprechende, gleich lautende Web-Dynpro-Applikation, also z.B. Component abc hat die Applikation abc zugeordnet. Wenn der Anwendung z.B. die URL.../sap/abc zugeordnet ist, dann werden wie dazugehörigen Bilder als .../sap/abc/img.gif geladen.

Es kann jedoch vorkommen, dass der Component abc eine zweite Applikation xyz zugeordnet wird. Dann hat diese Applikation die URL.../sap/xyz, und ein dazugehöriges Bild sollte ebenfalls über .../sap/xyz/img.gif geladen werden. Das Bild ist jedoch unter .../sap/abc/img.gif abgelegt. Anstatt relative Pfade zu verwenden, sollten Bilder über die Applikations-URL geladen werden, und nicht über den Component-Namen. Dies bietet die folgenden Vorteile:

• Kundensicht

  Alle Bestandteile einer Anwendung sollten auch im entsprechenden Verzeichnis unter dieser Anwendung gespeichert sein. Für Kunden, die z.B. die Anwendung SalesOrder verwenden, ist es am einfachsten, alles unterSalesOrder/* abzulegen.

• Load-Balancing

  Bei dem Einsatz von Load-Balancers werden diese üblicherweise von Kunden derart konfiguriert, dass sie URL-Pfade verwenden, um spezielle Maschinen zu erreichen und alle Requests, die auf andere Pfade zeigen, abzuweisen. Hierbei ist es wichtig, alle Bilder über die URL zu laden, unter der auch die entsprechende Anwendung läuft.

Informationen über die verschiedenen URL-Formate, die von Web Dynpro ABAP aufgelöst werden können, finden Sie unterHandling von Web-Ikonen.

Bei der Verwendung relativer URLs für das Laden von Bildern muss die Funktionsweise von URLs im Browser beachtet werden. Wenn beispielsweise bei einer URL der Form.../sap/app ein Bildimg.gif (oder./img.gif)geladen werden soll, trennt der Browser das letzte Segment ab und generiert eine neue URL in der Form .../sap/img.gif. Das app-Segment ist also nicht mehr vorhanden. Die einzige Methode, den Browser korrekte URLs generieren zu lassen, besteht darin, ein nachstehendes /-Zeichen an die URL anzuhängen. Wenn eine Anwendung z.B. mit .../sap/app gestartet wird, dann ändern Sie die URL in .../sap/app/ ab, entweder über einen Redirect oder implizit zu dem Zeitpunkt, wenn der Frameset geladen wird.

Häufig definieren Kunden externe URLs im HTTP-Servicebaum des ICF. Eine entsprechende URL könnte folgendermaßen aussehen:

Beispiel

Beachten Sie dabei, dass interne Links im ICF-Baum gleichermaßen funktionieren.

Aufgrund der Verwendung von relativen URLs für Bilder werden diese korrekt geladen. Sobald eine Applikation gestartet wurde, muss für sie der interne Name im ICF-Baum verwendet werden, damit klar ist, was tatsächlich dahinter abläuft (Pointer im ICF-Baum).

Wenn eine Web-Dynpro-Anwendung für eine Homepage direkt unter der Wurzel-URL abläuft, dann sieht die URL z.B. folgendermaßen aus:

Beispiel