CN102217230B - 开通方法和系统 - Google Patents

Abstract

公开了开通一个或多个网络元件的方法和系统，以及重新开始用于开通一个或多个网络元件的失败的客户服务订单的方法和设备。开通逻辑构架从商业支持系统接收客户服务订单CSO，调用用于执行所述客户服务订单的相应的开通逻辑，并检测接收的客户服务订单是否为要重新开始的CSO。在所述客户服务订单的执行时间，存储历史处理数据。如果检测到接收的客户服务订单是要重新开始的CSO，则开通逻辑构架基于以前存储用于要重新开始的CSO的历史处理数据来建立伪环境。然后，CSO的成功部分定向到伪环境，而CSO的未完成部分定向到实际网络元件。

Description

开通方法和系统

技术领域

本发明涉及开通(供应：provisioning)方法和系统，更具体地，涉及重新开始用于开通一个或多个网络元件(Network Element)的失败的客户服务订单(Customer Service Order)的解决方案。

背景技术

开通是使网络准备好服务于终端用户(end user)的重要方面。开通通常包括多个参数、多个节点的开通，并且开通系统需要保持数据一致。

典型的开通系统如下工作：

CSO(客户服务订单)从运营商(operator)的商业支持系统(businesssupport systems(BSS))发送到开通系统。CSO通常包含一串参数，它们可使一个或多个NE(网络元件)准备好支持某个服务并使订户能使用所述服务。这样的CSO需要被开通到网络中，它可以多个NE(网络元件)的开通结束，有对它们中每个的多个请求/响应通信。

在此种开通序列中，在相同节点内或跨过多个NE都保持数据的完整性和一致性非常重要，因为数据的不完整性和不一致性将导致无法实现服务。典型情况是：

●部分订户数据居于多个NE中并且它们需要精确相同，或者它们是有关的。这些数据要么在所有位置中，要么这些数据应在其中的一些中。

●在开通仅仅一个NE的情况下，可有发送的多个请求并且每个都带有部分数据。商业支持系统想使整个CSO被完成。

用于完整性/一致性问题的传统解决方案包括：

●通过存储未完成命令(即，CSO的未完成部分)进行重试。如果命令在中间失败，典型地由于NE因例如链接失败而不可用，则失败的命令和它之后所有的将一起存储在队列中以稍后执行。

●重新运行以前的命令。将重新运行已经成功执行的、影响订户数据一致性的命令，以消除不一致性。

然而，所述现有解决方案都存在问题。CSO可以朝向一个或多个NE的多个命令结束。命令的生成可依赖于NE自身的状态。例如，在你知道如何生成和执行下一个“修正”命令之前，你需要进行“读取”命令以从NE读取NE的状态。这意味着上述生成非常经常地需要通过一些逻辑/代码动态地而非静态来进行。

于是，对于通过存储未执行命令的上面的重试方法，需要针对在失败时留下的命令进行预测。这很经常是不可能成功进行，特别是在具有复杂逻辑的场景中或当与NE的交互(例如，读取)是强制的时候。

与通过设法稍后调整(fix)不一致性的重试方法相比，重新运行通过取消已经成功进行的并回到以前的状态，而设法直接解决不一致性。其问题是：重新运行场景可能有许多，特别是对于复杂逻辑，并且重新运行太可能在CSO刚失败时失败，于是你将卡住。例如，如果“创建订户”命令失败并且随后的重新运行也在中间失败，则不论通过设法再次创建(由于某部分已经存在，而创建带有已存在部分剩下的新的一个将导致不一致)，或是删除(由于其部分还没有创建，删除将不成功)，你都不能前进。

发明内容

本发明的目的在于解决上述问题的至少某个，并通过重新开始以前失败的开通的尝试，提供解决数据一致问题的新机制。

根据本发明的一方面，提供开通一个或多个网络元件的方法。所述开通方法包括以下步骤：从商业支持系统接收客户服务订单CSO，并调用用于执行所述客户服务订单的相应的开通逻辑。该方法进一步包括以下步骤：检测接收的客户服务订单是否为要重新开始的客户服务订单。如果检测到接收的客户服务订单是要重新开始的客户服务订单，则开通方法进一步包括以下步骤：将客户服务订单的成功部分定向到伪环境，所述伪环境基于存储用于所述客户服务订单的历史处理数据，并且将客户服务订单的未完成部分定向到实际网络元件。

