RosettaNet概述

RosettaNet组织（http://www.rosettanet.org）于1998年6月创建，是非盈利性的国际性组织，目前归属于GS1 US。它在全球存在众多的分支机构，在国内，其联盟网址为http://www.rosettanetchina.org.cn，于2003年底成立。RosettaNet协议，起初应用于高科技、半导体、电子制造行业，目前正逐步向物流、电信、海关等领域渗透，成为名副其实的真正意义上的供应链端到端的B2B协议。EDI 和 RosettaNet 之间的主要区别在于， EDI 在公司之间交换文档，而 RosettaNet 跨网络定义业务流程并对其进行集成，以确定最佳操作过程。

标准

RosettaNet 标准为电子商务标准化提供一个健壮的、非专有的解决方案，它是免费的，可以通过 RosettaNet 网站公开。这些标准是由全球领先的高科技公司通力协作而开发出来的。通过遵循这些标准，贸易合作伙伴、解决方案提供商及系统集成商可以利用这些专业技术和经验。此外，通过采用 RosettaNet ，贸易合作伙伴可以从可重复规范和准则的全局框架中受益，该框架允许调节和自动化实时的、服务器到服务器的事务，这意味着获得了跨整个供应链的全局事务可视性和一致性。使用这些标准化过程，还让贸易合作伙伴降低了成本、更快速地响应客户请求，而且它还可以提升效率、保证高度完整的数据处理。这些标准涵盖以下核心领域：
· 合作伙伴接口过程（ Partner Interface Processes ）
· RosettaNet 实现框架（ RosettaNet Implementation Framework ）
· RosettaNet 业务和技术字典（ RosettaNet Business and Technical Dictionaries ）

PIP

Partner Interface Processes (PIP) 是对确定每一层供应链而进行广泛研究的结果。它们是一组常规的、标准化的过程，可以用于现实世界中企业对企业相互适应的基础。 PIP 旨在通过为各贸易合作伙伴指定业务文档的结构和格式、活动、操作及角色来封装业务流程。简而言之，可以将 PIP 定义为与贸易合作伙伴进行交换的表现形式和消息内容。要记住 PIP 是规范而不是实现；这赋予了采用 RosettaNet 的贸易合作伙伴很大的灵活性，可以自己实现 PIP 规范或购买可降低开发成本的第三方产品。 RosettaNet 将 PIP 指定的整个电子商务供应链领域划分为 7 组称为“集群”的核心业务流程，外加用于管理目的的第 8 个集群。这些集群如下：

· RosettaNet Support ：提供管理功能。

· Partner Product 和 Service Review ：允许为贸易合作伙伴配置文件和产品信息订阅的开发进行信息收集、维护和分发。

· Product Information ：支持产品和设计信息的分发和定期更新，包括产品变更声明和详细技术规范。

· Order Management ：支持整个订单管理业务领域，从定价和提供报价，一直到采购订单初始化、状态报告和管理。订单开票、付款和差错通知也都使用该过程集群来管理。

· Inventory Management ：支持库存管理，包括协作、补给、价格保护、报告和受限产品的分配。

· Marketing Information Management ：支持市场信息发布，包括活动计划、引导信息和设计注册。

· 服务和支持：提供售后销售技术支持、服务担保支持及资产管理能力。

· 制造：提供设计交换、配置、过程、质量和其他制造方面的信息，以支持“虚拟制造”环境。

每个集群由两个或多个段组成。段是相关功能的组。作为一个例子，“CLUSTER 3: Order Management”拥有用于管理报价、订单条目以及运输和分发方面的段。段进一步划分为 PIP，PIP 定义一个或多个活动（Activity），而活动又指定了操作（Action）。在解释活动和操作的区别之前，我们先分析一个关于集群的层次结构的实例：

CLUSTER 3: Order Management

Segment A: Quote and Order Entry

PIP 3A1: Request Quote

Activity: Request Quote

Action: Quote Request Action

Action: Quote Confirmation

Segment B: Transportation and Distribution

Segment C: Returns and Finance

Segment D: Product Configuration

图 1 是展示 PIP 中业务角色、消息及其交换顺序的 PIP 交互图。

 

可以将 PIP 描述为专门的系统到系统的、基于 XML 的对话。每个 PIP 规范都由以下三个主要部分组成 ：

· Business Operation View (BOV) 负责捕获业务实体的语义和角色之间的信息流（当它们参与业务活动时）。 BOV 通常附有流程图。

