业务审批方法、装置、设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种业务审批方法、装置、设备及存储介质。

背景技术

随着网络技术的进步与移动设备的广泛使用，传统银行业务逐渐开始进入移动端领域，其业务场景也开始趋于多元化，不再局限于银行的办公区域或网点，实现贷款业务等银行业务的移动审批已经成为了建立新时代数字化银行的一个必然需求。

在目前的移动端业务审批过程中，主要是通过移动端直接访问银行系统后台的数据库，这种访问方式下，需要在移动端后台增加与银行系统后台匹配的大量复杂且难以梳理的安全校验与业务规则校验，且系统接口也需要做相应的改造，开发成本极高。

发明内容

本公开实施例提供了一种业务审批方法、装置、设备及存储介质，实现了基于银行系统现有服务器的访问接口访问服务器并进行业务审批，因此不需要对银行系统接口进行针对移动设备的改造，方便开发，节省成本。

第一方面，本公开实施例提供了一种业务审批方法，业务审批方法应用于移动设备，该业务审批方法包括：

确定待审批业务；

确定所述移动设备的数据库中记录的待审批业务对应的业务详情页面的请求地址；

基于请求地址，得到业务详情页面；

对业务详情页面执行审批操作，得到审批结果。

可选地，对业务详情页面执行审批操作，得到审批结果，包括：确定数据库中与待审批业务对应的元素标签名；根据元素标签名，确定业务详情页面中的待处理元素，待处理元素包括待输入提交信息的第一元素和待执行操作的第二元素；向第一元素中输入待审批业务和/或用户信息；对第二元素执行审批操作，确定业务详情页面基于审批操作输出的审批结果。

可选地，该业务审批方法还包括：监测对业务详情页面执行审批操作的等待时长；在等待时长小于阈值的时间段内，确定是否执行完审批操作；若执行完审批操作，则停止监测等待时长，并进行下一步操作。

可选地，确定待审批业务之前，该业务审批方法还包括：接收到通过前端界面发送到移动设备后台的请求，确定请求中包含的用户信息，用户信息包含用户编号；基于用户编号，查询缓存记录中是否存在用户编号；若缓存记录中存在用户编号，则确定身份验证通过。

可选地，该业务审批方法还包括：若缓存记录中不存在用户编号，则通过用户编号，从移动设备的数据库中确定用户编号对应的加密后密码，向服务器发送携带有用户编号和加密后密码的身份验证请求；确定服务器反馈的身份验证请求的结果为身份验证通过。

可选地，该业务审批方法还包括：若身份验证结果为身份验证通过，则将用户信息存入缓存记录中。

可选地，确定待审批业务之前，包括：接收到通过前端界面发送到移动设备后台的请求，确定请求中包含的机构信息，机构信息包括用户机构号；确定移动设备的数据库中包含的用户机构号对应的机构选择请求地址；向机构选择请求地址发送包含用户编号和用户机构号的机构选择请求，得到机构选择的结果。

可选地，向机构选择请求地址发送包含用户编号和用户机构号的机构选择请求之前，包括：确定移动设备的数据库中包含的用户编号和用户机构号对应的权限信息；确定权限信息是否满足数据库中与待审批业务对应的权限要求；若权限信息满足权限要求，确定权限验证通过；或者，若权限信息满足权限要求，确定权限验证不通过，输出权限验证不通过的提示信息。

第二方面，本公开还提供了一种业务审批装置，该业务审批装置包括：

确定模块，用于待审批业务和移动设备的数据库中记录的待审批业务对应的业务详情页面的请求地址，并基于请求地址，得到业务详情页面；

处理模块，用于对业务详情页面执行审批操作，得到审批结果。

可选地，确定模块具体用于：确定数据库中与待审批业务对应的元素标签名；根据元素标签名，确定业务详情页面中的待处理元素，待处理元素包括待输入提交信息的第一元素和待执行操作的第二元素；相应地，处理模块具体用于向第一元素中输入待审批业务和/或用户信息；对第二元素执行审批操作，确定业务详情页面基于审批操作输出的审批结果。

可选地，确定模块还用于：监测对业务详情页面执行审批操作的等待时长；在等待时长小于阈值的时间段内，确定是否执行完审批操作；若执行完审批操作，则停止监测等待时长，并进行下一步操作。

