CN1672158A - 使用多个传递媒体的成批通信过程 - Google Patents

Abstract

公开了一种用于经由多个传递媒体将信息成批通信给接收者的方法(100)、系统和计算机程序产品。所述传递媒体包括传真、电子邮件、水陆路邮件、SMS消息发送和归档(并适合于未来的新媒体类型)。单个接口用于接收包括一个或多个模板文档(110)和特定于每个接收者的数据(106)的、用于分配的信息(106、108、110)。通过基于所述接收者的传递偏好(122、176)，将指定的一个传递媒体(144、150、156、162、168)用于每个所述接收者，从而基于所接收信息(106、108、110)传送至少一个文档。将一个不同的所述传递媒体用于借助所述指定传递媒体向其传输失败的任何接收者，可能逐步升级(172、178)文档的传输。所述逐步升级步骤(172、178)可能取决于来自载体的关于将所述文档到每个接收者的传递的状态信息(176)。

Description

使用多个传递媒体的成批通信过程

技术领域

本发明通常涉及成批通信，尤其涉及用于使用多个传递媒体成批通信的方法和系统。

背景技术

商家、公司和机构(以下简称为始发者)出于各种原因使用与其客户、供应商和其它方(以下简称为接收者)的成批通信。一般而言，使用一个以下媒体执行所述成批通信：平信、电子邮件、传真和发送到接收者的移动电话的短消息业务(SMS)消息。

通信始发者与其接收者具有不同类型的成批通信，范围从专门销售通信到连续传递诸如发票、报表和催告通知的基本信息。一般而言，所述成批通信具有以下公共元素：

独立提供接收者信息的列表，所述列表通常必需从公司数据库或记账系统中提取；

使用文档模板的形式；

来自所述接收者列表的数据被合并、或覆盖到所述模板文档上；以及

最终的“合并”文档被传递到客户。

与接收者的通信可能始发于所述始发者的不同部门或实体，并被依据所使用通信媒体类型以不同方式执行。在执行所述各种通信时，所述始发者依据始发者是经由平信、电子邮件、传真还是SMS发送信息，使用不同接口和技术。所述始发者可能选择内部托管相关通信所需的一些或所有技术，但在其它情况下所述始发者也可能外办所述通信。

存在邮件合并软件应用，用于生成信封的地址标签，以及合并和打印信件。始发者可能还具有安装于内部的专用系统和打印部门，以管理水陆路邮件合并。邮寄机构为始发者提供了外办其水陆路邮件要求的能力。一般而言，定制手稿被写入从所述始发者的数据库提取的地图数据，并将所提取的数据覆盖到预先打印的纸面材料上。

传真机器具有存储列表并进行成批消息传递的能力。依据通信大小，可使用诸如微软Outlook的工具来执行成批电子邮件发送。所述应用使用户能够将数据库的数据字段并入微软Word文档，然后将合并后文档经由其邮件合并工具电邮给接收者列表。除了微软Outlook和微软Word之外的其它软件应用具有类似的功能。对于此领域内的软件应用而言，传真插件和传真打印驱动器等必须安装在网络或所述软件所安装的工作站上。商家或公司还提供成批传真和电子邮件业务。一些需要始发者为不同接收者提供个人化文档；其它执行始发者的数据合并。企业资源计划(ERP)和记账软件可能还支持在所述应用或软件程序包内电邮或传真的能力。然而，这通常适合于单个通信(即在商务过程内的特定点从所述程序包内部发送单个电子邮件或传真)，而不允许成批的个性化和传递。

始发者可能会使其系统适合于经由载体发出SMS消息。一般而言，这是通过使用“电邮到SMS”型服务而得以执行的，所述“电邮到SMS”型服务使得电子邮件被发送到指定地址，以特定方式格式化，然后作为SMS消息转发到移动电话。始发者可能能够成批外办SMS消息发送，但通常并不提供，或不支持第三方产品提供合并来自与其它传递机制相同的数据库的个人化数据的能力。

存在通常能够将电子邮件转发到传真或SMS的有限合并业务。除此之外，所述业务并不提供格式化和合并功能。所述业务并不允许在使用相同接收者列表和数据库时，为不同传递机制指定特定的格式化规则，且并不支持水陆路邮件作为一种传递选项。

MessagingDirect(来自ACI)提供电子快递。电子快递是一种直接的电子记账和支付解决方案。这些工具寻求以电子传递的速度、效率和灵活性组合传统的直接企业对企业的纸面交易。两者还尝试通过直接的电子商务便利流线型商业过程：数字签名、合法约束和安全递送的端到端电子交易，例如账单、报表、发票、确认书、保单。整个商务过程旨在在线交易，使得电子交易直接在商家与其客户、合伙者和供应商之间流过电子信道。所述MessaingDirect系统并不支持电子邮件、传真或水陆路邮件传递的统一接口。所述MessagingDirect产品需要所有接收者登记到所述业务。

MessageReach和传真邮件合并(来自Xpedite)具有用于不同媒体的不同供应，但并不同时个人化和传递单个接收者列表到多个媒体。

Pulse Enterprise(来自Esker软件)是另一个相似应用，但并不支持逐步升级，也不被作为ASP模型(或网络业务)提供，且不支持水陆路邮件传递。Pulse Enterprise还需要传真插件等与软件一起安装。使用Pulse Enterprise的公司必须将所述软件和硬件安装在其环境内，并管理Pulse Enterprise以及传真、SMS、电子邮件接口等。Pulse Enterprise包括一般文本识别^TM(GDR)部分。一般文本识别^TM寻求自动将文本和打印流数据转换为多种电子格式，并处理所述文档，将其传递到任何接收设备。

因此，明显存在着对于一种自动化业务的需要，所述自动化业务使始发者能够将一个成批通信业务与单个公共接口一起使用，并再利用相同的接收者数据组，从而能够经由所有现有不同媒体执行到接收者的成批通信，所述媒体包括常规或水陆路邮件、电子邮件、传真和SMS(以及其它任何将来可能会出现的新传递媒体)。此外，明显存在着对于一种自动化业务的需要，所述自动化业务使始发者能够基于每个接收者对于接收所述信息的偏好，管理消息到接收者的传递，而所述始发者无需安装和管理特定于特殊传递类型的技术，所述偏好包括如果所述信息在第一媒体上失败则如何传递所述信息。此外，明显存在着对于一种自动化业务的需要，所述自动化业务能够基于所述接收者的偏好，格式化数据，并经由单个接口将数据传递到传递媒体(传真、电子邮件、SMS、纸面和归档)的整个频谱。

发明内容

根据本发明第一方面，提供了一种用于经由多个传递媒体将信息成批通信到接收者的方法，所述传递媒体包括传真、电子邮件、水陆路邮件和SMS消息发送。优选的是，这包括扩展到未来其它新媒体类型的能力。经由单个接口接收包括关于接收者的信息的用于分配的信息。所接收的信息可能包括一个或多个模板文档和特定于每个接收者的数据(包括可嵌入图像数据)。通过基于所述接收者的传递偏好，将指定的一个所述传递媒体用于每个所述接收者，传送至少一个基于所接收信息的文档。

优选的是，所述方法包括的步骤是，将一个不同的所述传递媒体用于所述指定传递媒体传输失败的一个或多个接收者的每一个，逐步升级传输所述至少一个文档。所述至少一个文档可能被转换为适合于每个接收者的所述指定一个或所述一个不同传递媒体的格式。然后可以使用所述指定一个或所述一个不同传递媒体，将格式化后文档发送到用于传输的载体。来自所述载体的关于传输的报告可能被处理为，为每个接收者提供关于所述文档传递的状态信息。而所述逐步升级步骤可能依据所述状态信息。

所述方法可能还包括步骤：将所述一个或多个模板文档和特定于每个接收者的数据(可选地包括特定于每个接收者的图像数据)合并，以为每个所述接收者提供所述至少一个文档。所述方法可能还包括步骤：为每个传递媒体确定文档模板类型，并为所述文档模板类型选择合并过程。特定于每个接收者的数据可能被提供给对应的合并过程。所述传递媒体可能包括归档，以便利接收者在未来某个时刻对所合并模板文档的附加拷贝的请求。

本发明其它方面还包括一种用于基于上述方法，经由多个传递媒体将信息成批通信到接收者的系统和计算机程序，所述传递媒体包括传真、电子邮件、水陆路邮件和SMS消息发送(并能够扩展到其它新媒体类型)。以下将详细描述本发明的这些和其它方面。

附图说明

以下将参照附图描述本发明的一些实施例，在附图中：

图1是根据本发明实施例的说明用于处理消息的过程的详细流程图；

图2是根据本发明实施例的说明用于三种不同接入方法的业务接口的方框图；

图3是根据本发明实施例的说明可插数据文件转换器的方框图；

图4是根据本发明实施例的说明文档合并器的方框图；

图5是根据本发明实施例的详细流程图，其说明用于处理接收者的偏好规则和每个接收者的对应传递媒体的过程；

图6是根据本发明实施例的说明用于基于接收者偏好逐步升级处理的过程的详细流程图；

图7是根据本发明实施例的说明用于生成合并报告的过程；

图8是根据本发明实施例的接收者用于指定传递偏好的用户接口的图像捕捉；

图9是根据本发明实施例的说明合并和传输处理的并行性和流水线操作的框图；

图10a-10c是根据本发明实施例的接收者列表XML方案的列表；

图11是根据本发明又一实施例的消息分配系统的方框图；

图12是图11系统引擎的方框图；

图13描述了模板；

图14示出了包括在接收者记录内的改发/逐步升级信息；

图15是说明转换网络接口功能的规则的表；

图16示出了可能付诸实践的屏幕上的登录；

图17示出了主屏布局的实例；

图18示出了用于观察用户的管理控制板；

图19示出了企业接口作业提交屏；

图20示出了状态报告的实例；

图21A和21B示出了作业配置控制板；

图22示出了包括FTP接口所提交的消息发送的定义的文件；

图23是消息分配系统的体系结构的方框图；

图24示出了XML格式的接收者文件的实例；

图25是数据库结构的实体关系图；

图26示出了纸面作业的配置参数的实例；

图27示出了Java_Mapping_Class_Resource记录内的一种资源类型的实例；

图28是说明作业执行流的方框图；

图29是包括成批接口、网络接口和公共接口的系统的方框图；以及

图30示出了接收者列表XML方案。

具体实施方式

公开了一种方法、系统和计算机产品，用于基于接收者的传递偏好，并引入逐步升级，经由多个传递媒体将信息成批通信给单个接收者组。优选的是，所述方法、系统和计算机程序能够将业务作为网络业务传递。此外，所述传递媒体包括水陆路邮件、电子邮件、加密邮件、传真、SMS和归档(并适合于包括未来其它媒体类型)。在下文中，阐述了大量特定细节，包括通信网络、通信协议、诸如MHTML、Postscrpt等的数据格式。但对于本领域技术人员而言，依据本公开，显然可在并不背离本发明范围和精神的情况下做出修改和/或替代。在其它情况下，本领域技术人员众所周知的细节被省略，以使本发明清晰。

在本文的语境中，术语“逐步升级”、“逐步升级”、“正在逐步升级”和单词“逐步升级”的其它形式是指改发。因此，短语“使用一个不同传递媒体逐步升级传输至少一个文档”是指使用另一媒体改发所述传输。

所述接收者尤其规定偏好借助哪个媒体传递信息。此外，所述接收者能够规定，如果使用优选媒体无法实现所述传递，则借助哪种媒体传递信息。因此，如果传递失败，则根据所述接收者的偏好逐步升级到不同媒体。优选的是，使用以面向对象方式开发的、由多个子部分构成的计算机软件实施所述过程。指向所述软件的所述用户接口优选的是被作为网络业务传递。更优选的是，所述软件应用被以Java和可扩展标示语言(XML)写。以下将立即提供概述，然后参照附图详细描述具体实施方式。

依据对于计算机存储器内的数据操作的算法和符号表示，明确或隐含说明具体实施方式的一部分。所述算法描述和表示是本领域技术人员在数据处理领域内用于将其工作内容最有效传递给本领域其他技术人员的方法。算法在本文中通常被认为是导致所需结果的有条理的步骤顺序。所述步骤需要物理数量的物理操作。一般而言，尽管并不必要，但所述数量采取能够被存储、传送、组合、比较和操纵的电或磁信号的形式。有时出于公共使用的原因，所述信号被认为是比特、值、单元、符号、字符、术语、号码等。

然而，以上类似的术语与适当的物理量相关，仅是适用于所述量的便利标签。除非特别说明，从以下清晰可见，本领域技术人员应当理解，本文使用诸如“计算”、“合并”、“计算”、“转换”、“确定”、“比较”、“生成”、“选择”、“输出”等术语的段落参考这样一种计算机系统或类似电子设备的作用和过程，所述计算机系统将所述计算机系统的寄存器和存储器内的以物理(电子)量表示的数据操纵并转换为，所述计算机系统存储器或寄存器或其它信息存储、传输或显示设备内的以物理量类似表示的其它数据。

本技术规范还公开了一种用于执行所述方法操作的装置。所述装置可能被出于所需目的而特别构造，或是可能包括通用计算机或其它由存储在所述计算机内的计算机程序选择性激活或重新配置的设备。本文所述的算法和显示并不固然与任何特定计算机或其它装置相关。各种通用机器都可与根据本文教义的程序一起使用。作为选择，更多专用装置构造为执行所需方法步骤都可能是适当的。例如，互联网目录服务器计算机可能被配置为，通过安装用于执行如下所述的计算、比较和选择步骤的计算机程序，从而将所存储的目录批量载入。

此外，本技术规范还公开了一种计算机程序产品，其包括计算机可读媒体，所述计算机可读媒体具有存储在其上的执行方法操作的计算机程序。所述计算机可读媒体此处包括任何用于在信源与目的地之间通信计算机程序的传输媒体。所述传输媒体可能包括存储设备，例如磁或光盘、存储器片或其它适合于与通用计算机接口的存储设备。所述传输媒体可能还包括诸如互联网系统内示范的硬布线媒体，或诸如在GSM移动电话系统内示范的无线媒体。所述计算机程序并不限于任何特定编程语言和实施方式。应当理解的是，各种编程语言及其编码可用于实施本文包括的公开教义。

在任何一个或多个附图中，在参考具有相同参考标号的步骤和/或特征时，为说明起见，所述步骤和/或特征具有相同(多个)功能或(多个)操作，除非出现相反意向。

为了便于参考，将借助以下子标题阐述本发明：

A.第一实施例

I.概述，

II.消息处理，

III.(多个)业务接口，

IV.可插数据文件转换器，

V.文本合并器，

VI.偏好规则过程，

VII.发射机，

VIII.载体接口，

IX.逐步升级处理器，

X.报告，

XI传输/合并的并行性/流水线技术

B.第二实施例

I.概述，

II.概念，

III.网络接口，

IV.系统体系结构，

V.数据文件结构，

VII.数据库结构，

VIII.Java映射类和XSL模板，

A.第一实施例

I.概述

根据本发明实施例的成批通信过程和系统的重要方面包括：

始发者可经由单个接口并使用单个接收者列表，执行与使用一个业务的接收者的成批通信，但可经由包括常规(平)邮、电子邮件(加密和未加密)、传真和SMS的所有当前可用媒体传递，并将文档传递到托管文档归档和检索系统(并能够扩展到未来其它媒体技术)。

可为单个接收者规定传递偏好以及逐步升级规则。例如，接收者可规定所述接收者偏好经由传真接收通信，但如果传真失败，则所述信息优选地通过水陆路邮件接收。这可在单个接收者层面以及总体层面上执行。

存在一个对所述系统的应用编程接口(API)。经由所述一个API，可使用传真、电子邮件、加密电子邮件、SMS、水陆路邮件和归档(以及其它未来可用媒体类型)执行传递。

所述过程被以组件化方式设计，以容易适合于未来类型的传递媒体的集成(例如，WAP、其它无线等)。

单个接收者列表可用于传递到所有不同的目标媒体。所述接收者列表可以是任何格式，所述过程将所述列表转换为XML。支持各种输入接收者文件格式，数据转换被执行为XML格式。

可通过将所述接收者列表内的字段用于所有不同传递媒体，执行合并(个人化)。这包括个人化SMS文本消息、电子邮件主体和主题文本、以及Word、便携式文档格式(PDF)、超文本标示语言(HTML)和MIME-HTML(MHTML)的文档合并。MIME表示多目的互联网邮件扩展。通过将XML文档格式和XSL和XSL-FO样式表用于数据格式化和说明来支持文档合并。

所述业务管理所有到包括水陆路邮件邮寄商店的载体以及托管归档业务的接口。软件不必安装在始发者处，也不必在所述始发者处管理。可以为相同的媒体类型支持不同的载体，而始发者可能规定其优选载体。

提供了传递结果的集成报告，包括关于已发生的逐步升级的报告，以及所有接收者通过不同媒体类型的成功/失败。提供了一种集成报告接口，其使得用户能够浏览单个接收者的消息发送和逐步升级状态。