优选地，历史处理数据作为日志数据存储。

优选地，所述开通方法进一步包括以下步骤：从接收的CSO生成至少一个开通命令，并执行所述至少一个开通命令。

优选地，CSO的成功部分包括成功执行的开通命令。

优选地，历史处理数据包括成功执行的开通命令和对应的响应。

优选地，将CSO的成功部分定向到伪环境的步骤包括以下步骤：检索与以前成功执行的命令对应的存储的响应，并将所检索的响应转发到开通逻辑。

优选地，开通方法进一步包括存储客户服务订单的步骤。

优选地，开通方法进一步包括：如果客户服务订单成功执行，则将客户服务订单标记为完成，否则，将客户服务订单标记为失败。

优选地，开通方法进一步包括以下步骤：自动重新开始/重试标记为失败的CSO。

根据本发明的另一方面，提供一种重新开始用于开通一个或多个网络元件的失败的客户服务订单CSO的方法。所述重新开始方法包括以下步骤：调用用于执行所述客户服务订单的开通逻辑，将客户服务订单的成功部分定向到伪环境，所述伪环境基于所述客户服务订单的历史处理数据，并且将客户服务订单的未完成部分定向到实际网络元件。

根据本发明的又一方面，提供一种用于重新开始用于开通一个或多个网络元件的失败的客户服务订单CSO的设备。重新开始设备包括用于调用用来执行所述客户服务订单的开通逻辑的装置、用于将客户服务订单的成功部分定向到伪环境的装置、以及用于将客户服务订单的未完成部分定向到实际网络元件的装置，所述伪环境基于所述客户服务订单的历史处理数据。

根据本发明的再一方面，提供一种开通系统。开通系统包括适于托管(host)至少一个开通逻辑的开通逻辑构架，开通逻辑构架可操作以从商业支持系统接收客户服务订单CSO，与一个或多个网络元件NE通信，并且检测接收的CSO是否为要重新开始的CSO；以及用于存储关于所述客户服务订单的历史处理数据的存储器。开通系统进一步包括如上面定义的重新开始设备，用于重新开始被检测为要重新开始的客户服务订单。

根据本发明的再一方面，提供一计算机程序产品。该计算机程序产品包括程序指令，当通过计算机机器加载时，其可操作以引起计算机机器执行上面描述的开通方法或重新开始方法。

通过上面的技术解决方案，本发明克服了现有技术重新开始解决方案中的问题。处理一致性的传统方法(上面描述的通过排队进行重试和重新运行)需要使开通逻辑知道可引起一致性的所有场景。这对于具有复杂订户数据关系的解决方案可能变得相当复杂。并且该解决方案特定于建立的每个NE开通解决方案(例如，IMS、核心网、发消息)。通过根据本发明的解决方案，可得到一般的构架，并且使开通逻辑没有这样的一致性问题，使得它可被简化并聚焦于正常的开通流。

这样，开通逻辑的设计者不需要考虑诸如一致性问题的一般问题。因此，大大简化了开通的设计，并且也大大降低了对应的设计成本。同时，本发明提供随意地在一个开通逻辑构架或平台配置不同开通逻辑的可能性。本发明可向/从开通系统自由增加/移除开通逻辑，并因此降低了开通系统的总部署成本。

因此，本发明为每个特定开通解决方案带来了大大降低的开发成本。同时，本发明更加健壮防御CSO的失败，从而运营商网络中的订户数据保持得更一致，摆脱了由数据不一致性带给运营商的大量麻烦。

附图说明

现在将参考附图更详细地讨论本发明，其中：

图1示意性示出了根据本发明一个实施例的开通系统的方框图；

图2示意性示出了根据本发明一个实施例的开通方法的流程图；

图3示出了根据本发明一个实施例的以数个命令开通一个网络元件的示例；

图4示出了根据本发明一个实施例的跨过多个网络元件开通的示例；

图5示出了正常的开通方法的序列图，其中出现失败并且CSO未成功执行；以及