可选地，确定模块还用于：在确定待审批业务之前，接收到通过前端界面发送到移动设备后台的请求，确定请求中包含的用户信息，用户信息包含用户编号；基于用户编号，查询缓存记录中是否存在用户编号；若缓存记录中存在用户编号，则确定身份验证通过。

可选地，确定模块还用于：若缓存记录中不存在用户编号，则通过用户编号，从移动设备的数据库中确定用户编号对应的加密后密码，向服务器发送携带有用户编号和加密后密码的身份验证请求；确定服务器反馈的身份验证请求的结果为身份验证通过。

可选地，确定模块还用于：若身份验证结果为身份验证通过，则将用户信息存入缓存记录中。

可选地，确定模块还用于：在确定待审批业务之前，接收到通过前端界面发送到移动设备后台的请求，确定请求中包含的机构信息，机构信息包括用户机构号；确定移动设备的数据库中包含的用户机构号对应的机构选择请求地址；向机构选择请求地址发送包含用户编号和用户机构号的机构选择请求，得到机构选择的结果。

可选地，确定模块还用于：在向机构选择请求地址发送包含用户编号和用户机构号的机构选择请求之前，确定移动设备的数据库中包含的用户编号和用户机构号对应的权限信息；确定权限信息是否满足数据库中与待审批业务对应的权限要求；若权限信息满足权限要求，确定权限验证通过；或者，若权限信息满足权限要求，确定权限验证不通过，输出权限验证不通过的提示信息。

第三方面，本公开还提供了一种移动设备，该移动设备包括：

至少一个处理器；

以及与至少一个处理器通信连接的存储器；

其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使移动设备执行如第一方面任一所述的业务审批方法。

第四方面，本公开还提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现如本公开第一方面任一所述的业务审批方法。

第五方面，本公开还提供了一种计算机程序产品，计算机程序产品包含计算机执行指令，计算机执行指令被处理器执行时用于实现如本公开第一方面任一所述的业务审批方法。

本公开实施例提供的业务审批方法、装置、设备、系统及存储介质，通过确定移动设备前端输入和选择的待审批业务，然后根据数据库中记录的待审批业务对应业务详情页面的请求地址，通过请求地址得到服务器提供的业务详情页面，并基于业务详情页面在移动设备后台自动完成对应审批操作，整个过程不需要用户参与和感知，同时，实际获得和进行审批操作的页面为服务器现有的页面，从而能够满足服务器端的技术栈要求、安全校验和业务规则校验要求，而不需要另外开发现与服务器端匹配的接口，在保证安全性的同时，节省开发成本。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1为本公开实施例提供的业务审批方法的一种应用场景图；

图2为本公开一个实施例提供的业务审批方法的流程图；

图3为本公开另一个实施例提供的业务审批方法的流程图；

图4为本公开又一个实施例提供的业务审批方法的流程图；

图5为本公开一个实施例提供的业务审批装置的结构示意图；

图6为本公开一个实施例提供的移动设备的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

下面以具体地实施例对本公开的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例进行描述。

现有的基于移动设备的银行业务审批，一般采用简单的移动端直接调用方式，即通过传输控制协议(Transmission Control Protocol，简称TCP)连接直接向移动端后台发起交易，然后移动端后台经过一定的校验规则后同步更新银行系统服务器数据库，完成贷款的审批与发放。但移动端后台的校验规则为移动端开发人员设置的，复杂程度和安全性远低于银行系统服务器校验规则的安全性。而如果要保证移动端与银行系统服务器具有相同的安全性，则需要在移动端后台增加大量复杂且难以梳理的安全校验与业务规则校验，同时对银行系统服务器接口也需要做相应的改造，开发成本极高。同时，银行系统服务器的代码开发时间远远早于移动端后台代码开发时间，由于计算机行业发展迅速，移动端和银行系统技术栈往往存在较大差异，适配二者的接口难度大、费时多，要保证相同安全性，对于一个具体的业务功能，往往需要重新开发一套全新的接口，开发难度大，代码复用性低，从而导致软件研发效率低下。

为了解决上述问题，本公开实施例提供一种业务审批方法，通过移动端后台直接访问银行系统的服务器进行验证，在验证通过时，从服务器获得银行系统现有的访问接口，进行业务审批，以减少另外开发移动端程序所需的工作量，同时有效保证基于移动设备审批银行业务的安全性和可靠性。

下面对本公开实施例的应用场景进行解释：