所述过程被设计用于“成批邮件发送”情况，其中以类似于其中大量接收者被常规水陆路邮件邮寄店作为目标的方法的方式，大量接收者被作为目标。

所述过程或系统使用以下一个或多个技术，以提供在其它消息发送业务中尚未发现的特征：

所述过程识别与接收者通信所需的公共单元，并逐步升级XML文档内的那些单元。所述单元包括接收者的传递偏好和一组逐步升级准则。使用简化符号规定所述传递偏好和逐步升级准则。专有XML方案还被定义为描述XML文档格式。

所述过程提供了一种可远程接入的安全电子接口或公共接口。所述单个应用编程接口(API)以一致方式支持所有形式的消息发送。所述公共接口可由文件传送协议(FTP)或简单对象访问协议(SOAP)接入。所述接口还可经由网络用户接口接入。

所述业务提供数据合并(个人化)能力，以使所述业务能够将接收者数据合并为各种文档格式，包括PDF、HTML、MHTML、微软Word和文本。所述业务优选地使用可扩展样式表语言格式化对象(XSL-FO)格式化引擎，来执行所述数据合并。所述个人化能力包括个人化电子邮件消息以及经由SMS发送的消息的主旨和主体文本。

所述API支持一种用于规定数据转换器的机制。所述业务具有安装在其内的专用码，其能够动态写和插入定制数据转换器。所述数据转换器取得任何格式的接收者数据(即从机构的记账或ERP系统提取)，并将所述接收者数据转换为公共XML格式，以馈入消息发送引擎。

所述业务管理以下所有载体接口：SMS、电子邮件、加密电子邮件、传真、常规(平)邮和归档。这是通过在所述系统内具有独立的代码层来执行的，所述代码层将公共载体接口提供给剩余的消息发送引擎。这还能够使未来的媒体类型能够容易地并入所述业务(例如WAP)。所述业务还可存储所述始发者可能具有的关于载体选择的偏好。

所述业务将所述一个单个组的输入数据重复用于所有不同的文档模板和传递媒体类型。所述业务通过执行一个模块或部分内的文档合并，以及格式化以显示给独立模块内的载体接口来执行上述重复利用。

所述业务通过获取从所述载体接收回的不同类型的报告，并将所述报告转换为存储在相关数据库内的公共格式，将单个、集成的报告接口提供给所述用户。所述业务然后相对于单个消息接收者协调这些传递报告，以便跟踪传递并驱动逐步升级进程。这使得所述业务能够将关于单个消息成功和失败的报告提供给所述用户，并显示已为单个接收者设置的逐步升级路径。

所述业务还被以能够实现大量消息发送吞吐量的方式实施。所述业务通过将所述合并过程内的步骤分为不同部分来执行所述大量消息发送。所述部分然后被同时执行，从而使得许多不同步骤得以同时执行。

II.消息处理

图1示出了可在软件内实施的消息发送过程100。处理在步骤102内开始。在步骤104中，经由API接收接收者数据文件106、jobDescriptor.XML 108和模板文档110。以下将详细描述jobDescriptor.XML 108的细节。在步骤112中，所述作业参数被处理，而数据文件被输入。在步骤114中，进行检查以确定是否已指定数据转换器。如果步骤114返回真(是)，则处理在步骤116内继续，并装载所指定的客户转换器。在步骤118中，使用所述客户转换器将所述数据转换为XML，处理然后在步骤120内继续。如果步骤114返回假(否)，则处理在步骤120内继续。

在步骤120中，验证并语法分析XML接收者列表，然后将所述XML接收者列表存储到数据库。这生成了所存储的接收者数据和传递偏好122。在步骤124中，接收者传递偏好被处理，并被分为不同媒体类型束。在步骤126中，进行检查以为每个媒体类型确定文档模板类型，并选择对应的文档合并器。所述文档模板对于特定媒体类型的所有接收者而言都是相同的。所述文档合并器获取每个单个接收者的数据，并将所述数据合并为文档模板，以为所述接收者生成个人化文档。所述文档模板可能是XSL模板。作为选择，支持MS Word模板和HTML模板。这是“模板类型”。依据所述模板类型，装载不同的文档合并器(XSL-FO合并器、MS Word合并器、HTML合并器等)。从步骤126开始，可能执行一个或多个若干合并步骤或操作。所述合并步骤包括文本合并128、PDF合并130、Postscript合并132、HTML合并134和微软Word合并136。本领域技术人员应当理解，依据本公开，在并不背离本发明范围和精神的情况下，可实践其它类型的合并。接收者数据138被提供给合并步骤128-136。

处理从每个步骤128-136继续到步骤140。在步骤140中，进行检查以为接收者选择传递载体。这得以执行，是通过重新检查先前处理接收者传递偏好步骤124的结果，并结合为所述作业始发者配置的每个媒体的优选载体。所述两条信息的组合被用于判定将使用的载体模块。如果将发送传真，则处理继续通过包括步骤142-144的路径。如果将发送电子邮件，则处理继续通过包括步骤148-152的路径。如果将发送水陆路邮件，则处理继续通过包括步骤154-158的路径。如果将发送SMS消息，则处理继续通过包括步骤160-164的路径。如果将归档所述文档，则处理继续通过包括步骤166-170的路径。

对于传真路径而言，合并后的文档在步骤142内被转换为位图格式，优选为TIFF。在步骤144中，所述TIFF格式文档被发送到用于传输的传真载体。在步骤146中，处理并语法分析所生成的传真载体报告。在所述接收者列表上设置传输状态。处理然后继续到步骤172。

对于电子邮件路径而言，在步骤148中，在需要时将合并后的文档转换为MHTML格式。通常，无需转换为MHTML，因为所述文档保持为PDF、HTML或微软Word附件。在步骤150中，包括作为附件或作为嵌入MTHML的文档的电子邮件消息被发送到用于传输的电子邮件载体。在步骤152中，处理并语法分析所生成的电子邮件载体报告。在所述接收者列表上设置传输状态。处理然后继续到步骤172。

对于水陆路邮件路径而言，在步骤154中，在需要时将合并后的文档转换为Postscript格式。在步骤156中，所述Postscript格式文档被发送到用于传输的常规水陆路邮件载体。在步骤158中，处理并语法分析所生成的水陆路邮件载体报告。在所述接收者列表上设置传输状态。处理然后继续到步骤172。

对于SMS消息路径而言，在步骤160中，在需要时为SMS格式化合并后的文档。在步骤162中，所述SMS格式文档被发送到用于传输的SMS载体。在步骤164中，处理并语法分析所生成的SMS载体报告。在所述接收者列表上设置传输状态。处理然后继续到步骤172。

对于归档路径而言，在步骤166中，在需要时格式化合并后文档，以便归档。所述格式通常为PDF或Postscript，然而所述归档系统并不限于任何特定格式，因此所述格式取决于始发者的偏好。在步骤168中，格式化的文档被发送到所述归档系统。在步骤170中，处理并语法分析所述归档系统所生成的报告。在所述接收者列表上设置传输状态。处理然后继续到步骤172。

在步骤172中，如果需要，依据接收者列表状态和传递偏好176处理逐步升级。在步骤178中，进行检查以确定是否需要任何逐步升级。如果步骤178返回真(是)，对于为其发生逐步升级的接收者，处理继续到步骤174。否则，如果步骤178返回假(否)，则处理在步骤180中终止。

此处引入作为参考的澳大利亚临时专利申请No.20029050435的在图11和11A-11M的类图内描述了用于提供图1过程100的软件体系结构。在澳大利亚临时专利申请No.20029050435内，图11描述了图11A-11M各部分的布置。类图提供了应用体系结构，以及构成应用的各部分的详细描述。所述部分包括逐步升级处理、状态处理、作业提交和处理、合并、格式化和载体传输。所述方案通信所述体系结构的若干方面。

以下将详细描述所述过程的其它方面。

III.(多个)业务接口

本发明实施例优选地被提供为托管业务，通常被称为应用业务提供商(ASP)模型。优选的是，三种不同的接入方法用于接入托管业务，并分别由三种不同接口部分支持。在图2内描述了所述业务接口200，其包括网络业务接口(SOAP)210、FTP接口212和网络图形用户接口(基于浏览器/HTML)214。所述三种外部接口部分210、212和214都使用相同的基础公共接口部分216，优选的是XML。

网络业务是通用描述、发现和集成(UDDI)和网络服务定义语言(WSDL)标准所描述的正式接口。所述托管业务提供了一种符合于此标准的接口210。FTP(文件传送协议)是用于经由互联网传送文件的公共协议。所述托管业务提供了FTP接口212，因为所述接口212是众所周知的、始发者容易接入的接口。所述网络图形用户接口214被用于使始发者能够经由图形用户接口手动地提交作业。

各种接口210、212、214是轻便的，将数据整理为公共格式，以提交给如图2所示的基础公共接口216。所述接口参数作为XML被传送。XML方案已被定义为描述作业。所述方案提供了一种用于为不同媒体提供不同文档模板、并为特定作业规定其它偏好的机制。表1示出了图1的所述公共XML作业描述文件(“JobDescriptor”XML)108的格式，包括所述XML方案内的重要标志。

表1

标志           描述

<job_type>    job_type标志允许设置总体作业类型，定义所有接收者经由其发送消息的媒体。所述标志优先于预计与即将发生的逐步升级功能一起使用的transmission_rules标志，从而允许一组传输规则作为在作业层而非接收者层的逐步升级规则而被提供。

所支持的作业类型包括：

 <job_ype>FAX ONLY</job_type>

<job_type>EMAIL ONLY</job_type>

<job_type>FAX AND EMAIL</job_type>

<job_type>FAX AND EMAIL AND SMS</job_type>

(…等——允许媒体的所有组合)

<job_type>LIST PREFERENCE</job_type>

                  LIST PREFERENCE作业类型使用在接收者层面上设置的传输规则。详见RecipientData.xml。

<transmission_rules>transmission_rules标志允许在作业层上定义一组传输规则。所述规则适用于所述特定作业的所有接收者，例如

<transmission_rules>f：e</transmission_rules>

<fax_template>          传真模板标志允许为出于传真传输目的生成的文档定义模板，例如<fax_template>AcmeRelativeImage.xsl</fax_template>

<email_template>        电子邮件模板标志允许为出于电子邮件传输目的生成的文档定义模板，例如<email_template>AcmeRelativeImage.xsl</email_template>

<paper_template>    纸面模板标志允许为出于经由传统信件发送目的生成的文档定义模板，例如

<paper_template>AcmeRelativeImage.xsl</paper_template>

<emai_body_template>电子邮件主体模板允许包括文本电子邮件主体，所述电子邮件主体被经由电子邮件媒体发送到所有接收消息发送的接收者。所述标志包含作为电子邮件主体包括的文本数据。所述标志可能包括被定义的合并字段<<ff(merge_field_name)>>。所述合并字段标志的生成是通过按下alt键并键入0171来生成<<以及0187来生成>>，例如

<email_body_template>

Dear<<ff_fistname>>，

请找到包括的、您对月<<ff_month>>的陈述。

致意

<<ff_creditmanager>>

</email_body_template>

<emai_subject_template>电子邮件主题模板允许包括文本电子邮件主题，所述电子邮件主题被经由电子邮件媒体发送到所有接收消息发送的接收者。所述标志包含作为电子邮件主题包括的文本数据。所述标志可能包括被定义的合并字段<<ff(merge_field_name)>>。所述合并字段标志的生成是通过按下alt键并键入0171来生成<<以及0187来生成>>，例如

<email_subject_template>

请找到被包括的您对<<ff_monty>>月的陈述。

</email_subject_template>

<sms_template>    电子邮件主题模板允许包括的SMS消息主体被发送到接收者。所述标志包括作为SMS主体发送的文本数据，并可能包括被定义的合并字段<<ff_(merge_field_name)>>。所述合并字段标志的生成是通过按下alt键并键入0171来生成<<以及0187来生成>>，例如

<sms_template>

您<<ff_monty>>月的陈述已被电邮给<<ff_emailaddress>>，

</sms_template>

<associated_image>相关图像标志允许包括可能必需作为文本合并一部分的0-n个图像，例如<assicuated_image>Acme.gif</associated_image>

<recipient_list>     接收者列表标志定义用于提供所有接收者细节和合并数据的所述接收者数据。更多信息请详见RecepientData.xml，例如<recipient_list>AcmeSmall.xml</recipient_list>

IV.可插数据文件转换器

使用托管业务的始发者将包括关于作为目标的接收者的信息作为特定成批通信的部分提交。所述文件可能是从内部数据库或商家、机构等的记账系统中提取的。本发明实施例标准化XML输入文件，因此数据转换300将接收者列表文件310转换为图3所示的XML 314。例如，所述接收者列表文件310可能是文本或平面文件。这是使用数据文件转换器312来执行的，所述数据文件转换器优选的是使定制的转换器能够被插入基础平台的组件。于是，所述输入文件的转换对于所述业务的用户而言是透明的。在本发明实施例中，数据转换被实施为：

Java接口被定义为CustomMapperInterface

所述Java接口具有以下所定义的方法：

             ConvertFile(Hashmap hm，Destination d)

所述JobDescriptor.xml输入文件具有指示是否使用客户映射器的“CustomlJavaMapping”标志，可规定转换类别的“CustomJavaClassName”标志，以及可规定文件名的键控组的“JavaMappingFile”标志。

所述作业处理引擎使用Java的反射能力，以例示所述客户Java转换器类别，并将JavaMappingFile参数传递到Hashmap内的客户Java转换器类别。

所述客户Java类别然后处理文件参数，并生成转换后文件。

V.文本合并器

本发明实施例格式化数据，以传递到不同类型的媒体。图4示出了如何相应地处理文档合并400。所述XML接收者列表410(对应于图3的列表314)和XSL或XSL-FO模板412被提供给文档合并模块或部分414，以便以所需格式，优选的是PDF或HTML，生成文档416。为了执行所述说明格式化，所述XSL和XSL-FO标准被用于定义用于格式化和XML数据说明的规则。所述文档合并模块或部分414将所选择XSL或XSL-FO模板412应用于基础XML接收者列表410，以生成传输到所述用户的PDF或HTML文档416。

为了使单个接收者列表能够用于基于所述接收者的传递偏好合并(个人化)和传递数据到各个不同媒体，图10a、10b和10c定义和示出了特定XML接收者列表方案1000。尽管图10示出了一种特定方案，但本领域技术人员应当理解，依据本公开，在并不背离本发明精神和范围的情况下，可对此方案做出修改和/或替换。所述方案1000被分为两个主要子部分：

1.传输规则组，其描述不同媒体的接收者的寻址和偏好准则。

2.接收者数据部分，其包括被合并到所传送文档内的数据。可根据我们的XML方案构造所述接收者数据部分。作为选择，提供了一种XML数据子单元类型，其允许始发者根据其自己的XML方案构造这部分接收者数据。

VI.偏好规则处理

本发明实施例允许通过将特定符号用于定义偏好规则，为单个接收者规定偏好规则，包括复杂偏好规则。例如，本发明实施例使用符号(F：S-P)来表示发送传真和SMS，且如果两者都失败，则借助水陆路邮件(纸面)发送。优选的是，用户接口用于选择传递偏好，而简化符号用于规定传递偏好。表2详细示出了传递媒体类型的规则符号

表2

媒体                         符号

传真                          F或f

电子邮件                      E或e

SMS                           S或s

纸面                          P或p

语音                          V或v

归档                          A或a

加密电子邮件(密码)            C或c

将被确定的新媒体类型

为了适合于优先规则，以及将多个媒体类型组合为一个规则的能力，使用若干算符。列表偏好被规定为一系列以线(-)分隔的规则。所述线(-)指示，如果前面的规则失败，则使用下一规则。如下所述，规则可能很简单，例如规定单个媒体类型(例如F用于传真)，或以加号(+)或冒号(：)算符分隔的一串媒体类型。圆括号“(”“)”用于封装包括多个媒体类型的规则。

说明使用线(-)算符的简单优先规则的实例为：

E-F-P    (1)

此规则指示发送电子邮件(规则1)。如果规则1失败(例如，如果并未指定电子邮件地址)，则发送传真(规则2)。如果规则2失败，则经由基于纸面的媒体发送(规则3)。

如果两种媒体类型被以加号(+)算符分隔，则这表示将信息发送到两种所述特定媒体类型(无优先顺序)。如果两者都无法发送，则所述规则失败。例如规则(F+E)指示试图发送电子邮件和传真。如果既未提供传真号码，又未提供电子邮件地址，则所述规则失败。

加号(+)算符和优先算符(-)的组合的实例是

(E+F)-P(2)

此规则指示发送传真和电子邮件。如果这两种媒体都失败(例如，因为未指定传真号码和电子邮件地址)，则线(-)算符发挥作用，处理移至指示以纸发送所述文档的下一规则。

如果两种媒体类型由冒号(：)算符分开，则这指示发送到两种特定媒体类型(无优先顺序，即与加号(+)算符相同)。然而，如果无法发送到其中一个媒体，则此规则失败。例如，(F：E)指示试图发送电子邮件和传真。如果未提供传真号码，或未提供电子邮件地址，则此规则失败。冒号(：)算符与优先算符(-)组合的实例是：

