4.Web Dynpro for ABAP之
URL of a Web Dynpro Application(PDF)
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服务树的根节点开始。除了在开头的签名<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 |
|
符合规范 | |
|
符合规范 | |
|
MS IE 可以 | |
|
MS IE 可以 | |
|
MS IE 不可以 | |
|
不可以(虽然符合规范) | |
|
|
|
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参数重写了应用程序中的参数。
5.Web Dynpro for ABAP之Component Usages