图1为本公开实施例提供的业务审批方法的一种应用场景图。如图1所示，在进行业务审批流程中，移动设备100根据用户110在前端的输入操作，记录用户输入的用户信息、待审批业务等输入信息，然后将输入信息发送到银行系统的服务器120进行验证，并基于访问接口审批对应业务，从而完成业务审批。

需说明的是，图1所示场景中移动设备、用户和服务器仅以一个为例进行示例说明，但本公开不以此为限制，也就是说，移动设备、用户和服务器的个数和位置关系可以是任意的。另外，该应用场景还可以包含其他设备，例如数据存储设备等，该数据存储设备相对服务器120或移动设备100可以是外部存储器，也可以是集成在服务器120或移动设备100中的内部存储器。

以下通过具体实施例详细说明本公开提供的业务审批方法。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本公开一个实施例提供的业务审批方法的流程图。该业务审批方法应用于移动设备。如图2所示，本实施例提供的业务审批方法包括以下步骤：

步骤S201，确定待审批业务。

其中，待审批业务为移动设备通过用户在前端的业务审批相关应用中输入和选择得到的业务相关信息。业务审批相关应用可以是移动端的信贷类管理应用，也可以是移动端单独开发的用于业务审批的页面组封装后的应用程序。特别地，业务审批相关应用在用户输入和选择待审批业务时，并不与银行系统服务器进行交互，从而使得业务审批相关应用仅需要满足移动端的技术栈要求，开发难度低。

进一步地，待审批业务包括服务器端对应业务审批程序中需要的全部相关信息，如业务具体种类、年限、上一审批节点的审批人意见等。

其中，移动设备可以为任意移动终端设备，如手机、平板电脑等。

可选地，移动设备从业务审批相关应用中获取的待审批业务对应的信息，保存在移动设备内的数据库中，以方便查询和调用。

步骤S202，确定移动设备的数据库中记录的待审批业务对应的业务详情页面的请求地址。

示例地，移动设备的数据库中包含有预设的字典表，字典表中有移动端开发人员预先记录的全部待审批业务种类，以及服务器端开发人员预先记录的与待审批业务种类对应的服务器端业务详情页面的请求地址。

业务详情页面用于表示包含完成业务审批所必要的输入信息和进行设定触发操作的页面文件。业务详情页面可以有一个，也可以有多个，根据需要办理的审批业务而定，且为预先设置完毕的现有页面。

进一步地，业务详情页面为服务器端的现有页面，因而满足银行系统服务器对安全校验、技术栈等方面的要求。

因此，可以通过查询数据库中的字典表，获取待审批业务对应业务详情页面请求地址。进一步地，一个待审批业务种类在字典表中可能对应多个页面的请求地址，也可以是对应同一请求地址中页面的多个可选的次级页面，如请求地址对应服务器端固定的业务选择页面，根据业务选择页面上选择的待审批业务不同，可以进入不同的业务详情页面。

因而，可以通过对与待审批业务种类对应的页面的标签进行关键词定位，如具有特定命名规则的页面文件名、内容中包含特定标签或特定表单ID的页面文件；并可通过当前的待审批业务对应的具体环节、事项和业务品种，来确定待审批业务的种类。

可选地，这一过程可通过现有的基于java开发的开源工具HtmlUnit实现，通过HtmlUnit读取各对象接口的文件，从而快速找到业务详情接口。

步骤S203，基于请求地址，得到业务详情页面。

移动设备通过访问请求地址对应的服务器，得到对应的业务详情页面，其过程与服务器端基于请求地址得到业务详情页面的过程相同，因此，这一过程能够接收服务器端现有校验规则的检验，从而保证这样过程的安全性。

得到业务详情页面的过程对于移动设备的用户是无感知的过程，全部在移动设备后台完成，因此，无需考虑与移动端技术栈的匹配问题，同样能节省开发成本。

步骤S204，对业务详情页面执行审批操作，得到审批结果。

其中，审批操作包括输入和选择业务详情页面中需要输入和选择的待审批业务相关信息，以及完成业务审批需要的确认或点击操作。审批结果，包括服务器基于审批操作反馈的确认审批操作对应的结果或审批完成的提示信息。

可选地，审批结果可以对应于审批过程中某一个环节，如初级审批人审批意见的提交反馈结果；也可以是审批过程的全部环节完成后的操作结果，如提交审批意见后得到的审批完成提示。