(E：F)-P(3)

此规则指示发送传真和电子邮件两者。如果一种媒体失败(例如，因为未指定传真号码或电子邮件地址)，则线(-)算符发挥作用，处理移至下一规则，其指示以纸发送所述文档。

各个算符的优先顺序如下：()，+，：，-。首先评估圆括号，在冒号(：)之前评估加号(+)算符，这些都在线(-)之前评估。解释使用所有不同算符，并说明优先规则如何作用的复合规则的实例为：

(E：F+S)-(P：V)    (4)

在这种情况下，圆括号具有优先级，因此首先评估规则(E：F+S)。加号(+)的优先级紧随圆括号，因此然后评估规则F+S。这指示将信息发送到传真和SMS。然后评估“：”，因此接着评估规则E：“F+S”。这指示将信息发送到电子邮件和“F+S”(这指示发送到传真和SMS)。所述信息被发送到电子邮件、传真和SMS三者。如果规则(F+S)失败，则这是因为传真和SMS都失败。规则E：“F+S”的失败发生是因为电子邮件或“F+S”都失败。如果整个第一规则E：“F+S”失败，则线(-)算符发挥作用，实践下一规则(P：V)。所述规则(P：V)指示将信息发送到纸面和语音。总而言之，实例(4)的规则指示将信息发送到电子邮件、传真和SMS媒体。如果电子邮件失败(例如未指定电子邮件地址)，或SMS和传真都失败(例如无SMS和传真号码)，则所述信息被发送到纸面和语音。

在本发明实施例中，用户接口部分或模块允许快速输入简单传递组合，同时提供输入复合规则的选项。图8所示的用户接口部分800被授权广播选项，并包括用于每个媒体类型，包括传真、电子邮件、SMS、语音和纸面，的若干记号框符(tick box)802。单选按钮804被用于发送到所有媒体，并使用列表偏好。用户可指定以框符文本条目806(例如(E+S)-F-P)跳过所述列表偏好的规则。

偏好规则处理器解释接收者偏好，并为每个接收者确定发送到哪个传递媒体。图5示出了一种用于处理偏好规则的方法500。XML格式的接收者数据510被提供给步骤512，其依据具体情况装载第一或下一个接收者的偏好规则数据。在步骤514中，处理从先前处理结束的位置开始。在步骤516中，进行检查以确定是否为处理保留了更多的字符。如果步骤516返回假(否)。则规则处理的当前一轮在步骤548中结束。否则，如果步骤516返回真(是)，则处理在步骤518中继续。

在步骤518中，依据表示优先算符或媒体符号的字符实施执行分支。如果步骤518确定“(”或“)”，则处理继续到步骤520。在步骤520中，进行检查以确定包括何种圆括号类型。如果在步骤520中确定“(”，则处理继续到步骤522，并记录开括号(open parathensis)。否则，如果在步骤520中确定“)”，则处理继续到步骤524。在步骤524中，记录闭括号(close parathensis)，并生成一组先前规则组。从每个步骤522和524开始，处理继续到步骤516。

如果步骤518确定当前符号为字母(F，E，S，P，A，C)，则处理继续到步骤526。在步骤526中，进行检查以确定所述字母为F、E、S、P、A还是C。如果步骤526返回F，则处理继续到步骤528，接收者被加入传真列表。如果步骤526返回E，则处理继续到步骤530，接收者被加入电子邮件列表。如果步骤526返回C，则处理继续到步骤532，接收者被加入加密电子邮件列表。如果步骤526返回P，则处理继续到步骤534，接收者被加入水陆路邮件(纸面)列表。如果步骤526返回S，则处理继续到步骤536，接收者被加入SMS列表。如果步骤526返回A，则处理继续到步骤538，接收者被加入归档列表。从每个步骤528、530、532、534、536和538开始，处理继续到步骤516。

如果步骤518确定当前字符是算符“：”、“+”或“-”，则处理继续到步骤540。在步骤540中，进行检查以确定哪个算符为当前字符。如果步骤540返回“-”，则处理继续到步骤542，记录“-”符号之后的位置。处理然后继续到步骤548。如果步骤540返回“-”，则处理继续到步骤544，并记录“-”(OR)算符。处理继续到步骤516。如果步骤540返回“+”，则处理继续到步骤546，并记录“+”(AND)算符。处理然后继续到步骤516。

VII.发射机

所述发射机执行数据的最终转换，以显示给载体接口。例如，对于传真，从文档合并过程输出的PDF文档被转换为Tiff文件，以显示给传真载体。所述系统允许不同发射机被插入适合于不同载体的地方。

VIII.载体接口

所述载体接口执行最终的数据转换，以及批处理为特定于载体的文件格式，以传输到为特定媒体类型所选择的载体。可能为不同载体接口插入备选载体，而载体的选择可能被动态配置为始发者的用户简表的一部分。

IX.逐步升级处理器

所述逐步升级过程检查来自所述载体接口的响应，并语法分析每个接收者的传输结果。如果传输失败，则逐步升级过程使用接收者的偏好规则(经由偏好规则处理器)来确定是否经由不同媒体重试通信，并管理重新计划经由不同媒体传输数据的活动。图6的流程图示出了逐步升级处理600，尤其示出了电子邮件的逐步升级规则如何工作(电子邮件是最复杂的)。对于其它媒体类型而言，所述逐步升级简单地基于从载体接收回的成功/失败报告。

在图6中，处理在步骤610中开始，其中尝试将电子邮件发送到所述载体。在步骤612中，进行检查以确定是否由于未知SMTP服务器而发生错误。如果步骤612返回真(是)，则处理在步骤624继续。如果步骤612返回假(否)，则处理继续到步骤614。在步骤614中，进行检查以确定退回的电子邮件是否到达托管业务处的始发者的(客户的)收件箱(Emdirect)。如果步骤614返回真(是)，则处理继续到步骤622。在步骤622中，始发者人工指示发往接收者的电子邮件传递失败。这优选的是经由网络接口得以执行。处理然后继续到步骤624。如果步骤614返回假(N)，则处理继续到步骤616。

在步骤616中，进行检查以确定电子邮件打开期限是否已到期。如果步骤616返回假(否)，则处理继续到步骤618。在步骤618中，处理等待，直至期限到期，然后处理继续到步骤616。如果步骤616返回真(是)，则处理继续到步骤620。在步骤620中，进行检查以确定电子邮件跟踪是否显示所述电子邮件已打开。如果步骤620返回真(是)，则处理在步骤632终止，并不执行逐步升级。如果步骤620返回假(否)，则处理继续到步骤630。

在步骤624中，进行检查以确定逐步升级是否需要始发者的批准。如果步骤624返回假(否)，则处理继续到步骤630，并逐步升级到下一媒体类型。否则，如果步骤624返回真(是)，则处理继续到步骤626。在步骤626中，进行检查以确定是否已提供始发者批准。如果步骤626返回假(否)，则处理继续到步骤628。在步骤628中，等待经由网络接口的人工始发者批准事件。处理然后继续到步骤626。如果步骤626返回真(是)，则处理继续到步骤630。以下将阐述过程的其它细节。

所述逐步升级处理提供了以下功能：

提供作为额外选项的逐步升级功能(在用户层上被配置)、并相应收费的能力。

在作业层上指定特定作业是否需要逐步升级的能力。

当在作业提交时选择“列表偏好”时，根据接收者的传递偏好逐步升级工作的能力。

如果使用广播选择，而非“列表偏好”，逐步升级以遵循所指定选择的能力(例如，电子邮件+传真+纸面，首先尝试电邮到所述接收者，然后如果电子邮件失败，则实施传真，如果传真失败，则实施纸面)

始发者人工干预所述逐步升级过程，并人工指示将处理或不处理哪个逐步升级的能力。

用户人工地将电子邮件标志为需要逐步升级的能力(因此始发者可了解到达的退回，然后前去网址，并将其标记为需要逐步升级)。

对于不同媒体类型而言，逐步升级准则如下。对于一些媒体类型而言，已描述了备选机制。当备选方案可用时，始发者选择始发者可能应用哪个逐步升级准则。这被配置为始发者的用户偏好的一部分。

如果在预先规定数量的重试之后无法发送传真，则逐步升级可能会发生。这可能归因于各种原因，从无效的传真号码到网络难以连接(NCN)到指定的传真机。

如果在预先规定天数内，接收者未跟踪到电子邮件为打开，则可能发生逐步升级。可能不会执行电子邮件退回的自动处理，但可能提供一种功能，由此作业提交者可人工指示特定电子邮件并未被成功发送(经由网络接口)。如果无法联系到SMS号码(号码无效)，则逐步升级可能会发生。这取决于这种级别的报告是否可由移动业务提供商提供。

如果无法成功读出水陆路邮件地址的条形码，则逐步升级可能会发生。无法读出水陆路邮件地址的条形码，可能出于各种原因——例如可能没有邮政编码或邮政编码无效，或特定街道的街道号无效。

以下字段在用户配置屏上可用于存储以下与逐步升级相关的用户偏好：

如果无打开记录则逐步升级电子邮件吗？

如果以上为是，则在逐步升级之前电子邮件必需未打开多少天？

需要将电子邮件人工标记为需要经由网络接口逐步升级的能力吗？

在任何逐步升级实际发生之前需要人工干预吗？

对于已配置“逐步升级”的始发者而言，所有经由网络接口提交的作业自动开启逐步升级。逐步升级根据所选择的广播偏好继续，或如果列表偏好被选为广播偏好，则逐步升级根据单个接收者的列表偏好继续。

对于已配置逐步升级的始发者而言，经由JobDescriptor.XML文件内的FTP接口可得到附加选项。这是“逐步升级”标志。如果“逐步升级”标志被设置为“Y”，则逐步升级适用于所述作业。根据所选择的广播偏好继续逐步升级，或如果列表偏好被选为广播偏好，则根据单个接收者的列表偏好继续逐步升级。

作业处理引擎跟踪每个接收者的传递状态，并在接收者的逐步升级事件发生时(例如接收到坏的传真报告，或电子邮件在X天内未打开，或用户人工标记特定作业需要逐步升级)，使接收者沿着逐步升级路径移动。

可能经由网络接口设置逐步升级电子邮件的人工标记。在提交作业之后，始发者能够搜索所述作业，然后选择“增加电子邮件逐步升级”按钮。这为所述始发者提供了所有电子邮件接收者的列表，而所述始发者能够检查与所述始发者希望逐步升级的任何接收者邻近的“逐步升级”框符。此显示屏的目的主要是适合于所述始发者已接收到电子邮件退回，因此希望人工指示需要逐步升级的情况。此功能还适合于其它情况，其中始发者/发送者已预先了解所述接收者将不会接收电子邮件(例如——电子邮件到财务部，但了解到规则的电子邮件联系在度假，因此希望发送传真/信件，从而使得其替身接收到传真/信件)。

逐步升级状态：在提交作业之后，用户可在任何时候搜索作业，然后观察所有所述接收者的当前状态，以及所述接收者已逐步升级或正在等待始发者批准继续逐步升级。还示出了逐步升级的原因(例如“3次重试之后传真失败”，“5天内电子邮件未打开”，“街道地址的街道号码无效”，“人工标记为逐步升级”等)。

逐步升级处理：根据逐步升级状态屏，如果始发者已在其简表内配置“人工干预”，则始发者能够选择“过程逐步升级”功能。这显示等待逐步升级的接收者的列表。对于任何已发生逐步升级事件的接收者而言，存在着靠近于接收者状态行的“继续”检查框符。所述始发者能够标记(经由“标记所有”按钮)始发者希望继续为其逐步升级的一些或所有接收者，然后按下“继续所选择逐步升级”按钮。

消息重试：根据逐步升级状态屏，所述始发者还能够选择“重试消息”功能，其显示等待逐步升级的接收者列表。除了逐步升级之外，所述始发者能够相对于特定接收者选择“重试”或“以修改后地址重试”。如果选择“以修改后地址重试”，则首先将提示修改后传真号码、电子邮件地址或水陆路邮件地址的屏显示给所述用户。对于这两种选择而言，应用然后继续尝试使用旧的或更新后细节重新发送到所述接收者。所述用户可为其希望重新发送到的每个接收者执行所述进程(每次执行一个)。如果重新发送尝试成功，则将不再处于逐步升级状态。如果重新发送尝试失败，则接收者回复到等待逐步升级状态。只要选择“以修改后地址重试”，就还向始发者电邮原件的拷贝，以及修改后细节，以提醒始发者更新其自己的数据库。

当一组接收者的逐步升级事件发生时，(归因于接收到显示失败的传真状态报告，或用于指示电子邮件需要逐步升级的“打开”期限到期)，电子邮件被发送到提交所述作业的始发者。如果始发者已配置“人工干预”选项，则所述始发者然后能够前进到网络上的逐步升级状态屏，以便人工继续逐步升级。

X.报告部分

报告部分负责从载体接口接收传递报告，并将所述传递报告组合为一个公共状态格式，以存储到相关数据库内。所述报告部分还包括始发者所使用的图形接口和工具，以生成和观察集成传递报告(经由基于网络的HTML接口观察它们，或经由电子邮件接收它们)。

图7是说明如何语法分析不同载体报告、并将其存储在数据库内，以使网址能够将集成报告显示给始发者的过程700的流程图。在步骤710中，通过提交消息发送作业开始处理。在步骤712中，接收信息被存储在接收者数据的数据库内714。在步骤716中，消息被经由FTP发送到载体。在步骤718中，经由FTP从所述载体接收报告。在步骤720中，语法分析所述载体报告，并将接收者传输结果存储到数据库内。传输在步骤722中结束。从步骤720开始，所述状态在接收者数据库内被更新。

在独立但相关的过程内，用户始发者可能在步骤726内请求状态报告。所述接收者数据库内更新后的状态信息被提供给步骤726之后的步骤728。

XI.合并/传输的并行性/流水线

以这样一种方式设计托管业务，即组成合并和传递过程的子任务在可能的情况下同时运行。这种设计能够实现所述托管业务内的高吞吐量，并使托管业务能够提供其所支持的复杂逐步升级进程。图9示出了不同部分902、904、906的多个实例900如何同时操作，以使数据吞吐量流线型。具体而言，合并模块902的多个实例同时操作，并将输出提供给多个并行发射机模块904中的对应一个。所述发射机模块904反过来耦合到多个载体906中的对应一个。

B.第二实施例

I.概述

本发明实施例提供了一种方法、系统和计算机产品(网络业务)，用于基于接收者的传递偏好、并引入如果传递失败则根据接收者的偏好逐步升级到不同媒体，从而经由多个传递媒体(传真、电子邮件、SMS、水陆路邮件和归档)将信息成批通信给单个接收者组。以面向对象方式开发计算机软件，从而使得其由多个子部分构成。指向所述软件的用户接口优选的是被作为网络业务传递。

消息广播业务使用以下技术：

(A)所述系统识别与客户通信所需的公共单元，并逐步升级XML文档内的那些单元。所述单元包括客户的传递偏好，以及一组改发准则。使用唯一简化符号指定传递偏好和改发准则。专有XML方案已被定义为描述XML文档格式。

(B)所述系统提供了可远程接入和安全的电子接口。单个数据流以一致方式支持所有形式的消息发送。可经由交互式网络用户接口提供所述数据流，或通过互联网借助非交互式成批提交(借助FTP或其它协议)来提供所述数据流。

(C)所述系统支持一种用于指定数据转换器的机制。所述系统具有安装在内的专用代码，其能够动态写和插入定制的数据转换器。所述数据转换器取得任何格式的接收者数据(即从机构的记账或ERP系统提取)，并将所述数据转换为公共XML格式，以馈入消息发送引擎。

(D)所述系统提供数据合并(个人化)能力，以使所述系统能够将接收者数据合并为各种文档格式，包括PDF、HTML、TIFF、微软Word和文本。所述系统使用XSL-FO格式化引擎来执行所述数据合并。所述个人化能力包括个人化电子邮件消息的主旨和主体文本以及经由SMS发送的消息的能力。

(E)所述系统管理以下所有载体接口：SMS、电子邮件、传真、常规(平)邮和归档。这是通过在所述系统内具有独立的代码层来执行的，所述代码层将公共载体接口提供给剩余的消息发送引擎。这还使未来的媒体类型能够容易地并入系统(例如WAP)。

(F)所述系统通过获取从所述载体接收回的不同类型的报告、并将所述报告转换为存储在相关数据库内的公共格式，从而将单个集成报告接口提供给所述用户。所述系统然后相对于单个消息接收者协调这些传递报告，以便跟踪传递并驱动逐步升级进程。这使得所述系统能够将关于单个消息成功和失败的报告提供给所述用户，并显示已为单个接收者采取的逐步升级路径。

(G)所述系统还被以能够实现大量消息发送吞吐量的方式实施。通过将所述合并过程内的步骤分成不同部分来执行所述大量消息发送。所述部分然后被同时执行，从而使得许多不同步骤得以同时执行。

