一种业务处理方法及装置与流程

本发明涉及业务支撑系统设计技术领域，特别是指一种业务处理方法及装置。

背景技术：

移动公司客户关系管理属于核心业务系统，系统功能菜单多达1600个，系统支撑的角色包括普通营业员、营业班长、客户经理、账务员、投诉管理员等诸多角色，经过多年的发展，系统需要一定程度的重构。

现有系统存在单点登录系统，使用多个系统时不需要同时登录，各系统布局类似。根据中国移动集团公司的规范，业务支撑系统界面一般如图1所示，工作区是办理业务的核心区域。营业员与客户沟通确定办理某项业务后通过搜索、导航等方式打开功能菜单，功能菜单展现在工作区，每个业务菜单有特定的统一资源定位符(uniformresourcelocator，url)。在办理业务的过程中工作区会访问页面框架获取一些缓存数据。

由于系统规模庞大，重构只针对营业员角色使用的100多个核心功能。重构时方案是新建一个系统，不在原系统上开发，因此面临一个问题：营业员可操作的功能菜单总计600个左右，新建系统无法提供营业员所需的全部功能。

技术实现要素：

本发明的目的在于提供一种业务处理方法及装置，用以解决新建业务支撑系统无法提供营业员所需的全部业务功能的问题。

为了实现上述目的，本发明提供了一种业务处理方法，应用于第一业务支撑系统，所述第一业务支撑系统提供第二业务支撑系统中的部分业务功能，所述方法包括：

获取用户发送的业务请求；

根据所述业务请求对应的统一资源定位符url路径，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供；

若所述业务请求对应的业务由所述第一业务支撑系统提供，则对所述业务请求进行响应处理；

若所述业务请求对应的业务由所述第二业务支撑系统提供，则将所述业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对所述业务请求进行响应处理。

其中，所述根据所述业务请求对应的统一资源定位符url路径，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供，具体包括：

根据所述url路径中存放资源的主机域名信息，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供。

其中，所述若所述业务请求对应的业务由所述第二业务支撑系统提供，则将所述业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对所述业务请求进行响应处理，包括：

若所述业务请求对应的业务由所述第二业务支撑系统提供，则对所述业务请求进行封装处理，得到与所述第二业务支撑系统适配的业务请求；

将与所述第二业务支撑系统适配的业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对封装后的业务请求进行响应处理。

其中，所述指示所述第二业务支撑系统对封装后的业务请求进行响应处理，包括：

若所述用户已完成登录验证，且所述用户第一次通过所述第一业务支撑系统向所述第二业务支撑系统发送业务请求，则获取所述第二业务支撑系统为所述用户分配的、用于保持会话状态的会话控制session对象；

根据所述session对象，指示所述第二业务支撑系统对封装后的业务请求进行响应处理。其中，所述将与所述第二业务支撑系统适配的业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对封装后的业务请求进行响应处理的步骤之后，还包括：

获取所述第二业务支撑系统对封装后的业务请求进行响应处理后的响应报文；

对所述响应报文进行解析处理，得到适配于所述第一业务支撑系统的响应报文并返回给用户。

其中，上述业务处理方法，还包括：

获取用户在所述业务请求响应处理过程中输入的用户隐私信息；

若所述用户隐私信息为隐私程度大于预设阈值的高密级信息，则将所述高密级信息或根据所述高密级信息形成的高密级认证标识分别保存于所述第一业务支撑系统的服务器及所述第二业务支撑系统的服务器中；

若所述用户隐私信息为隐私程度低于预设阈值的低密级信息，则将所述低密级信息分别以适配于第一业务支撑系统和第二业务支撑系统的代码格式保存于所述第一业务支撑系统中。

本发明还提供了一种业务处理装置，应用于第一业务支撑系统，所述第一业务支撑系统提供第二业务支撑系统中的部分业务功能，所述装置包括：

第一获取模块，用于获取用户发送的业务请求；

判断模块，用于根据所述业务请求对应的统一资源定位符url路径，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供；

第一处理模块，用于若所述业务请求对应的业务由所述第一业务支撑系统提供，则对所述业务请求进行响应处理；

第二处理模块，用于若所述业务请求对应的业务由所述第二业务支撑系统提供，则将所述业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对所述业务请求进行响应处理。

其中，所述判断模块具体用于根据所述url路径中存放资源的主机域名信息，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供。

其中，所述第二处理模块包括：

封装单元，用于若所述业务请求对应的业务由所述第二业务支撑系统提供，则对所述业务请求进行封装处理，得到与所述第二业务支撑系统适配的业务请求；