示例性地，当业务需要后台进行审核时，其基本流程为：有权管理人员通过其对应的设备查看待办审批事项与审批详情，并查看用户信息，以便基于用户信息进行判断，同时查看待办审批业务的流程，从而检查业务审批流程的合规性；然后提交审批结果，并将结果信息发送到服务器，并通过移动设备的前端界面显示发送成功的信息，从而完成需要审核的业务审批的全流程，而这一流程实际上都是基于本实施例前述的业务审批相关应用实现的，而提交审批意见后，移动设备才会开始本实施例从步骤S201至步骤S204的过程，其中，待办理业务即对应前述有权管理人员全部操作和输入的信息。

本公开实施例提供的业务审批方法，通过确定移动设备前端输入和选择的待审批业务，然后根据数据库中记录的待审批业务对应业务详情页面的请求地址，通过请求地址得到服务器端提供的业务详情页面，并基于业务详情页面在移动设备后台自动完成对应审批操作，整个过程不需要用户参与和感知，同时，实际获得和进行审批操作的页面为服务器端现有的页面，从而能够满足服务器端的技术栈要求、安全校验和业务规则校验要求，而不需要另外开发现与服务器端匹配的接口，在保证安全性的同时，节省开发成本。

图3为本公开另一个实施例提供的业务审批方法的流程图。本公开实施例提供的业务审批方法是在图2所示实施例的基础上的细化。如图3所示，本实施例提供的业务审批方法包括以下步骤：

步骤S301、确定待审批业务。

步骤S302、确定移动设备的数据库中记录的待审批业务对应的业务详情页面的请求地址。

步骤S303、基于请求地址，得到业务详情页面。

可选地，当待审批业务对应的业务详情页面还包括需要选择和输入信息的次级页面，如需要填写和转发二级审批人的业务，此时，得到业务详情页面，包括得到业务详情接口和与业务详情接口对应的次级接口。

此时，进入业务详情接口中的业务详情页面文件后，根据页面文件中各元素ID，缩小页面解析范围，然后根据页面文件中的结构标签等获取关键元素，如提交按钮页面对象，然后可通过模拟触发点击一类的事件，从业务详情业务进入二级页面，从而基于二级页面完成业务审批。

在一些实施例中，移动设备的字典表中与待审批业务对应的信息，还包括相对应二级页面的标签关键词或关键元素信息，以方便查询和定位。

步骤S304、确定数据库中与待审批业务对应的元素标签名。

其中，元素包括业务详情页面中的需要交互的表单、输入框、按钮等页面元件，业务详情页面中的每个元素都包含相应的标签；数据库的字典表中，包括有与待审批业务种类对应的元素标签的关键词，通过该关键词，可以确定业务详情页面上的元素标签名。

步骤S305、根据元素标签名，确定业务详情页面中的待处理元素。

其中，待处理元素包括待输入提交信息的第一元素和待执行操作的第二元素。

其中，通过对页面分析，解析包括前述业务详情页面、二级页面在内的访问接口中的页面元素，如通过页面元素的ID或者NAME等标签进行快速定位，也可通过元素之间的父子、元素种类等关系逐步定位，最终获得目标元素，并通过识别对应元素的标签，判断是否需要通过模拟点击等方法进行操作的触发或者是否输入提交信息，并确定需要输入的提交信息，如用户名、机构、待审批业务的类型或其他可以与登录界面中输入的信息相对应的内容，以方便将从确定的待审批业务相关信息中得到的内容填充至对应的元素中。

步骤S306、向第一元素中输入待审批业务和/或用户信息。

其中，用户信息为审批业务相关应用的登录用户的信息，即审批人的信息，如在审批意见上需要附上的审批人的身份和权限说明等信息。在用户登录审批业务相关应用时，就会输入到移动设备中。

步骤S307、对第二元素执行审批操作，确定业务详情页面基于审批操作输出的审批结果。

其中，审批操作，包括对第二元素中的按钮进行点击、与待审批业务相关的表单进行选择，由于这些操作都与审批相关，因而统称为审批操作。

在一些实施例中，当完成全部审批操作时，即完成包括点击提交按钮的操作时，业务详情页面会将审批操作及第一元素中输入的信息发送到服务器，同时自动刷新页面，显示提交完成或审批完成的提示页面，这一提示页面即为审批结果。

其中，输入待审批业务和/或用户信息、执行审批操作及得到审批结果，均是移动设备后台自动完成的过程。移动设备只会在确定审批结果时，将审批结果对应的信息通过业务审批相关应用显示给审批人员。