·(A)能够为单个接收者指定传递偏好，以及改发规则。例如，接收者可指定所述接收者偏好经由传真接收通信，但如果传真失败则借助水陆路邮件发送。

·(B)存在着一个借助其将接收者信息提供给所述系统的数据流。经由所述一个流，可经由传真、电子邮件、SMS、水陆路邮件和归档中的任何一个执行传递。

·(C)所述接收者列表可以是任何格式，所述系统将所述列表转换为XML。

·(D)可使用所有不同传递媒体的接收者列表内的字段，执行合并(个人化)(包括个人化SMS文本消息、电子邮件主体和主题文本，以及Word、PDF、HTML和MHTML的文档合并)。

·(E)所述系统管理到载体的所有接口(包括水陆路邮件邮寄商店和托管归档业务)。无需在所述始发者处安装或管理任何软件。

·(F)单个接收者列表可用于传递到所有不同目标媒体。

·(G)传递结果的集成报告，包括关于已发生的逐步升级、以及所有接收者通过不同媒体类型的成功/失败的报告。

·(H)所述系统被特意设计用于“成批邮件发送”情况，其中以类似于其中大量接收者被常规水陆路邮件邮寄店作为目标的方法的方式，大量接收者被作为目标。

·允许公司和机构使用所述一个系统，经由一个接口，并使用单个接收者列表，但经由所有当前可用媒体传递执行与其客户的成批通信，所述可用媒体包括常规(平)邮、电子邮件(加密和未加密)、传真和SMS、以及将文档传递到托管文档归档和检索系统。

·其还支持单个接收者层面以及总体层面上的传递偏好和改发规则的技术规范。

·所述系统管理到传真、电子邮件和SMS载体和常规(平)邮邮寄商店的接口。

·所述系统还支持各种输入接收者文件格式，并将数据转换为XML格式。

·所述系统通过将XML文档格式以及XSL和XSL-FO样式表用于数据格式化和说明来支持文档合并。

·所述系统已被以实现大量消息吞吐量的方式实施。

·所述系统提供了集成报告接口，所述集成报告接口使得用户能够观察单个接收者的消息发送和逐步升级状态。

所述技术作为托管业务被提供，通常被称为应用业务提供商模型，或是以完全得到许可的形式被提供。存在三种不同的方法接入所述系统，所述三种不同接入方法由两个不同接口部分支持。两个外部接口部分都使用相同的基础公共接口部分。图29是描述包括成批接口3010、网络接口3012和公共接口3020的系统3000。

A.网络图形用户接口(基于浏览器/HTML)3012

对于希望经由图形用户接口人工提交作业的实体而言，基于网络浏览器的HTML接口3012被提供给所述系统。

B.成批接口3010

支持了通过互联网的作业成批提交。这允许客户的ERP系统将作业直接发送到所述系统。FTP(文件传送协议)是用于经由互联网传送文件的公共协议。所述业务提供了作为成批接口3010的FTP接口，因为所述接口是众所周知的便于实体接入的接口。可能还使用诸如通用描述、发现和集成(UDDI)以及网络业务定义语言(WSDL)标准所描述的正式接口的其它提交接口。

C.公共接口3020

各种接口3010、3012是轻便的，将数据整理为公共格式，以提交给如图29所示的基础公共接口3020。所述接口参数被作为XML传送。

所述报告部分负责从所述载体接口接收传递报告，并将所述报告组合为一个公共状态格式，以存储在相关数据库内。所述部分还包括用户用于生成和观察集成传递报告的屏幕和工具(经由基于网络的HTML接口观察它们，或经由电子邮件接收它们)。图7示出了如何语法分析不同的载体报告，并将其存储在所述数据库内，以使所述网址能够将集成报告显示给所述用户。

为了提供一种使单个接收者列表能够被用于合并(个人化)并传递数据给各个不同媒体的机制，基于接收者传递偏好，定义了一种特殊的XML方案。图30示出了接收者列表XML方案。

关键不同点在于：

·消息分配系统是用于将消息广播到几百或几千接收者的通用产品。

·数据可被以任何电子格式提交给所述消息分配系统，包括经由许多接口的打印流，但并不仅限于此。

·所述消息可被广泛地为每个接收者个人化。

·XML技术被用于定义支持有力合并功能的复杂消息模板。

·所述消息分配系统引入了被称为数据转换器或Java映射类的有力特征。这允许所述消息分配系统接受任何格式的接收者信息。

·消息可被同时发送到传真、电子邮件、纸面或SMS。可容易地加入新媒体类型(例如PDA)。“归档”的输出媒体类型(允许输出消息被拷贝到归档)的设计正在发展中。

·每个接收者都可指定一种不同的媒体类型。因此，单个消息分配可被借助纸面发送到一些接收者，借助电子邮件发送到另外一些接收者，借助传真发送到又一些接收者，等等。

·提供了“改发”特征。如果消息无法被传递到接收者的第一选择媒体，则所述消息分配系统重试所指定的第二选择，甚至是第三选择。因此，例如，如果发往特定接收者的传真传输失败，则所述消息分配系统自动尝试借助电子邮件、纸面或其它发送。分别为每个接收者指定改发规则，或在需要时为整个作业全局地指定改发规则。

在本发明第二实施例中，如图11所示公开了电子消息广播系统。所述消息分配系统1100被特别设计为处理“一个到多个”情况，其中单个消息1110由所述消息分配系统1100(尤其是由系统引擎1120)接收，并被广播到几十、几百或几千个目的地1130。所述消息分配系统提供了将消息分别“适合于”发往每个接收者的功能。消息被经由互联网或借助专用通信链路接收和传送。

消息可能包括文本、图形、所嵌入音频/视频，实际上包括任何可电子表示的内容。

所述消息分配系统可用于广播各种信息，范围从备忘录和销售材料到发票和报表。

图12是详细说明图11的系统引擎1120的全面体系结构的方框图。互联网接口1210耦合到应用服务器1220，应用服务器1220耦合到数据库服务器1240。可使用PC硬件1232，例如使用微软Windows2000操作系统来实施应用1220。

所述应用服务器1220包括Java虚拟机1228、JDBC 1230、ApacheTomcat网络服务器1224以及JBoss应用服务器1226。所述应用服务器1220还包括含有Java程序和功能的应用软件1222。

所述数据库服务器1240包括PC硬件1246上的操作系统级(例如微软Windows 2000)、JDataConnect 1244和SQL服务器1242。

所述系统优选的是在位于安全数据中心内的计算机上运行。希望其它消息分配系统安装在其它位置的数据中心内。所述系统软件1220优选的是以Java编程语言写，并可能包括多个第三方应用程序包(其多数还被设计为用于Java平台)。所述消息分配系统使用XML标准来表示数据。

所述消息分配系统可在广泛的平台上运行，例如所述系统可在使用微软的Windows 2000的PC“应用服务器”1232、1246上运行。所述Java程序环境由Apache Tomcat网络服务器1224和JBoss应用服务器1224提供。

所有不变数据被保持在经由Java JDBC接口1230接入的另一PC“数据库服务器”1240的消息分配系统数据库内。所述数据库软件可能是微软的SQL服务器1242，其使用JDataConnect软件1244来处理到消息分配系统服务器的链接。

II.概念

所述消息分配系统优选的是被实施为专门为大量消息发送市场开发的软件。所述系统控制被称为消息分配系统引擎的消息发送计算机。

所述消息分配系统从发送者接受消息(即，文本、图形、声音/视频文件等的电子表示)，并将所述消息的拷贝分配给多个(几十、几百或几千)接收者。一般而言，发送者是某个机构，而接收者是个人或其它机构。发送者可能是客户，并由客户id识别。在此文档中，依据上下文可互换地使用术语“发送者”和“客户”。所述消息的内容可能被专门设计用于每个接收者，而消息的总体格式对于所有接收者而言一般都是类似的。例如，假设发送者是银行，消息表示每月银行报表。所述消息的总体格式(即所述银行的名称、银行的标志、栏目标题等)对于所有接收者而言都是相同的，但细节(即接收者的名称和地址、账户余额和单笔贷/借交易)对于每个接收者而言是不同的。

从发送者接受消息、并将所述消息的多个拷贝分配给接收者的整个过程被称为作业。当作业完成时，所述消息分配系统自动为发送者准备作业状态报告。所述报告总结作业的结果(即多少接收者消息被成功传递，以及多少接收者消息传递失败)，并以单个接收者为基础提供成功/失败的细节(例如尝试了多少次到特定接收者的传递，以及为何失败)。

所述消息分配系统还准备一组包括关于每个接收者消息传输结果的更详细信息的账单记录。所述账单记录被发送到计费系统，在计费系统中在月末将账单记录用于为客户开发票。

每个用户都被分配一个或多个消息分配系统账户(每个账户由账户id识别)。每个作业必须与账户相关。所述账户定义作业的特定操作特征(例如传真纸的最大尺寸、所需打印质量以及可使用的消息分配系统特征等)，且所述账户被用于计费过程，以确定对于所述作业向用户收费多少。客户通常可能会将多组适当配置的账户指配给他企业内的机构单元(成本中心、部门或其它)。

发送者通常借助在线网络接口与所述消息分配系统相互作用(即提交作业、检索作业状态报告等)。所述客户任命其机构内的特定个人来执行所述相互作用；所述个人被称为用户(其由客户内的唯一用户id识别)。用户借助诸如互联网浏览器或Netscape接入网络接口。

在一些情况下，作为网络接口的备选，用户可使用FTP文件传送将作业通过互联网提交给所述消息分配系统。在本文档的后面将讨论此选择。

接收者可经由多个由不同载体传递的不同媒体接收他的消息。所述媒体包括：

·电子邮件——所述消息分配系统将所述消息电子地发送到载体，所述载体将所述消息作为电子邮件发送到接收者的电子邮件地址，所述消息被嵌入电子邮件主体和/或作为附件。

·纸面——所述消息分配系统将所述消息电子地发送到载体，所述载体打印消息、将所打印消息置于信封内并将所述消息通过邮寄系统邮寄给接收者。

·SMS——所述消息分配系统将所述消息电子地发送到载体，所述载体将所述消息作为文本传递到所述接收者的移动电话。

·传真——所述消息分配系统将所述消息电子地发送到载体，所述载体将所述消息转发到所述接收者的传真机。

预计未来将引入其它媒体。所述系统体系结构被设计为以最小努力支持引入新媒体。可能会实施允许输出消息被发送到档案文件的“档案”媒体。

所有上述媒体可唯一寻址。所述地址被称为目的地id。

目的地id的格式对于每个媒体类型而言都是不同的。对于传真机和移动电话而言，目的地id是电话号码，对于纸面而言，目的地id是邮寄地址，而对于电子邮件而言，目的地id是电子邮件地址。因此，特定接收者可能具有以下目的地id，例如：

传真目的地id  +61 21234 5678

SMS目的地id  +61 438 987654

纸面目的地id  Mr P Jones，24 Waratah St，St Leonards，NSW，2065

电子邮件id     pioes@bigpond.com.au

使用每种媒体类型的一个目的地id。以“每个接收者”为基础指定目的地；在任何特定作业中，每个接收者可指定不同媒体和不同目的地。

为了启动作业，用户将模板文件和接收者文件提交给所述消息分配系统。作业可能需要一个或多个模板文件。模板文件仅包括单个模板。对于每个传递媒体而言，作业需要一个或多个模板。例如，处理SMS和电子邮件的作业可能需要一个模板用于SMS消息、五个模板用于电子邮件消息(一个用于电子邮件主题、一个用于电子邮件主体的文档版本、一个用于电子邮件主体的HTML版本、一个用于两个电子邮件附件的每个)。

以各种不同格式提供模板，包括Adobe Acrobat PDF(PDF)格式、TIFF图像(TIF)格式、Postscript(PRN)格式、XML样式表(XSL)格式、微软Word(DOC)格式和简单文本(TXT)格式。

每种模板描述消息的不变部分(即对于所有接收者而言都是相同的那些部分)。

特定模板类型(即仅DOC、XSL和TXT)是“可个人化”的(即，它们可选包括一个或多个“合并字段”)。XSL模板也可能附有“模板工具文件”。

·合并字段在所述模板内被称为“占位符”。每个合并字段都指示在所述消息分配系统为特定接收者生成消息时，特定于接收者的数据被插入的地方。因此，例如，模板可能包括被称为“cust_name”“account_balance”和“date”的合并字段，其可能出现在如图13所示的模板1300内。

·为说明起见，图13的实例示出了“chevron”字符划界的合并字段。这是它们实际如何出现在DOC和TXT模板内(而不是XSL模板内)。

·模板工具文件可能附带XSL模板文件。这些包括图形、声音、视频剪辑或其它多媒体文件。例如，如果银行报表消息包括标志，则所述模板文件可能附带包括适当图形的图像文件(可能被称为“BandLogo.jpg””)。

作业需要一个或多个接收者文件。当接收到所述接收者文件时，所述消息分配系统将所述接收者文件一起集中或组合为单个文件。所述文件的内容被称为接收者列表。

所述接收者列表包括许多接收者记录(通常几百或几千)。每个接收者记录都可能包括描述消息的一个预定接收者的文本。接收者记录可能包括以下信息：

·接收者信息——所述记录包括一些关于接收者的基本信息，例如他的姓名和参考代码。

·目的地id——对于每个可借助其将消息传递到所述接收者的媒体而言，都存在一个目的地id。因此，例如，如果接收者可能仅借助电子邮件或传真接收消息，则所述接收者记录仅包括电子邮件地址和传真电话号码；“纸面”和“SMS”的目的地id为空(指示无法借助邮件或SMS联系接收者)。指定目的地id不是必然意味着使用所述id。在“目的地偏好信息”内指定了用于传递特定消息的目的地id。

·合并值——接收者记录包括对应于所述模板文件内“合并字段”的“合并值”。当消息分配系统为所述接收者生成消息时，所述合并值由所述消息分配系统置于所述合并字段内。例如，模板可能包括被称为“<<account_balance>>”的合并字段，而特定接收者记录可能包括“$451.34”的合并值。当所述消息被传递到接收者时，文本“$451.34”，而非合并字段名称出现在所述消息内。

·目的地偏好信息——目的地偏好信息告知所述消息分配系统将所述消息发送到哪个目的地。

·对于每个接收者而言，最多指定数量(例如3)的传递尝试可被指定为目的地偏好信息的一部分。每次尝试都可指定到不同目的地id的最多特定数量(例如3)传输；第一次传输是主传输，而其它传输是拷贝传输。

·所述消息分配系统以第一次尝试开始。所述系统同时发送主和拷贝传输。如果所述主传输无法到达所述接收者，则所述消息分配系统进行下一次尝试。处理以这种方式继续，直至主传输已成功完成，或直至所有尝试都结束。

·以这种方式多次尝试传递主传输被称为改发。“拷贝”传输的任何失败在所述消息分配系统看来无关紧要，且并不导致改发。

·以上由图14实例示出。接收者记录1400指定图14所示的尝试和传输。所述消息分配系统首先将主传输发送给传真，并同时将拷贝发送给电子邮件。如果所述主传输(即传真)成功，则完成所述接收者的处理。

如果所述主传输失败(例如，如果传真号码占线或不可得到)，则所述消息分配系统启动尝试序号2(即，所述系统尝试将主传输发送到纸面，将拷贝发送给SMS)。这标记所述消息分配系统的处理的结束，因为并未指定第三次尝试。

III.网络接口

用户与所述消息分配系统之间的相互作用可能借助网络浏览器接口实现。为了开始与所述消息分配系统相互作用，用户简单地起动网络浏览器(例如微软的互联网浏览器或Netscape的浏览器)，并输入适当的URL。

输入所述URL在所述用户与消息分配系统引擎之间建立逻辑链接，并使图16所示的“登陆屏”1600得以显示。

以下将描述由所述消息分配系统显示的屏幕以及如何使用。

客户、用户和账户

所述网络接口允许“用户”(代表“客户”，并在消息分配系统“账户”下操作)将作业提交给所述消息分配系统，并执行其它操作。

在系统运营商的机构内，可能存在一组负责所述消息分配系统的操作控制以及支持消息分配系统的客户的工作人员。他们在本文被称为消息分配系统支持组。所述支持组具有所述系统的全面管理责任，尤其具有建立新客户使用所述系统的作业。

当所述消息分配系统支持组的成员将新客户引入所述系统时，所述组成员在消息分配系统数据库内生成以下项目：

·包括关于所述客户的信息的单个“CUSTOMER”记录，

·若干“ACCOUNT”记录，每个“ACCOUNT”记录都包括关于所述客户能够使用的账户的信息，以及

·描述管理员用户(即具有特别特权的用户)的一个或多个“USER”记录

·客户的管理员用户可能被允许生成所述客户的一个或多个标准用户(即不具有管理员特权的用户)，因此标准用户的管理在所述客户的直接控制下。然而，管理员用户可能仅由消息分配系统支持组生成。

