Web Dynpro for ABAP：URL of a Web Dynpro Application

from: http://www.cnblogs.com/rlwang/archive/2011/04/22/2024445.html

     Web Dynpro程序的URL是系统自动生成的。我们能够在Web Dynpro Explorer的’Properties’页签找到应用程序的URL。.

         Web Dynpro程序的URL有下面的结构(默认的配置)，下面的格式是正确的：

l SAP namespace

<schema>://<host>.<domain>.<extension>:<port>/sap/bc/webdynpro/<namespace>/<application name>

l Customer namespace

<schema>://<host>.<domain>.<extension>:<port>/abc/klm/xyz/<namespace>/webdynpro/<application name>

<schema>://<host>.<domain>.<extension>:<port>/namespace>/webdynpro/<application name>

     <schema> 代表URL结构(例如协议),这个经常为http或者https协议(如果做了配置),<host>是执行这个应用程序的服务器的名称，<domain>和<extension>是在一个通用名字下组成的几个主机,可能是独立主机或者是网络，如果使用了标准的http端口(80)或者https端口(443)，<port>号码可以省略。

    命名空间(namespace)可能是标准的命名空间/SAP/或者客户化的命名空间(见下).

应用程序名称是Web dynpro component在web dynpro explorer里定义的web application名称。

 

SAP命名空间的应用

    Web Dynpro应用存储在目录/sap/bc/webdynpro/<namespace>/<application name>的网络服务树下面。如果只有component名称被指定，使用标准的名称空间/sap/. SAP应用总是部署在/sap/名称空间。如果单独名称空间下创建了Web应用，必须使用下面格式的URL, components以/<namespace>/<application name>格式指定。例如, /test40p/myfirstapp.

应用	URL
Application 1a Application 1b	http://us4049.wdf.sap.corp:1080/sap/bc/webdynpro/sap/myfirstapp http://us4049.wdf.sap.corp:1080/sap/bc/webdynpro/sap/mysecondapp
Application 2a Application 2b	http://us4049.wdf.sap.corp:1080/sap/bc/webdynpro/test40p/myfirstapp http://us4049.wdf.sap.corp:1080/sap/bc/webdynpro/test40p/mysecondapp

上面两例子中，Web Dynpro应用程序mysecondapp属于myfirstapp component.

 

Pictures

注意图片总是用下面的URL载入(见下)

应用	URL
Application 1a Application 1b	http://us4049.wdf.sap.corp:1080/sap/bc/webdynpro/sap/myfirstapp/img/gif http://us4049.wdf.sap.corp:1080/sap/bc/webdynpro/sap/mysecondapp/img/gif
Application 2a Application 2b	http://us4049.wdf.sap.corp:1080/sap/bc/webdynpro/test40p/myfirstapp/img/gif http://us4049.wdf.sap.corp:1080/sap/bc/webdynpro/test40p/mysecondapp/img/gif

对于mysecondapp/img.gif,在MIME处理调用之前，新来的请求必须被改变，以便指向myFirstApp/img.gif.

 

如果没有更进一步的调用行动, Web Dynpro 程序通常放到/sap/bc/webdynpro下面，为了更易理解，许多客户开发程序更喜欢放置到不同的URL命名空间/sap/bc.

 

 

客户化的名称空间的应用

           通常用户会在ICF因特网服务树中创建自己的分支，把自己的应用放到这里。例如公司XYZcorp有一个注册的名称空间，并且在ICF创建了下面的入口：/xyzcorp/webdynpro/. Web dynpro处理器存储在ICF的节点上。用户可以在ICF路径下创建一个应用程序。对于一个新的web dynpro部件/xyzcorp/myfirstapp，我们可以在ICF服务树下面找到对应的路径： …/xyzcorp/webdynpro,如果这个路径存在，则应用程序存储在ICF树下，或者在MIME存放。

      

Application	URL
Application3a Application3b	http://us4049.wdf.sap.corp:1080/1wda/webdynpro/myfirstapp http://us4049.wdf.sap.corp:1080/1wda/webdynpro/mysecondapp

注意：命名空间不允许从HTTP服务树的根节点开始。除了在开头的签名<namespace>/webdynpro, 可以放到ICF树的任何地方。例如：SCM在命名空间/ICH/下创建了”Internet Communication Hub”项目。在这种情况下，URL格式如下：/sap/scm/ich/webdynpro/myFirstApp.

 

 

FQDN

完全全称域名必须在WebDynpro的URL指定。

 

 