· Functional Service View (FSV) 派生于 BOV ，它在 PIP 执行期间详细描述了网络组件之间的交互。网络组件通常被视为 RosettaNet “服务”。在图 1 中，“ Buyer （买方）”和“ Seller （卖方）”是两个 RosettaNet 服务，双方都映射到 BOV 中定义的角色。

· Implementation Framework View (IFV) 根据 RosettaNet Implementation Framework 指定 RosettaNet 服务之间的操作消息格式和通信要求。通信要求包括安全的传输协议，如 SSL 和数字签名。对于消息格式， RosettaNet 为在 PIP 执行时进行交换的操作消息分配 XML DTD 和 Message Guideline 。要注意， RosettaNet 联盟旨在使用 W3C XML-Schemas 来定义未来的 Action 和 Signal 消息的结构。

活动（ Activity ）是贸易合作伙伴（更确切地说，是在 BOV 中定义的贸易合作伙伴角色）之间业务信息的交换。例如，可以将一对贸易合作伙伴视为 Buyer 和 Seller 。 Buyer 可以向 Seller 请求报价，而且该活动被正式命名为“ Request Quote ”。在 Activity 过程中进行交换的 PIP 模型的 BOV 中，每个 Action 都映射到 Business Document 。 PIP 规范的早期版本包括了对等网络组件间的通信请求。从 RNIF 2.0 起，情况与以往不同了，这些方面可以从 PIP 规范的 BOV 和 FSV 部分派生。

 

RNIF

RosettaNet Implementation Framework (RNIF) 设计用于辅助电子商务系统实现者和解决方案提供者，他们需要创建或实现协同执行 RosettaNet PIP 的可互操作的软件应用程序组件。通过遵守 RNIF 规范，这些团体可以确保其应用程序能与经营同一业务的贸易合作伙伴进行集成。RNIF 定义 PIP 的打包、身份验证、授权、加密和非拒绝性要求。RNIF 2.0 还介绍传输独立性的概念：这确保 RosettaNet Business Message 必须以与发送者生成它们的完全相同的方式交付给贸易合作伙伴。 当前， RosettaNet 为 HTTP 和 SMTP传输协议指定传输绑定和其他细节。将来，其他实现也将受支持，不过到那时，开发人员应意识到使用其他协议将被认为不符合 RosettaNet 。为了确保所有贸易合作伙伴都能支持至少一种传输协议，HTTP 传输协议必须可用于所有解决方案提供者。RNIF 2.0 的核心是 RosettaNet Business Message 规范。图 2 展示了用于交换 RosettaNet Business Message 的 RosettaNet 网络应用协议栈。

RosettaNet Business Message

图 3 描述了 RosettaNet Business Message 的各个组成部分。该消息是在 RosettaNet 端点间进行交换的基本单位，而且包含 PIP （即操作和签名消息）中的各个文档及其他任何相关实体，比如标题、附件和数字签名。通过提供关于支配其创建和表现形式的规则的细节， RNIF 可以确保所有贸易合作伙伴都能理解这些业务消息。

Preamble Header实例

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Preamble SYSTEM "Preamble_MS_V02_00.dtd">
<Preamble>
<standardName>
<GlobalAdministeringAuthorityCode>RosettaNet</GlobalAdministeringAuthorityCode>
</standardName>
<standardVersion>
<VersionIdentifier>V02.00</VersionIdentifier>
</standardVersion>
</Preamble>

　　

通过 Preamble XML 文档的样本实例我们可以看到，它识别标准 (RosettaNet) 及其版本 (02.00)。 Activity 中第一条消息的发送者固定了 Preamble 中元素的值，而且这些值必须在后继消息中保持不变。 RNIF 规范声明，Preamble 的结构必须遵循 Preamble DTD。

