CN101051918A - 实现业务请求的方法以及联机指令系统 - Google Patents

Abstract

本发明公开了一种实现业务请求的方法，包括：将业务请求分解为第一指令请求；将分解出的第一指令请求转换为针对网元的第二指令请求；将转换后的第二指令请求发送给对应的网元。本发明还公开了一种联机指令系统。由于本发明将来自业务请求系统的业务请求分解为相应的指令请求，并转换为针对网元的指令请求，然后发送给对应的网元，使得操作人员不需要了解具体到网元的指令请求就能够简单地实现业务请求，从而向操作人员提供了简单的业务请求模式，降低了对操作人员专业知识的过高要求，而且还减少了业务请求的完成时间，提高了效率。而且，在本发明实施例的技术方案中，各个部分以及它们之间的逻辑关系都是可配置的，从而能够非常方便地使用。

Description

实现业务请求的方法以及联机指令系统

技术领域

本发明通信技术领域，特别是一种实现业务请求的方法以及一种联机指令系统。

背景技术

电信运营商业务系统，例如客户管理系统(CRM)、客户维护(CustomCare)、帐单(Billing)等业务支撑系统(BSS)/运营支撑系统(OSS)，无法避免都要或多或少地开展一些业务，需要与诸如归属位置寄存器(HLR)/鉴权中心(AuC)、无线智能网(WIN)、移动数据业务平台(MDSP)、短消息中心(SMSC)、语音邮箱系统(VMS)、多媒体信息服务中心(MMSC)、统一消息服务(UM)、下一代网络(NGN)、公共电话交换网(PSTN)等网络侧的网元(NE)存在接口，以进行业务开通(Service Provisioning)，Provisioning系统就相当于介于BSS/OSS和NE之间的接口。Provisioning系统有被称为联机指令系统的，也有被称为业务开通系统(ServiceProvisioning)的，本发明统一称之为联机指令系统。图1给出了联机指令的位置。

目前，电信运营商无法避免会存在CRM、Custom Care、Billing等多个BSS/OSS系统，或存着不同专网的BSS/OSS运营系统，这些系统都需要交叉开展业务，需要与网络侧的网元存在接口，如果每个BSS/OSS业务请求系统都与网元直接相连，而每个网元又存在不同特色的通信协议，那势必会形成一个庞大的网状结构，这样不仅加大了运营商BSS/OSS系统的投入成本，同时还延长了运营商支撑新业务的进度。而且，由各个BSS/OSS系统提供的网元接口功能往往非常薄弱，不利于运营商快速地推出新业务。另外，此时的网元接口可维护性较低，如果发生异常，将很难处理。

现有联机指令系统的模式如图2所示。参照图2，现有的联机指令系统一般存在以下的特点：一个网元接口对应一套独立的程序或进程，接口与接口之间相互独立，每个接口有内部独立的处理逻辑。

申请人在实际使用过程中发现：在现有的技术方案中，如果需要扩展一个接口，即扩展一个网元进程，在某个网元中扩展一个业务，基本采用写死代码的方式。但是，写死代码将会导致局方每次扩展一个业务都需要修改代码。

另外，现有技术中还有一种采用指令模板的方式，即一个网元业务对应一个指令模板。但是，该指令模板只有专业人士才能配置，而且需要较多的时间去调试，并不能由运营商简单地动手进行配置。同时，一般的指令模板都是针对同一网元的简单逻辑，无法针对多个网元的并行、串行、回滚、交互、条件等各种复杂逻辑，比如说，一个业务需要首先向网元1发送查询指令，查看某个业务的状态，再根据获取业务状态条件决定是否并行的向网元2、网元3发送开通指令，如果发送给网元2、网元3任何一条指令失败，则触发回滚操作，取消已经成功开通的业务。在现有接口模式下，还不能支持这样的复杂逻辑。

换言之，由于现有技术中的联机指令系统只能提供对网元写死代码的方式、或者复杂的指令模板方式，而这些方式需要操作人员必须具备非常高深的专业知识以及对相关网元非常了解才能实现。因此，上述现有技术导致普通操作人员无法通过提交一个简单的请求来开通业务。

另外，在很多情况下，运营商希望在开通一个业务时，按照一定的业务逻辑向多个网元发送多条指令，但是，由于现有技术对各个网元进行单独的配置，从而无法支持复杂的业务逻辑，亦即无法支持向多网元并行、串行、条件、回滚等逻辑。