载入图片

         通常情况图片是经过应用程序的URL载入的。 Web Dynpro ABAP程序的图片存储在MIME仓库中。对于每个component, 总有同一对应的web dynpro应用程序与其对应。例如，component abc分配给应用程序abc. 如果URL…/sap/abc分配给应用程序，则对应的图片载入路径如这样…/sap/abc/img.gif.

           Component abc可以被赋给第二个应用xyz.所以这个应用程序有URL …/sap/xyz,所对应的图片也需要从目录…/sap/xyz/img.gif进行加载. 即使图片存储在目录…/sap/abc/img.gif，也使用了相对路径，图片应该通过应用程序的URL加载，而不是通过component名字。有以下的优点：

l 客户视图

应用程序的所有的components应该存储在这个应用程序对应的相关的路径下。对于客户化的使用，例如应用程序的SalesOrder，大部分存储到salesorder/*目录下。

l 负载平衡

当使用负载平衡时,客户经常寂静做过配置，他们用URL路径到达指定的计算机，拒绝指向其他路径的请求。这点非常重要，所有的图片通过相应应用程序中的URL加载。

 

 

 

URL 中附属的标记 ’/’

           当相应的URLS用来加载图片的时候，记住在浏览器中的URLs.例如，如果一个图片img.gif(或者./img.gif)通过格式…/sap/app格式加载，浏览器删掉最后一个部分并且产生一个格式为…/sap/img.gif新的URL. ‘app’部分不再存在，唯一方式产生正确的URLs的方式是在URL的末端加上’/’字符。例如，如果一个应用程序以…/sap/sap开始，改变URL成…/sap/app/，或者当架构载入时使用重置命令，或者隐式。

 

 

 

特殊情况

           客户开发经常定义外部URLs在ICF的HTTP服务树，相应的URL如下示例：

Application	URL
Application 1a	http://us4049.wdf.sap.corp:1080/superapp/

注意内部链接功能和在ICF树是一样的。

           自从相对的URLs在图片中被使用，他们总是被正确的加载。一旦一个应用被启动，在ICF树的内部名字必须用在这应用程序上，所以在它后面发生了什么是非常清楚明了的事情。

 

 

主页

如果一个为首页的Web Dynpro 应用直接在根目录的URL下执行，URL格式如

        下示例：

Application	URL
Special case 1a	http://us4049.wdf.sap.corp:1080/

 

 

 

1)       完全合格域名(FQDN)

 Fully Qualified Domain Names

在Web Dynpro ABAP中，客户浏览器访问AS-ABAP时有FQDN是非常必要的。因为这个原因，当一个ABAP应用程序被调用时，完整的URL必须赋值给Web Dynpro ABAP程序。URL不能被减短(例如不指定域名)。

           域的使用必须满足cookie指定的需要

(参考http://wp.netscape.com/newsref/std/cookie_spec.html).

为了检查FQDN/FQHN,在ABAP开发环境中的Web Dynpro浏览器中，从导航树中Web Dynpro的component/interface选择相应的Web Dynpro应用程序，在管理数据中检查URL,    在路径细节中检查URL是否包含了所有的域名和主机名。

 

 

目的

       以下原因是FQDN的必要阐述：

l Cookies能够通过一个域设置域范围，例如SSO2 cookies.

域需要用在交叉框架的javascript，对于portal集成非常重要。

l 在HTTPS环境下，客户和服务器名称必须对应于各自的认证和各自的协议。注意：AS-ABAP运行的domain并不必须要用FQDN从浏览器访问AS-ABAP。典型的例子如同时运行在内网和外网的AS-ABAP， 这种情况下FQDN通过浏览的位置对应的AS-ABAP决定而不是AS-ABAP自己。

 

 

完全合格域名的配置 configuration of Full Qualified Domain Names

       如果主机名简单指定了主机和端口，并没有指定域名，Web 应用程序中缩短的URL如下语法所示：

   <schema>://<host name>:<port>/sap/…

   例如：

   http://pwdf0487:1080/sap/bc/webdynpro/sap/wdr_test_events

    而完全的URL语法如下：

    <schema>://<host name>.<domain><extension>:<port>/sap/…

   例如：

   Http://pwdf0487.wdf.sap-ag.de:1080/sap/bc/webdynpro/sap/wdr_test_events

 

      不支持IP地址

    URLs中包含的ID地址并不被支持,如下语法:

    <schema>://<ip address>:<port>/sap/…

    例如：

    Http://10.21.81.0:1080/sap/bc/webdynpro/sap/xyz

下面的记号是需要的，如语法：

<schema>://<host name>.<domain> <extension>:<port>/sap/…

例如:

http://hs0059i.wdf.sap.corp:1080/sap/bc/webdynpro/sap/xyz

 

为了正确映射IP地址，下面是必须的：

l 在客户位置带有AS-ABAP的名字和IP地址映射的DNS最小的组成

l 假如AS-ABAP名字能够被使用，HTTP代理在防火墙进行了相应配置，URL会映射到正确的IP地址。

l 可以应用下面解决方案进行简单安装：

在每个工作区更新主机文件，输入行10.17.73.210 hostname.domain.ext 到文件\WINNT\system32\drivers\etc]hosts.

 

 

    主机名中不支持’_’

       如果cookies中的主机名称包含下划线“_”，浏览器不会支持 。

       IE6和IE5.5包含安全补丁MS01-55不会支持包含下划线的主机名，cookies会话不会被保存。如果浏览包含的Web应用程序是，会导致浏览中断。

       示例：开发系统命名为dev_sys, Q系统命名为qsys ,这意味着域名为：qsys.company.co.xx,通过对比，下面的标记是非法不支持的：

                               Dev_sys.company.co.xx

              Qsys.my_company.co.xx

      所以，主机名和域名不能够包含下划线‘_‘.

 Cookie规范协议中的域名受限

   Portal必须从域名开始，并且域名必须满足因特网标准的cookie的规范，与其一致。否则portal不会创建MYSAPSSO2cookie.

因为浏览器能够决定cookie会被发送到哪个浏览器，URL必须包含域名规范，因为发送的决定是基于这些信息的。而相应于netscape cookie规范，cookies只能被设置成一个域名，由于安全机制的限制，并且一个域名包含2个或者3个点(.)。这7个顶级域名(.com,.edu,.net,.org,.gov,.mil,.int)任何一个必须至少包含一个domain component(通常是公司或者组织的名称)，打到2个点(.)。每个域名有不同的结束标记(这些包含顶级域名例如国家的UK,DE,FR等等)，必须有2个domain components。这些域名必须包含至少3个点。更多详细信息查看cookie规范。示例:

 有效的域名：

l <host>.sap.com

   顶级域名->两个domain components

l <host>.portal.sap.de

 非顶级域名->三个 domain components

   有些浏览器对于域名有很少的限制和约束，违反了cookie规范说明。

      IE允许下面的域名：

       【语法】 <host>.sap.de

这个非顶级域名，它只有2个domain components.

 

域名倒数第二部分至少包含了3个字符的格式可以被认可的。否则会有问题。对于所有的英文格式的域名，cookie的发送方式是有不同的限制的。

 例如：

URL	Description
http://www.xy.com/	符合规范
http://www.xy.co.uk/	符合规范
http://%3chost%3e.epd.de/	MS  IE 可以
http://www.sap.de/	MS  IE 可以
http://%3chost%3e.ep.de/	MS IE 不可以
http://www.co.uk/	不可以(虽然符合规范)

 

HTTPS

SSL的用处是为了做加密的数据传输，保证服务器是可靠的连接，这些工作是通过SSL服务器认证实现的。对于每个HTTPS URL，浏览器在SSL服务器检查URL所包含的完整的主机名是否符合规范。如果浏览器确认不符合，将会有错误警告。

例如：SSL服务器认证发布“CN=tcs.mysap.com,OU=SAP Trust Community, O=SAP AG, L =Walldorf, C=DE”.下面的URL将被检查：

URL	行为描述
…/com.mysap.tcs//:http	HTTPS/No SSL
…/com.mysap.tcs//:https	符合规范
…/com.mysap.01tcs//:https	错误警告

 

    SSL服务器发布的”CN=mysap.com,…”认证,所有上面列出来的URLs均会返回错误信息。

    认证授权(CA),对于components经常有自己的发布的验证的规则。万用字符(*)在平常名字中不会被允许。

注意：当使用SSL中断了代理(在到Web服务器/AS-ABAP之前)，必须保证SSL代理的认证服务器对应的主机名对于浏览器是可见的。更多信息查看AS-ABAP安全。

 

 

FQDN设置

       下面的参数和变量用于设置主机名和域

l SAPLOCALHOST

l SAPLOCALHOSTFULL

l Icm/host_name_full

 

ICM设置FQHN符合下面的结构：

1.       SAPLOCALHOSTFULL在SAP配置(建议高级配置使用)中有最高的优先级.如果在SAP的文件中做了配置，ICM设置作为了FQHN值。

注意：SAPLOCALHOSTFULL的系统默认值包含的主机名不含有域名，这就是为什么系统通过ICM默认忽略。

 

   如果参数没有设置,值在iicm/host_name_full sapurl_li中被使用。

   1． 如果这个参数也没有做设置，ICM代替了操作系统的FQHN. 参数SAPLOCALHOST并不全满足，不被服务器的ICM使用。 SAP建议设置SAPLOCALHOSTFULL(高级配置)和icm/host_name_full.

 

 

 

2)      URLs和命名空间

   当我们使用主机的命名空间，在ICF因特服务树和MIME仓库中有许多奇怪的路径需要注意。

    当创建了自己的命名空间，应该按以下的命名规范。

    通常，Web Dynpro应用程序通过se80创建,或者在sap 命名空间中用它的简单的名字，例如，myapp,或者在客户化的命名空间用比较复杂的命名规范，/<namespace>/<application name>, 例如，/test40p/myapp. 相应的，ICF路径都在/sap/和自己的命名空间下，如下例：

应用程序名称	ICF 路径
Myapp	Myapp/sap/webdynpro/bc/sap/
Myapp/p40test/	Myapp/p40test/webdynpro/bc/sap/

 

如果ICF路径结构在SAP命名空间(/sap/bc/webdynpro/sap/myapp) 或者在客户化命名空间(sap/bc/webdynpro/acme/myapp)非常冗长，可以在默认的主机名下面的最高级别路径直接创建命名空间(/acme/webdynpro/myapp).作此操作必须满足下面的先决条件：

l 在ICF中对应的最高级别的节点和Webdynpro的子节点必须创建在相对应的命名空间。

    对于Webdynpro子节点，HTTP的请求处理CL_WDR_MAIN_TASK必须在处理列表中定义。

  

    对于这个子节点的系统登录也必须做配置。一旦这个被配置，对于webdynpro的所有的子节点的系统登录自动有效。

如果应用程序已经存在在很长的ICF路径下，必须做相应的移动：

n 在老路径下的所有存在的应用程序，在ICF的路径下需要手工创建新的应用程序节点：/acme/webdynpro/myapp1。

n 然后同时需要删除路径/sap/bc/webdynpro/acme下的所有的子应用程序。

n 另外，新命名空间的文件夹和webdynpro的子文件夹应该设置在MIME仓库中。

 

    一旦先决条件满足了，ICF路径将会在最高级别，如下所示：

Application name	ICF Path
Myapp/wda1/	Yappm/webdynpro/wda1/
Myapp/acme/	Myapp/webdynpro/acme/

 

  准备设置

     为了让Web dynpro在客户命名空间中运行的平稳，必须做以下的设置工作：

1.       通过事务代码SICF打开ICF.

2.       为自己的命名空间创建一个跟节点，(例如，/acme)在默认主机名得服务树下面直接创建。注意：只能在这里输入和保存名称。

3.       在自己创建的根节点下面创建子节点，名称为webdynpro.路径如：/acme/webdynpro. 注意：子节点的名字必须是webdynpro，并且不含有空格。

4.       为子节点webdynpro在Handlerlist注册下创建处理方法，CL_WDR_MAIN_TASK.

5.       如果在很长的ICF路径下有一个存在的应用程序节点，他们中的每个旧的程序都会创建新的路径并且完全删掉旧的路径。

6.       在MIME仓库树中为你的命名空间创建一个新的根节点，在下面有个Webdynpro的子节点。类CL_MIME_REPOSITORY_API的方法CREATE_ROOT_FOLDER提供给他。

在路径MIME的仓库树中的路径： /acme/webdynpro.

移动存在原来旧的路径下的的图片放到MIME仓库中新的对应的路径下。

 

     检查配置

1.       调用事务SE38

2.       去自己的测试程序

3.       检查应用程序的Characteristics下的 URL，语法如下记号：

Http://host.domain.ext:port/1wda/webdynpro/helloword

 

 

 

 

 

 

 

 

 

 

 

 

     3）通过参数调用Web Dynpro应用程序

 

 使用

      Web Dynpro应用程序的URL参数通过主component定义。

      Components窗口有inboud plug. Inboud plug可以带有参数，也就是所谓的URL参数。

      默认值被被URL参数的值重写，可以在应用程序中设置这些参数。如果既没有默认值，也没有URL参数进行指定，运行时就会触发错误。

 

  步骤

1.       在component中，转到窗体编辑器。

这里你可以改变预定义的inbound plug，或者创建一个新的inbound plug.

a.       指定plug作为启动plug(Start).

b.       数据类型应该为string，因为这里并不进行数据转换和数据检察。

c.       激活component.

2.       为这个程序指定要调用的component，窗口，启动plug，然后就可以指定参数了。

   和默认参数不同，启动plug参数也是可用的，也可以赋给默认值。如果没有默认值指定，

   当调用这个程序时，参数将会被指定为URL参数。

3.       调用应用程序。

 此步骤中，URL参数重写了应用程序中的参数。