所述消息分配系统保持与特定客户相关的信息。所述信息可能包括客户的账户信息、用户信息以及关于所述客户的用户所提交的各个作业的信息。从接入控制的角度而言，所述信息可能包括并通常形成“封闭群”。客户的用户仅可接入关于与所述客户相关的账户、用户和作业的信息。所述用户无法接入关于其它客户的信息。这是所述消息分配系统的安全要求。

这可能有一个例外。所述消息分配系统支持组可能在所述消息分配系统内以“控制”的客户id登记为“特别客户”。属于此特别客户的用户(“控制用户”)可能具有特别的权利，适合于所述消息分配系统支持组所执行的监管角色。特别地，仅对于控制用户：

·管理员用户可能得到授权，以接入和改变任何客户的客户、用户和账户信息，并将作业提交给任何客户，以及

·标准用户可能具有浏览(但不可改变)任何客户的客户、用户和账户信息，并将作业提交给任何客户，将电子邮件错误报告给任何客户的能力。

控制用户可能“模仿”任何指定客户的用户，并因而接入所述系统，如同所述控制用户正代表所述客户。当控制用户以这种方式“模仿”客户时，其被称为代理客户。

图15的表1500总结了支配允许各种类型用户执行的网络接口功能的规则。以下将提供图15所示的功能描述。

图15的以脚注“1”指示的功能是特定于客户的。为所述指定代理客户(即，所述控制用户首先指定特定代理客户，然后执行功能)执行所述功能。其它控制客户功能无需首先指定代理客户。至于图15内的脚注“2”，可能还允许用户改变其自己用户记录上，而非其它用户的USER记录上的特定字段。

登录

图16显示了可能使用的登录屏1600。所述用户可能必需将客户id、用户id和密码输入登录屏1600上。

屏幕布局

一旦用户成功登录，则图17的主屏1700被显示，并保持显示，直至用户“取消”所述屏幕。所述主屏采取左边主菜单的形式，在一些情况下，在顶端为一系列标记。图17示出了方案。

左边由主菜单占据(“主菜单”1、“主菜单”2等)。可能通过给所述选择加黑边框，突出当前所选择的主菜单选项。(图17内的“主菜单”2)

所述屏幕的顶端可能包括客户名称(其后是括号内的客户id)以及用户姓名(其后是括号内的用户id)。所述用户姓名和id识别当前登录的用户。所述客户名称和id可能指示“拥有”所述用户的客户，或如果所述客户是“控制”，则指示代理客户。代理客户和管理员用户可能被以斜体字显示。

所述屏幕的剩余部分包括对应于当前所选择主菜单项目的控制板或控制板组(即一个或多个顶端相互重叠的控制板)。在控制板组的情况下，所述屏幕顶端的标记可能用于显示(即在所述栈的顶端)所述组内的单个控制板。每个控制板都包括含有描述文本、数据输入字段、下拉菜单、单选按钮、复选框和其它工具的信息。提交或取消所述控制板或调用帮助信息的按钮可能位于所述按钮处。

管理

管理控制板组允许浏览、在一些情况下允许改变客户的USER和ACCOUNT记录。

图18示出了用于浏览用户的控制板实例。可能存在所述控制板的若干变量，一个用于正常用户，一个用于客户的(或控制)管理员用户，一个用于所述USER记录所代表的特定用户。图18示出了管理员用户可见的控制板1800。

所述控制管理员用户和客户的管理员用户可将信息输入所述控制板上的任何字段。对于多数标准用户而言，所有字段都是“只读”的。对于此记录应用的标准用户而言，除了“密码”、“联系”和“测试目的地”字段之外的所有字段都是“只读”的。

多数字段与数据库上USER记录内的字段存在“一对一”对应关系。在“所述用户可能向其提交作业的账户”的列表内的所标记项目反映所述用户的“USER_ACCOUNT_XREF”记录。

提交消息分配系统作业

用户可能使用两个接口中的一个将作业提交给消息分配系统。

·企业接口

所述企业接口通常由拥有复杂计算机系统的大企业用于跟踪和管理其客户和供应商。所述企业接口面向“基本邮件”，例如发票和报表。

·在这种情况下，消息格式趋向于复杂(并入标志和其它图形)，但并不频繁改变。这意味着适当模板的开发虽然是耗时的任务，但一旦完成就无需经常重复。

·用于企业接口客户的模板可能由消息分配系统支持组为客户的技术规范开发的。完成的模板可能然后存储于公司控制下的消息分配系统的数据库内。只要客户运行作业，所述系统就会(通过引用适当作业类型)参考所述模板，但所述模板自身并不改变，而且实际上所述客户无法修改所述模板。

·使用所述企业接口的客户可能具有包括关于其供应商、客户、职员、伙伴等的联系细节和其它信息的数据库。因此，当所述客户希望将消息经由所述消息分配系统发送到各个接收者时，所述客户可能相对于其自己的数据库运行“数据库提取”程序，以生成接收者文件。

·企业接口模板可能以XML样式表(XSL)格式存储。例外附件并不包括合并字段的电子邮件的情况可能是例外。它们可能被以Adobe Acrobat PDF格式指定。

·接收者文件格式广泛改变，但所述消息分配系统在接收时将所述文件格式全部转换为XML格式。

·作为使用所述企业接口的应用的实例，考虑每月银行报表作业。所述报表的大体格式(即标题、标志、样板、文本等)并不由银行规则地改变。所述格式可能由所述消息分配系统支持组为银行的技术规范研发的一组XSL模板文件描述。然而，报表细节(客户名称、地址、交易细节、账户余额等)每月对于每个客户是不同的。一般而言，所述报表细节由程序每月从银行的主机数据库中提取，然后被作为接收者文件转发到所述消息分配系统。

·标准接口

所述标准接口可能用于更小的不太复杂的作业。

·所述标准接口的用户可能负责准备所述用户自己的模板文件，只要所述用户启动作业就提供所述模板文件。这在所述模板相对简单(例如可使用简单字处理器准备的备忘录、新闻稿和市场活动)的情况下是实用的。在这种情况下，其对于为每个消息分配新系统作业准备的新模板文件是共同的。

·在一些情况下(即其中涉及简单的文本信息)，所述用户可经由标准接口在线输入用户的模板文件。在其它情况下，所述用户可能脱机准备模板文件(例如，以微软Word“DOC”格式)。

·接收者文件可能是“逗点分隔值”(CSV)格式，但可能由所述消息分配系统在接收时转换为XML格式。

所述标准接口特别适合于这样的客户，其希望快速生成简单备忘录或销售材料，并将所述消息广播给其客户。所述企业接口适合于稳定应用，例如报表和发票，其中所述格式持续一段时期，但在所述时期内被重复使用。

表3和4以技术术语总结了所述两个接口之间的区别。

表3

特征

企业接口	标准接口
		模板与相关图像被预定义，并存储在所述消息分配系统数据库内	借助每个作业提交模板
可合并模板为XML样式表(XSL)格式	可合并模板为微软Word(DOC)或简单文本(TXT)格式
		接收者文件可以是任何格式(但被所述消息分配系统转换为XML)	接收者文件可能是CSV格式(但被所述消息分配系统转换为XML)
可能输出到电子邮件、传真、SMS或纸面	可能输出到电子邮件、传真、SMS，但不发送到纸面

表4

模板格式

模板类型		企业接口		标准接口
						媒体	使用	可合并	不可合并	可合并	不可合并
纸面	一页或多页	XSL	-	-	-
						传真	主题页	XSL	-	TXT	-
一页或多页	XSL	-	DOC-	PDF、Postscript、TIFF
					电子邮件		主旨	XSL	-	TXT	-
	HTML主体	XSL	-	-		HTML
							文本主体	XSL	-	-	TXT
	附件	XSL	PDF	DOC		任何格式
					SMS		消息文本	XSL	-	TXT	-

发送到载体的消息的对应格式可能改变：

·每个纸面消息可能被作为postscript文件发送到所述载体

·每个传真文件可能被作为一个或多个TIFF文件(带有包括在简单文本格式的特别标题内的“主题”信息)发送到载体

·每个电子邮件消息可能被以复合格式发送到所述载体，其中：

-主旨可能被以简单文本形式编码在特殊控制文件内，

-HTML和文本主体可能被分别编码为HTML文件和简单文本文件，

-企业接口附件可能被作为PDF文件发送，以及

-标准接口附件可能被以与最初接收格式相同的格式发送。

·以上规则的一个例外是DOC格式的任何标准接口附件被以PDF格式发送到所述载体。

·所述标准接口所处理的HTML文件优选的是完全独立的(所述文件并不包括对于诸如图像文件的外部工具的参考)。

·每个SMS消息都被以文本形式发送到移动电话。

所述用户首先选择所述作业在其下运行的账户。所述“下拉”菜单可能列出所述用户得到授权使用的所有客户(或代理客户)的账户的名称。当所述用户点击“提交”时，新的控制板被显示，以反映(在所选择账户内指定的)企业接口或标准接口。

企业接口

图19示出了企业接口作业提交屏1900的布局。

·作业参考

-所述作业参考字段可能是可选的。所述用户可能输入对其有意义的作业的名称。所述名称被显示在所有与所述作业相关的报告上。

·作业类型

-此字段向所述用户提供作业类型的列表，每个所述作业类型都由对所述用户有意义的名称识别。所述用户必须从所述列表中选择一个项目。

-作业类型在所述消息分配系统数据库内表示为作业配置。每个作业配置都包括作业层信息，以及已由所述消息分配系统支持组预先准备、测试和存储在所述数据库内的模板文件和模板工具文件的集合。

·接收者文件

起初，可能向所述用户提供一个文本输入字段(带有相关“浏览”和“上传”按钮)

为了指定接收者文件，所述用户点击显示浏览窗口的“浏览”按钮。在所述用户选择所需文件之后，其文件路径显示在文本输入字段内。当所述用户点击“上传”按钮时，所述文件被上传到所述消息分配系统，并出现在“上传文件”列表内。所述用户可能以这种方式上传用户希望上传的文件量。

-在“所上传文件”列表一侧的“删除”按钮可用于删除所选择的所上传文件。

-所述消息分配系统的企业接口接受各种格式的接收者文件。所述接收者被转换为XML格式，并以这种形式保持在转换后形式数据库内。

·作业起动时间

可能向所述用户提供立即处理所述作业或将所述作业安排为在以后日期和时间起动的选项。所述“日期”字段提供了将来最多30天的选择。所述“时间”字段允许用户指定精确到时分的起动时间。

所述用户选择“提交”来提交所述作业。在提交所述作业之后，所述消息分配系统定位所述模板、模板工具以及对应于其数据库内所指定作业类型的其它作业信息。所述系统然后在需要时验证接收者文件。如果在所述验证过程期间内遭遇错误，则所述消息分配系统错误地显示接收者的细节。所述用户然后校正所述错误，并重新提交所述作业。

观察作业状态报告

用户可能在作业被提交之后的任何时间请求作业状态报告。所述消息分配系统从其数据库上的信息得到所述作业的当前状态，并将适当的作业状态报告显示在所述屏幕上(如果用户希望则用户可打印)。

图20的实例示出了使用企业接口提交的发票分配作业的全作业状态报告2000(即包括所有四个选项)。所述报告2000可能被以“打印机友好”格式(白底黑色)显示，并可能显示在新的浏览器窗口内。在所述实例内，所述消息分配系统作业id是“34656”，而所述用户所指配的作业参考是“发票3”。

所述作业被在22:21时在账户“基本邮件”下提交，而所述作业状态报告被在4小时31分钟之后生成(第二天早上2:52am)，同时所述作业仍然在“第二次尝试”阶段内(如所述“作业状态”指示)。可能的作业状态是“处理并未开始”、“尝试1正在进行中”、“尝试2正在进行中”、“尝试3正在进行中”、“完成”和各种错误状态。所述作业指定763接收者，并被经由所述企业接口提交。

所述报告的剩余部分指示生成所述报告时消息传输的状态。信息被分为三类：

·“主消息”信息涉及指定的每次尝试在接收者记录内首先进行的传输。传输主消息的失败潜在引起改发发生(即启动下一次尝试)。

·“拷贝消息”信息涉及并不触发改发的其它所有传输。

·“电子邮件附件打开”仅指电子邮件附件的打开。

在实例报告2000内，发送763个主消息，每个接收者一个。主消息中的12个失败，并引起第二次尝试。在763个主消息内，两个失败(甚至是在尝试任何指定的改发之后)。其它四个仍然未决(即已发送所述四个消息，但尚未确定传递状态)。其它94个“复制”消息被发送。在这些消息中，89个被成功传递，2个失败，3个仍然未决。

所述报告的第二和第三段指定每个单个传输的细节。每个传输状态都被以下述格式表示：

nn-mm-hh:mmd

其中：

“nn”表示如下的传输状态：

-“OK”指示成功。

-“IP”指示“正在进展中”。

-“NC”指示“未证实”(即假定OK，但未明确证实)。“NC”状态是电子邮件的特征，以下将解释。

-“两个数字”指示错误发生(数字指示失败的原因)。

“mmm”是目的地媒体(EML、FAX、SMS或PAP)，

“hh:mm”是传递或未传递的时间(或对于SMS和纸面而言，传输到载体的时间)，

“d”是字包括在消息在后续日被传递(或无法传递)情况下的上标数字。数字“1”表示下一日，“2”表示再下一日等等。

在“主消息”段内，其主消息传输失败(即使是在若干次尝试之后)，或仍然“正在进展中”的所有接收者被在报告的前端分组。其它由接收者参考排序。在“拷贝消息”段内，接收者被以相同顺序排列。所述报告的最后部分指示电子邮件附件打开的时间。每个附件都由“Xn”指示，其中“n”是识别所述段开始的图例内的附件的编号。上述报告2000仅仅是一个实例，在并不背离本发明精神和范围的情况下可实践许多改变。

作业配置(仅控制用户)

图21A和21B的作业配置控制板2100可用于控制用户，并用于在对应于作业配置的所述消息分配系统内增加、改变和删除记录群集。可能仅接入企业接口作业的作业配置。

在选择“作业配置”主菜单选项之后，显示选择的控制板，以向所述用户提供选择现有作业配置或生成新作业配置的选择。在完成所述控制板之后，显示所述主作业配置控制板2100。

图21A和21B的控制板2100显示指定作业配置的完全细节。所述信息可能被格式化为若干由水平行分开的段。每个段都可能代表所述作业配置记录群集内的一个记录。在所示的实例内，所述作业配置包括JAVA_MAPPING_CLASS记录、JAVA_MAPPING_CLASS_RESOURCE记录、COFIG_DATA记录、TEMPLATE记录以及两个TEMPLATE_ARTIFACT记录。

每个段都示出了被输入到所述记录的文件的文件名，以及所述记录内其它字段的值。所述用户可能在需要时改变字段。所述用户可能还通过使用所述“输入”按钮前的“浏览”按钮(可能调用所述用户能够从其选择将要输入的文件的“浏览”窗口)来输入新文件(代替现有文件)。作为选择，所述用户可能使用“删除”按钮来删除整个段(即删除相关记录)。

对于可重复的段而言，提供“增加一个新…记录”按钮来增加另一个空段。

在所述控制板底部的部分允许所述群集内的文件被作为ZIP档案输出到指定文件。所述文件可能被以指定目录(例如C：\JobConfigurations)存储在所述消息分配系统服务器上，并可能具有自动生成的名称，即客户名称、作业配置显示名称(即作业类型)和日期的串接。直至用户点击“提交”按钮方对所述数据库做出改变。所述删除按钮允许在需要时删除整个群集。

IV.FTP接口

在特定情况下，客户可能必需从其企业系统中生成接收者文件，并将所述文件发送到消息分配系统以便自动分配(即无需人工干预)。在这种情况下，所述网络接口可能并不适合于其需要。所述消息分配系统因此允许“企业接口”式作业被借助FTP传输通过互联网提交。所述FTP传输替代作业提交(以及相关)屏幕。所述客户、用户和账户记录应当在所述FTP传输之前正确建立。

在FTP作业提交之后，用户可能使用正常消息分配系统功能(即检查作业状态报告)，以监控所述作业的过程。

为了经由所述FTP接口提交作业，所述用户使用FTP客户程序，以将单个ZIP文件经由互联网发送到所述消息分配系统。所述传输过程可能被通过使用SSL安全来执行，并需要所述用户输入FTP“用户id”(其可能采取形式“ccccc-uuuuu”，其中“ccccc”是用户的消息分配系统客户id，而“uuuuu”是用户的消息分配系统用户id)以及FTP“密码”(其可能与用户的消息分配系统用户密码相同)。

所述ZIP文件包括以下文件：

·被称为“jobcontrol.xml”的作业控制文件；以及

·一个或多个在所述作业控制文件内指定其名称的接收者文件(见接收者文件)

图22示出了所述作业控制文件(jobcontrol.xml)2200的格式。所述文件内的多数字段是其网络接口同等物的对应部分。测试属性指定这是否为测试作业。客户可能指定唯一“作业参考”，从而使得客户可随后在“状态报告”屏幕上识别所述作业。

V.系统体系结构