发明内容

有鉴于此，本发明实施例提出了一种实现业务请求方法，用以向操作人员提供简单的业务请求模式。本发明实施例还提出了一种联机指令系统。

本发明实施例提供了一种实现业务请求的方法，该方法包括：

将业务请求分解为第一指令请求；

将分解出的第一指令请求转换为针对网元的第二指令请求；

将转换后的第二指令请求发送给对应的网元。

本发明实施例还提供了一种联机指令系统，该系统包括：

请求分解模块，用于将业务请求分解为第一指令请求；

网元适配器，用于分解、解析所述第一指令请求并转换为针对网元的第二指令请求，以适配同一协议下不同网元之间的差异；

网元前置机，用于在所述联机指令系统与网元之间收发第二指令请求，并实现协议的通用适配。

从上述方案中的一个技术方案可以看出，由于本发明将来自业务请求系统的业务请求分解为相应的指令请求，并转换为针对网元的指令请求，然后发送给对应的网元，使得操作人员不需要了解具体到网元的指令请求就能够简单地实现业务请求，从而向操作人员提供了简单的业务请求模式，降低了对操作人员专业知识的过高要求。由于操作简单，所以还减少了业务请求的完成时间，提高了效率。

进一步，本发明实施例还提供了在业务请求中存在指令请求之间的逻辑关系时，可以根据逻辑关系对应地发送指令请求，从而能够实现现有技术不能实现的逻辑方案，进一步简化了业务请求的模式，降低了对操作人员的要求，并提高了效率。

而且，在本发明实施例的技术方案中，各个部分以及它们之间的逻辑关系都是可配置的，本领域技术人员可以根据各种应用场景的需要对各种信息、业务请求、指令请求以及其中的逻辑关系等等进行配置，从而能够非常方便地使用。

附图说明

图1为联机指令系统的位置示意图；

图2表示现有联机指令系统的模式；

图3为本发明实施例技术方案中的抽象图；

图4为抽象后的业务、网元、业务请求系统的关系模式示意图；

图5为本发明实施例中的方法流程示意图；

图6为本发明实施例中的系统结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，以下举实施例对本发明进一步详细说明。

为了解决现有技术中的缺陷，本发明实施例提供了完整的智能化业务配置方案，使得操作人员只需要向联机指令系统发送简单的业务请求，然后联机指令系统将业务请求分解转换为针对网元的指令请求，并将所述指令请求发送给对应的网元，从而向操作人员提供了简单的业务开通模式，降低了对操作人员的专业要求。

下面具体描述本发明实施例的实现方案。

为了实现本发明实施例的技术方案，需要对业务、网元、指令等进行抽象。

图3为本发明实施例中技术方案的抽象图。

首先描述对于网元的抽象。由于网元接口很多，如果针对一个网元接口开发一套完整的定制逻辑，不仅会导致很大的人力浪费，而且成本太高。因此将网元层面细分为网元前置机层和网元适配器层。

网元前置机层是对协议的一种抽象，解决相同协议的网元连接、签到、报文发送和获取机制，比如网元前置机层可以分为套接字(Socket)MML、远程登录协议(Telnet)、文件传输协议(FPT)、点到点短消息协议(SMPP)、文件类型定义(DTD)XML over HTTP、简单对象访问协议(SOAP)1.1、SOAP1.2等等；在协议层进行同一的抽象，提供给各种采用同一协议、不同实现的网元以同一类型网元前置机。

其次是网元适配器，由于虽然采用同一种协议，但是实际报文拼接的规则、报文解析的规则、心跳机制等等差异比较大，网元适配器的存在就是适配这些差异。

经过以上两层屏蔽后，剩下的就是可以完全配置化的网元信息，其包括两部分：网元基本信息、网元指令信息。其中，网元基本信息包括网元名称、IP、端口(PORT)、登陆用户名/密码、失败重发次数、是否需要签到、网元启动状态、指令发送间隔时间、指令等待响应超时时间、同步/异步方式、连接数目等等。网元指令信息包括网元的指令、指令参数、指令与参数关系、参数枚举值等等。这些网元信息可以直接与网元绑定，但是这种情况下每个网元都需要配置录入对应的相关的指令信息，因此，优选地将网元信息与网元模板绑定，网元模板是对采用同一种指令集的网元的一种抽象，一个网元模板下可能存在很多个网元。另外，网元适配器与网元模板是一一对应的关系。