图6示出了根据本发明一个实施例的重试图5的失败的CSO并重新开始开通的方法的序列图。

在整个附图中，相同的附图标记指示类似或对应的特征。在附图中指示的一些特征典型地以软件实施，且就这一点而论代表软件实体，例如软件模块或对象。但是，本发明并不限于此。所述特征也可以硬件，固件，或软件、硬件、和固件的任何结合来实现。

具体实施方式

发明人认识到开通系统可划分成2层，一般开通逻辑构架和开通逻辑。开通逻辑构架托管开通逻辑，并提供用于开通逻辑执行的公共环境或平台。

发明人还认识到开通系统承担的各个任务可被划分并分别通过开通逻辑构架和开通逻辑分担。开通逻辑构架能够承担各个开通逻辑共有的一般事务处理(transaction)，以使得开通逻辑不需要考虑将使设计变复杂的一般事务处理并可专注于具体的开通任务。

在上述一般事务处理中，保持数据的完整性或一致性以及从失败重新开始是非常重要的事情。发明人就完整性/一致性问题的解决方案的想法是：通过使用历史处理数据，例如已经存储用于以前失败的CSO的处理日志，为开通逻辑建立“伪”环境。在“伪”环境中，用于从失败中重新开始的事务处理通过开通逻辑构架来处理，并保持对开通逻辑透明。以这种方式，开通逻辑不需要知道失败，开通逻辑只是进行正常开通流，就像没有出现失败。即，可以从开通逻辑省略失败恢复机制。使用前述伪环境，开通逻辑构架可重新开始那个CSO的开通。

图1示意性示出根据本发明一个实施例的开通系统200的方框图。如图1所示，开通系统200耦合到商业支持系统300及一个或多个网络元件NE1-NEn 101-10n。所述商业支持系统300是用于管理和配置网络中支持的服务的专用系统，而所述网络元件NE1-NEn是指在网络中需要向终端用户提供某服务的所有装置或系统。即，所述网络元件NE1-NEn代表用于支持服务的所有必要单元。注意到所述耦合可为有线的或无线的。所述耦合还能够是直接耦合或间接耦合，在间接耦合中存在至少一个中间节点。本发明适用各种各样的耦合并且无意在这方面限制本发明。

开通系统200包括适合用于托管各个开通逻辑700的开通逻辑构架400、用于存储关于CSO执行的历史处理数据的日志数据库500、以及用于存储接收的CSO的CSO数据库600。

开通逻辑构架400托管开通逻辑700，并能创建用于开通逻辑700的“伪”环境，以重新开始以前失败的开通。

在根据本发明的开通处理的开始，开通系统200(或开通逻辑构架400)从商业支持系统300接收客户服务订单CSO，并以接收的CSO来开通所述一个或多个网络元件NE1-NEn、101-10n。因此，开通系统200(或开通逻辑构架400)包括通信装置(未示出)，用于代表开通逻辑700与商业支持系统300和一个或多个网络元件NE1-NEn、101-10n通信。然后，开通逻辑构架400调用被托管的(hosted)对应开通逻辑，用于执行所述接收的CSO，并检测接收的CSO是否为要重新开始的CSO。基于接收的CSO，调用的开通逻辑700生成一个或多个命令。开通逻辑构架400将所有命令和响应与和每个命令有关的参数和执行状态一道记录在日志数据库500中。注意到在其它存储介质中存储历史处理数据也是可行的。但使用在开通系统200中存储日志数据的日志数据库500是有利的，因为现有开通系统常常具有这样的功能并且这样的实现将对现有开通系统带来较少更改。CSO数据库600存储来自商业支持系统300的订单。这在商业支持系统300不想再次发送CSO的情况下是需要的，那么直接在CSO失败之后开通系统可检索CSO并自动重新开始/重试它。

