集成中需要解决的关键问题(OSLC相关)
OSLC服务发现
DOORS支持OSLC RM 规范，其提供的服务支持OSLC规范要求的寻址方式，如下图所示：
正常的基于OSLC的集成方式，客户端代码要基于OSLC的服务发现机制逐层获取所需要的服务地址，这是最为理想和健壮的实现方式。DOORS/DWA对外提供了跟服务入口是：
| https://server:port/dwa/public/rootservices |
OSLC服务的HTTP请求头设置
Accept: application/rdf+xml OSLC-Core-Version: 2.0 |
实现方式上可以采用最原生的HTTP请求-响应，然后基于返回的数据解析XML数据。也可以采用OSLC相关的类库，比如OSLC4J库。
OSLC Delegated UI 的加载
OSLC “Delegated UI” 为系统集成提供了良好的用户体验，基于这种方式，跨领域工具的工件选择和创建都是无缝的，客户端程序的实现不需要构建与目标工具一致的UI，只需要对目标工具提供的 "Delegated UI" 进行加载并展示。通过这种集成机制，在当前工具中能够提供与目标工具一致的用户界面，极大的提高用户体验。如果您是在Web系统中集成DOORS，则通过HTML的IFRAME直接加载DOORS的OSLC UI 地址即可。如果是在非WEB系统中，则要选择相应的HTML加载控件即可。如下是在桌面客户端中加载DOORS的需求选择界面的示例：
如何获取选择或创建后的需求数据
基于OSLC Delegated UI机制加载界面并选择或创建资源后，第三方应用需要获取选择或创建的资源URI和标签。实现方式如下图所示：
选择数据后通过H5的POST MESSAGE机制进行跨域数据传递，因此，在上层应用中，需要通过事件监听机制获取Post的数据。以Web系统为例，则需要在页面中注册如下事件监听：
| window.addEventListener("message", function (event) {var message = event.data;// TODO: Handle the message}, false); |
Message内容结构如下：
| {oslc-response:{oslc:message: "oslc.select",oslc:results:[{"rdf:resource": "https://clm-pc:9443/rm/resources/_K40n0TpwEemxhdDGwPP8YA","rdf:type":"https://clm-pc:9443/rm/types/_iDi60TNFEemOcdPKSpXMaQ","oslc:label":"2：demo"}]}} |
集成效果示例
视图选择：
链接关系创建后：
最后
与需求管理系统的集成，在实际的研发生命周期中具有较高的业务价值。建议与DOORS集成时首选采用OSLC方式进行集成，特别是涉及到链接这种情况时，OSLC提供的Delegated UI机制具有更好的用户体验。另外，本篇粗略描述基于OSLC形式与DOORS进行集成的几个方面。对于支持OSLC规范的工具来说，集成形式大同小异。比如，RTC、DNG、RQM等工具都支持OSLC规范，如果与这些工具进行集成，则要参考相应的领域规范以及工具对OSLC的支持能力了。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