发送单元，用于将与所述第二业务支撑系统适配的业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对封装后的业务请求进行响应处理。

所述发送单元包括：

获取子单元，用于若所述用户已完成登录验证，且所述用户第一次通过所述第一业务支撑系统向所述第二业务支撑系统发送业务请求，则获取所述第二业务支撑系统为所述用户分配的、用于保持会话状态的会话控制session对象；

响应子单元，用于根据所述session对象，指示所述第二业务支撑系统对封装后的业务请求进行响应处理。其中，上述业务处理装置，还包括：

第二获取模块，用于发送单元将与所述第二业务支撑系统适配的业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对封装后的业务请求进行响应处理的之后，获取所述第二业务支撑系统对封装后的业务请求进行响应处理后的响应报文；

解析模块，用于对所述响应报文进行解析处理，得到适配于所述第一业务支撑系统的响应报文并返回给用户。

其中，上述业务处理装置，还包括：

第三获取模块，用于获取用户在所述业务请求响应处理过程中输入的用户隐私信息；

第一存储模块，用于若所述用户隐私信息为隐私程度大于预设阈值的高密级信息，则将所述高密级信息或根据所述高密级信息形成的高密级认证标识分别保存于所述第一业务支撑系统的服务器及所述第二业务支撑系统的服务器中；

第二存储模块，用于若所述用户隐私信息为隐私程度低于预设阈值的低密级信息，则将所述低密级信息分别以适配于第一业务支撑系统和第二业务支撑系统的代码格式保存于所述第一业务支撑系统中。

本发明实施例具有以下有益效果：

本发明实施例的业务处理方法，获取用户发送的业务请求；根据业务请求对应的url路径，判断业务请求对应的业务是否由第一业务支撑系统提供；若业务请求对应的业务由第一业务支撑系统提供，则对业务请求进行响应处理；若业务请求对应的业务由第二业务支撑系统提供，则将业务请求发送至第二业务支撑系统，并指示第二业务支撑系统对所述业务请求进行响应处理。本发明实施例能够使操作员从第一业务支撑系统登录，登录后在第一业务支撑系统中同时使用第一业务支撑系统和第二业务支撑系统的功能，实现用户跨系统的操 作，进而解决了现有新建业务支撑系统无法提供营业员所需全部业务功能的问题。

附图说明

图1为现有业务支撑系统的界面示意图；

图2为本发明实施例的业务处理方法的第一工作流程图；

图3为本发明实施例的业务处理方法的第二工作流程图；

图4为本发明实施例的业务处理装置的结构框图。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合具体实施例及附图进行详细描述。

本发明的实施例提供了一种业务处理方法及装置，用以解决新建业务支撑系统无法提供营业员所需的全部业务功能的问题。

本发明实施例的业务处理方法，应用于第一业务支撑系统，所述第一业务支撑系统提供第二业务支撑系统中的部分业务功能，所述方法包括，如图2所示，包括：

步骤21：获取用户发送的业务请求。

在本发明的具体实施例中，第一业务支撑系统具体为新业务支撑系统，第二业务支撑系统具体为传统业务支撑系统，新老系统均是web系统，基础协议为http，传统业务支撑系统中可提供操作员所需的全部业务功能，新业务支撑系统中只提供操作员经常使用的一些业务功能。

这里，操作员可首先通过网页或客户端登录新业务支撑系统，接着通过搜索、导航等方式打开某功能菜单，然后通过单击、双击或输入回车等方式选择某菜单项，并将菜单请求发送至新版系统。

步骤22：根据所述业务请求对应的统一资源定位符url路径，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供。

在本发明的具体实施例中，可具体根据所述url路径中存放资源的主机域名信息，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供。

新、老两个系统中菜单的url路径是不一致的，对老系统和新系统均包含的功能，如开户，在老系统中统一资源定位符url是/crm/so/common/somainforsec.jsp？busioper_id＝500000020001，在新系统中是gsm_open，在新系统开户未完成时开户功能对外提供的菜单项对应的url为上述第一个。可见新老系统的菜单项所对应的url差异较大，新版系统能够识别其url路径区分业务由哪个系统处理。

步骤23：若上述业务请求对应的业务由上述第一业务支撑系统提供，则对所述业务请求进行响应处理。

这里，若上述业务请求对应的业务由上述第一业务支撑系统提供，则直接由第一业务支撑系统对上述业务请求进行响应处理，并将响应处理的结果返回给用户。