可选地，在对业务详情页面执行审批操作时，监测对业务详情页面执行审批操作的等待时长；在等待时长小于阈值的时间段内，确定是否执行完审批操作；若执行完审批操作，则停止监测等待时长，并进行下一步操作。

其中，等待时长指从执行审批操作，到页面接收审批操作并触发相应事件的时长。

或者可以采用现有的异步JavaScript和XML(Asynchronous Javascript AndXML，简称AJAX)方法，以处理异步访问。

在一些实施例中，对于业务详情页面需要和服务器进行信息联动的情况，也可以通过这一方法进行。

由此，在移动设备内实现基于服务器现有访问接口进行业务审批的全过程。

其中，步骤S304至步骤S307为对图2对应实施例中步骤S204的进一步细化。

在本实施例中，通过确定待审批业务及其对应业务详情页面的请求地址，进而得到业务详情页面，并基于对业务详情页面的页面分析，确定需要待处理元素，并通过对待处理元素执行对应的操作，得到审批结果，从而完成业务审批。这一过程为移动设备后台基于页面分析技术实现，无须用户参与，从而实现在移动设备端，模拟服务器端的页面登录和操作，进而实现无感知的快速操作；且能够基于服务器端现有的业务详情页面进行审批操作，不需要重新开发访问接口，减小业务开发难度，同时能够满足服务器端对审批业务所需要信息的要求，有效保证业务审批过程的安全性，同时节省开发成本。

图4为本公开又一个实施例提供的业务审批方法的流程图。如图4所示，该业务审批方法可以包括：

步骤S401、接收到通过前端界面发送到移动设备后台的请求，确定请求中包含的用户信息，所述用户信息包含用户编号。

其中，通过前端界面发送到移动设备后台的请求包含头部信息，头部信息为请求信息中固定位置包含的内容，头部信息中包含用户信息和机构信息，其中，用户信息包括用户编号。

具体的，前端界面为移动设备上基于待审批业务设置的业务审批相关应用对应的前端界面，包括用户登录界面和审批界面。

用户在前端界面输入的信息会经过移动设备内预先设置的校验规则校验后，实时保存在移动设备后台的数据库中。

当用户输入完毕所有信息并在前端界面选择完成业务审批或提交业务审批结果时，触发将包含待审批业务的请求发送到移动设备后台的过程。此时，可以从数据库中读取与请求的用户编号对应的用户加密后的密码，确定用户信息。

此处的用户为有权审批人员，而非申请办理业务的银行客户。

此时，用户通过前端界面实现的登录过程，实际上并非通过登录界面与服务器直接连接登录，而是获取用户输入的信息，这一过程不涉及服务器端的交互。在用户提交请求时，将用户信息发送到请求地址进行身份验证，这一过程才会存在与服务器端的交互。

步骤S402、基于用户信息，查询缓存记录中是否存在用户编号。

其中，移动设备内的设置有用于保存包括用户编号和加密后的用户密码的用户信息的缓存记录，当用户信息通过一次服务器端的验证时，服务器端会返回用户信息相关的记录文件(简称cookie)，移动设备将cookie保存到缓存记录中，此时即用户处于登录状态中。在用户再次进行访问时，就可以直接查询缓存记录。

步骤S403、若缓存记录中存在用户编号，则确定身份验证通过。

若缓存记录中存在用户信息，说明用户已进行过身份验证，且身份验证已经通过，此时用户处于登录状态；由此，可以减少访问服务器并验证的过程，以提高审批流程的效率。

进一步地，缓存记录中存在用户信息，还说明用户也完成了机构选择的流程，因此，只需要进行后续的待审批业务相关确认和操作流程即可。

步骤S404、若缓存记录中不存在用户编号，向服务器发送携带有用户编号的身份验证请求。

具体的，通过用户编号，从移动设备的数据库中确定用户编号对应的加密后密码，向服务器发送携带有用户编号和加密后密码的身份验证请求。

查询数据库中与业务审批相关应用对应的相关记录表，获取用户对应的经过加密处理后的密码；通过用户编号和加密处理后的密码，向服务器发起超文本传输协议(HyperText Transfer Protocol，简称HTTP)的请求，即身份验证请求，并通过返回结果判断是否登陆成功。

进一步地，该HTTP请求在服务器端会经过服务器的校验，校验通过后，若通过校验，会收到服务器返回的cookie。