以下将描述所述消息分配系统的内部体系结构，包括选择通过所述消息分配系统的主处理流。对于J2EE和Java网络容件的全面了解是理想的，但对于理解以下描述并不重要。此段有时参考数据库内的表(或“记录类型”)。它们的名称被以大写字母打印。所述记录的功能和结构的细节包括在段VII内。

图23是说明所述消息广播系统2400的体系结构的方框图。所述系统2400包括前端2410和后端2420。用户2402可使用模块2412检索作业状态报告，使用所述标准接口2414提交作业，使用所述企业接口2416提交作业，所有都在所述前端2410内。FTP文件2404可能被提供给所述企业接口2412。

在标准接口2414内，从用户2402接收信息，并上传接收者列表和模板。调用“验证”来检查接收者列表。从所述用户接收所述提交请求，并调用所述“提交”过程。

从接口2414，所述后端2420的标准作业提交处理器2424验证或检查输入数据，并提交所述作业。这包括将所述接收者列表转换为XML，并将所述作业存储在所述作业队列内。处理然后在flux模块2432处继续。

所述企业接口从所述用户2402接收作业信息，并上传所述接收者列表。通过调用所述验证过程来检查所述接收者列表。从所述用户接收所述提交请求，调用提交来处理所述请求。从所述接口2416，处理在所述企业作业提交处理器2426处继续。其通过检查所述输入数据验证所述接收者列表，并操作所述提交过程，所述提交过程将所述接收者列表转换为XML，并将所述作业存储在作业队列内。处理然后在flux2432内继续。处理器2424和2426的输出是事件。作用然后从flux2462发生。

所述作用继续到束处理器2450。模块2452为每种媒体类型建立一个传输束，然后起动每个传输束的过程束线(a、b、c和d)。所述线被描述为A、B、C和D，并分别耦合到模块2454、2456、2458和2460。每个所述模块2454、2456、2458和2460都具有类似格式。例如，所述传真传输束2454包括合并、格式化和传送操作。纸面传输束2456、SMS传输束2458和电子邮件传输束2460具有类似设置。每个束模块的输出都被提供给各自的载体，例如作为载体的expedite 2462、EDI邮局2464、SMS通达2466和message通达2468。每个载体都将状态报告提供回所述后端2420。Expedite 2462提供传真状态报告2442，EDI邮局2464提供纸面状态报告2440，SMS通达2466提供SMS状态报告2438，而message通达2468提供电子邮件状态报告2436。

所述电子邮件状态报告2436、SMS状态报告2438、纸面状态报告2440和传真状态报告2442被提供给状态收集器模块2434。所述模块2434由Flux 2434周期性调用。其检索由所述载体提供的状态信息，并将其应用于所述作业队列。所述作业队列2430具有作业和模板信息、接收者信息和状态信息。所述作业队列2430可将账单记录提供给所述计费系统2460，并将状态信息更新给所述束处理器2450。所述作业队列2430将输出提供给所述状态报告模块2422，所述状态报告模块2422检索状态信息，优选作为XML文档。所述状态报告模块2422提供由所述前端2410内的模块2412检索的作业状态报告。所述用户2402可检索使用XSL样式表格式化的所述XML状态报告，并以打印机友好格式显示所述XML状态报告。以下将更为详细地阐述这些和其它细节。

作业队列

所述作业队列2430是所述消息分配系统2400的主要部分。所述队列2430包括当前正在运行、等待运行或最近已完成的每个消息分配系统作业的细节。每个作业都由各种类型记录的群集表示在数据库内。每个群集都以JOB记录打头。所述记录包括作业自身的细节，所使用的模板，消息被发送到的接收者，合并字段和目的地。

在正常操作期间内，所述消息分配系统2400在预定时间(例如每分钟)扫描作业队列2430，并提取正在运行或最近已完成的所有作业的细节。任何正显示“控制台”控制板的消息分配系统支持组浏览器接入所述数据提取，并使用所得到的数据，以显示所述系统内作业的当前状态。这样，所述消息分配系统支持组具有作业队列2430的最新概览。

所述支持组使用“作业控制”控制板所提供的功能来影响作业的处理(例如恢复错误作业，重新传输束文件等)。因此，所述作业队列提供控制中心点，其可用于平滑所述系统2400的处理负载，迅速对客户的请求做出反应，并解决未预料到的问题，而不必从头开始重新提交用户的作业。

只要已验证所述作业，且所述用户经由处理器2424或2426提交所述作业，作业即被放置在所述作业队列2430内。所述作业保持在所述队列2430内，直至已完成所述作业之后的一段时间(以便为所述用户提供检查所述作业所生成的作业状态报告2422的时间)。其可能随后由“回收站”过程删除。

处理作业

图23示出了所述消息分配系统的高级体系结构2400。较大框2400指示所述消息分配系统自身。数据结构是模块2434、2436、2438、2440、2442、2454、2456、2458和2460，而外部实体是模块2402、2404、2460、2462、2464、2466和2468。过程由模块2412、2414和2416(servlet和JSP)以及模块2422、2424、2426、2434和2450(会话bean)描述。

所述系统2400基本上被分为两半，前端2410和后端2420，而所述作业队列2430代表它们之间的“桥”：

·所述前端逻辑2410可能由在Tomcat容件内运行的Java“JSP””和“servlet”提供。

·所述后端2420可能包括在JBoss容件内运行的Java EJB“会话bean”(其使用EJB“实体bean”和其它Java对象)。

所述前端并不直接访问所述数据库，而是调用所述后端2420内的会话bean执行。

前端

所述消息分配系统前端2410包括与处理所述用户接口相关的逻辑。所述前端2410被设计为将快速响应提供给用户2402，因此可从前端2410排除冗长处理任务。

所述前端的主要功能是接收用户2414、2416所提交的作业，并将其置于所述作业队列2430上等待处理。图示出了三个较重要的前端过程2412、2414、2416：

·经由所述企业接口2416提交作业，

·经由所述标准接口2414提交作业，以及

·请求作业状态报告2412。

可能存在其它前端过程，但为简化起见，所述过程并未包括在图23内。

每个“前端”过程(包括servlet和JSP的混合)具有执行所有其数据库检索和更新的对应“后端”会话bean。从数据库接入/锁定考虑，这允许所述前端2410通过释放servlet和JSP来提供良好的交互式响应。

Flux

只要所述前端2410将作业放置于所述作业队列2430上，所述“前端”(或更精确地说是所述前端的会话bean)触发Flux事件2432。Flux是由SIMS软件提供的事件调度工具。只要所述消息分配系统2400有效，所述调度工具即持续运行，作为Java虚拟机内的独立过程。所述工具将其自己的信息表保持在所述消息分配系统数据库内。这些由Flux2432整体管理。Flux模块2432响应于定时器或其它过程所触发的事件，并对于每个采取预定义的作用。例如，当新作业被置于所述作业队列2430上时，所述前端的会话bean定义将被立即(或如果所述用户已预定随后将运行的作业，则在某个未来的时间)触发的Flux2432的事件。当触发所述事件时，Flux2432调用所述“后端”2430内的会话bean，以处理所述事件。

后端

所述“后端”2420包括充当前端过程的“助手”的一组会话bean。所述后端会话bean执行所述前端部分需要的数据库接入操作。例如，

·EnterpriseJobSubmissionProcessroBean.java执行实施企业作业提交接口的servlet和JSP的数据库操作。

·StatusReportBean.java从实施“作业状态报告”功能的servlet和JSP所使用的数据库收集状态报告信息。

·AccountBean.java代表实施所述账户维持控制板的servlet和JSP执行ACCOUNT记录上的数据库I/O。

所述后端2420还包括执行所述消息分配系统2400的“实际工作”，即处理从所述作业队列2430得到的作业的会话bean。作业的处理如下继续：

1.所述消息分配系统2400扫描所述作业内的所有RECIPIENT记录，并为每个所述记录识别链接到第一个ATTEMPT记录的TRASMISSION记录。每个都代表消息必须被作为第一次尝试的一部分发送到的目的地。所述消息分配系统2400然后在存储器内生成若干传输束2454、2456、2458、2460(有时称为“传输分组束”)。每个目的地媒体都存在一个传输束2454、2456、2458、2460(即，一个用于传真，一个用于电子邮件等)，每个传输束包括若干传输分组。每个传输分组都包括关于带有指向所述媒体的“第一次尝试”目的地的接收者的信息。

因此，例如，如果特定RECIPIENT记录在其第一次“尝试”中指定到传真和电子邮件的“传输”，则所述接收者的细节的拷贝在所述传真传输束和电子邮件传输束内都出现。

2.所述传输束然后被在不同处理线上并行处理。每个传输束都被在三个阶段内处理：

合并阶段——来自所述接收者记录的合并值被替换为所述媒体的(多个)模板内的适当合并字段，从而为每个接收者生成完全合并消息。

格式化阶段——如果需要，将所述束内的每个消息重新格式化为适当的输出格式(例如用于传真的TIFF)。

传送阶段——每个传输束都被写入磁盘文件，然后被传送到载体(例如用于传真的Xpedite、用于电子邮件的MessageReach、用于纸面的EDI邮寄)，以向前传输到其目的地。

3.所述消息分配系统2400然后等待由所述载体提供的载体状态报告。每个载体2462、2464、2466、2468生成每个所接收传输束的载体状态报告。所述报告2436、2438、2440、2442将每次单个消息传递指示给接收者。载体状态报告的检索被称为状态收集2434。

4.所述消息分配系统2400使用各个载体状态报告2436、2438、2440、2442内的信息，以更新所述作业队列2430内的接收者状态信息(保持在所述TRANSMISSION记录内)。所述信息包括成功/失败代码、已完成的时间传输、所发送的页/字节数量等。

一旦所述第一次“尝试”的所有各种载体状态报告已被接收，并置于所述作业队列2430内，所述消息分配系统2400即再次扫描所述作业队列2430内的接收者数据。如果存在着任何发往其的第一次尝试主(即第一)传输失败的接收者，则所述作业由消息分配系统2400(通过重复步骤1到4)使用其“第二次尝试”传输来重新处理。如果所述两次尝试中的任何一次的主传输失败，则以第三次尝试传输再次重复所述过程。

在处理作业期间内或之后的任何时间，所述客户可能请求联合“作业状态报告”。这提供了所述作业细节的完全总结、接收者数量以及在此瞬间发送的每个消息的命运。可选地，当作业完成时，所述用户可将所述报告自动电邮给所述用户。所述选择被指示在账户记录内。所述消息分配系统可能生成一组计费记录(一个用于到接收者的每次所尝试的传输)，所述一组计费记录包括每次传输尝试的所有细节(即页数、所发送的字节数、成功/失败状态等)，并将其发送到所述计费系统2460，其中所述记录可能用于向客户开发票。

VI.数据文件结构

以下将描述所述消息分配系统所使用的若干数据文件的格式。

模板文件

可以各种格式提供模板文件，所述模板文件可分为两组，即包括合并字段的模板文件和不包括合并字段的模板文件。

所述第一组可能包括XML样式表(XSL)文件、微软Word(DOC)文件和简单文本(TXT)文件。

·XML样式表(XSL)文件

-XML样式表是以XML符号表示的文件，所述XML符号精确描述文档的格式(包括文本、图像、页边距、标题、页尾和其它工具)。所述文件还包括用于定义“合并字段”的规定。扫描接收者文件(XML格式)、提取每个接收者的“合并值”、将所述合并值与XSL样式表组合以及为每个接收者生成输出文档(以称为XSL:FO的格式)的过程，可能由被称为Xalan(由Apache提供)的软件产品执行。XSL和XSL:FO的细节可在文档内找到：可扩展样式表语言(XSL)，版本1.0，W3C介绍，2001年10月15日，万维网联盟出版，在http：//www.w3.org/TR/xsl内可得到。

·微软Word(DOC)文件

-DOC文件可由微软Word字处理器生成。“合并字段”可被在文档内定义，并使用Word的标准“合并”功能以“合并值”替代。在所述消息分配系统内，DOC模板的合并可能由微软Word自身执行。Word在Windows 2000控制下(即在Java虚拟机之外)作为直接执行的独立程序运行。所述消息分配系统可能使用微软的DCOM功能与Word相互作用(即将模板和接收者文件传递到其并接收合并后结果)。

·文本文件(TXT)

-文本文件是可能可选地包括合并字段的ASCII文本的简单串。在适当的地方，允许“行末”字符(即<CR>和<LF>)，但不允许其它格式化的字符。

无法包括合并字段的其它模板类型包括：

·TIFF(TIF)文件

TIFF文件包括位图图形形式的图像。

·Adobe Acrobat文档(PDF)文件

所述文件的格式由Adobe发布。

·Postscript(PRN)文件

Postscript文件被特别设计为驱动各种打印机(可能由所述消息分配系统用于生成指向纸面的输出)。用户通常通过将文本和其它信息输入字处理器、然后将所述文件输出到打印文件(其缺省状态具有PRN的文件类型)，而非物理打印机，从而生成Postscript文件。

·HTML(HTM)文件

HTML文件包括以HTML标示语言格式化的信息。

接收者文件

所述企业接口2416的用户以各种格式将文件提交给所述消息分配系统2400，而所述标准接口2414的用户优选地以“逗号分隔值”(CSV)格式提交所述文件。具体的Java类(数据转换器的一部分)被用于在将所提交的文件置于所述作业队列2430(在所述消息分配系统数据库内)内之前，将所述文件转换为XML格式。所述类被保持在包括在所述数据库中的作业配置的JAVA_MAPPING_CLASS内。所述java映射类可能使用其它工具来辅助映射过程。这可能包括其它Java类、XFlat映射文件和XSL样式表。所述工具被保持在包括在所述数据库中的作业配置的JAVA_MAPPING_CLASS_RESOUCE内。

XFlat映射文件是一组报表(以被称为XFlat的格式转换定义语言表示)，其可被提交给“XML转换功能”，一种处理各种简单格式转换的程序。

XML格式

XML格式的接收者文件包括若干<recipient>单元，每个接收者一个。图24内示出了这样的一个文件2500(仅包括一个接收者)的实例。以下将简要描述此实例内的数据：

·个人细节

“<personal-details>”单元包括指示接收者的标题、名和姓的子单元。它们在传真“带状地址”内使用(只要传真被发送到接收者)，以及作为邮寄地址的第一行(当纸面邮件被发送到所述接收者时)。可选的“<reference>”单元可用，其可能包括在所述消息分配系统所生成的作业状态报告上出现的用户指定文本的至多10个字符。所述发送者通常使用所述单元来以对接收者有意义的名称(例如雇员编号、银行账户号、医疗号等)识别所述接收者。

·目的地偏好

“<destination-preference>”单元指定将用于所述接收者的目的地，以及在失败情况下调用的改发选项。所述单元包括一个、两个或三个“<attempt>”子单元。每个“<attempt>”子单元指定空格或逗号所分隔的一个、两个或三个传输。每个“传输”都对应于“<destination>”字段内的“id”属性，从而指示特定目的地。所指定的第一传输是“主”。在传真的情况下，每次“传输”包括至多三次重试。

·目的地

一个“<destination>”单元可能被允许用于每种媒体类型(如“媒体”属性所指示的)。如果并未为特定媒体提供单元，则这意味着无法借助所述媒体到达接收者。所述“id”属性被用作到先前所述“<attempt>”单元的链接，并可能包括任何便利的识别符。所述“<destination>”单元的子单元指定实际目的地自身。

允许两种样式的纸面地址。图24示出了语法分析后的形式。未语法分析的地址也可被使用以下单元输入：

·<address-line-1></address-line-1>

<address-line-2></address-line-2>

<address-line-6></address-line-6>

·接收者数据

“<recipient-data>”单元包括合并字段。在以上实例中，存在代表发票上的单行的合并字段，这包括若干代表所述行内信息项的子合并字段。然而，这仅是一个实例。所述“<recipient-data>”字段允许彻底的格式自由(倘若所述字段包括合式的XML)。

VII.数据库结构

所述消息分配系统数据库包括各种表。图25是实体关系图，2600示出了所述表和关系。在图25中，数据库表之间的“多到一”对应关系由所述关系的“多”侧上的“鸟足”指示。

以下将描述每个表(被称为“记录”或“实体”)与所述表内的栏(有时称为“字段”)。每个表都包括唯一主密钥，优选的是称为“xxx_PK”(其中“xxx”是表的名称)。所述密钥是数据库复制原因需要的，并通常是自动生成的。

客户、账户和用户

所述消息分配系统具有关于客户、账户和计费偏好的信息。所述消息分配系统仅需所述信息的子集。出于此原因，可能为客户提供对于所述计费系统的直接在线接入，从而使得客户对其账户和计费偏好具有直接控制(而所述消息分配系统子集在需要时被下载到所述消息分配系统)。

数据可能被在所述消息分配系统与计费系统之间相互复制。如果这样，则可能将保持在所述消息分配系统内的所述数据的量可保持为最小。所述消息分配系统将与客户相关的信息存储为三个主实体，即客户2610、用户2612和账户2614。每个客户“拥有”并管理其自己的用户和账户组。以下将描述所述数据库表和每个字段。

客户

所述表2610代表客户，其是所述数据库内的其它所有实体链接到的“锚点”。