Delivery Header实例

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE DeliveryHeader SYSTEM "DeliveryHeader_MS_V02_00.dtd">
<DeliveryHeader>
<isSecureTransportRequired>
<AffirmationIndicator>Yes</AffirmationIndicator>
</isSecureTransportRequired>
<messageDateTime>
<DateTimeStamp>20041109T145200.000Z</DateTimeStamp>
</messageDateTime>
<messageReceiverIdentification>
<PartnerIdentification>
<domain>
<FreeFormText>DUNS</FreeFormText>
</domain>
<GlobalBusinessIdentifier>012345678</GlobalBusinessIdentifier>
<locationID>
<Value>London</Value>
</locationID>
</PartnerIdentification>
</messageReceiverIdentification>
<messageSenderIdentification>
<PartnerIdentification>
<GlobalBusinessIdentifier>880123456</GlobalBusinessIdentifier>
<locationID>
<Value>Hong Kong</Value>
</locationID>
</PartnerIdentification>
</messageSenderIdentification>
<messageTrackingID>
<InstanceIdentifier>083084</InstanceIdentifier>
</messageTrackingID>
</DeliveryHeader>
Service Header实例
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ServiceHeader SYSTEM "ServiceHeader_MS_V02_00.dtd">
<ServiceHeader>
<ProcessControl>
<ActivityControl>
<BusinessActivityIdentifier>Create Purchase Order</BusinessActivityIdentifier>
<MessageControl>
<fromRole>
<GlobalPartnerRoleClassificationCode>Buyer</GlobalPartnerRoleClassificationCode>
</fromRole>
<fromService>
<GlobalBusinessServiceCode>Buyer Service</GlobalBusinessServiceCode>
</fromService>
<Manifest>
<numberOfAttachments>
<CountableAmount>0</CountableAmount>
</numberOfAttachments>
<ServiceContentControl>
<ActionIdentity>
<GlobalBusinessActionCode>Purchase Order Request Action
</GlobalBusinessActionCode>
</ActionIdentity>
</ServiceContentControl>
</Manifest>
<toRole>
<GlobalPartnerRoleClassificationCode>Seller</GlobalPartnerRoleClassificationCode>
</toRole>
<toService>
<GlobalBusinessServiceCode>Seller Service</GlobalBusinessServiceCode>
</toService>
</MessageControl>
</ActivityControl>
<GlobalUsageCode>Test</GlobalUsageCode>
<pipCode>
<GlobalProcessIndicatorCode>3A4</GlobalProcessIndicatorCode>
</pipCode>
<pipInstanceId>
<InstanceIdentifier>20041109T145200.000Z</InstanceIdentifier>
</pipInstanceId>
<pipVersion>
<VersionIdentifier>1.4</VersionIdentifier>
</pipVersion>
<KnownInitiatingPartner>
<PartnerIdentification>
<domain>
<FreeFormText>DUNS</FreeFormText>
</domain>
<GlobalBusinessIdentifier>880123456</GlobalBusinessIdentifier>
<locationID>
<Value>Hong Kong</Value>
</locationID>
</PartnerIdentification>
</KnownInitiatingPartner>
</ProcessControl>
</ServiceHeader>

Service Header 为消息提供过程上下文。它还提供以下方面的信息：消息是 Test 消息还是 Production 消息、PIP 的发起者、发起者是已知的合作伙伴还是未知的合作伙伴以及QoS协商信息（当前未使用）。

RNIF2.0 的一个新功能（RNIF 1.1 中所没有的）是支持通过集线器路由RosettaNet Business Message。 Delivery Header 使该路由变得轻松自如，而且还包含用于发送和接收贸易合作伙伴身份的元素、消息的日期和时间戳以及全球惟一跟踪 ID。消息发起者必须确保 Delivery Header 在 RosettaNet Business Message 中出现，而且必须由发起者进行添加。正如我们前面所提到的，RosettaNet Business Message 中的每一个文档都作为单独的 MIME 或 S/MIME 部分进行打包。在 RNIF 2.0 中 ，RosettaNet Business Message 的某些部分可以加密，包括 Service Content 和 Service Header 部分。为了使无访问加密 Service Header 的权限的第三方集线器能为消息进行路由，RNIF 指定，Delivery Header 不应加密。

 

字典

在过去，B2B 集成工作所面临的核心问题之一是，处理各公司在其采购过程中所使用的惟一定义的术语。这不可避免地在贸易合作伙伴之中造成了许多混淆。为了解决该问题，RosettaNet 联盟提供一个公共词汇表，以供指导电子商务之用。RosettaNet Business Dictionary (RNBD) 指定，在贸易合作伙伴之间定义业务活动的属性。该字典定义PIP Message Guideline 中的 Business Property（例如，业务地址）和 Fundamental Business Data Entity（例如，BusinessTaxIdentifier）。

RosettaNet Technical Dictionary (RNTD) 提供定义产品和服务的属性。RNTD 排除了当实现多个 PIP 时贸易合作伙伴使用各自字典的需要。 而且它不再是行业特定的，可以用在各种供应链应用程序中。 RNTD 设计用于支持生产信息的无歧义、自动化的电子交换。这通过标准化用于描述产品特征和信息的语义来实现。