示例性的，用户在对特定业务进行审批，如该用户已经进行过基于该审批应用的业务审批操作，则移动设备上已经保存了其相对应的用户信息和cookie，此时，不需要再向服务器进行用户身份验证流程。而如果用户之前未进行过相对应的业务审批操作，则移动设备会将其登录的账户信息通过http请求发送到服务器，与服务器中记录的审批人员信息进行对比验证，验证通过时，则会将验证通过的信息及相对应的cookie发送到移动设备，移动设备的缓存记录保存该cookie，以方便重复访问。

进一步地，缓存记录中的记录存在时限，超过时限后，缓冲数据库会删除相应记录。

步骤S405、确定服务器反馈的身份验证请求的结果为身份验证通过。

进一步地，若根据验证信息确定验证通过时，将用户信息存入缓存数据库，并设置过期时间等参数。

若该用户之前在同一移动设备进行了登陆，如在业务审批过程中止后，再次进行审批过程，会将用户相关的登陆信息cookie存入数据库缓存，缓存数据库中的记录过期前就不再需要模拟登陆。

可选地，当验证失败时，可以输出需要重新验证或审批操作失败的提示，并且不保存输入的记录。

步骤S406、接收到通过前端界面发送到移动设备后台的请求，确定请求中包含的机构信息，机构信息包括用户机构号。

其中，用户所在机构信息为审批人员对应的机构信息，可以为机构的名称、代码或编号。根据用户所在机构信息不同，其对应的审批权限不同，如某些业务只能在银行分行审批，而不能在支行审批。因此，在完成用户身份验证后，需要对其权限进行确认。

进一步地，用户所在机构信息通过请求的头部信息中的用户机构编号得到。

进一步地，确定机构信息可以在身份验证过程之前，也可以在身份验证之后进行。

步骤S407、确定所述移动设备的数据库中包含的所述用户编号和所述用户机构号对应的权限信息。

其中，确定权限的过程在向服务器发送请求之前进行。一般在接收到从前端界面将发送到后端的请求时，即进行权限的确认。

步骤S408、确定权限信息满足移动设备内的数据库中与待审批业务对应的权限要求。

其中，确定过程在移动设备内部进行，通过与数据库内预设的权限要求对比，从而确定待审批业务对应的权限信息。

进一步地，若所述权限信息满足所述权限要求，确定权限验证通过。

在一些实施例中，权限验证通过时，不反馈任何消息，直接进行后续操作即可。

进一步地，若所述权限信息满足所述权限要求，确定权限验证不通过，输出权限验证不通过的提示信息。

在一些实施例中，权限验证不通过时，中止业务审批的相关流程；输出权限验证不通过的提示信息还包括：自动切换到前端界面中的机构选择页面中，重新选择机构，再选择完毕后再次提交请求，并重新进行权限验证；或者，直接停止业务审批流程。

步骤S409、确定移动设备的数据库中包含的用户机构号对应的机构选择请求地址。

进一步地，根据请求头部信息中的用户编号和用户机构号，从移动设备的数据库字典表中获取机构选择请求地址。

在一些实施例中，机构选择请求地址为固定值，不同用户编号和用户机构号对应的区别为向机构选择请求地址传递的参数不同。

步骤S410、向所述机构选择请求地址发送包含所述用户编号和所述用户机构号的机构选择请求，得到机构选择的结果。

携带上用户编号和用户机构号的机构选择信息，向机构选择请求地址发送机构选择请求，基于发送的机构选择信息，实现服务器端的机构选择，得到机构选择的结果。

其中，机构选择结果一般为服务器反馈的机构选择完成的信息。由于用户的权限在从前端到后端的过程中已经通过了系统内置的权限校验，因此，在向服务器发送请求时，不需要校验权限，只需要完成服务器端办理审批业务所必要的用户机构选择即可。

步骤S411、确定移动设备的数据库中记录的待审批业务对应的业务详情页面的请求地址。

在身份验证和机构选择通过后，移动设备自动进行确定业务详情页面的流程。

步骤S412、基于请求地址，得到业务详情页面。

步骤S413、对业务详情页面执行审批操作，得到审批结果。

在一些实施例中，步骤S401至步骤S413的操作为用户在业务审批相关应用中操作完成并点击提交或相对应按钮后才进行的步骤；由此，将用户操作的步骤和移动设备与服务器交互的步骤彻底分隔开，进而不需要开发移动端业务审批相关应用时，考虑兼容服务器端系统的技术栈和安全性要求，方便开发，节省成本。