换言之，一个网元前置机对应多个网元适配器，网元适配器适配不同网元的差异，简明起见，在图3中只标出了与各网元前置机对应的网元适配器中的一个；网元适配器与网元模板为一一对应关系，抽象具有相同指令特性的网元；一个网元模板对应多个实际网元，这些不同的网元具备不同的基本信息。这些抽象的最终目的，就是将所有指令都可配置化，新增、修改指令只需修改配置。

接着描述对业务进行抽象。首先，说明一下业务的概念，业务是提供给上级业务请求系统使用的各种操作的名称，如开户业务、开通短消息业务、关闭来电显示业务、预付费用户充值业务等等。对于网元的指令来说，是不可随意修改的，而业务是可以随意更改的，具备一定的灵活性。

业务抽象的元素包括业务、业务参数、业务参数枚举值、业务与参数之间关系、业务参数与业务参数关系等。经过抽象后，操作人员开展一个新业务，可以灵活地通过配置的方式，在联机指令系统新增一个业务，业务包含几个参数，这些参数可能存在为不同的类型，存在不同的值范围。比如IMSI参数，参数类型为NumberString类型，长度为6-15；如果参数为枚举值类型，则可以配置一下参数的枚举值；如果业务参数存在默认值，则配置一个默认值；如果业务中两个参数之间存在互斥关系，比如输入MSISDN后就不允许输入IMSI，则配置一下在该业务中两个参数之间的互斥关系。

通过上述方式，本发明实施例完成了对提供给业务请求系统的业务的配置。

基于上述基础，下面描述具体业务如何与正确的网元的指令相关联，即对业务与网元指令关系抽象。

首先，在说明业务与指令之间的抽象之前，说明一下网元类型的概念。网元类型是对网元的一种分类，或者叫网元模板的一种分类，比如HLR类型可能有爱立信HLR、诺基亚HLR、西门子HLR等，它们都隶属于同一种类型，叫HLR类型。一般来说，一种网元类型可能存在多种网元模板的网元，但一般只需要向该网元类型中的一个网元发送指令。比如开户，需要向HLR发送指令，即需要向网元类型为HLR的网元发送指令，而HLR存在着爱立信、诺基亚、西门子等多种模板的多个网元，所以实际在发送时，只需要根据一定的规则向其中的一个发送指令，而不是多个。在实际应用中，同一种网元类型的网元会划分有不同的号段，号段分为移动台国际综合业务数据网号码(MSISDN)号段和国际移动用户识别码(IMSI)号段，通过MSISDN/IMSI信息就可以匹配到正确的网元。本发明实施例也可以通过其它标识来匹配到正确的网元。

接下来，分析一下业务包括指令逻辑关系的一些场景。例如，一个开户业务存在如下的指令规则：向网元类型1、网元类型2、网元类型3并行的发送指令；发送指令全部成功后，需要向网元类型4发送指令；网元类型4指令如发送失败，则向网元类型5发送指令，发送成功则向网元类型6发送指令。

根据这样的规则，用户可以通过业务配置系统来映射业务与网元类型的关系，用来配置业务与这6种网元类型之间的关系以及这6种网元类型指令之间的逻辑关系。

在配置完与网元类型的映射关系后，用户还可以根据系统提供的配置业务与具体网元模板指令映射关系的界面，来配置业务与某个具体模板指令的映射关系。同时允许这样的场景，比如：并行发送指令1、指令2，如果其中任何一个失败，则终止执行；指令1、指令2成功后，发送指令3，指令3如果执行成功，则对应该网元模板的指令执行结束，如果失败，则发送指令4、指令5回滚指令1、指令2的操作。实际的配置还可以更复杂，可以引入条件指令，即当业务参数的参数值为A时，发送指令1，为B时，发送指令2。另外，还可以允许这样的方式，指令2的执行，需要从指令1执行的返回结果中取值，取值后赋给指令2的某个参数，进行发送，这种情况可以成为交互指令。

在能够配置业务与指令关系基础上，本发明实施例还能配置业务参数与指令参数的关系，能够让业务参数的值赋给指令参数。当然，对于业务参数枚举值，也可以配置与指令参数枚举值之间的关系，形成不同的映射关系。