如果检测到接收的CSO是要重新开始的CSO，则开通逻辑构架400将建立伪环境，用于执行所述CSO的以前成功执行的命令。否则，将不建立伪环境。在两种情况下，开通逻辑700以相同方式执行生成的命令，并总是考虑生成的命令从新的CSO生成，而不知道任何失败。在伪环境中，开通逻辑构架400从日志数据库检索历史处理数据，以便得到关于成功执行的命令的所有信息，包括用于命令执行的请求、有关的参数、对命令的响应等。通过所有这些历史处理数据，开通逻辑构架400接收来自开通逻辑700的请求并忽略该请求，将所检索的响应、或许与必要的参数或状态一道转发到开通逻辑700。可从该处理中排除实际网络元件NE1-NEn、100-10n的原因在于该处理已经由实际网络元件NE1-NEn、100-10n以前成功执行并且不需要再一次地执行。对于开通逻辑700，开通逻辑构架400装扮成实际网络元件NE1-NEn、100-10n并与开通逻辑700相互作用。

重要点是开通逻辑700不受影响并且甚至不知道重新开始的开通的解决方案。支持伪环境的是开通逻辑构架400。根据本发明的一个实施例，开通逻辑构架400包括负责各个功能的各个模块，它们为多个开通逻辑所共有并且可在开通逻辑构架400中实现。例如，开通逻辑构架400可包括专用于重新开始问题的重新开始设备。

尽管日志数据库500和CSO数据库600被示为两个分离的数据库，但在需要时它们可包含在一个单一数据库中或者跨过多个数据库分布。尽管在此使用术语“数据库”，但它也可由可用来存储想要的信息并能够由计算机访问的所有种类的存储介质来实现，包括但不限于以任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。

以下将参考图2-6详细描述操作和步骤的序列。

图2示意性示出了根据本发明的开通方法的流程图。开通方法开始于步骤S1，其中通过开通系统200从商业支持系统300接收CSO，并将CSO传递到开通逻辑构架400。做为选择，直接通过开通逻辑构架400自身接收CSO。优选地，在步骤S1期间CSO被存储在CSO数据库600中。然后，在步骤S2，开通逻辑构架400调用用于执行所述接收的CSO的对应开通逻辑700，并且调用的开通逻辑700基于接收的CSO生成少许开通命令。在步骤S3，开通逻辑构架400检测接收的CSO是否为要重新开始的CSO。这应已经在CSO中标记。如果接收的CSO不是要重新开始的CSO，则处理进行到步骤S4，其中开通逻辑构架400从以前生成的命令中取命令。然后在步骤S5，开通逻辑构架400将关于所取的命令的请求和有关参数(如果有的话)定向到实际网络元件NEI-NEn、100-10n，即，请求NEI-NEn 100-10n执行所取的命令并返回对应的响应。在步骤S6，实际网络元件NEI-NEn、100-10n执行所取的命令并向开通系统200返回对应的响应。然后，在步骤S7，包括执行的命令和有关参数的请求与对应的响应一道被存储在日志数据库500。在步骤S7之后，处理进行到步骤S8，其中确定CSO是否完整地执行。即，确定是否CSO的所有命令都已经执行。如果答案是“是”，则意味着CSO的所有命令都已执行并且处理进行到步骤S13，其中响应发送到商业支持系统300并且开通方法结束。然而，如果在步骤S8确定还有仍未执行的命令剩下，处理返回到步骤S4，其中取下一个命令并且过程以同上面类似的方式进行。

如果在步骤S3，接收的CSO被检测为要重新开始的CSO，则处理进行到步骤S9。在步骤S9，开通逻辑构架400建立用于执行生成的命令的伪环境。然后，在步骤S10，开通逻辑构架400从以前生成的命令中取命令。然后，在步骤S11，确定重新开始的CSO的所取的命令是否以前成功执行。这可通过核对日志数据库500来做。如果它已经成功执行，则在步骤S12开通逻辑构架400将请求定向到建立的伪环境。更具体地，开通逻辑构架400从正执行的开通逻辑700接收请求，并从日志数据库500检索对应的响应，或许与开通逻辑700需要的有关的参数或状态信息一道。然后，响应被转发到开通逻辑700。即，开通逻辑构架400或建立的伪环境由此装扮成实际网络元件，并返回开通逻辑700需要的响应。这样，在开通逻辑700看来，所述命令的执行像往常一样完成。然后，处理返回到步骤S10，像上面那样取并执行重新开始的CSO的下一个命令。如果在步骤S11确定命令以前已经失败，则处理进行到步骤S5，其中开通逻辑构架400将所取的命令定向到实际网络元件NE1-NEn、100-10n。然后，处理如上所述地继续，直到重新开始的CSO的所有命令成功执行。如果重新开始的CSO的所有命令已经执行，则处理进行到步骤S13，其中响应发送到商业支持系统300，并且重新开始的开通方法结束。