customer_PK：自动生成的唯一主密钥。

id：客户识别符。所述n个字符(n可能是8)的识别符唯一地识别所述客户。客户的每个用户在登录到所述消息分配系统时输入所述客户id。

name：所述客户的名称(例如ABC银行机构)。所述字段出现在各个屏幕以及关于所述客户的报告上。

timezone_code：识别所述客户位于的时间区。

enabled：指示所述客户被启用还是禁用的布尔标志。不允许禁用客户接入所述消息分配系统(即所述客户的所有用户都无法登录)。

enabled_change_time：指示“enabled”标志最后改变的日期/时间。从所述数据库删除已经禁用一段长的时期的客户。

ftpJobSubmission：如果所述客户可经由FTP提交作业，则设置为“真”。

用户

用户记录2612包括关于用户(即接入所述消息分配系统的人)的信息。所述数据库内的所述表的实际名称是“USER”。增加所述后下划线字符，以避免与SQL保留字“user”的冲突。

user_PK：自动生成的唯一主密钥。

id：用户识别符。所述n个字符(n可能是8)的识别符唯一地识别所述用户。所述用户在登录到所述消息分配系统时输入所述用户id。

name：所述用户名称(例如Mary Smith)。所述字段出现在各个屏幕以及关于所述用户的报告上。

password：登录时输入的用户密码。

customer_FK：链接到“拥有”所述用户的客户。

email，phone_number，fax_number，mobile_number：这些字段可能包括所述用户的联系信息(从而使得所述消息分配系统支持组能够在需要时联系所述用户)。

test_email，test_fax_number，test_sms_number：这些字段包括将被用作测试作业目的地的所述用户的电子邮件地址、传真号码和SMS电话号码。

enabled：指示所述用户被启用还是禁用的布尔标志。不允许禁用用户接入所述消息分配系统。

enabled_change_time：指示“enabled”标志最后改变的日期/时间。可能从所述数据库删除已经禁用一段规定时期的客户。

administrator：指示所述用户是否为管理员用户的布尔标志。管理员用户具有标准用户无法得到的特定特权。

账户

所述账户记录2616包括关于账户的信息。每个账户2616都定义此账户下运行的作业的特征和限制。

account_PK：自动生成的唯一主密钥。

name：账户名称。这是对于作为账户催询者的客户有用的“有意义”名称。

customer_FK：到“拥有”所述账户的客户的CUSTOMER记录的链接。

enabled：指示所述账户被启用还是禁用的布尔标志。不允许禁用用户接入所述消息分配系统。

enabled_change_time：指示“enabled”标志最后改变的日期/时间。可能从所述数据库删除已经禁用一段时期的账户。

enterprise：指示所述账户需要标准接口还是企业接口用于作业提交。

product：指示所述账户下可用的消息分配系统的代码。

fax_carrier，fax_carrier_user，fax_carrier_password，

email_carrier，email_carrier_user，email_carrier_password，

sms_carrier，sms_carrier_user，sms_carrier_password，

paper_carrier，paper_carrier_user，paper_carrier_password：

所述“xxx_carrier”字段包括将用于媒体“xxx”的所述载体的三个字符识别符。当前值是：

用于Xpedite的XPD，用于EDI邮寄的EDI，

用于MessageReach的MSR，用于SMSReach的SMR。

所述“xxx_carrier_user”和“xxx_carrier_password”字段由所述消息分配系统在借助FTP将文件传送到所述载体时内部使用的字段。可能使用其它识别符，包括用于不同载体的识别符。

fax_quality：传真的输出质量(标准或增强型)。

fax_max_page_size：以字节表示的传真页最大尺寸。

fax_cover_page：指示是否生成在所述账户下提交的作业的传真封面页的布尔值。

fax_company，fax_address_1，fax_address_2，fax_address_3：这些字段内的公司名称和地址被打印在每个传真的封面页上。

email_from_address：所述消息分配系统生成的电子邮件到达的接收者来自的电子邮件地址。

email-timeout：电子邮件未决的最大时间(优选的是从作业尝试开始的小时)。当到达此时间时，假定所有未决电子邮件成功，且开始下一次尝试。

email_job_status_address：作业状态报告被发送到的电子邮件地址。

USER A CCOUNT XREF

所述“交叉参考”实体2614指定用户2612和账户2616的单个有效组合。对于每个用户而言，所述实体定义在所述用户提交所述消息分配系统作业时所述用户可能指定的账户。对于每个账户而言，所述实体2614定义可能使用所述实体的用户。

user_account_xref_PK：自动生成的唯一主密钥。

user_FK：到USER记录的链接。

account_FK：到ACCOUNT记录的链接。

作业队列

所述作业队列作为所述消息分配系统的相关数据库2600内的一组表存在。在图25的实体关系图内，作业队列实体是：

2618，2632，2634，2640；2620，2622，2626，2628，2630；以及2636，2638，2642，2644，2646，2648，2650和2652。

一旦已生成作业队列条目，就不会改变记录2636、2638、2642、2644、2646、2648、2650、2652、2652、2620、2622、2624、2626、2628和2630，但有时会更新记录2618、2632、2634和2640，以指示作业处理的状态。

在作业提交时间建立记录2636、2638、2642、2644、2646、2648、2650和2652。在对于所述标准接口的作业提交时间还建立所述记录2620、2622、2624、2626、2628、2630，但在企业接口的情况下，当通过若干作业首先实施并保持所述作业时，所述记录可能由所述消息分配系统支持组建立。

作业

所述作业队列层级的顶端是JOB记录2618。在所述队列内存在用于每个作业的记录，而所述JOB记录2618构成与作业相关的所有信息的“锚”记录。

job_PK：jobid是所述消息分配系统所生成的、唯一识别所述作业的数字识别符。所述识别符出现在与所述作业相关的输出上(例如作业状态报告)，并在所述用户提交作业时显示在“确认屏”上。

user-reference：用户生成的作业名称，其被包括在各种消息分配系统/计费报告内，并可能包括用户希望的任何文本。

job_configuration_FK：链接到所述作业的JOB_CONFIGURATION记录。

account_FK：链接到所述作业在其下运行的账户的ACCOUNT记录。

user_FK：链接到启动所述作业的用户的USER记录。

submit_time：提交所述作业的日期和时间。

fax_only：表示“将传真发送到所有具有所定义传真地址的接收者”。

sms_only：表示“将SMS消息发送到所有具有所定义SMS地址的接收者”。

email_only：表示“将电子邮件发送到所有具有所定义电子邮件地址的接收者”。

fax_preferred：表示“借助传真(如果定义了传真地址)发送到所有接收者，否则借助电子邮件”。

email_preferred：表示“借助电子邮件(如果定义了电子邮件地址)发送到所有接收者，否则借助传真”。

job_submission_folder：各个作业工具(模板、接收者文件、传输束文件等)存储其内的文件夹的名称。

master_status：总体作业状态。

master_change_time：master_status最后被改变的日期和时间。

作业配置信息

包括记录类型JOB_CONFIGURATION 2620、TEMPLATE2624、TEMPLATE_ARTIFACT 2622、CONFIG_DATA 2626、JAVA_MAPPING_CLASS_RESOURCE 2628以及JAVA_MAPPING_CLASS 2630的记录群集定义了作业所使用的各种工具和配置。

对于使用企业接口提交的作业而言，当所述消息分配系统支持组首先建立作业时定义所述记录群集。所述记录群集由许多作业使用，且对于每个作业都保持不变。所述群集包括各个数据文件的内容(模板、图像等)，每个文件可能都由所述消息分配系统支持组在所述群集被建立时作为二进制对象(BLOB)输入到所述数据库记录。

对于使用标准接口提交的作业而言，在提交所述作业时生成所述记录群集，且所述记录群集与特定作业相关。所述模板可从所述群集内查询，而非实际上存储在数据库自身内；所述模板被单独保持为平面文件。

JOB CONFIGURATION

所述记录2620是作业配置记录群集的“锚”。

job_configuration_PK：自动生成的唯一主密钥。

display_name：这是作业配置的名称，所述作业配置对于客户有意义，并在作业提交屏(“作业类型”)上使用，以选择作业配置。仅为企业接口作业定义所述字段。

enterprise：指示所述作业配置是应用于所述企业接口还是标准接口的布尔标志。

customer_FK：链接到“拥有”所有使用所述作业配置的作业的CUSTOMER记录。

TEMPLATE

所述记录2624定义了模板(即，可合并的微软Word、XSL或文本文档；或PDF、TIFF、HTML或postscript格式的不可合并文档)。对于企业接口作业而言，所述模板2624自身作为二进制图象保持在所述记录内。对于标准接口作业而言，所述模板2624被作为平面文件保持在数据库之外(所述作业提交文件夹内)。

template_PK：自动生成的唯一主密钥。

filename：构成所述模板的文件的文件名。

filetype：构成所述模板的文件的文件类型。

attach_name：此名称是仅为电子邮件附件模板定义的，是在发送到所述接收者时提供给附件文件(不包括文件类型)的名称。

media_type：指示所述模板应用的媒体。

fo_rendering_engine：这是仅为纸面模板定义的，包括所述消息分配系统用于生成postscript输出(当前为XEP或FOP)的FO翻译引擎。

job_configuration_FK：链接到JOB_CONFIGURATION记录。

component_type：指示所述模板定义的最终接收者消息的哪个部分。对于传真而言，这可能是“主题”或“其它”。对于电子邮件而言，其可能是“主题”、“主体”或“附件”。对于纸面和SMS而言，其未被定义。

component_sequence：这是如果component_type不是“附件”而定义的部分的序号。该字段表示所述消息内的附件的序号。例如，四个附件的电子邮件消息的电子邮件附件被标号1、2、3和4。

template：该字段仅对于企业接口模板而言有效，包括模板自身。(对于标准接口作业而言，所述模板保持在作业提交文件夹中的平面文件内。)

TEMPLATE ARTIFACT

所述记录2622指示所述JOB_CONFIGURATION 2620内的TEMPLATE记录2624所使用的图像和其它多媒体文件。此记录是为企业接口作业(其使用XSL模版)定义的。

template_artifact_PK：自动生成的唯一主密钥。

filename：所述工具从那里被输入的文件的文件名。

filetype：所述工具从那里被输入的文件的文件类型(通常为GIF或JPG)。

job_configuration_FK：链接到JOB_CONFIGURATION记录。

artifact：包括所述工具自身。

CONFIG DATA

所述记录2626包括特定于媒体类型的配置数据。所述记录用于纸面，并包括诸如使用哪个送纸器箱(paper feeder bins)、是否双面打印等的信息。所述记录是为企业接口作业定义的。

config_date_PK：自动生成的唯一主密钥。

filename：所述配置数据从那里被输入的文件的文件名。

filetype：所述配置数据从那里被输入的文件的文件类型(通常为TXT)。

media_type：指示所述配置数据应用于的媒体。

job_configuration_FK：链接到JOB_CONFIGURATION记录。

configuration：所述配置数据自身。图26是提交给EDI邮寄的纸面作业的典型配置2700的实例。

JAVA MAPPING CLASS

所述记录2630是必备的，并包括Java类，所述Java类用于将接收者文件转换为XML(可能还使用一个或多个JAVA_MAPPING_CLASS_RESOURCE记录)。标准接口作业使用CSV格式化后的接收者文件，因此所述作业使用被称为“CSV映射类”的标准java映射类。

java_mapping_class_PK：自动生成的唯一主密钥。

filename：所述java类别被从那里输入的文件的文件名。

filetype：所述java类别被从那里输入的文件的文件类型(通常为CLASS)。

job_configuration_FK：链接到JOB_CONFIGURATION记录。

class：包括java类别。

JAVA MAPPING CLASS RESOURCE

此记录2628是可选的，并包括所述Java映射类用于重新格式化所述接收者列表信息的资源对象。所述记录2628可能包括任何类型的资源，例如所述XFlat语言(用于输入到“XML转换”产品)的其它java类别、XML样式表或报表。

java_mapping_class_resource_PK：自动生成的唯一主密钥。

filename：所述XFlat映射数据被从那里输入的文件的文件名。

filetype：所述Xflat映射数据被从那里输入的文件的文件类型。

job_configuration_FK：链接到JOB_CONFIGURATION记录。

resource_data：包括资源自身。

图27示出了可能存储在所述记录内的一种资源类型的实例2800。所述XFlat报表将CSV文件转换为XML。在所述CSV文件中，每个记录包括三个字段，表示“refno”、“name”和“salary”。

接收者信息

RECEIPIENT、ATTEMPT、TRANSMISSION、MERGE_DATA、DESTINATION、PAPER_ADDRESS_PARSED、PAPER_ADDRESS_UNPARSED、PHONE_NUMBER记录2636、2638、2640、2642、2644、2652、2650、2648、2646分别定义作业的接收者信息。

RECEIPIENT

每个所述记录2636都表示一个接收者。

recipient_PK：自动生成的唯一主密钥。

job_FK：链接到所述作业的JOB记录。

Tjtle：所述接收者的名称(Mr、Mrs、Dr等)

first_name：所述接收者的名。

last_name：所述接收者的姓。

user_data：从用户角度来看，通常用于识别所述接收者的用户定义的数据。

ATTEMPT

每个接收者可能存在最多三个ATTEMPT记录2638。每一个都表示在所述接收者列表记录内指定的一个“<attempt>”。所述ATTEMPT记录2638被编序号，从而可以正确顺序接入所述记录。所述ATTEMPT记录的目的是分组其下的TRANSMISSION记录。

attempt_PK：自动生成的唯一主密钥。

recipient_FK：链接到RECIPIENT记录。

seq_number：此次尝试的序号(1、2或3)。

TRANSMISSION

每次尝试可能存在最多三个TRANSMISSION记录2640。每一个都代表在接收者列表记录中的“<attempt>”单元内指定的传输。所述TRANSMISSION记录2640被编序号，从而可以正确顺序接入所述记录。第一个(序号始终为“1”)代表主传输(如果其失败则引起改发)。

当所述作业被置于作业队列内时建立以下字段：

tansmission_PK：自动生成的唯一主密钥。

destination_FK：链接到DESTINATION记录。

attempt_FK：链接到ATTEMPT记录。

account_FK：链接到所述作业的ACCOUNT记录。

recipient_FK：链接到RECIPIENT记录。

transmission_bundle_FK：链接到TRANSMISSION_BUNDLE记录。

job_FK：链接到所述作业的JOB记录。

attempt_no：尝试编号。

seq_number：此次传输的序号(1、2或3)。

State：指示此次传输“尚未尝试”(INACTIVE)，“成功完成”(即OK)，还是“完成失败”(即误码)。

剩余字段在已尝试传输时建立，并包括与传输成功/失败相关的信息：

job_reference：用户对于所述作业的参考id。

user_data：所述用户对于所述接收者的参考id。

destination_address：此次传输被发送到的电话号码、电子邮件地址或纸面地址。

date_time_job_submitted：提交作业的日期和时间。

date_time_message_dilivered：所述消息被传递到接收者的日期和时间。

carrier_name：载体的名称(Xpedite等)。

carrier_reference_id：载体的参考id(例如Xpedite的作业编号)。

medium：所述传输被发送到的媒介(传真、纸面等)。

size_of_message：消息的字节总量。

destination_country：所述消息被传递到的国家或区域。

delivery_success_failure_code：指示所述传输成功或失败原因的载体代码。

MERGE DATA

来自所述接收者记录的合并数据2642被以XML文本形式存储。

merge_data_PK：自动生成的唯一主密钥。

recipient_FK：链接到RECIPIENT记录。

merge_data：包括作为一串XML格式化后的文本的合并数据自身。

DESTINATION

对于每个接收者而言，每种媒体存在一个DESTINATION记录2644(即最大为四个)。所述记录包括“媒体id”(指示传真、纸面、SMS或电子邮件)，并“指向”单个“子记录”，所述“子记录”为以下记录类型中的一个。

destination_PK：自动生成的唯一主密钥。

recipient_FK：链接到RECIPIENT记录。

media-type：指示所述目的地表示的媒体，从而指示所寻找目的地地址的类型(见以下)。

PAPER ADDRESS PARSED

所述记录2652包括未语法分析的纸面目的地地址。

paper_address_parsed_PK：自动生成的唯一主密钥。

destination_FK：链接到DESTINATION记录。

street_address：街道号和名称。

suburb：城郊。

state：州。

postcode：邮编。

country：国家

PAPER ADDRESS UNPARSED

所述记录2650包括语法分析后的纸面目的地地址。

paper_address_parsed_PK：自动生成的唯一主密钥。

destination_FK：链接到DESTINATION记录。

address_line_1：地址的行1。

address_line_2：地址的行2。

address line 3：地址的行3。

address_line_4：地址的行4。

address_line_5：地址的行5。

address_line_6：地址的行1。

PHONE NUMBER

此记录2648包括电话号码(即SMS或传真的目的地地址)。

phone_number_PK：自动生成的唯一主密钥。

destination_FK：链接到DESTINATION记录。

country_code：国家代码。

area_code：区号。

local_number：电话号码的剩余部分。

