用于向物流系统的用户发送通知的方法和系统的制作方法

专利名称：用于向物流系统的用户发送通知的方法和系统的制作方法
技术领域：
本发明涉及一种用于向一个物流系统的用户发送通知的方法和系统。
为运行一个具有许多用户和一个或多个物流供应方的一个物流系统必需向系统参与者发送某些信息。以下将发送信息称作为通知。这种通知可以通过一个或多个不同通信途径来进行。
通知将根据物流系统内所出现的事件来发送。其中物流系统的一个事件可以不触发、触发一个或多个通知。物流系统的事件与通知的对应可以在一个通知组件里根据交易逻辑来实现。
通知可以用不同的通信途径来发送。通信途径表明了送交一个通知的种类和方式。原则上可以通过多种通信途径来送交具有同一个信息内容的通知。
尤其是运输企业和递送企业经营一种用于注册用户的包裹专业设备时必须有一种具有各种不同的通知和通信途径的物流系统。例如一个邮政企业为其注册用户经营这种包裹专业设备或包裹自动机，递送者将这些用户的包裹或其它邮寄物存放在设备的一个机柜里。在此后必需通知该用户他的一个包裹已存放。另外该物流系统还必须告知，例如用户是否已将其包裹取走。此外在物流系统之内还必须交换有关新客户的注册情况、客户数据、收取期限和代收货款数额。
在一个用于包裹专业设备的物流系统之内通常通过信函或短讯发送通知。通知的产生、管理和发送优选包含不同的数据库和处理过程。
在分配货物时已知使用了物流系统。对于所要分配的货物来说可指各种不同的商品、材料和物品。物流系统用来例如在仓库、中间仓库、集装箱、汽车、发送者和接收者之间通过各种不同的运输途径来组织和监控有关的货物的分配。物流系统的功能要适合于以下要求，即，使货物的分配能够在考虑了例如运输途径、负载、储存时间和数据传送等方面实现优化。
专利申请人特别采用了物流系统用来分配信件和货物邮件(小包裹、包裹)、运输箱、托盘和集装箱。所涉及的物流系统主要用于在一个发送者和一个接受者之间进行邮寄物的分配，其中例如像运输速度、仓库和车辆的使用以及传送邮寄物数据这样的标准是很重要的。
由德国的实用新型专利201 03 564U1已知例如一种用来发送和接收邮寄物的系统，这种系统似乎尤其适用于电子商务。系统包括有多个自动发货机(ADM)，邮寄物就寄放在这里并在这里取走。该系统还包括有一个用来处理系统操作的LAMIS-服务器-计算机程序。例如通过通信途径如信函，通知用户为他储存在ADM上的邮寄件。
本发明的目的是提供一种用于将通知传送给一个物流系统用户的方法，它可以对系统内的各种不同的事件产生尽可能灵活的反应并产生对用户来说专门的通知。
根据本发明该目的通过如下方法来解决根据物流系统之内的各种不同的事件调用各种不同的具有相应功能的模块，其中这些模块产生通知指令，它将被传送给一个中央发送组件，该组件根据指令产生相应的通知并将其发送给用户。
本发明的目的另外还通过一个用于实施此方法的系统来实现。
具有各自功能的用来对物流系统之内的事件产生反应的模块构组成了一个外部接口，通过这接口反映了各种不同的使用情况。在本发明的一个特别优选实施例中，由这些模块所产生的通知指令只是在特殊情况下才直接传送给发送组件，而它一般被登记在一个通信请求等候队列里。队列读取器由计时器控制，从通信请求队列里读出指令并将它传送给中央发送组件。在此之前要校验通知的状态。状态的变化可能是例如在这期间一个包裹已被提取，或者提取者有了变化。
根据本发明的一个方面，该发送组件根据来自一个或多个数据库的数据而产生通知。对于这些数据库而言更为适宜地至少是指一种用户数据库、一种包裹数据库、一种自动机数据库和一种文件数据库。用户数据库包含了例如关于物流系统的注册用户的数据，其中各个用户都有一个ID(标识符)用来进行识别。这些数据可以包含有地址、电话号码或者其它。包裹数据库包含了在系统之内所输送的包裹的信息，其中包裹同样也通过一个ID来识别。自动机数据库包含了使用在系统之内的包裹专业设备的信息，同样也包含有ID。
文件数据库包含了用于产生用户特有的通知的模板。为此它包含有优选用于信函通知和SMS(短讯服务)通知的模板。这些模板具有虚拟参量，将数据库里用户特有的数据填入其中。
所产生的通知被发送组件传送至一个网关用于发送给用户。
本发明的其它优点、特点和适宜的改进设计方案见从属权利要求和根据附图对优选实施例所作的如下说明。
附图示出了