注意到就是上面开通方法也可能由于任何种类的失败而失败。如果开通方法在步骤S1-S13的任何一个失败，则方法立刻结束并向开通系统报告错误。然后，为了重新开始开通，仅需要重新启动根据本发明的上述开通方法。

这样的解决方案并不真正关心在开通逻辑内实施什么，它甚至可正进行重新运行。那么重新开始的开通将继续它正在进行的：例如，重新运行。

注意到方法步骤的顺序并不必须如上所述。本领域技术人员意识到上述顺序可随意地改变，除非另有具体指示。例如，可在调用开通逻辑步骤之前执行检测步骤。此外，生成开通命令的操作有时将在步骤S4中执行，因为某些命令的生成依赖于以前命令的结果。更一般地，开通逻辑700的操作可不同于上文地分布，因为本发明并不真正关心在开通逻辑之内实施什么，并且从开通逻辑构架400的角度来说明和描述上面的流程图。

图3示出了本发明的典型应用场景，其中以数个命令开通一个NE。在该场景中，开通逻辑700生成对一个网络元件100的少许开通命令。如果成功执行一个或数个命令但剩下的由于失败而没有执行，则对于网络元件100可存在不一致性。

如图3中所示，开通系统从商业支持系统300接收一个创建用户CSO。在选择性的实施例中，CSO可以已经存储在开通系统200，即在CSO数据库600中，并且不需要从商业支持系统300接收。为了在网络元件100上创建用户，需要从CSO生成至少一个命令。例如，生成两个命令，即，用于为用户创建订户服务简档的一个命令1和用于创建将参照该服务简档的订户的另一个命令。如果第一命令成功但第二命令失败，由于为不存在于系统中的订户创建订户服务简档，网络元件100中将存在数据不一致性。

通过根据本发明的开通重新开始解决方案，开通逻辑构架400将自动地(需要失败的CSO与对应的历史处理数据一道存储在开通系统200中)或在再次接收CSO并检测到它要重新开始之后重试创建用户CSO，开通逻辑如正常的那样运行而不知道它已经为与前面相同CSO运行过。当第一创建订户服务简档命令1’通过开通逻辑700生成时，开通逻辑构架400检测到该命令1′属于“重新开始的”CSO，并将核对日志数据库500以看看该命令是否已经成功执行。在此情况下，它已经成功执行，于是开通逻辑构架400将从日志数据库500历史处理数据中获得响应，并将其转发到开通逻辑700。开通逻辑700获得响应，并且继续处理，完全不知道创建订户服务简档命令其实没被执行。然后，生成了第二命令创建订户2′，开通逻辑构架400再次检测到该命令2′属于“重新开始的CSO”并核对日志数据库500以看看命令是否已成功执行。这次命令2′失败，因此开通逻辑构架400将它定向到NE。然后创建订户命令2′将在网络元件100中执行并且将创建订户。这次，订户在网络元件100中被成功创建，并因此通过参照创建的订户服务简档的创建的订户，成功创建用户。即，完整地执行CSO并且成功地重新开始开通方法。

上述CSO只是用于说明目的的示例。其它种类的CSO也是可能的。从CSO生成的命令的数目并不限于两个，它可以是1个、3个、4个、5个或更多。可不管该数目来应用本发明。

图4示出了本发明的另一个典型应用场景，其中本发明跨过多个网络元件开通。这是根据本发明的重新开始的开通解决方案的最典型使用。如图4中作为示例所示，商业支持系统300向开通系统200发送创建用户CSO。为了完成开通，在本示例中，三个网络元件NE1-NE3、100-103将涉及下面三个步骤：

步骤1：在NE1 100中作为订户创建用户

步骤2：在NE2 102中激活用于用户的存在服务

步骤3：将用户的电话公共Id加入NE3 103中，以使用户经由电话被接入