在本实施例中，通过移动端先查询缓存数据库，若缓存数据库中有相应记录，就直接向服务器发送请求以获取访问接口，如果不存在相应记录，则再向服务器发送申请以进行身份校验和机构选择，在机构选择通过后确定业务详情页面，并基于业务详情页面进行审批操作，以完成业务审批。通过同时考虑用户的所在机构信息，实现对用户的权限的校验，提高了业务审批效率；同时，由于向服务器发送的请求能够在服务器端经过充分校验，安全性和防假能力也能充分保证。

图5为本公开一个实施例提供的业务审批装置的结构示意图。如图5所示，该业务审批装置500包括：确定模块510和处理模块520。其中：

确定模块510，用于待审批业务和移动设备的数据库中记录的待审批业务对应的业务详情页面的请求地址，并基于请求地址，得到业务详情页面。

处理模块520，用于对业务详情页面执行审批操作，得到审批结果。

可选地，处理模块520具体用于：确定数据库中与待审批业务对应的元素标签名；根据元素标签名，确定业务详情页面中的待处理元素，待处理元素包括待输入提交信息的第一元素和待执行操作的第二元素；相应地，处理模块具体用于向第一元素中输入待审批业务和/或用户信息；对第二元素执行审批操作，确定业务详情页面基于审批操作输出的审批结果。

可选地，确定模块510还用于：监测对业务详情页面执行审批操作的等待时长；在等待时长小于阈值的时间段内，确定是否执行完审批操作；若执行完审批操作，则停止监测等待时长，并进行下一步操作。

可选地，确定模块510还用于：在确定待审批业务之前，接收到通过前端界面发送到移动设备后台的请求，确定请求中包含的用户信息，用户信息包含用户编号；基于用户编号，查询缓存记录中是否存在用户编号；若缓存记录中存在用户编号，则确定身份验证通过。

可选地，确定模块510还用于：若缓存记录中不存在用户编号，则通过用户编号，从移动设备的数据库中确定用户编号对应的加密后密码，向服务器发送携带有用户编号和加密后密码的身份验证请求；确定服务器反馈的身份验证请求的结果为身份验证通过。

可选地，确定模块510还用于：若身份验证结果为身份验证通过，则将用户信息存入缓存记录中。

可选地，确定模块510还用于：在确定待审批业务之前，接收到通过前端界面发送到移动设备后台的请求，确定请求中包含的机构信息，机构信息包括用户机构号；确定移动设备的数据库中包含的用户机构号对应的机构选择请求地址；向机构选择请求地址发送包含用户编号和用户机构号的机构选择请求，得到机构选择的结果。

可选地，确定模块510还用于：在向机构选择请求地址发送包含用户编号和用户机构号的机构选择请求之前，确定移动设备的数据库中包含的用户编号和用户机构号对应的权限信息；确定权限信息是否满足数据库中与待审批业务对应的权限要求；若权限信息满足权限要求，确定权限验证通过；或者，若权限信息满足权限要求，确定权限验证不通过，输出权限验证不通过的提示信息。

在本实施例中，业务审批装置通过各模块的结合，能够实现基于服务器现有的访问接口进行业务审批，同时对于用户无感知，从而方便了移动设备上对应业务应用的开发，节省了开发成本。

图6为本公开一个实施例提供的移动设备的结构示意图。如图6所示，该移动设备600包括：存储器610和处理器620。

其中，存储器610存储有可被至少一个处理器620执行的计算机程序。该算机程序被至少一个处理器620执行，以使移动设备实现如上任一实施例中提供的业务审批方法。

其中，存储器610和处理器620可以通过总线630连接。总线630可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extendedindustry standard architecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于实现数据库访问装置与其他设备(例如客户端、读写库和只读库)之间的通信。

存储器610可能包含随机存取存储器(random access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

处理器620可以是通用处理器，包括中央处理器CPU、网络处理器(networkprocessor，NP)等；还可以是数字信号处理器DSP、专用集成电路ASIC、现场可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

相关说明可以对应参见方法实施例所对应的相关描述和效果进行理解，此处不予赘述。

本公开一个实施例提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行以实现如上任一方法实施例提供的业务审批方法。

其中，计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本公开一个实施例提供了一种计算机程序产品，其包含计算机执行指令，该计算机执行指令被处理器执行时用于实现如上述方法实施例中的业务审批方法。

在本公开所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。