图1一种特别优选的实施例的外部接口、中央发送组件和通信请求队列之间的处理流程；图2一种特别优选的实施例的一个通信请求队列、一个中央发送组件和一个递送合同逻辑之间的流程；图3中央发送组件、各个不同的数据库和网关之间的处理流程；及图4在一个用于传送通知的系统之内的流程总示意图。
以下将描述一种物流系统，用来运行一种带有一个或多个具有可变数量注册用户的包裹专业设备的系统。这是指本发明的一种特别优选的实施例，这种根据本发明的方法当然也适合于其它的在其中发送通知的物流系统。
用于运行一个或多个包裹专业设备的物流系统根据其功能例如分成至少如下的处理过程UC BNK1确认一个用户的注册UC BNK2修改用户数据UC BNK3通知“新包裹”UC BNK5通知“包裹已被取走”
UC BNK6通知“包裹已送回”UC BNK7通知“确定代理人”UC BNK8通知“取消代理人”对于系统之内所列的事件给用户发送通知，它告诉用户这个事件和/或确认这个事件。在本发明的一种特别优选实施例中，通过物流系统的各个不同的模块和/或单元来实施各个处理过程。模块中例如可以是一种用户数据库，注册单元或者物流系统-系统管理单元。模块同样与其它组件一起构成了一个外部接口10。
以下说明在模块之内的流程和功能调用。由模块所产生的通知指令或者传输给一个中央发送组件30直接发送或者记录入一个通信请求队列组件40里延时发送。在该队列组件里可以有定期地阅读所有等候的通知指令并发送相应的通知。所产生的通知优选以信函或短讯形式发送。
UC BNK1确认注册情况一个新用户在包裹专业设备的物流系统中注册后，一个注册模块就调用一个功能模块newRecipient(User)(新接受者(用户))用于发送一个确认通知。通过与该用户对应的当事人的当事人逻辑模块，功能模块确定必要的通知，并将其加入到一个通信请求队列里延时发送。
UC BNK2修改用户数据在用户修改储存在一个用户数据库里的用户数据之后，用户数据库就调用一个功能模块updateRecipient(User)(更新接受者(用户))用于发送一个确认通知。通过与该用户对应的当事人的当事人逻辑模块，功能模块确定必要的通知，并将这通知加入通信请求队列里延时发送。
UC BNK3通知“新包裹”若一个包裹被送给一个物流系统-包裹自动机，那么就将一个对应的信息发送给一个物流系统-系统管理单元。该物流系统-系统管理单元调用一个功能模块notifyDelivery(Parcel)(通知交货(包裹))用于发送一个确认通知。通过与该包裹对应的当事人的当事人逻辑模块，功能模块确定必要的通知，并将该通知加入通信请求队列里延时发送。
UC BNK5通知“包裹已取走”若一个包裹已从一个物流系统包裹自动机里取走了的话，那么就将一个相应的信息发送给物流系统-系统管理单元。该物流系统-系统管理单元接着调用一个功能模块notifyPickup(Parcel)(通知取货(包裹))
用于发送一个确认通知。通过与该包裹对应的当事人的当事人逻辑模块，功能模块确定必要的通知，并将该通知加入通信请求队列组件里。
UC BNK6通知“包裹已返回”若一个包裹已从一个物流系统-包裹自动机里送回的话，因为在一个规定的取走期限内没有被取走，那么将一个相应的信息发送给物流系统-系统管理单元。该物流系统-系统管理单元调一个功能模块parcelFailed(parcel)(包裹发送失败(包裹))用于发送一个确认通知。通过与该包裹对应的当事人的当事人逻辑模块，功能模块确定必要的通知，并将此通知加入通信请求队列组件中。
UC BNK7通知“确定代理人”如果为已在一个物流系统包裹自动机里等候的一个包裹设定了一个代理人，那么将一个相应的信息发送给物流系统-系统管理单元。这物流系统-系统管理单元就调用一个功能模块addSubstitute(Parcel，User)(增加代理(包裹，用户))用于发送一个确认通知。通过与该包裹对应的当事人的当事人逻辑模块，功能模块确定必要的通知，并将此通知加入通信请求队列组件中。
UC BNK8通知“取消代理人”
若为一个物流系统-包裹自动机里的一个等候的包裹里已取消了一个确定的代理人，那么将一个相应的信息发送给物流系统-系统管理单元。该系统管理单元调用一个功能模块removeSubstitute(Parcel，User)(取消代理(包裹，用户))用于发送一个确认通知。通过与该包裹对应的当事人的当事人逻辑模块，功能模块确定必要的通知，并将该通知加入到通信请求队列组件里。
此外，例如可以在通过在模块之内通过一些功能来反映如下的事件包裹自动机不起作用notifyADMFailed(Parcel parcel，Boolean failure)(通知ADM失败(包裹包裹，布尔逻辑失败))类属的通知genericNotification(Parcel parcel，Addressable add，int type)(类属通知(包裹包裹，可设定地址的增加，国际型))通知给递送商包裹送到notifyDeliveryProvider(Parcel parcel)(通知递送提供商(包裹包裹))通知给递送商包裹取出notifyPickupProvider(Parcel parcel)(通告提货供应商(包裹包裹))
分支机构notift Filiale(String description，Delivery Machine adm，Addressablerecipient，booleanfilialeCODParcel)(通告分支机构(字符串说明，发送机adm，具有地址的接收者，布尔分支机构COD包裹))仓库notifyWarehouseDelivery(Stringdescription，DeliveryMachineadm，Addressable recipient)(通知仓库运输(字符串说明，发送机adm，具有地址的接收者))地址检验失败notifyAddresscheckFailed(String description，Addressable recipient)(通知地址检验失败(字符串说明，具有地址的接收者))国际互联网-口令notifyInternetPassword(string description，Addressable recipient)(通知国际互联网-口令(字符串说明，具有地址的接收者))信息文本类属notifyGenericMessageText(string description，Addressable recipient)(通知信息文本类型(字符串说明，具有地址的接收者))递送-返回供应商(notify DeliveryRetoureProvider(Parcel Parcel)(通知递送-返回供应商(包裹包裹))
提取-返回供应商notifyPickupRetoureProvider(Parcel Parcel)(通知提取-返回供应商(包裹包裹))通过递送代理人-供应商取出notifyPickupByDeliveryAgentProvider(Parcel Parcel)(通知通过递送代理人-供应商取出(包裹包裹))修改电子邮箱E-mailnotifyEmailchanged(Addressable recipient)(通知修改电子邮箱E-mail(具有地址的接收者))修改移动电话号码notifyMobileNumberChanged(Addressable recipient)(通知修改移动电话号码(具有地址的接收者))修改邮政编码notifyPostpinChanged(Addressable recipient)(通知修改邮政编码(具有地址的接收者))修改口令notifyInternetPassword Changed(Addressable recipient)(通知网络口令修改(具有地址的接收者))通知最好以信函或SMS(短讯服务)形式发送，为此例如可以使用一个信函和SMS网关。
为了使用按照本发明的方法在实践中也已确认为适宜的是对没法发出的通知一览表定期地(例如每隔24小时)进行人工的后处理。
图1至4表示了根据本发明的系统的一种特别优选的实施例的最重要组成组件的总览图。外部系统用阴影线表示，而属于通知系统的部分则用白色表示。
图1示出了一种通知组件的一个特别优选实施例的构成。通知组件与一个外部接口10相连接，该接口在物流系统出现某些事件时就从外面被调用。接口通过具有各自功能的多个模块构成。物流系统的事件通过一个未示出的B2B帐目逻辑组件而转变成通知指令。对于某些特殊情况来说可以将这些指令直接通过一个中央发送组件30来发送。然而按照标准将这些指令写入在一个通信请求队列组件40里并从那里定时控制地转送至发送组件30。这例如允许在较迟的时刻(例如在2天或7天之后)来定义提醒通知。写入请求队列的优点还在于此处对失败的发送自动进行重复发送。
图2可见在写入通信请求队列组件40之后的工作流程。在通信请求队列组件40里的指令按定时控制由一个队列阅读器50读出。再次对一个B2B递送合同逻辑20进行校验，看状态在这期间是否已经修改。状态的修改例如如下进行取走了一个寄存的包裹或者取包人已经修改。若成功地确认了，那么将一个通信请求传送给发送组件30用于进行发送。
图3表示了与中央发送组件60联系在一起的工作流程。在发送组件里的过程流用箭头表示。发送组件从外面得到指令，然后从连接的数据库里读取必要的数据用来传送通知。就数据库来说至少是指一种用户数据库70、一种包裹数据库80和一种自动机数据库90。自动机数据库包含了系统的包裹专业设备的数据。然后由文件数据库100里阅读一个由B2B组件20预先规定的模板110并用实际的数据替代模板里的虚拟参量。这样所产生的信函或SMS可以通过例如一个信函-和SMS网关120发送。
图4中将通知组件的三个部分汇总成一个共同的总览图。明显地看到在右边的中央发送组件30和左边的交易逻辑组件的部分之间是分开的。
以下详细叙述按照本发明的方法的一种特别优选的实施例的系统的各个组件及其功能。
外部接口外部接口10与通知组件相连接并且直接由各个不同的使用情况得出对于每个使用情况最好规定一个固有的功能，它在通知组件之内实现必要的功能。这些功能对应于物流系统的事件并且涉及到例如包裹对象和/或用户对象。该功能当然可以扩展并且也可以涉及其它的对象。
newRecipient(User)(新接受者(用户))在一个新用户注册之后被调用。
updateRecipient(User)(更新接受者(用户))在一个用户修改了其留在用户数据库里的用户数据之后被调用。
notifyDelivery(Parcel)(通知交货(包裹))当已送入一个物流系统包裹自动机里的包裹之后被调用。
notifyPickup(Parcel)(通知取货(包裹))
当一个包裹已从一个物流系统-包裹自动机里取出之后被调用。
notifyPickup(Parcel)(通知取货(包裹))当一个包裹已从一个物流系统-包裹自动机里取出之后被调用。
parcelFailed(parcel)(包裹发送失败(包裹))当一个包裹已从一个物流系统-包裹自动机里送回之后被调用，因为在某一个取包期限内没有被取走。
addSubstitute(Parcel，User)(增加代理(包裹，用户))若对于一个等候于物流系统-包裹自动机中的包裹已确定了一个代理人的话就被调用。
removeSubstitute(Parcel，User)(取消代理(包裹，用户))若对于一个等候于物流系统-包裹自动机中的包裹已取消了一个确定的代理人的话，就被调用。
所涉及的包裹对象或用户对象都有各自的方法。内部将物流系统的事件转变成临时存储在内部队列40里的通知。这些方法将是否实现或未实现转换和中间存储作为结果返回。
模板机制必需要的模板可以发送出各种不同种类的通知，对于这些通知来说也已确认为适宜的是设置模板110并将其存储在一个文件数据库里。通知的种类通过一个模板名得到反映，这个模板名在通知的信息内容的基础上对模板分类，对于B2C情况需要用例如以下模板新用户注册 BNK1用户数据修改 BNK2包裹送入 BNK3，BNK3N包裹等候达48h BNK4，BNK4N包裹在48小时后送回 BNK5，BNK5N对于最后三种类型的包裹通知来说可以应用有代收货款的包裹的模板变种和没有代收货款的包裹的模板变种。除了名字之外还要通过递送合同、通信途径和语言来标识模板。除了所述的模板之外当然可以应用任意许多其它模板。
对于所有通知来说应该有既用于SMS发送的模板，也有用于信函发送的模板。对于信函发送来说优选需要既用于信息文本，也用于公函文本的模板。
数据库-文档为了使模板110的维护更简单将这些模板都存在一个数据库100里。在本发明的一种特别优选实施例中该数据库包括了多个字段，它表示于以下表格中
需要注意数据库的关键字“contract”根据用于通知的物流系统的事件可以是一个物流供应方或者一个物流缔约方(在BNK1和BNK2时)，也可以是一种递送合同(在BNK3-BNK5时)。
虚拟参数机制也已确认为适宜的是在这模板110之内利用各个不同的虚拟参数，以替代具体的信息。鉴于应用HTML-格式化的信函，这些虚拟参数更为适宜地不应该被定义为HTML-标记。
可以设置至少如下的虚拟参数>M_NR< 物流系统-用户号码的事件>M_Adresse< 称呼>M_FirstName< 名字>M_SurName< 姓>M_SMS< 用户的SMS-号码
>M_Mail< 用户的电子信箱(e-Mail)地址>M_Street< 用户的街道和门牌号>M_ZipCode< 用户的邮政编码>M_City< 用户所在城市地名>AUT_Street< 自动机所在的街道和门牌号>AUT_ZipCode<自动机的邮政编码>AUT_City自动机所在城市地名>POD_Amount< 代收货款数额和货币除了所述的虚拟参数之外当然可以应用其它的虚拟参数。
信息长度在SMS-信息中最大长度一般达160个字符。由于信息如物流系统-自动机的事件的位置具有可变的长度，因此过长的字段(例如说明城市分区的街道或位置的信息)则会造成“超过”160个字符，为了避免一种这样的“超过”，在本发明的一种特别优选的实施例中采用了一个智能机制，这种机制根据各个字段的长度情况、各字段的重要性以及可利用的剩余长度得到尽可能是所有主要的信息。
智能机制的另一种可选的方案就是所有字段在相应数据库里的简化版的文档，从而使最大长度永不超过160字符。但它的缺点在于变化的SMS-模板带来了新的长度限制。因此某些信息如由用户输入的地址就不可能容易地匹配。
B2B递送合同逻辑B2B递送合同逻辑(模块)20规定了对于某一个物流供应方、某一个物流缔约方，以及对某一个递送合同(在某一个物流供应方和某一个物流缔约方之间)来说，这各个交易逻辑应该显得如何。为此这里将各个事件转换成通知指令。物流系统的事件新的接收和更新的接收仅取决于物流供应方或者物流缔约方，与之对应的是相应的用户。物流系统的其它事件与包裹的送交有关联，也就是既取决于物流供应方(它输送包裹)，也取决于物流缔约方(它规定了接收者或者收到者)。为了转换逻辑对于物流系统的每个事件都定义了所要发送的通知的表格(通信请求)，这些包括了多个可以设定的参数。
物流系统的事件如果例如要多次重复地进行通知，或者要告诉多个具有不同角色的人，那么对于每个事件都可以寄存多个通知。
所要告诉的人就是应该通知的那些人。可能的值为接收者、代理人、物流供应方或物流缔约方。
规定了一个应该发送通知的日期。在逻辑里只是存入了一个相对日期，那么该日期利用物流系统的事件的日期换就成一个绝对日期。为此可能的值例如为立即 立即发送通知+x时间单元 在X时间单元后发送-x时间单元 在包裹出发之前的X时间单元里发送。
可以预先规定某一种通信途径。如果某一个逻辑只规定用SMS通知，那么这是必要的。可能的值是信函、短讯和用户(用户所给通信途径)。因此例如可能反映出一个递送合同逻辑，它允许只是通过某一个通信途径来进行通知。
优选可以选择一个用于传送的模板110。这具有如下优点各种不同的文本可以在同一个递送合同里利用，例如用于物流系统的各个不同的事件。模板另外总是交到当前的递送合同的限制。某一个模板(例如BNK1)对于两个不同的递送合同具有不同的内容，此外，对于二个不同的递送通信途径可以提供同一个模板的不同版本。
另外可以存储附带的信息，这些信息需要用来在商业逻辑之内进行区分或者需要用在以后的对逻辑的校验，如这二种如下所示的可能的信息在代收货款包裹时进行区分这里对于具有规定的代收货款额的包裹来说利用另一个模板。这个模板例如包含了代收货款额作为提货者的信息。
在B2B过程，其中虽然有一个包裹的代收货款额，但这个额度并不传送给提货者，因为这代收货款例如通过汇总帐单结算。
校验包裹是否已取走这里应该校验，看包裹是否还在物流系统自动机里或者在这期间已被取走。如果例如在多日之后发送提醒通知，这是特别有帮助的。
包裹-对象必须提供一种方法，它传递回了包裹从包裹自动机里离开的发出日期。这是必要的，以便可以在发出之前X天传送通知。要是没有规定发出日期，那么可以按照标准预定一定数值的自然天。
物流供应方DPAG(B2C-情况)在以下表格中举例规定了在注册一个物流供应方的用户时所要发送的通知(通信请求)。此处是指递送者，没有发送通知。
物流缔约方最终用户(B2C-情况)以下表格举例规定了在注册一种虚拟承包商“最终用户”的用户时所要发出的通知(通信请求)。此处归纳了所有的于B2C情况注册的用户。
递送合同逻辑→最终用户(B2C-情况)对于在一个物流供应方和最终用户之间的B2C逻辑，以下表格举例规定了所要发出的通知(通信请求)
物流供应方LP(B2B-情况)
物流缔约方LC(B2B-情况)
递送合同-逻辑LP→LC(B2B-情况)
通信请求队列需要一个自身的数据库表格，在其中临时存储些用于所要发送的通知(通信请求)的指令。表格优选只是用来管理这队列，而包裹和接收者的具体信息例如各自总是由用户数据库70或者包裹数据库80里读出。
然而可能适宜的是扩展通信请求队列的字段。例如可以接收自动机号和自定义文本说明。这样通知就不会仅与包裹连接，而是在一定情况下也与邮政号码、事件和自动机号码的组合相连接。另外还可以动态地产生通知。
Comm-Type-输入值可以由值“用户”(“User”)预先规定，从而通过由用户所规定的通信途径进行通知。类似地，如果采用用户设定，值“用户”(“User”)可以输入语言设定值“Lang”。是否以及在多大程度上必需要记载记录(状态＝3)，取决于具体的实施。
数据库的存取必须提供对物流系统的以下数据库的存取·用户数据库 提供一个用户的信息，通过用户号来标识·物流供应方数据库提供一个物流供应方的信息·物流缔约方数据库提供一个物流缔约方的信息·递送合同数据库 提供一个物流缔约方的信息
·包裹数据库 提供包裹的信息，通过一个明确的包裹号标识·自动机数据库 提供自动机位置的信息，通过自动机ID来标识发送通知的过程计时器通知组件定期地校验所有在通信队列40中的指令。这通过消息组件内的一个计时器41来实现。计时器时限优选可以自由配置。通信队列阅读器调用计时器功能就可以从通信队列40中阅读出所有记录，它们的发送日期在当天之后。
Select*from communication_Request_queueWhere State＝1//尚未处理和Send Date＜now()； //当前的对象的重新设计从队列中每个所读出的输入记录转换成一个通信请求对象。根据所要通知的使用者的明确的ID(Recipient ID)和包裹的ID(ParcelID)使相应的部分对象重新设计。这是必要的，以便能够查询对象的实际数据例如信函地址。
在这种情况下使用者或者认为是一个用户，一个物流供应方对象或者物流缔约方对象，所有这些对象实现了一个共同的须报告的接口。这提供了必要的方法用来发送通知给相应的对象。如果例如要使一个通知与包裹传送独立无关地进行发送，例如在用户注册时，那么包裹对象可能就取消。
包裹对象又提供了一种方法，借助此方法可以在放有包裹的自动机里进行存取。
所读出的对象物的数据一方面是所要传送的数据(如名字、住址、包裹自动机的位置)，还可以是控制数据(如信函和/或SMS，信函地址)。
逻辑检查从队列40中读出的通信请求根据B2B递送合同逻辑20进行检查，看它们是否还一直是有效的通知。如果只进行一次唯一的校验，那必须根据来自包裹数据库80的数据确保包裹尚未被取走。若包裹在这期间已被取走，那么通知就看作为“已完成的”。因此，该通信请求的状态将从处理的指令的内部队列中取消(状态设定为2＝处理完毕)。
若包裹在包裹数据库80里不再存在，那么就是由于它在这期间已被取走，同样也要将通信请求认证从要处理的指令的内部列表中取消。
中央发送组件通知被转送至中央发送组件30。在那里根据通信请求中所给定的通信途径和使用者的设定规定了，应该按那一种通信途径来发送通知。如果通过商业逻辑预先给定了某种通信途径，但使用者却不支持这种通信途径，那么此处有可能产生一个错误。
若只希望一个通信途径，那就直接调用所想要的SPI(服务供应商界面)。若使用者想通过多种通信途径来进行通知，那必须采取防护措施(预设一定的规则)，使通知通过第一种通信途径能够有效成功，但通过第二种却不到。那么必须重复试验这第二种通信途径，而不重新使用第一种通信途径。为此最有利地对于每个所希望的通信途径都设置了通信请求对象的副本，它则被转送给相应的SPI。
通过单个的通信途径的发送各个通信途径通过所谓SPI(服务供应商界面)反映出来。对于每种通信途径都有一个这样的SPI。每个SPI由通信请求对象来调用。根据该对象中的数据形成一个信函和/或SMS。为此读入适合的模板110，并使虚拟参数由以相应的数据库里读出的信息来代替。
发送的延迟对于发送通知的一种可能想要的限制是在夜间(例如22:00-8:00)或者完全停止处理或者只停止处理SMS-通知。如果想要完全地调准发送，那么这就可以通过例如计时器来实现。由于信函不会有故障，因而是更有利的是夜间只停止发送SMS。为此在SMS-SPI’S之内中断发送并将发送日期定到时间窗口之内的下一个合适的日期。随着在这时间窗口之内计时器走过第一个循环就重新阅读和实施通信请求。
真实性检验通知组件对所要传递的数据进行一种真实性检验。用户必须存在于用户数据库70里，包裹存在于包裹数据库80里。若一个用户例如已经清除了，那么就不再发送通知了。另外必须有包裹自动机的信息(位置)。要检验，看接收者地址(电子信箱或手机号码)是否是正确的，以及是否模板110的所有虚拟参数都可以用数据填满。另外这存在的模板必须具有肯定的真实性根据模板类型(其变化又包括语言、通信途径和B2B逻辑的变化)，必须在模板里有以下重要的数据字段。
要是不存在一个模板或者没有相应的记录，那就中断发送并在一个Log文件里产生一个相应的错误消息。若用SMS发送，那么一种智能机制可以使信息的最大长度达到160字符。
实施发送利用在段落“模板机制”中所述的机制产生所要发送的文本。这文本和接收者信息根据发送类型的不同传递给一个信函或者SMS-网关120。若至网关的传递失败了，那么立即尝试第二次传递，以便能够容易地克服短期的故障。
结果的存入若整个过程成功的话，就可将本发明的一种特别优选实施例中的指令队列中的记录消除，其方法是使字段状态设定为“2”。同时使字段CompletionDate设置为当前日期+钟点。这样的在通信申请40中的记录并不继续进行处理。它们应该更为适宜地在通信队列里保持某个时间可以使用，如果一个通知被证明为不可送出的话。
由于多种原因可能出现错误·用户并未在用户数据70库里或者自动机并不在自动机数据库90里。
·读出的数据不真实(例如没有完全填满)·模板有错或者不存在。
·由于技术方面原因不能发送通知(多次尝试后)。
若出现了错误，那就增加字段“Retry Count”的值。若“RetryCount”超出了一个预先规定的值(这也取决于计时器的频率)，那就在Log文件里产生一个出错消息并例如推动一个人工后处理。这可以是例如对存入数据的校验或者是人工从通信队列里取消记录。为了避免这种有错的通知总是进行再次尝试，一旦达到了一定的重复次数，就将状态定到“9”。这些通知不再被处理。此外，将当前的日期作为中断的日期存入在字段“Completion Date”里。排除故障之后人工将状态重新设到“1”。“Completion Date”和“Retry Count”同样也必须复位。
定期清除通信请求队列必须要进行定期的“清除”。所有办理完的时间长于某个时间间隔(例如一周)的情况应从数据库里去除。另外还应该把所有多于一个月的错误情况从通信请求队列里去除。完成日期或中断日期都存入“CompletionDate”里。也就是例如这样来实施
Delete from Communication-QueueWhere State＝2和Completion_date＜now+7天orState＝9和Completion_date＜now+30天记录机制发送信函或SMS时的故障应该同时记录存入在一个故障-Log-文件里。此LOG文件必须要定期地进行监测，以便例如能够找出一个网关的故障。另外应该至少在第一阶段同样也一起记录所有已发送的通知。这里应用了一种自身的LOG-文件，以简化故障监测。
设计建议和局限对于计时器的实现有多种可选方案。它可以-通过应用服务器的内部计时器；-通过一个工作流程分类(cron job)；-通过一个数据库计时器或者-一种另外开发的解决办法来实现。
第一种变种方法为优选。也可以有多种用来连接信函发送和SMS发送的可选方案-JMAPT(Java Message API)-JMS-利用应用服务器的一种适合的信函服务此处优选两个第一种变化方案版面设计通知组件不是必须包括页面或者互联网页。当然对于各个通知来说必需要有各个不同的模板。有利的是模板可以容易地更换。在以下段落中给出的模板仅为例示性的实施例。当然可以使每个所希望的通知文本与之相应的虚拟参量接合为一体。
BNK1 确认批准注册用信函通知
用SMS通知
BNK2＝确认修改用户数据用信函通知
用SMS通知
BNK3＝通知“新的包裹”用信函通知
用SMS通知
BNK3N＝通知“有代收货款的新包裹”用信函通知
用SMS通知
BNK4＝通知“包裹等候了48小时”用信函通知
用SMS通知
BNK4N＝通知“有代收货款的包裹等候您已48小时”用信函通知
用SMS通知
BNK5＝通知“包裹在48小时后取消”用信函通知
用SMS通知
BNK5N＝通知“有代收货款的包裹在48小时后取消”用信函通知
用SMS通知
对其它组件的要求对象包裹必须准备提供一个对象包裹，它提供一个包裹的信息，并由一个明确的包裹号码来标识·包裹必须提供一种方法，这种方法返回发出日期，也就是在该发出日期时将包裹从包裹自动机里取出。这是必须的，以便能够在发出前X天传递通知。要是没有发出日期的话，那么标准的是例如可以按照特定的某一个自然天数(例如9天)。
·递送合同对象必须通过一种方法来提供。
·包裹对象提供了一种方法，借助于该方法可以在包裹所在的自动机里存取。
对象机器对象机器允许在自动机数据库90里进行存取，通过自动机ID来标识。
·在这对象里的方法必须提供有关自动机位置的信息。所要通知的对象(可通知对象)用户物流供应方和物流缔约方对象用户提供一个用户的信息，它由用户号码来标识。对象物流供应方允许在物流供应方数据库上进行存取。对象物流缔约方提供一个物流缔约方的信息。
·所有对象应用一个共同的可通知的界面。这提供了必备的方法用来将一个通知发送给对应的对象，例如用来阅读电子信箱地址或称呼。
·必须可以通过一种肯定的ID(标识符)来标识可通知对象。为此例如User(用户)的、Logistikprovider(物流供应方)的、或Logistik Contractor(物流缔约方对象)的ID与带有对象类型的标识(US-，LP-，LC-)相联系就可以通过一个方法get Unique ID退回。这方法更为适宜地应该定义在可通知的接口里。
·为了重新设计构造一个通过这ID验证的可通知的对象，完成一个对象制造厂(Object-Factory)，它根据一个这样的ID产生相应的对象物。
逻辑对象物流递送合同，物流供应方和物流缔约方·B2B逻辑例如通过一个共同的接口上调用所有对象。
·这种对象通过明确的ID来标识。为此利用可通知对象的ID(get Unique ID)，它对于物流供应方和物流缔约方已存在。一种相应的方法也应该存在于Delivery Contract(递送合同)里，然后它使与对象类型(DC-)相联系的对象物ID退回。
为了进一步改善方法可能适宜的是单个或一起地实行以下规定的措施
·所有信函都脱机发送，就是使它的记录入一个通信队列里，从这队列里可以将它定期读出并处理。
·执行可以支持任意的(但优选固定的)语言。
·信函优选以普通的文本形式传送。
但本发明的特别优选实施形式为·支持超文本格式的信函。
·用户在注册时选择，想要用什么格式得到信函(普通文本或超文本)。发送时相应地引用其它的模板。
·多种语言性用户可在注册时选择其优选的语言。发送时相应地引用其它的模板。
·通过RFC1149标准支持通知。
·此外可以使用一种“Content Management”(内容管理)系统，以便可以更容易地管理这用于信函和SMS的模板。
标号列表10 外部接口 20递送合同逻辑(模块)30 中央发送组件 40通信请求队列41 计时器 50队列读取器70 用户数据库 80包裹数据库90 自动机数据库 100文件数据库110 模板 120网关
权利要求
1.用于向物流系统的用户发送通知的方法，其特征在于，根据所述物流系统之内的各种不同的事件调用各个不同的带有相应功能的模块，其中所述模块产生通知指令，所述指令被传送给中央发送组件(30)，所述发送组件根据指令产生与之相应的通知，并将所述通知发送给用户。
2.根据权利要求1所述的方法，其特征在于，所述物流系统运行具有一个或多个已注册用户的一个或多个包裹专业设备。
3.根据权利要求1和2中之一或两者所述的方法，其特征在于，用于产生通知的所述中央发送组件(30)在一个或多个数据库上存取。
4.根据权利要求3所述的方法，其特征在于，所述发送组件(30)在至少一个用户数据库(70)、一个包裹数据库(80)、一个包裹专业设备数据库(90)和一个文件数据库(100)上进行存取。
5.根据权利要求4所述的方法，其特征在于，通过ID来实现用户数据、包裹数据和包裹专业设备数据在数据库里的分配。
6.根据权利要求2至5中的一个或多个所述的方法，其特征在于，所述事件中至少涉及以下情况注册新用户；修改用户数据；将新包裹存放入一个包裹专业设备里；从包裹专业设备里取出一个包裹；退回包裹；设定取包裹的代理人；取消代理人。
7.根据上述权利要求中一项或多项所述的方法，其特征在于，由所述模块所产生的通知指令，或者写入发送组件(30)用于直接发送或者写入一个通信请求队列(40)里用于延迟发送。
8.根据权利要求7所述的方法，其特征在于，所述通知指令借助于一个用计时器控制的队列读取器(50)从所述通信请求队列(40)里读出并传送给所述中央发送组件(30)，所述发送组件产生相应的用户专有通知并将所述通知通过一个网关(120)发送给用户。
9.根据权利要求8所述的方法，其特征在于，所述通知指令的状态在传送至所述中央发送组件(30)之前要通过一个递送合同逻辑(60)进行确认。
10.根据上述权利要求中的一项或多项所述的方法，其特征在于，所述通知以信函形式和/或短讯形式发送给用户。
11.用于将通知传送给一个物流系统内的用户的系统，其特征在于，所述系统适用于实施根据权利要求1至10中的一项或多项所述的方法。
12.根据权利要求10所述的系统，其特征在于，所述系统至少包括具有各自功能用于产生通知指令的模块、中央发送组件(30)、通信请求队列(40)和一个或多个数据库。
13.根据权利要求12所述的系统，其特征在于，所述系统包括一个具有模板(110)的文件数据库(100)，用于为每个用户产生各自的通知。
14.根据权利要求11至13中一项或多项所述的系统，其特征在于，所述系统包括一个具有用户信息的用户数据库(70)。
15.根据权利要求11至14中的一项或多项所述的系统，其特征在于，所述系统包括一个具有包裹信息的包裹数据库(80)。
16.根据权利要求11至15中的一项或多项所述的系统，其特征在于，所述系统包括一个具有包裹专业设备信息的自动机数据库(90)。
17.根据权利要求11至16中任意一项或多项所述的系统，其特征在于，所述系统具有一个网关(120)，用于发送出通知。
全文摘要
本发明涉及一种用于将通知传送给物流系统的用户的方法和系统。本发明的特征在于，通过物流系统内的不同的事件调用每一个具有相应功能的不同模块，其中该模块产生消息指令，所述指令被传输到中央发送组件，该发送组件根据该指令产生相应的通知，并且将该通知发送到用户。
文档编号G06Q10/00GK1666214SQ03816031
公开日2005年9月7日 申请日期2003年8月6日 优先权日2002年8月16日
发明者鲍里斯·迈尔, 约翰内斯·桑特尔 申请人:德国邮政股份公司