在图4示出的示例中，前两个步骤成功执行，而第三步骤或许由于NE3 103的失败而出现失败。因此，前两个步骤中的所有命令和响应已经存储在日志数据库500中。当重试该CSO时，将通过开通逻辑构架400以像上面一样的方式“截取”到NE1和NE2的所有以前成功的命令。还使用存储在日志数据库500中的历史处理数据给开通逻辑700伪响应1′、2′。这将确定开通逻辑700不需要被修改并且仍然继续，好像其正在执行新的CSO而不是重新开始的CSO。

当来到以前执行中失败点时，即，在第三步骤3中，它如正常的那样继续，这是因为此阶段中的命令3′将定向到实际网络元件NE3103。这样，完整地执行CSO并且成功地重新开始开通方法。

在另一个应用场景中，本发明处理重新运行失败。为了确保数据一致性，当存在开通失败时一些开通逻辑自身支持重新运行。根据本发明的一个实施例，开通逻辑构架400能够处理这样的重新运行过程失败的场景，并且以和正常开通过程类似的方式重新开始重新运行过程。这样，重新运行过程可从其失败的任何地方继续。通过完成重新运行，消除了潜在的不一致性并且使网络状态回复到原始状态。

图5和图6示出了用于跨过多个网络元件开通的典型场景的更具体的序列。由于步骤量大，其被分组为两大步骤。第一步骤描述示于图5中的正常开通。第二步骤描述了示于图6中的重试CSO和重新开始开通。为了简化说明和解释，在附图中仅示出了两个网络元件NE1-NE2 101-102。但本发明并不限于此。从本公开的教导，本领域技术人员可容易地将两个网络元件扩展到更多网络元件，而不用引入任何创造性努力。

图5示出正常开通方法的序列图，其中出现失败并且CSO未成功执行。从图5中我们可明显地看到开通方法的时序。开通方法工作如下：

1.商业支持系统300发出用于开通的CSO。

2.开通逻辑构架400接收CSO并调用对应的开通逻辑700。

3.开通逻辑700生成命令，并将该命令发送给开通逻辑构架400，以在NE1 100上执行。

4.开通逻辑构架400检测命令并确定它不是从“重新开始的”CSO生成。做为选择，关于接收的CSO，可以已经做完检测。

5.开通逻辑构架400向NE1 100发送命令。

6.NE1 100执行命令并向开通逻辑构架400返回成功的响应。

7.开通逻辑构架400将命令和响应记录到日志数据库500，作为历史处理数据。

8.开通逻辑构架400将响应转发到开通逻辑700。

9.开通逻辑700得到来自NE1的成功的响应，并且继续处理以生成到NE2 102的第二命令。

10.开通逻辑构架400检测命令并确定它不是由“重新开始的”CSO生成的。

11.开通逻辑构架400向NE2 102发送命令。

12.NE2 102执行接收的命令。这次，NE2 102执行命令失败并返回失败的响应。

13.开通逻辑构架400将命令和响应记录到日志数据库500，作为历史处理数据。

14.开通逻辑构架400将响应转发到开通逻辑700。

15.开通逻辑70得到来自NE2 102的失败的响应并中断(abort)处理，并生成错误响应。

16.开通逻辑构架400检测错误响应，并且将失败的CSO存储到CSO数据库600中。该步骤在商业支持系统300不重新发送CSO的情况下是需要的。

17.开通逻辑构架400把该错误通知商业支持系统300。

图6示出根据本发明一个实施例的重试图5的失败的CSO并重新开始开通的方法的序列图。重新开始过程如下：

1.商业支持系统300重新发送CSO，或者在某时段(可配置)之后开通逻辑构架400从CSO数据库600得到失败的CSO。

2.开通逻辑构架400再次调用对应的开通逻辑700，并且向开通逻辑700重新发送CSO，该CSO标记有“重新开始的”标志(flag)。

3.开通逻辑700将开始正常处理，而不知道该CSO之前已经处理过，并且生成到NE1 100的第一命令。

4.开通逻辑构架400检测到这是重新开始的CSO，并核对日志数据库500以看看命令是否已经成功执行。在此情况下，答案是“是”。

5.由于命令成功执行，开通逻辑构架400将针对来自NE1100的以前的响应来核对日志数据库500。实际将不向NE1100发送命令。