步骤24：若上述业务请求对应的业务由上述第二业务支撑系统提供，则将上述业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对所述业务请求进行响应处理。

在本发明的具体实施例中，若上述业务请求对应的业务由上述第二业务支撑系统提供，则由第一业务支撑系统的http代理模块与第二业务支撑系统进行交互，并指示所述第二业务支撑系统对所述业务请求进行响应处理。

本发明实施例的业务处理方法，获取用户发送的业务请求；根据业务请求对应的url路径，判断业务请求对应的业务是否由第一业务支撑系统提供；若业务请求对应的业务由第一业务支撑系统提供，则对业务请求进行响应处理；若业务请求对应的业务由第二业务支撑系统提供，则将业务请求发送至第二业务支撑系统，并指示第二业务支撑系统对所述业务请求进行响应处理。本发明实施例能够使操作员从第一业务支撑系统登录，登录后在第一业务支撑系统中同时使用第一业务支撑系统和第二业务支撑系统的功能，进而解决了现有新建业务支撑系统无法提供营业员所需全部业务功能的问题。

进一步地，如图3所示，上述步骤24包括：

若所述业务请求对应的业务由所述第二业务支撑系统提供，则对所述业务请求进行封装处理，得到与所述第二业务支撑系统适配的业务请求。

将与所述第二业务支撑系统适配的业务请求发送至所述第二业务支撑系统， 并指示所述第二业务支撑系统对封装后的业务请求进行响应处理。

在本发明的具体实施例中，若上述业务请求对应的业务由上述第二业务支撑系统提供，则由第一业务支撑系统通过http代理模块与第二业务支撑系统进行交互，具体的，新系统判断用户请求的菜单项对应的url指向哪个老系统(一个新系统可与多个老系统建立相关的连接)，并由http代理模块将用户的功能请求进行适于该老系统的封装，具体可能包括创建request对象，设置url参数、设置请求报文头和设置报文体、设置字符编码格式等具体实现方式。将经过适应性封装的用户功能请求发送至对应的老系统服务器，由老系统服务器对用户功能请求进行处理。

进一步地，上述指示所述第二业务支撑系统对封装后的业务请求进行响应处理，包括：

若所述用户已完成登录验证，且所述用户第一次通过所述第一业务支撑系统向所述第二业务支撑系统发送业务请求，则获取所述第二业务支撑系统为所述用户分配的、用于保持会话状态的会话控制session对象；

根据所述session对象，指示所述第二业务支撑系统对封装后的业务请求进行响应处理。在本发明的具体实施例中，第二业务支撑系统首先根据用户功能请求中包含的用户信息通过sso(单点登录)平台判断该用户是否已经登录，若完成登录验证，第二业务支撑系统判断该用户是否首次由新系统的代理模块向老系统发起请求，若为首次，则老系统为该代理模块分配session，以便后续的跨系统用户请求均能够无缝衔接的执行。

进一步地，上述将与所述第二业务支撑系统适配的业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对封装后的业务请求进行响应处理的步骤之后，还包括：

获取所述第二业务支撑系统对封装后的业务请求进行响应处理后的响应报文。

对所述响应报文进行解析处理，得到适配于所述第一业务支撑系统的响应报文并返回给用户。

在本发明的具体实施例中，第二业务支撑系统对该用户功能请求进行处理，并进行响应，向第一业务支撑系统的http代理模块返回响应报文。具体的， http代理模块获取response对象、设置报文头和从第二业务支撑系统响应报文中获取数据写入当前response对象等，得到适用于第一业务支撑系统的响应报文后由第一业务支撑系统向客户端用户做出响应。

本发明实施例中实现了用户登录新系统并在新系统基础上办理新、老系统中的所有业务。由于操作员登录的是新系统，当请求的功能由老系统提供时，为方便操作员需要，通过代理手段实现在新系统的“办理区”直接展现老系统的页面，不需要用户跨系统重新登录，并且由老系统为该用户的代理模块分配session使用户的每部操作均能在新老系统间无缝传递。本发明实施例实现了在两个系统代码、部署都是独立情况下的用户无感知调用，既方便了用户，也避免了繁杂的系统开发和重构。

下面结合图3具体说明本发明实施例的工作流程。

如图3所示，本发明实施例的业务处理方法，应用于新业务支撑系统，所述第一业务支撑系统提供第二业务支撑系统中的部分业务功能，所述方法包括：

步骤31：操作员通过网页或客户端登录新系统，并发送http业务请求至新系统。

