URL of a Web Dynpro Application

Web Dynpro applications are stored in the ICF Internet service tree under the path /sap/bc/webdynpro/<namespace>/<application name>. In the SICF handler list handler CL_WDR_MAIN_TASK is defined for the webdynpro node.

If only the component name is specified, the standard namespace /SAP/ is used. SAPapplications are always delivered in the /SAP/ namespace. If you create your Web application in a separate namespace, it must be used in the URL. Components are specified in the format /<namespace>/<application name>, for example, /TEST40P/MYFIRSTAPP.

Examples

In these two examples the Web Dynpro application mySecondApp belongs to the component myFirstApp.

Pictures

Note that images are always loaded using the application URL (see below).

Examples

For mySecondApp/img.gif the incoming request must be changed so that it points to myFirstApp/img.gif, before the MIME handler is called.

If no further actions are performed, Web Dynpro applications are normally placed under /sap/bc/webdynpro. Understandably, many customers prefer to place their applications under a different URL namespace to /sap/bc.

Normally customers create their own branches in the ICF Internet service tree and place their applications there. For example, company XYZcorp has a registered namespace and has created the following entry in the ICF: /xyzcorp/webdynpro/. The Web Dynpro handler CL_WDR_MAIN_TASK is saved under this ICF node, on tab page Handler List of the relevant service node. Then the customer can create an application under this ICF path.

For a new Web Dynpro component /XYZCORP/MYFIRSTAPP you can find the following path in the ICF service tree: .../xyzcorp/webdynproIf this path exists, the application is stored under this tree in ICF, and also in the MIME repository.

Examples

More Information:

URLs and Namespaces

Package Assignment

If your own namespace node has still not been created under path /sap/bc/webdynpr, the parent node is always created in the same package that the application is assigned to in the system. If the application is a local object ($TMP), the parent node is automatically set to $TMP too when it is assigned to a package. All new ICF nodes generated for applications in the same namespace are automatically assigned to the package of the parent node.

So if the parent node is created as a local object, the node cannot be transported. If the child node is not a local object, the node can be transported, but it cannot be found in the target system because the anchor (= parent node) is not available there.

The fully qualified domain name (FQDN) must be specified in the URL of Web Dynpro applications. For more information see Fully Qualified Domain Names (FQDN) .

Usually images are loaded via the URL of the application in question. For Web Dynpro ABAP images are stored in the MIME Repository . For each component there is usually a corresponding identical Web Dynpro application, for example, component abc is assigned to application abc. For example, if URL .../sap/abc is assigned to the application, the associated images are loaded as .../sap/abc/img.gif.

Component abc may be assigned to a second application xyz. In so this application has the URL .../sap/xyz, and any associated images should also be loaded using .../sap/xyz/img.gif. The image however is stored under .../sap/abc/img.gif. Instead of using relative paths, images should be loaded via the application URL, and not via the component name. This has the following advantages:

• Customer view

  All the components of an application should also be stored in the relevant directory under this application. For customers using, for example, the application SalesOrder, it is easiest to store everything under SalesOrder/*.

• Load Balancing

  When load balancers is used customers normally configure them so that they use URL paths to reach specific computers, and reject all requests that point to other paths. Here it is important that all images are loaded via the URL under which the application is also running.

For information about the various URL formats that can be resolved by Web Dynpro ABAP, see Handling Web Icons .

When relative URLS are used to load images keep in mind how URLs behave in the browser. For example, if an image img.gif (or ./img.gif) is to be loaded with a URL of the format .../sap/app, the browser removes the last segment and generates a new URL with the format .../sap/img.gif. The app segment therefore no longer exists. The only way to get the browser to generate correct URLs is to attach a "/" character at the end of the URL. For example, if an application is started with .../sap/app, change the URL in .../sap/app/, either using a redirect command, or implicitly at the time when the frameset is loaded.

External URLs

Customers often define external URLs in the HTTP service tree of the ICF. A corresponding URL could look like:

Example

Note that internal links function the same in the ICF tree.

Since relative URLs are used for images, theses are always loaded correctly. As soon as an application has been started, the internal name in the ICF tree must be used for the application so that it is clear what is going on behind it (pointer in the ICF tree).

Homepages

If a Web Dynpro application for a homepage is running directly under the root URL, the URL looks like:

Example