通过以上三点的抽象，使得用户在新增业务时，可以智能的配置业务，灵活的设置回滚、条件、交互、并行、串行等逻辑，使得新增业务变成了一种具备友好操作界面的配置性操作，从而向操作人员提供了简单的业务开通模式，降低了对操作人员专业知识的要求。

当然，为了具备良好的可操作性，业务配置还会提供给用户被配置业务的校验功能，由系统自动校验配置业务请求的正确性，避免错误配置。例如，通过处理一个业务请求，判断根据该业务请求所完成的配置能否正确实现该业务请求的目的，从而校验其正确性。

另外，本发明实施例还进一步对业务请求系统进行抽象，从而可以对于业务请求系统的业务权限、号段权限、接入方式、接入IP限制进行管理，同时还可自动设置某个业务参数对应到该业务请求系统的默认值，使得业务请求系统在发请求时尽量减少参数的填写，由联机指令系统对各种复杂参数进行屏蔽，达到只需要填写MSISDN和/或IMSI就能开通业务的程度。

图4给出了抽象后的业务、网元、业务请求系统的关系模型。参照图4，抽象后的核心数据实体有业务、网元模板、指令及参数、业务请求系统，与这些核心数据实体相关的普通数据实体有业务类别、业务参数、网元类型、网元及号段、指令类别、IMSI号段、MSISDN号段、接入IP地址列表，图4中还给出了数据实体之间的关系，这里就不再一一赘述。需要指出的是，图4只给出了一些核心数据实体、普通数据实体以及它们之间的关系，在实际应用中，本领域的普通技术人员根据图4可以显而易见地进行其它数据实体的设置，因此本发明实施例的范围并不局限于图4。

根据上述设置，本发明实施例中从业务请求系统发起业务请求到最终发送到指令请求的过程如图5所示。

参照图5，本发明实施例中业务开通的方法包括以下步骤：

步骤101，运营商需要进行业务开通，操作人员通过诸如BOSS等业务请求系统主动发起与联机指令系统的连接。

举个简单的例子，某运营商要在已有设备上开展一个MMS业务，存在这样的规则，号段在13500000000-13599999999对应接入点名称(APN)为CN1，号段在13600000000-13699999999对应APN为CN2。只需要预先在联机指令中进行简单的配置，完成业务配置(含业务参数)、指令配置(含指令参数，如果已经存在则不需要配置)和业务与指令请求关系配置，并将号段分配逻辑(135号段对应CN1，136号段对应CN2)配置到业务参数与业务参数的逻辑中，以及分配权限给相应的请求系统。那么，在本步骤中，运营商的操作人员通过业务请求系统登录联机指令系统，并发送包括上述号段的开通MMS业务请求。

本发明实施例中的联机指令系统可以提供包括文件接口、Java应用程序接口(API)、socket MML接口、数据库接口、会话描述协议(SDP)接口、远程登录Telnet接口等的请求接口。

步骤102，联机指令系统检查登录的用户名、密码、IP地址是否正确，如果正确，则执行步骤103及其后续步骤；否则拒绝当前的登录，联机指令系统还可以进一步提示用户重新登录。

步骤103，联机指令系统根据已定义的格式，检查来自业务请求系统的业务请求的格式是否正确，如果正确，则执行步骤104及其后续步骤；否则停止当前业务请求，并可以进一步提示用户重新发送业务请求。

步骤104，联机指令系统根据业务请求系统与业务的关系，检查业务请求系统是否具有该业务的权限，如果有，则执行步骤105及其后续步骤；否则停止当前业务请求，并可以进一步提示用户。

步骤105，联机指令系统根据业务请求中所包含的号码段，检查业务请求系统是否具有号码权限，如果有，则执行步骤106及其后续步骤；否则停止当前业务请求，并可以进一步提示用户。

上述步骤102至步骤105为对业务请求系统进行鉴权的过程，虽然这里只给了上述几种鉴权内容，但是本发明实施例的保护范围并不局限于此，另外，上述步骤102至步骤105的先后次序也可以任意变换。

步骤106，联机指令系统根据业务与指令的关系，将业务请求分解为指令请求。

进一步，如果所述业务请求包括指令请求之间的逻辑关系，那么在分解过程中会得到该逻辑关系。

步骤107，联机指令系统通过网元适配器将分解出的指令请求转换为针对网元的指令请求，并向对应的网元发送指令请求，并等待网元的响应，即处理结果。