6.开通逻辑构架400将响应转发到开通逻辑700。

7.开通逻辑700得到响应而不知道该响应来自日志数据库500，并且继续处理。生成到NE2 102的第二命令。

8.开通逻辑构架400检测到这是重新开始的CSO，并核对日志数据库500，以看看命令是否已经成功执行。在此情况下，答案是“否”。

9.由于命令没有成功执行，开通逻辑构架400将向NE2 102实际发送命令，以再次执行。

10.NE2 102执行命令并返回成功的响应。

11.开通逻辑构架400将命令和响应记录到日志数据库500，作为历史处理数据。

12.开通逻辑构架400将响应转发到开通逻辑700。

13.开通逻辑700从NE2 102得到成功的响应并完成关于NE2 102的处理。

14.开通逻辑构架400检测到成功的响应并在CSO数据库600中将CSO标记为完成。

15.成功执行的通知发送给商业支持系统300。该步骤是可选的。

以上结合本发明具体实施例描述了本发明。应当注意的是，上述实施例描述而不是限制本发明，并且本领域技术人员将能设计许多可选择的实施例而不偏离所附权利要求书的范围。

在权利要求书中，放置在括号之间的任何附图标记不应解释为限制权利要求。词语“包括”(“包含”)不排除未罗列在权利要求中的元件或步骤的存在。在某元件前的“一”或“一个”不排除存在多个此类元件。可通过包含数个不同元件的硬件和通过适当编程的计算机来实现本发明。

在列举数个装置的设备或系统权利要求中，这些装置的一些或全部能通过同一个硬件部件(item)来实施。在相互不同的从属权利要求中记载某些手段(measures)的仅有事实不表明不能使用这些手段的组合产生良好效果。

Claims (32)

1. 开通一个或多个网络元件的方法，包括以下步骤：

从商业支持系统接收客户服务订单CSO；以及

调用用于执行所述客户服务订单的相应的开通逻辑；

其中所述方法还包括以下步骤：

检测所接收的客户服务订单是否为要重新开始的客户服务订单，

如果检测到所接收的客户服务订单是要重新开始的客户服务订单，

将所述客户服务订单的成功部分定向到伪环境，所述伪环境基于存储用于所述客户服务订单的历史处理数据，以及

将所述客户服务订单的未完成部分定向到实际网络元件。

2. 如权利要求1所述的开通方法，其中所述历史处理数据存储为日志数据。

3. 如权利要求1所述的开通方法，进一步包括以下步骤：

从所接收的CSO生成至少一个开通命令，以及

执行所述至少一个开通命令。

4. 如权利要求3所述的开通方法，其中所述CSO的成功部分包括成功执行的开通命令。

5. 如权利要求4所述的开通方法，其中所述历史处理数据包括成功执行的开通命令和对应的响应。

6. 如权利要求1-5中任何一项所述的开通方法，其中通过能托管各个开通逻辑的开通系统构架来建立所述伪环境。

7. 如权利要求1-5中任何一项所述的开通方法，其中，基于所存储的历史处理数据，所述伪环境可操作以伪装成要被开通的网络元件。

8. 如权利要求5所述的开通方法，其中将所述CSO的成功部分定向到所述伪环境的所述步骤包括以下步骤：

检索与以前成功执行的命令对应的所存储的响应；以及

将所检索的响应转发到所述开通逻辑。

9. 如权利要求1所述的开通方法，进一步包括存储所述客户服务订单的步骤。

10. 如权利要求9所述的开通方法，进一步包括：

如果所述客户服务订单成功执行，则将所述客户服务订单标记为完成，

否则，将所述客户服务订单标记为失败。

11. 如权利要求10所述的开通方法，进一步包括以下步骤：

自动地重新开始/重试标记为失败的CSO。

12. 重新开始用于开通一个或多个网络元件的失败的客户服务订单CSO的方法，包括以下步骤：

调用用于执行所述客户服务订单的开通逻辑，

将所述客户服务订单的成功部分定向到伪环境，所述伪环境基于所述客户服务订单的历史处理数据，并且

将所述客户服务订单的未完成部分定向到实际网络元件。