步骤32：新系统根据http业务请求对应的url路径，判断http业务请求对应的业务是否由新系统提供。

步骤33：若http业务请求对应的业务是否由新系统提供，则本地处理后返回请求响应。

步骤34：若http业务请求对应的业务是否由老系统提供，则需要通过新系统http代理模块与老系统进行交互。

具体的，新系统判断用户请求的菜单项对应的url指向哪个老系统(一个新系统可与多个老系统建立相关的连接)，并由http代理模块将用户的功能请求进行适于该老系统的封装，具体可能包括创建request对象，设置url参数、设置请求报文头和设置报文体、设置字符编码格式等具体实现方式。将经过适应性封装的用户功能请求发送至对应的老系统服务器，由老系统服务器对用户功能请求进行处理。

步骤35：老系统对用户请求进行验证，并进行响应。

具体的，首先根据用户功能请求中包含的用户信息通过单点登录(single signon，sso)平台判断该用户是否已经登录，若完成登录验证，老系统判断该用户是否首次由新系统的代理模块向老系统发起请求，若为首次，则老系统为该代理模块分配时域session，以便后续的跨系统用户请求均能够无缝衔接的执行。

步骤36：老系统向http代理模块返回响应报文并返回步骤34。

步骤37：http代理模块解析老系统响应报文，重新组织返回报文给客户端。

此步骤中具体可能包括获取response对象、设置报文头和从老系统响应报文中获取数据写入当前response对象等，得到适用于新系统的响应报文后由新系统向客户端用户做出响应。

本发明实施例能够使操作员从第一业务支撑系统登录，登录后在第一业务支撑系统中同时使用第一业务支撑系统和第二业务支撑系统的功能，实现用户跨系统的操作，进而解决了现有新建业务支撑系统无法提供营业员所需全部业务功能的问题。

此外，用户在操作新系统办理新系统涉及的业务时会涉及不同信息的输入或上传，当用户再调用老系统其他功能时，若涉及到上述相同的信息时通常需要用户重新上传。例如用户在新系统中完成了开户的功能，开户过程中输入了用户的基本信息如性别、生日和所处省份等低密级信息，同时输入了身份证号，并输入了身份证号或上传了身份证扫描件等高密级信息。此时若用户需要在老系统上开通海外漫游功能，通常需要重新输入上述低密级信息和高密级信息，用户体验差。

因此，本发明实施例的业务处理方法，还包括：

获取用户在所述业务请求响应处理过程中输入的用户隐私信息；

若所述用户隐私信息为隐私程度大于预设阈值的高密级信息，则将所述高密级信息或根据所述高密级信息形成的高密级认证标识分别保存于所述第一业务支撑系统的服务器及所述第二业务支撑系统的服务器中；

若所述用户隐私信息为隐私程度低于预设阈值的低密级信息，则将所述低密级信息分别以适配于第一业务支撑系统和第二业务支撑系统的代码格式保存于所述第一业务支撑系统中。

在本发明的具体实施例中，将用户低密级信息保存在新系统框架中，若新系统需要低密级信息，则可直接从用户本地获取；对于老系统所需的低密级信息，新系统框架也对照老系统原先获取的方式进行了保存(即在新系统框架中对应新系统和老系统的不同获取代码保存了两套本地低密级信息)，若老系统需要低密级信息，仍可在不修改代码的情况下从新系统框架中获取，一方面避免用户多次重复输入不重要的信息，一方面低密级信息保存在用户本地减轻系统间调用压力也不具有泄密风险。

当新系统获取用户高密级信息后，将该信息同时通过代理模块传送至老系统(无论各老系统是否需要)；或者当用户首先使用老系统相关功能，老系统通过新系统获取该高密级信息时，新系统服务器本地保存该高密级信息。即将相同的高密级信息同时保存在新系统的服务器和老系统的服务器上。当新系统或老系统再次需要该高密级信息时不再需要用户输入或上传，可直接由新系统或老系统的服务器调取，一方面保存在服务器更加安全可靠，另一方面避免高密级信息多次传输中的安全风险。或者