从前面的描述可知，本步骤中将分解出的指令请求转换为针对网元的指令请求包括：根据业务与指令请求的关系，将分解出的指令转换为针对不同类型网元的指令请求，然后根据同一类型网元中的具体网元即网元模板以及指令的参数，将针对该类型网元的指令请求转换为针对所述网元的指令请求。

进一步，如果存在指令请求之间的逻辑关系，那么联机指令系统将进一步根据所述逻辑关系将指令请求发送给对应的网元。

步骤108，联机指令系统进一步将处理结果回写到指令请求和/或业务请求中。

步骤109，联机指令系统还进一步将处理结果返回给BOSS等业务请求系统。

在上述流程中发送指令请求之后，联机指令系统还可以进一步校验所述业务请求是否正确，例如对所要实现的业务进行模拟测试。如果正确，则返回给业务请求系统；否则，将不正确的信息返回给业务请求系统。

上述流程不仅可以用于业务开通请求，还可以用于业务修改请求、业务取消请求或者业务查询请求等等。

上述流程向操作人员提供了简单的业务请求模式，降低了对操作人员专业知识的过高要求。并且，由于只要求操作人间进行简单的操作，所以还减少了业务请求的完成时间，提高了整个过程的效率。

图6为本发明实施例中联机指令系统的结构示意图。

如图6所示联机指令系统至少包括请求分解模块、网元适配器以及网元前置机，还可以进一步包括请求接口模块、请求鉴权模块、请求处理模块等。

其中，请求分解模块将业务请求分解为各个指令请求，并将指令请求发送给网元适配器。网元适配器分解、解析所述指令请求并转换为针对网元的指令请求，以适配同一协议下不同网元之间的差异。网元前置机则在所述联机指令系统与网元之间收发指令请求，并实现协议的通用适配。

联机指令系统还进一步包括请求处理模块，该请求处理模块将分解后的指令请求形成队列，并提供给网元适配器。进一步，如果请求分解模块还分解出指令请求之间的逻辑关系，那么请求处理模块根据该逻辑关系，将指令请求提供给网元适配器。请求处理模块还可以将网元的处理结果回写到指令请求和/或业务请求中，以及将所述处理结果返回给业务请求系统。

联机指令系统还进一步包括请求接口模块。该请求接口模块用于接收来自业务请求系统的业务请求。根据需要，该请求接口模块可以包括：文件接口、Java应用程序接口(API)、socket MML接口、数据库接口、SDP接口、Telnet接口等等。各种接口用于接收相应渠道的业务请求。例如：数据库接口接收数据库渠道的业务请求，Telnet接口接收Telnet渠道的业务请求。

进一步，联机指令系统还可以包括请求鉴权模块，该请求鉴权模块用于对业务请求系统进行鉴权。根据需要，请求鉴权模块可以包括：用于检查登录的用户名、密码和/或IP地址的第一检查单元；用于检查所述业务请求的格式是否正确的第二检查单元；用于检查业务请求系统的业务权限的第三检查单元；用于检查业务请求系统的号码权限的第四检查单元，等等。

如图6所示的联机指令系统不仅可以用于业务开通请求，还可以用于业务修改请求、业务取消请求或者业务查询请求等等。

继续参考图6，图6中还画出了业务请求系统以及网元。由于篇幅所限，图6中的业务请求系统只例示了帐单&客户维护系统、CRM系统、网络自维护(Web self-care)系统，网元也只例示了HLR、VMS、AAA、IN等。但是，本领域的普通技术人员显然可以看出，本发明实施例并不局限于所例示的内容。

本实施例中的联机指令系统向操作人员提供了简单的业务请求模式，降低了对操作人员专业知识的过高要求。由于仅需操作人员进行操作简单，所以还减少了业务请求的完成时间，提高了整个业务请求的效率。

进一步，本发明实施例的连接指令系统还可以根据逻辑关系对应地发送指令请求，从而能够实现现有技术不能实现的逻辑方案，进一步简化了业务请求的模式，降低了对操作人员的要求，并提高了效率。

而且，本领域技术人员可以根据各种应用场景的需要对本实施例的联机指令系统中的各种信息、业务请求、指令请求以及其中的逻辑关系等等进行配置，从而能够非常方便地使用。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (19)

1、一种实现业务请求的方法，其特征在于，该方法包括：