13. 如权利要求12所述的重新开始方法，进一步包括从日志数据库检索所述历史处理数据的步骤。

14. 重新开始用于开通一个或多个网络元件的失败的客户服务订单CSO的设备，包括：

用于调用用于执行所述客户服务订单的开通逻辑的装置，

用于将所述客户服务订单的成功部分定向到伪环境的装置，所述伪环境基于所述客户服务订单的历史处理数据，以及

用于将所述客户服务订单的未完成部分定向到实际网络元件的装置。

15. 如权利要求14所述的重新开始设备，进一步包括：

用于从日志数据库检索所述历史处理数据的装置。

16. 如权利要求14所述的重新开始设备，进一步包括：

用于从接收的CSO生成至少一个开通命令的装置，以及

用于执行所述至少一个开通命令的装置。

17. 如权利要求16所述的重新开始设备，其中所述历史处理数据包括成功执行的开通命令和对应的响应，并且其中所述用于将所述CSO的成功部分定向到所述伪环境的装置进一步包括：

用于检索与以前成功执行的命令对应的所存储的响应的装置；以及

用于将所检索的响应转发到所述开通逻辑的装置。

18. 开通系统，包括：

开通逻辑构架，适于托管至少一个开通逻辑，所述开通逻辑构架可操作以从商业支持系统接收客户服务订单CSO，与一个或多个网络元件NE通信，并检测所接收的CSO是否为要重新开始的CSO；

存储器，用于存储关于所述客户服务订单的历史处理数据；以及

如权利要求14-17中的任何一项所述的重新开始设备，用于重新开始被检测为要重新开始的客户服务订单。

19. 如权利要求18所述的开通系统，进一步包括CSO存储装置，用于存储来自商业支持系统的订单。

20. 如权利要求19所述的开通系统，进一步包括：

用于在所述客户服务订单成功执行的情况下将所述客户服务订单标记为完成、否则就将所述客户服务订单标记为失败的装置。

21. 如权利要求20所述的开通系统，进一步包括：

用于自动地重新开始/重试标记为失败的CSO的装置。

22. 开通一个或多个网络元件的设备，包括：

用于从商业支持系统接收客户服务订单CSO的装置；以及

用于调用用于执行所述客户服务订单的相应的开通逻辑的装置；

其中所述设备还包括：

用于检测所接收的客户服务订单是否为要重新开始的客户服务订单的装置，以及

用于执行以下操作的装置：

如果检测到所接收的客户服务订单是要重新开始的客户服务订单，

将所述客户服务订单的成功部分定向到伪环境，所述伪环境基于存储用于所述客户服务订单的历史处理数据，以及

将所述客户服务订单的未完成部分定向到实际网络元件。

23. 如权利要求22所述的开通设备，其中所述历史处理数据存储为日志数据。

24. 如权利要求22所述的开通设备，进一步包括：

用于从所接收的CSO生成至少一个开通命令的装置，以及

用于执行所述至少一个开通命令的装置。

25. 如权利要求24所述的开通设备，其中所述CSO的成功部分包括成功执行的开通命令。

26. 如权利要求25所述的开通设备，其中所述历史处理数据包括成功执行的开通命令和对应的响应。

27. 如权利要求22-26中任何一项所述的开通设备，其中通过能托管各个开通逻辑的开通系统构架来建立所述伪环境。

28. 如权利要求22-26中任何一项所述的开通设备，其中，基于所存储的历史处理数据，所述伪环境可操作以伪装成要被开通的网络元件。

29. 如权利要求26所述的开通设备，其中将所述CSO的成功部分定向到所述伪环境的所述装置包括：

用于检索与以前成功执行的命令对应的所存储的响应的装置；以及

用于将所检索的响应转发到所述开通逻辑的装置。

30. 如权利要求22所述的开通设备，进一步包括用于存储所述客户服务订单的装置。

31. 如权利要求30所述的开通设备，进一步包括用于执行以下操作的装置：

如果所述客户服务订单成功执行，则将所述客户服务订单标记为完成，

否则，将所述客户服务订单标记为失败。

32. 如权利要求31所述的开通设备，进一步包括：

用于自动地重新开始/重试标记为失败的CSO的装置。