当新系统获取用户高密级信息后，进行基于该高密级信息的认证操作，并形成高密级标识，并将该高密级标识通过代理模块传送至老系统；或者当用户首先使用老系统相关功能，老系统通过新系统获取该高密级信息后基于该高密级信息进行认证操作形成高密级标识，并将该高密级标识返回新系统进行保存。即将相同的高密级标识同时保存在新系统的服务器和老系统的服务器上。(例如用户在执行新系统的开户功能时输入了高密级信息身份证号，上传了高密级信息身份证复印件，新系统根据前两项高密级信息认证用户的真实身份后，生成“实名认证”的高密级标识，并将该标识同步至老系统。此时若用户再通过老系统办理开通海外漫游的功能时就不再需要从用户获取高密级信息，甚至不再需要从新系统获取高密级信息，而可以通过老系统本地的“实名认证”标识直接继续业务的办理)。一方面在服务器保存高密级标识(可以删掉经过验证的高密级信息)比直接保存高密级信息更安全，另一方面新老服务器间也无需再发送高密级信息而仅需要发送高密级标识，进一步提高安全性。

本发明实施例的业务处理方法，通过用户本地存储低密级信息，新系统、老系统服务器侧存储高密级信息或高密级标识，避免用户重复输入信息，并且 使跨系统的用户请求更安全可靠。

如图4所示，本发明的实施例还提供了一种业务处理装置，应用于第一业务支撑系统，所述第一业务支撑系统提供第二业务支撑系统中的部分业务功能，所述业务处理装置4包括：

第一获取模块41，用于获取用户发送的业务请求；

判断模块42，用于根据所述业务请求对应的统一资源定位符url路径，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供；

第一处理模块43，用于若所述业务请求对应的业务由所述第一业务支撑系统提供，则对所述业务请求进行响应处理；

第二处理模块44，用于若所述业务请求对应的业务由所述第二业务支撑系统提供，则将所述业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对所述业务请求进行响应处理。

本发明实施例的业务处理装置，所述判断模块42具体用于根据所述url路径中存放资源的主机域名信息，判断所述业务请求对应的业务是否由所述第一业务支撑系统提供。

本发明实施例的业务处理装置，所述第二处理模块44包括：

封装单元441，用于若所述业务请求对应的业务由所述第二业务支撑系统提供，则对所述业务请求进行封装处理，得到与所述第二业务支撑系统适配的业务请求；

发送单元442，用于将与所述第二业务支撑系统适配的业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对封装后的业务请求进行响应处理。

本发明实施例的业务处理装置，所述发送单元442包括：

获取子单元4421，用于若所述用户已完成登录验证，且所述用户第一次通过所述第一业务支撑系统向所述第二业务支撑系统发送业务请求，则获取所述第二业务支撑系统为所述用户分配的、用于保持会话状态的会话控制session对象；

响应子单元4422，用于根据所述session对象，指示所述第二业务支撑系统对封装后的业务请求进行响应处理。本发明实施例的业务处理装置，还包括：

第二获取模块45，用于发送单元442将与所述第二业务支撑系统适配的业务请求发送至所述第二业务支撑系统，并指示所述第二业务支撑系统对封装后的业务请求进行响应处理的之后，获取所述第二业务支撑系统对封装后的业务请求进行响应处理后的响应报文；

解析模块46，用于对所述响应报文进行解析处理，得到适配于所述第一业务支撑系统的响应报文并返回给用户。

本发明实施例的业务处理装置，还包括：

第三获取模块47，用于获取用户在所述业务请求响应处理过程中输入的用户隐私信息；

第一存储模块48，用于若所述用户隐私信息为隐私程度大于预设阈值的高密级信息，则将所述高密级信息或根据所述高密级信息形成的高密级认证标识分别保存于所述第一业务支撑系统的服务器及所述第二业务支撑系统的服务器中；

第二存储模块49，用于若所述用户隐私信息为隐私程度低于预设阈值的低密级信息，则将所述低密级信息分别以适配于第一业务支撑系统和第二业务支撑系统的代码格式保存于所述第一业务支撑系统中。

需要说明的是，该装置是与上述方法实施例对应的装置，上述方法实施例中所有实现方式均适用于该装置的实施例中，也能达到相同的技术效果。

本发明实施例的业务处理方法及装置，获取用户发送的业务请求；根据业务请求对应的url路径，判断业务请求对应的业务是否由第一业务支撑系统提供；若业务请求对应的业务由第一业务支撑系统提供，则对业务请求进行响应处理；若业务请求对应的业务由第二业务支撑系统提供，则将业务请求发送至第二业务支撑系统，并指示第二业务支撑系统对所述业务请求进行响应处理。本发明实施例能够使操作员从第一业务支撑系统登录，登录后在第一业务支撑系统中同时使用第一业务支撑系统和第二业务支撑系统的功能，实现用户跨系统的操作，进而解决了现有新建业务支撑系统无法提供营业员所需全部业务功能的问题。

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