EMAIL ADDRESS

此记录2646包括电子邮件目的地地址。

email_address_PK自动生成的唯一主密钥。

destination_FK：链接到DESTINATION记录。

email_address：电子邮件地址。

is_valid：指示所述地址语法是否有效的布尔值。

传输束信息

当所述消息分配系统处理特定作业传输尝试时，所述系统将接收者分为每个都指向特定媒体的“传输束”。每个传输束都被传送到一个载体，所述传输的命运最终被从所述载体传送回所述消息分配系统。为每个传输束生成TRANSMISSION_BUNDLE记录2632，其用于跟踪其状态。

TRANSMISSION BUNDLE

每个传输束都存在一个TRANSMISSION_BUNDLE记录2632。所述记录2632在生成所述束自身时生成，在从所述数据库最终删除所述作业时删除。

transmission_bundle_PK：自动生成的唯一主密钥。

job_FK：链接到所述作业的JOB记录。

Attempt：此次尝试的序号(1、2或3)。

media_type：指示此次传输束发往的媒体。

creation_time：生成所述记录的日期和时间。

bundle_status：所述传输束的处理状态。见段5.3.1。

status_change_time：bundle_status最后改变的日期和时间。

CARRIER REFERENCE

每个发送到用于特定媒体类型和作业id的载体的传输束都存在一个CARRIER_REFERENCE记录2634。所述记录2634在生成所述传输束文件自身时生成，在从所述数据库最终删除所述作业时删除。

在多数情况下，一次尝试仅为每个媒体类型生成一个传输束文件，但在一些情况下(例如发往Xpedite并超过10M字节的传真束文件)，所述文件可能被分为若干独立文件。出于此原因，每个TRANMISSION_BUNDLE记录2632可能偶尔存在若干CARRIER_REFERENCE记录2634。

carrier_reference_PK：自动生成的唯一主密钥。

transmission_bundle_FK：链接到TRANSMISSION_BUNDLE记录。

carrier_id：所述载体提供的、唯一指示所述传输束文件的识别符。所述识别符可能由所述消息分配系统用于从所述载体轮询反馈信息。所述字段的格式对于每个载体而言是不同的。

transmission_bundle_filename：传输束文件的名称。

statur_collected：指示是否已从用于所述传输束文件的载体接收到载体状态报告的布尔值。如果设置为“真”，则所述信息已被接收，并应用于TRANSMISSION记录。

其它

NUMBER-GENERATOR

这是用于将唯一作业id分配给新作业，并将唯一记录密钥分配给其它记录的单个记录2654。

number_generator_PK：自动生成的唯一主密钥。

job_number：将被指配的下一个作业id。

general_number：将被指配的下一个通用号码(用作用于除JOB记录之外的所有记录的记录密钥)。

VIII.Java映射类和XSL模板

所述消息分配系统被设计为一般化消息处理引擎。所述消息分配系统自身的“核心”被设计为将任何类型的消息广播到任何目的地。然而，每个消息分配系统客户的“作业类型”(aka“作业配置”)具有特别的处理特征。这分为两个类别：

验证和重新格式化从所述客户接收的接收者文件，以及

将合并值替换为所述模板内的合并字段，以生成每个单独特制的接收者消息。

所述处理类别分别称为Java映射类处理和模板合并处理。这些处理类别都包括特定于每个客户和作业类型的处理，以及作为用于在所述系统上建立新作业类型的进程一部分而开发的程序/样式表。此外，程序/样式表的开发可能由独立于开发消息分配系统自身的组的开发组执行。

图28是作业执行流的框图，示出了作业处理路径2900如何从消息分配系统“核心”2910传送到Java映射类2930和模板2940，以及如何从Java映射类2930和模板2940传送回消息分配系统“核心”2910。

所述消息分配系统2910的“核心”是不变的。所述系统软件2910表示任何类型的消息分配系统作业能够在其上运行的一般化平台。特定于客户的部分2930和2940对于每种作业类型而言是不同的。

在步骤2920中，所述用户将作业提交给系统软件2910。在步骤2912中集合所述作业信息。在Java映射类2930中，在步骤2932中验证所述接收者列表。然后，在步骤2934中映射所述接收者列表。当在步骤2914中起动所述作业时，处理然后在系统软件2910内继续。在步骤2916中，得到(“取得”)下一个接收者的合并字段。所述模板2940将所述接收者的合并值替代为所述模板的合并字段。所述消息被在步骤2918内发送到接收者；并在步骤2916内得到下一个接收者的合并数据。

Java映射类

Java映射类2930(或称为数据转换器)是所述消息分配系统2900的有力特征。所述类2930允许以任何格式将客户的接收者数据提供给所述消息分配系统。所述Java映射类2930是为特定客户的作业特制的消息分配系统2910自身的附属品。所述类2930将所有客户的接收者列表转换为在段VI.内描述的消息分配系统的标准格式。所述类2930还提供了自动对客户的接收者列表做出通用改变的能力。例如，Java映射类2930可能实施诸如“借助传真发送到NSW内的所有接收者，但借助电子邮件发送到其它接收者”的通用要求。每种作业类型存在一个java映射类2930(aka“作业配置”)，其功能是验证2932从客户接收的接收者文件，并将其转换2930为所述消息分配系统的标准接收者列表格式。

所述类别2930提供两个主要方法，即所述消息分配系统在必要时调用的“验证”和“映射”。所述Java映射类2930自身被保持在数据库内(在JAVA_MAPPING_CLASS记录内)，所述类别需要的各种资源(即XFlat方案和XSLT样式表)同样保持在数据库内(在JAVA_MAPPING_CLASS_RESOURCE记录内)。

特别的Java映射类环境

与其它消息分配系统类一样，Java映射类的类文件并不存储在JAR文件内；所述文件作为作业配置的一部分保持在所述数据库内的JAVA_MAPPING_CLASS记录内。只要需要所述类文件，所述消息分配系统即自动将所述类文件从数据库读入存储器，然后使用Java类装载器(本文称为“特别类装载器”)的专门消息分配系统子类装载文件。

Java虚拟机由用于载入所述类的类装载器区别所有类别。特定类装载器所载入的类仅能接入在此类装载器的“类途径”上特别指定的其它类别。所述Java虚拟机分为独立“世界”。以相同类装载器载入的所有类可相互直接接入，但一个“世界”内的类无法轻易接入另一“世界”内的类。术语“世界”在本文用于描述此概念。

所述Java特征已被特地用于限制Java映射类接入所述消息分配系统“核心”类别。Java映射类在与所述消息分配系统剩余部分不同的“世界”内操作：

所述消息分配系统类的核心可接入所有标准Java SDK程序包(java.io、java.util等)，以及所有客户开发的消息分配系统程序包。

Jav映射类可接入所有标准Java SDK程序包(java.io、java.util等)，以及专门的Java映射类程序包(com.system.mapper)。

因此，Java映射类被与所述消息分配系统“分离”，根本无法接入所述消息分配系统，因此无需对所述消息分配系统自身做出对应改变即可增强或修改Java映射类。这显著简化了系统管理，并保护系统免于“欺诈”Java映射类。

所述消息分配系统自身及其Java映射类可被设想为相同Java虚拟机内的独立“岛”。所述消息分配系统使用“反应API”(普通方法调用不工作)将自变量传送到Java映射类。

至于自变量传送机制，作为实际实例，考虑企业作业的作业信息(作业id、作业参考、作业提交文件夹和接收者文件)被从所述消息分配系统传送到Java映射类。

所述消息分配系统包括称为“EnterpriseJobSubmission”的类，其包括所有信息和更多(以各种格式存储，包括简单串和其它消息分配系统定义的类)。明显的策略是仅将企业作业提交对象传送到Java映射类内的“setJobSubmission”方法。这会失败，因为所述Java映射类并不了解“EnterpriseJobSubmission”类，因为所述类的定义并未包括在提供给用于载入Java映射类的类装载器的类路径内。简而言之，所述Java映射类仅了解其自己“世界”内的类；所述类对于所述消息分配系统的“世界”内的类别一无所知。然而，每个Java映射类都了解称为“EnterpriseJobSubmissionData”的类。所述类定义是Java映射类自己“世界”的一部分(因此并非所述消息分配系统的世界的一部分)。因此，在调用Java映射类之前，所述消息分配系统(使用特别类装载器)生成EnterpriseJobSubmissionData的实例，并使用其“设置”方法将必要数据(即作业id、作业参考、作业提交文件夹和接收者文件)置于实例内。所述消息分配系统必须借助反射调用所述设置方法，因为对象存在于其它“世界”内。所述消息分配系统然后生成Java映射类自身的实例(再次使用专门的类装载器)。最后，所述系统使用其“设置”方法中的一个，将企业作业提交数据对象传送到Java映射类2930。

所述Java映射类2930可接入此对象，并以常用方式将所述对象存储在其成员变量中的一个内，因为所述对象在其自己的“世界”内，而所述“世界”包括的所有对象是作为标准Java环境一部分的简单对象(串、阵、文件等)。在所述消息分配系统与Java映射类2930之间信息传送使用上述技术。

Java映射类方法

企业接口作业的Java映射类必须扩展企业映射类(其反过来扩展映射类)，还必须实施客户映射接口。这需要表5所示的方法：

表5

方法类型	方法符号	在哪里定义	描述
				Publicvoid	SetJobSubmissionData(ObjectjobSubmissionData)	映射器	设置关于所述作业的信息
Publicvoid	SetMappingResources(ArrayListmappingResource)	映射器	设置关于映射资源的信息(XFlat文件、XSL模板等)
				Publicbolean	validate()	Java映射类	验证接收者文件
Publicbolean	map()	Java映射类	生成所映射的接收者文件
				Publicstring	GetErrorMessage()	映射器	得到错误消息文本
Publicstring	getEvnetId()	映射器	得到事件id
				Publicbolean	isUserError()	映射器	如果发生用户错误则真
Public int	getErrorCode()	映射器	得到误码
				Public file	getMappedRecipientFile()	企业映射器	得到所映射的接收者文件

以上公开了一种方法、系统和计算机程序产品，用于基于接收者的传递偏好，并引入逐步升级，从而经由多个传递媒体将信息成批通信给单个接收者组。尽管已描述了少量的实施例，但对于本领域技术人员而言，依据本公开，显然可在并不背离本发明精神和范围的情况下进行修改和/或替换。

Claims (36)

1、一种用于经由多个传递媒体将信息成批通信给接收者的方法，其中所述传递媒体包括传真、电子邮件、水陆路邮件和SMS消息发送，所述方法包括步骤：

经由单个接口接收用于分配的信息，所述用于分配的信息包括关于接收者的信息；以及

基于所述接收者的传递偏好，利用为每个所述接收者所指定的其中一个所述传递媒体，从而基于所述接收的信息而传送至少一个文档。

2、根据权利要求1的方法，还包括步骤：对于借助指定的传递媒体向其传输失败的一个或多个接收者，通过将一个不同的传递媒体用于所述多个接收者中的每一个，来逐步升级所述至少一个文档的传输。

3、根据权利要求1的方法，其中所述接收的信息包括一个或多个模板文档和特定于每个接收者的数据。

4、根据权利要求3的方法，还包括步骤：将所述一个或多个模板文档和所述特定于每个接收者的数据合并，以为每个接收者提供所述至少一个文档。

5、根据权利要求4的方法，还包括步骤：为每个传递媒体确定文档模板类型，并为所述文档模板类型选择合并过程。

6、根据权利要求5的方法，其中所述特定于每个接收者的数据被提供给对应的合并过程。

7、根据权利要求2的方法，还包括步骤：

将所述至少一个文档转换为适合于每个接收者的所述指定的一个或所述不同的一个的传递媒体的格式；以及

使用所述指定的一个或所述不同的一个传递媒体，将所述格式化后的文档发送到用于传输的载体。

8、根据权利要求7的方法，还包括步骤：处理来自所述载体的关于所述传输的报告，以提供关于所述文档到每个接收者的传递的状态信息。

9、根据权利要求8的方法，其中所述逐步升级步骤依据所述状态信息。

10、根据权利要求1的方法，其中所述传递媒体包括归档。

11、根据权利要求1的方法，其中所述传递媒体包括一个或多个新媒体类型。

12、一种用于经由多个传递媒体将信息成批通信给接收者的系统，所述传递媒体包括传真、电子邮件、水陆路邮件和SMS消息发送，所述系统包括：

单个接口，用于接收用于分配的信息，所述用于分配的信息包括关于接收者的信息；以及

用于基于所述接收者的传递偏好，利用为每个所述接收者所指定的其中一个所述传递媒体，从而基于所述接收的信息而传送至少一个文档的装置。

13、根据权利要求12的系统，还包括用于对于借助指定的传递媒体向其传输失败的一个或多个接收者，通过将一个不同的传递媒体用于所述多个接收者中的每一个，来逐步升级所述至少一个文档的传输的装置。

14、根据权利要求12的系统，其中所述接收的信息包括一个或多个模板文档和特定于每个接收者的数据。

15、根据权利要求14的系统，还包括用于将所述一个或多个模板文档和所述特定于每个接收者的数据合并，以为每个接收者提供所述至少一个文档的装置。

16、根据权利要求15的系统，还包括用于为每个传递媒体确定文档模板类型，并为所述文档模板类型选择合并过程的装置。

17、根据权利要求16的系统，其中对于所述特定于每个接收者的数据执行对应的合并处理。

18、根据权利要求13的系统，还包括：

用于将所述至少一个文档转换为适合于每个接收者的所述指定的一个或所述不同的一个传递媒体的格式的装置；以及

用于使用所述指定的一个或所述不同的一个传递媒体，将所述格式化后的文档发送到用于传输的载体的装置。

19、根据权利要求18的系统，还包括用于处理来自所述载体的关于所述传输的报告，以提供关于所述文档到每个接收者的传递的状态信息的装置。

20、根据权利要求19的系统，其中所述用于逐步升级的装置依据所述状态信息。

21、根据权利要求12的系统，其中所述传递媒体包括归档。

22、根据权利要求12的系统，其中所述传递媒体包括一个或多个新媒体类型。

23、一种计算机程序产品，所述计算机程序产品包括计算机可读媒体，所述计算机可读媒体具有记录在其内的计算机程序，所述计算机程序用于经由多个传递媒体将信息成批通信给接收者，所述传递媒体包括传真、电子邮件、水陆路邮件和SMS消息发送，所述计算机程序产品包括：

经由单个接口接收用以于分配的信息的计算机程序代码单元，所述用于分配的信息包括关于接收者的信息；以及

基于所述接收者的传递偏好，利用为每个所述接收者所指定的其中一个所述传递媒体，从而基于所述接收的信息而传送至少一个文档的计算机程序代码单元。

24、根据权利要求23的计算机程序产品，还包括用于对于借助指定的传递媒体向其传输失败的一个或多个接收者，通过将一个不同的传递媒体用于所述多个接收者中的每一个，来逐步升级所述至少一个文档的传输的计算机程序代码单元。

25、根据权利要求23的计算机程序产品，其中所述接收的信息包括一个或多个模板文档和特定于每个接收者的数据。

26、根据权利要求25的计算机程序产品，还包括用于将所述一个或多个模板文档和所述特定于每个接收者的数据合并，以为每个所述接收者提供所述至少一个文档的计算机程序代码单元。

27、根据权利要求26的计算机程序产品，还包括用于为每个传递媒体确定文档模板类型，并为所述文档模板类型选择合并过程的计算机程序代码单元。

28、根据权利要求27的计算机程序产品，其中对于所述特定于每个接收者的数据执行对应的合并处理。

29、根据权利要求24的计算机程序产品，还包括：

用于将所述至少一个文档转换为适合于每个接收者的所述指定的一个或所述不同的一个传递媒体的格式的计算机程序代码单元；以及

用于使用所述指定的一个或所述不同的一个传递媒体，将所述格式化后的文档发送到用于传输的载体的计算机程序代码单元。

30、根据权利要求29的计算机程序产品，还包括用于处理来自所述载体的关于所述传输的报告，以提供关于所述文档到每个接收者的传递的状态信息的计算机程序代码单元。

31、根据权利要求30的计算机程序产品，其中所述用于逐步升级的计算机程序代码单元依据所述状态信息。

32、根据权利要求23的计算机程序产品，其中所述传递媒体包括归档。

33、根据权利要求23的计算机程序产品，其中所述传递媒体包括一个或多个新媒体类型。

34、一种用于经由多个传递媒体将信息成批通信给接收者的方法，所述传递媒体包括传真、电子邮件、水陆路邮件和SMS消息发送，所述方法参照附图的图1-10中任何一个被公开。

35、一种用于经由多个传递媒体将信息成批通信给接收者的系统，所述传递媒体包括传真、电子邮件、水陆路邮件和SMS消息发送，所述系统参照附图的图1-10中任何一个被公开。

36、一种用于经由多个传递媒体将信息成批通信给接收者的计算机程序产品，所述传递媒体包括传真、电子邮件、水陆路邮件和SMS消息发送，所述计算机程序产品参照附图的图1-10中任何一个被公开。

Images