将业务请求分解为第一指令请求；

将分解出的第一指令请求转换为针对网元的第二指令请求；

将转换后的第二指令请求发送给对应的网元。

2、根据权利要求1所述的方法，其特征在于，该方法进一步包括对业务请求进行鉴权的步骤。

3、根据权利要求2所述的方法，其特征在于，所述对业务请求进行鉴权的步骤包括：

检查登录的用户名、密码和/或IP地址；和/或

检查所述业务请求的格式是否正确；和/或

检查提交所述业务请求的业务请求系统的业务权限；和/或

检查提交所述业务请求的业务请求系统的号码权限。

4、根据权利要求2所述的方法，其特征在于，所述对业务请求进行鉴权的步骤包括：根据业务请求中的移动台国际综合业务数据网号码MSISDN和/或国际移动用户识别码IMSI，来检查提交所述业务请求的业务请求系统的号码权限。

5、根据权利要求1所述的方法，其特征在于，所述将分解出的第一指令请求转换为针对网元的第二指令请求的步骤包括：

根据业务请求，将分解出的第一指令请求转换为针对不同类型网元的指令请求；

根据同一类型网元中的具体网元，将针对该类型网元的指令请求转换为针对所述网元的第二指令请求。

6、根据权利要求1所述的方法，其特征在于，所述将转换后的第二指令请求发送给对应的网元的步骤包括：

将转换后的第二指令请求形成队列，并发送给对应的网元。

7、根据权利要求1所述的方法，其特征在于，所述业务请求进一步包括指令请求之间的逻辑关系；

所述将转换后的第二指令请求发送给对应的网元的步骤包括：根据所述逻辑关系将第二指令请求发送给对应的网元。

8、根据权利要求1所述的方法，其特征在于，该方法进一步包括：

将处理结果回写到第一指令请求、和/或第二指令请求和/或业务请求中；和/或

将处理结果返回给业务请求系统。

9、根据权利要求1所述的方法，其特征在于，该方法进一步包括校验所述业务请求是否正确的步骤。

10、根据权利要求1～9中任意一项所述的方法，其特征在于，所述业务请求为业务开通请求、业务修改请求、业务取消请求或者业务查询请求。

11、一种联机指令系统，其特征在于，该系统包括：

请求分解模块，用于将业务请求分解为第一指令请求；

网元适配器，用于分解、解析所述第一指令请求并转换为针对网元的第二指令请求，以适配同一协议下不同网元之间的差异；

网元前置机，用于在所述联机指令系统与网元之间收发第二指令请求，并实现协议的通用适配。

12、根据权利要求11所述的系统，其特征在于，该系统进一步包括：

请求接口模块，用于接收来自业务请求系统的业务请求，并转发给所述请求分解模块。

13、根据权利要求12所述的系统，其特征在于，所述请求接口模块包括：文件接口、和/或Java应用程序接口API、和/或套接字模块管理语言MML接口、和/或数据库接口、和/或会话描述协议SDP接口、和/或远程登录Telnet接口。

14、根据权利要求11所述的系统，其特征在于，该系统进一步包括：

请求鉴权模块，用于对业务请求进行鉴权。

15、根据权利要求14所述的系统，其特征在于，所述请求鉴权模块包括：

第一检查单元，用于检查登录的用户名、密码和/或IP地址；和/或

第二检查单元，用于检查所述业务请求的格式是否正确；和/或

第三检查单元，用于检查业务请求系统的业务权限；和/或

第四检查单元，用于检查业务请求系统的号码权限。

16、根据权利要求11所述的系统，其特征在于，该系统进一步包括业务处理模块，该业务处理模块用于将转换后的第二指令请求形成队列，并发送给对应的网元。

17、根据权利要求11所述的系统，其特征在于，该系统进一步包括业务处理模块；

所述业务分解模块进一步分解出第二指令请求之间的逻辑关系；

所述业务处理模块根据所述逻辑关系将第二指令请求发送给对应的网元。

18、根据权利要求11所述的系统，其特征在于，该系统进一步包括业务处理模块，该业务处理模块用于将处理结果回写到第一指令请求、和/或第二指令请求和/或业务请求中，或者将处理结果返回给业务请求系统。

19、根据权利要求11所述的系统，其特征在于，该系统进一步包括业务处理模块，该业务处理模块用于校验所述业务请求是否正确。

Images