应用中实现审批的方法和装置与流程

本发明涉及互联网应用技术领域，特别涉及一种应用中实现审批的方法和装置。

背景技术：

随着互联网应用技术的迅猛发展，目前存在着多种多样的企业管理应用，以将企业的日常办公司网络化，进而为企业内部成员之间的沟通和协同工作提供便利。

通过企业管理应用，将越来越多地实现现实工作场景的网络化，进而得以在企业管理应用中提供越来越多的企业办公功能。

所提供的企业办公功能包括审批功能，该审批功能用于将报销等审批流程网络化，但是对于现有的审批功能而言，所涉及的审批人大都是固定不变的，例如，对于任意申请审批的企业成员，所设置的审批人都是一具体的人员，无法根据申请审批的企业成员而自适应地设置，进而使得审批功能实现中审批人的设置缺乏自适应性。

技术实现要素：

基于此，有必要提供一种应用中实现审批的方法，所述方法能够在审批功能的实现中自适应地设置审批人，进而提高审批人设置的自适应性。

此外，还有必要提供一种应用中实现审批的装置，所述装置能够在审批功能的实现中自适应地设置审批人，进而提高审批人设置的自适应性。

一种应用中实现审批的方法，包括：

服务器接收应用发送的申请审批请求包；

根据所述申请审批请求包中的标识信息获得审批关系；

根据所述标识信息中包含的企业标识得到角色数据，从所述角色数据获得组织架构；

在所述组织架构中进行关系型审批人的递归寻找，将递归寻找得到的关系型审批人生成审批人数据；

根据所述审批人数据对所述申请审批请求包进行响应，通过所述响应在所述应用中自动设置审批人。

一种应用中实现审批的方法，包括：

侦听得到应用中触发的申请审批指令；

响应于所述申请审批指令生成申请审批请求包，将所述申请审批请求包发送至服务器；

接收服务器对所述申请审批请求包进行的响应，得到所述服务器自动匹配的审批人数据；

通过所述审批人数据在所述应用中自动设置审批人。

一种企业社交网络中实现审批的装置，包括：

申请接收模块，用于接收企业社交网络发送的申请审批请求包；

关系获得模块，用于根据所述申请审批请求包中的标识信息获得审批关系；

角色数据获得模块，用于根据所述标识信息中包含的企业标识得到角色数据，从所述角色数据获得组织架构；

递归寻找模块，用于在所述组织架构中进行关系型审批人的递归寻找，将递归寻找得到的关系型审批人生成审批人数据；

响应模块，用于根据所述审批人数据对所述申请审批请求包进行响应，通过所述响应在所述应用中自动设置审批人。

一种应用中实现审批的装置，包括：

申请侦听模块，用于侦听得到应用中触发的申请审批指令；

申请组包模块，用于响应于所述申请审批指令生成申请审批请求包，将所述申请审批请求包发送至服务器；

响应接收模块，用于接收服务器对所述申请审批请求包进行的响应，得到所述服务器自动匹配的审批人数据；

自动设置模块，用于通过所述审批人数据在所述应用中自动设置审批人。

为解决上述技术问题，将采用如下技术方案：

服务器接收应用发送的申请审批请求包，由申请审批请求包中的标识信息获得审批关系，进而根据标识信息中包含的企业标识得到角色数据，从角色数据获得组织架构，在组织架构中进行关系型审批人的递归寻找，将递归寻找得到的关系型审批人生成审批人数据，根据审批人数据对申请审批请求包进行响应，通过该响应在应用中自动设置审批人，由此将得以在应用中实现审批人的自动匹配和设置，即能够在审批功能的实现中自适应地设置审批人，提高审批人设置的自适应性。

附图说明

图1是一个实施例中应用中实现审批的方法的流程图；

图2是图1中根据申请审批请求包中的标识信息获得审批关系的方法流程图；

图3是另一个实施例中应用中实现审批的方法的流程图；

图4是另一个实施例中应用中实现审批的方法的流程图；

图5是一个实施例中应用中实现审批的方法的流程图；

图6是另一个实施例中应用中实现审批的方法的流程图；

图7是一个实施例中应用的用户添加页面的示意图；

图8是另一个实施例中应用中实现审批的方法的流程图；

图9是一个实施全名字应用的页面示意图；

图10是图8中侦听应用中触发进行的审批人管理，获取企业标识和审批人设置信息的方法流程图；

图11是一个实施例中实现报销审批的时序图；

图12是一个实施例中进行审批人显示的界面示意图；

图13是一个实施例中应用中实现审批的装置的结构示意图；

图14是图13中关系获得模块的结构示意图；

图15是另一个实施例中应用中实现审批的装置的结构示意图；

图16是另一个实施例中应用中实现审批的装置的结构示意图；

图17是一个实施例中应用中实现审批的装置的结构示意图；

图18是另一个实施例中应用中实现审批的装置的结构示意图；

图19是另一个实施例中应用中实现审批的装置的结构示意图；

图20是图19中审批人管理侦听模块的结构示意图；

图21是本发明实施例提供的一种服务器的结构示意图。

具体实施方式

体现本发明特征与优点的典型实施方式将在以下的说明中详细叙述。应理解的是本发明能够在不同的实施方式上具有各种的变化，其皆不脱离本发明的范围，且其中的说明及图示在本质上是当作说明之用，而非用以限制本发明。

在一个实施例中，该应用中实现审批的方法如图1所示，包括：

步骤110，服务器接收应用发送的申请审批请求包。

向服务器发送申请审批请求包的应用是任意具备审批功能的应用，其运行于终端。用户通过终端中应用被触发运行即可随时通过应用所具备的审批功能来申请进行审批。在一个实施例中，所指的应用可以企业社交网络应用。

企业社交网络应用是一办公工具，即办公沟通工具，企业内部成员作为企业社交网络应用的用户，将通过企业社交网络应用实现企业内部的沟通功能和办公功能。

服务器所接收得到的申请审批请求包则是在用户触发应用中的审批功能，申请进行审批时生成并向服务器发送的。

在具体实现中，服务器接收得到应用发送的申请审批请求包之后，还将申请审批请求包进合法性判断，在判断得到申请审批请求包为合法请求时，方可执行步骤130。

如果判断得到申请审批请求包并不是合法的，即应用中触发的申请审批操作是非法操作，则拒绝执行并在回包中返回对应的错误码。

需要说明的是，对于所进行的合法性判断，包括（1）该申请审批请求包的加密处理是否正确；（2）通过session key（会话密钥）校验申请审批的用户是否为合法的授权用户。

步骤130，根据申请审批请求包中的标识信息获得审批关系。

申请审批请求包至少携带了标识信息，标识信息用于对企业和用户进行唯一标示。

首先需要说明的是，应用是面向于各企业的，即企业可通过应用实现其内部成员之间的沟通功能和办公功能。因此，在应用中，需要通过标识信息对企业和企业内部成员，即用户进行唯一标示。

审批关系用于为申请审批的用户自动设置审批人。该审批关系包括指定的审批人和/或关系型审批人，并且该审批关系是与标识信息中的企业标识唯一对应的，即对于任意企业而言，都有其所唯一对应的审批关系。

由此将使得服务器中审批关系的存储是与标识信息相关的。在具体实现中，将以标识信息对企业所进行的唯一标识来实现审批关系的存储。

因此，根据申请审批请求包中的标识信息能够在服务器中获得审批关系，该审批关系是针对相应企业中的用户，即申请审批的用户生效的。

步骤150，根据标识信息中包含的企业标识得到角色数据，从角色数据获得组织架构。

获得的审批关系包括关系型审批人，因此，服务器针对企业所进行的存储包括如前所述的审批关系，除此之外，还包括角色数据。企业的角色数据也将是以企业标识为索引进行存储的。

因此，在服务器接收到申请审批请求包之后，能够根据申请审批请求包中标识信息包含的企业标识获得角色数据。

标识信息除了包括企业标识之外，还包括了用户标识。根据用户标识在相关企业的角色数据中获得用户标识相关的组织架构。

其中，用户标识相关的组织架构是相应企业组织架构的一部分。具体的，用户所在的项目组以及用户的上级项目组将构成用户标识相关的组织架构。

步骤170，在组织架构中进行关系型审批人的递归寻找，将递归寻找得到的关系型审批人生成审批人数据。

由审批关系便能够获得指定的审批人和/或指定的关系型审批人。因此，能够通过审批关系进行审批人的自动匹配，得到能够为申请审批的用户自动设置审批人的审批人数据。

在审批关系包括了指定的关系型审批人的情况下，将在角色数据所提供的组织架构中进行关系型审批人的递归寻找。

审批关系中的关系型审批人用于指定用户与审批人之间的关系，进而与用户存在此关系的其它用户均能够在用户申请进行的审批中成为审批人。

需要说明的是，审批关系中的关系型审批人可以是多个，则在指定了多个关系型审批人的审批关系中，多个关系型审批人之间存在着关系层级。根据审批关系中指定的多个关系型审批人将会得到多个审批人，通过得到的多个审批人进行多级审批。

企业的角色数据记录了企业中各用户所在的项目组以及自身在项目组中的身份。除此之外，还记录了企业的组织架构。企业的组织架构包括了企业的多个项目组。

其中，需要说明的是，所指的项目组指的是根据企业中的组织架构所构建的多个用户形成的集合，例如，其可对应企业中的一部门，或者一小组，在此不进行限定，将根据实际运营的需要进行灵活地设定。

在企业的角色数据中，根据审批关系中指定的关系型审批人进行审批关系计算即可得到相对用户能够成为审批关系中指定的关系型审批人的其他用户，进而相应得到审批人数据。

通过如上所述的过程，服务器便能够为用户自适应地匹配审批人，进而得到与审批关系中指定的关系型审批人相符合的其他用户，以成为应用中自动设置的审批人，实现了应用中审批人的自动设置。

可以理解的，审批关系可包括指定的审批人和关系型审批人，以为申请进行审批的用户自动设定包括了多种类型的审批人存在的多层级的审批流程，进而适应于实现审批过程的需要。

具体实现中，关系型审批人包括上级关系审批人。上级关系审批人指的是作为用户的上级的其他用户均能够成为用户的审批人。因此，在获得的组织架构中，以用户所在的项目组为起始寻找用户的直接上级。

在此寻找过程中，如果用户自身即为所在项目组的上级，或者项目组所有用户都不是“上级”身份，则递归至该项目组的上一级组织架构寻找直接上级，如此递归向上一级组织架构，直至找到上级为止。

在完成上级关系审批人的递归寻找之后，将由递归寻找得到的上级关系审批人生成审批人数据。

审批关系中包括了多个上级关系审批人的递归寻找过程将与上述寻找过程相类似，即重复执行上述过程，直至完成审批关系中最后一个上级关系审批人的递归寻找。

通过如上所述的过程，实现了审批人的递归寻找，进而能够在企业的组织架构中为用户自适应地自动设置审批人，使得应用中审批人的设置能够与企业实际的组织架构相适配，提高了审批人自动设置的准确性和有效性。

步骤190，根据审批人数据对申请审批请求包进行响应，通过该响应在应用中自动设置审批人。

服务器根据审批人数据对应用发送的申请审批请求包进行响应，以在应用为审批功能实现中申请进行的审批自动设置审批人。

通过如上所述的过程，将使得服务器能够为申请进行审批的应用自适应地提供审批人数据，进而实现应用中审批人的自动设置，并且所自动设置的审批人是根据用户的标识信息所自动匹配得到的，因此，自动设置的审批人与用户相适应，而并不是针对所有用户固定不变的，自适应性得到极大增强。

在一个实施例中，步骤130如图2所示，还包括：

步骤131，提取申请审批请求包中标识信息包含的企业标识。

申请审批请求所携带的标识信息中包含了企业标识，因此，在服务器接收得到应用发送的申请审批请求包之后，由申请审批请求包提取得到标识信息所包含的企业标识。

步骤133，在存储的审批关系中根据企业标识进行查找，得到企业标识对应的审批关系。

服务器中存储了众多企业的审批关系，并且每一企业的审批关系都是以其企业标识为索引进行存储的。因此，在存储的审批关系中，根据企业标识进行查找得到该企业标识所对应的审批关系。

由此可知，该审批关系是相应企业所唯一对应的，换而言之，该审批关系将是对企业中所有成员，即用户生效的。审批关系将为相应企业的所有成员申请进行审批提供了审批人的设置原则，进而得以在审批关系的指引下自动获得与用户适应的审批人，为审批人的自动设置提供了实现的可能性。

在一个实施例中，获得的审批关系包括指定的审批人，如上所述的方法还包括：根据审批关系中指定的审批人进行数据提取得到审批人数据。

一方面，应用中审批人的设置可以是预先指定的审批人，即根据申请审批请求包中的标识信息获得的审批关系中，包括了指定的审批人。指定的审批人是为企业中审批的实现指定具体的用户作为审批人。

如果获得的审批关系包括了指定的审批人，则直接取出审批人数据即可。

获得的审批关系可以仅包括指定的审批人，而另一方面，获得的审批关系并不仅限于此，因此服务器根据审批人数据对申请请求包进行的响应中，既包括指定的审批人所对应的审批人数据，还可包括其它的审批人数据。

另外，审批关系所包括的指定的审批人为多个，则所进行的多个审批人的指定中存在着关系层级；因此，与之相对应的，所提取的审批人数据也是按照指定的多个审批人直接提取得到的，并根据所存在的关系层级建立多个审批人之间的层级。

例如，审批关系包括用户A、用户B和用户C，则在此审批关系中指定了用户A、用户B和用户C作为审批人，并且在这三个审批人之间，将以用户A为第一级审批人，用户B为第二级审批人，用户C为第三级审批人。

由此，通过在审批关系中指定审批人，使得相应企业所实现的审批功能中，能够为用户的审批过程提供指定的审批人，进而使得应用中审批功能的实现能够适应现实中企业的需求。

在一个实施例中，如上所述的方法如图3所示，还包括：

步骤210，服务器接收应用发送的用户添加请求包。

用户添加请求包是应用中用户为所在企业添加新用户所发起的。在此过程中，所指的用户是指应用中管理员身份的用户。

应用中，一企业都设置有一个或者几个管理员身份的用户，而其他用户则作为企业中的普通用户。

管理员身份的用户通过自身终端运行的应用实现企业中新用户的添加；对于服务器而言，其所实现的新用户添加将是通过用户添加请求包实现的。

具体实现中，用户添加请求包包括标识信息、触发用户添加操作的用户标识、应用标识、用户所有信息字段和操作时间戳，其通过加密后得到最终的用户添加请求包，并发送到服务器。

因此，服务器在接收到用户添加请求包之后，也将进行合法性判断，在合法性判断通过之后方可添加新的用户。在优选的实施例中，此过程还将附带记录最近一次的操作时间和触发用户添加操作的用户。

步骤230，根据用户添加请求包执行相应企业的用户添加操作。

服务器接收到用户添加请求包之后，将依据用户添加请求包中的内容执行用户添加操作，以使得新用户能够在应用中实现其所在企业的相关功能。

步骤250，在完成用户添加操作之后，根据用户添加请求包中的身份字段更新相应企业的角色数据。

身份字段用于标示用户在企业中所属项目组的身份。在一个实施例中，身份字段包括上级和普通成员，用户的身份字段可以是其中任意一个，在此不进行限定。

服务器实现了新用户添加之后，根据新用户所在的项目组在相应企业的角色数据中进行更新，并按照用户添加请求包中的身份字段在角色数据中对新用户的身份进行更新。

换而言之，通过用户添加请求包中身份字段所进行的角色数据更新，将使得服务器为企业所存储的角色数据中增添了新用户以及新用户的身份。

具体的实际运营中，用户的身份字段可以从用户添加请求包中用户所有信息字段提取得到。

在一个实施例中，如上所述的方法还包括：

判断是否存在标识信息对应的审批关系，若为否，则根据标识信息对应的历史审批人生成审批人数据，若为是，则执行步骤130。

在根据标识信息对服务器存储的审批关系进行查找的过程中，如果相应企业在服务器中未存储审批关系，则会根据标识信息获取此用户曾经进行审批的设置的历史审批人，以此来实现用户在应用中审批人的自动设置，并且也能够保证审批人自动设置的有效性。

在一个实施例中，如上的方法如图4所示，还包括：

步骤310，服务器接收应用发送的审批设置请求包。

审批设置请求包用于实现企业中审批关系的设定和更新。审批设置请求包由应用发送至服务器，在服务器中触发进行企业的审批人管理，进而设定或者更新向企业所有成员生效的审批关系。

在具体实现中，所指的审批人管理即为增、删、改审批人的过程。

在一实施例中，审批设置请求包包含标识信息、触发进行审批设置操作的用户标识、应用标识、审批人设置信息和操作时间戳，换而言之，审批设置请求包是通过这些内容的加密处理之后最终得到的。

因此，在优选的实施例中，服务器对接收的审批设置请求包进行合法性判断，在合法性判断通过之后方可执行步骤330。

步骤330，从审批设置请求包获得企业标识和审批人设置信息。

用户通过应用发送的审批设置请求包携带了企业标识和审批人设置信息。其中，审批人设置信息用于实现相应企业所对应的审批人关系生成和存储。

具体的，审批设置信息包括指定的审批人和/或设定的关系型审批人由指定的审批人和/或设定的关系型审批人能够得到相互之间的关系层级。在一个实施例中，设定的关系型审批人为上级关系审批人。

例如，审批设置信息包括两个上级关系审批人，则对应的关系层级为二级，则对于申请审批的用户而言，其所在项目组的直属上级将作为第一级的审批人，然后在第一级审批人的基础上，再寻找第一级审批人的直属上级，以此作为第二级审批人；

在此基础上，如果审批设置信息还包括了指定的审批人，并且对应的关系层级为三级，则即上级关系审批人、上级关系审批人、指定的审批人三级，则在寻找得到第二级审批人之后，将以指定的审批人作为第三级审批人。

步骤350，通过审批人设置信息生成企业的审批关系，并以企业标识为索引存储审批关系。

服务器从审批设置请求包获得审批设置信息，进而由审批设置信息为相应企业生成审批关系，并存储，以便于对该企业中所有用户生效。

通过如上所述的过程，实现了与具备审批功能的应用相配合的服务器，进而通过如上所述过程，使得服务器在企业社交网络应用中实现审批人的自动设置，优化了应用中审批功能的实现。

此外，还相应地提供了一种应用中实现审批的方法，该方法如图5所示，包括：

步骤410，侦听得到应用中触发的申请审批指令。

如前所述的，企业社网络应用将运行于各用户自身的终端。而所指的用户即为使用了应用的企业内部成员。

应用中触发自身配备的审批功能，该审批功能包括审批流程的实现、审批设置过程和用户添加所相关的角色数据更新。

对于应用中审批流程的实现，将首先在应用中触发进行审批申请，生成申请审批指令。

用户层面，在一个实施例中，此过程将是通过应用中相应按钮触发点击实现的，例如，可在应用中点击“我要报销”按钮来发起申请审批过程，进而相应生成申请审批指令。

步骤430，响应于申请审批指令生成申请审批请求包，将申请审批请求包发送至服务器。

申请审批请求包的内容包括申请审批的用户标识、应用标识、操作时间戳等字段，因此，在对申请审批指令进行响应时，将获取所需要的字段，以组合得到申请审批请求包的包体，进而得到最终的申请审批请求包，并向服务器发送。

步骤450，接收服务器对申请审批请求包进行的响应，得到服务器自动匹配的审批人数据。

发送了申请审批请求包的应用将会接收到服务器的回包，该回包将是服务器对申请审批请求包所进行的响应，由此便能够得到服务器自动匹配的审批人数据。

步骤470，通过审批人数据在应用中自动设置审批人。

通过如上所述的过程，使得应用在申请进行审批之后，能够通过与服务器的交互获得为当前申请进行的审批自动设置审批人，进而提高应用中审批功能实现的智能化程度和自适应性。

在完成了应用中审批人的自动设置之后，即可完成后续的审批流程。具体的，在应用中完成审批信息的输入并提取之后，将获取得到审批信息并与自动设置的审批人相应生成审批请求包，将审批请求包发送至服务器。

服务器将审批请求包中的审批信息进行写入存储，并通知相关审批人进行审核，以得到最终的审批结果，并向企业社交网络返回。

以报销审批为例，在报销审批流程中，审批信息包括申请审批的用户标识、企业标识、申请时间、报销类型、报销事由、报销明细、费用类型、发生时间、费用金额、费用说明、证明材料等信息。

在一个实施例中，如图6所示，如上所述的方法还包括：

步骤510，侦听应用中触发进行的用户添加和用户添加中的身份设置，获得企业标识和用户所有信息字段。

如前所述的，应用可发起新用户的添加。换而言之，应用中管理员身份的用户触发进行用户添加操作，在应用的用户添加页面进行用户所有信息字段的输入，此用户所有信息字段输入的过程包括了身份设置过程，即如图9所示的页面，在完成输入之后，通过进行的保存便完成用户添加操作，应用将获得企业标识和用户所有信息字段。

图7示出了一个实施例中应用的用户添加页面600，在此用户添加页面600中，身份设置即为身份项目的选取610。

进一步的，在本实施例中，步骤510包括：侦听应用中触发进行的用户添加，根据用户添加中进行的身份字段设置和其它字段完善生成用户所有信息字段，并获取企业标识。

步骤530，根据企业标识和用户所有信息字段生成用户添加请求包，发送用户添加请求包至服务器。

步骤550，通过用户添加请求包在服务器执行相应企业的用户添加操作，并更新企业标识对应的角色数据。

通过如上所述的过程，在应用实现了用户的添加，并且在用户的添加过程中，更新相应的角色数据，进而使得后续审批功能的实现中审批人的自动化设置能够得到优化，为审批人的自动设置提供有效的数据支撑。

在另一个实施例中，如图8所示，如上所述的方法还包括：

步骤710，侦听应用中触发进行的审批人管理，获取企业标识和审批人设置信息。

步骤730，根据企业标识和审批人设置信息生成审批设置请求包，发送审批设置请求包至服务器。

步骤750，通过审批设置请求包在服务器生成企业的审批关系。

通过如上所述的过程，将在应用配备独立的设置入口，以便于对企业的审批关系进行设置，进而使得设置的审批关系能够对全体企业成员生效，以应用中的配置过程。

在优选的实施例中，管理员身份的用户通过自身终端运行的应用来实现所在企业的审批人管理。

如图9所标示的，在此仍然以报销审批为例，在应用的页面810中，通过触发进行的流程设置而在应用的页面810弹出进行审批人选择的界面830，管理员身份的用户通过在进行审批人选择的界面830即可完成所在企业的审批人管理。

进一步的，在本实施例中，步骤710如图10所示，包括：

步骤711，侦听应用中触发进行的审批人管理，得到审批人选择中选定的上级关系审批人和/或指定的审批人。

步骤713，由上级关系审批人和/或指定的审批人形成审批人设置信息，并获取企业标识。

通过此过程，得以在应用中自行实现审批人的设置，即为后续审批功能的实现指定上级关系审批人和/或具体的审批人。

如上所述的应用中审批的实现可应用于任意审批场景，例如，请假场景、文案审核场景等，所指定的审批关系也并不限于上级关系审批人，也可以是与上级关系审批人类似的其它概念，例如，“主编辑”等。

下面结合一个具体的实施例来阐述如上所述的应用中审批的实现过程。本实施例中，将以报销审批为例进行说明。

在此，为方便时行简洁清楚的说明，以管理员身份登录至企业管理页面，并在企业管理页面中通过选取的企业应用来进入报销应用管理页面，此报销应用管理页面即被视为报销管理端；运行于终端且普通成员身份的用户所登录的应用将视为客户端。

对于与应用相配合的服务器而言，其包括报销服务器和用于进行存储的数据库。

图11示出了一个实施例中实现报销审批的时序，该实时将用于实现应用中一企业相关的审批关系设置和报销审批。

具体的，一方面，对于应用中一企业相关的审批关系设置，将通过执行步骤810至步骤840实现。

另一方面，对于应用中一企业相关的报销审批的实现，将通过执行步骤850至步骤891实现。

对于步骤890所返回的审批人，将在如图12所示的界面900中进行显示，即界面900中对于审批人项目910的显示，并且在此界面900中提交相应的报销信息，如报销类型、费用类型、发生时间和费用金额等信息，进而执行步骤891即可进行报销审批

如上所述的应用除了在报销审批中适用之外，在审批相关的其它流程中也具有普适性。

另外，还相应地提供了一种应用中实现审批的装置，该装置如图13所示，包括申请接收模块1010、关系获得模块1030、角色数据获得模块1050、递归寻找模块1070和响应模块1090，其中：

申请接收模块1010，用于接收企业社交网络发送的申请审批请求包。

关系获得模块1030，用于根据申请审批请求包中的标识信息获得审批关系。

角色数据获得模块1050，用于根据标识信息中包含的企业标识得到角色数据，从角色数据获得组织架构。

递归寻找模块1070，用于在组织架构中进行关系型审批人的递归寻找，将递归寻找得到的关系型审批人生成审批人数据。

响应模块1090，用于根据审批人数据对申请审批请求包进行响应，通过响应在应用中自动设置审批人。

在一个实施例中，关系获得模块1030如图14所示，包括企业标识提取单元1031和查找单元1033，其中：

企业标识提取单元1031，用于提取申请审批请求包中标识信息包含的企业标识。

查找单元1033，用于在存储的审批关系中根据企业标识进行查找，得到企业标识对应的审批关系。

在一个实施例中，获得的审批关系包括指定的审批人，如上所述的装置还包括数据获得模块。该数据获得模块用于根据审批关系中指定的审批人进行数据提取得到审批人数据。

在一个实施例中，如上所述的装置如图15所示，包括添加请求接收模块1110、添加操作执行模块1130和角色数据更新模块1150，其中：

添加请求接收模块1110，用于接收应用发送的用户添加请求包。

添加操作执行模块1130，用于根据用户添加请求包执行相应企业的用户添加操作。

角色数据更新模块1150，用于在完成用户添加操作之后，根据用户添加请求包中的身份字段更新相应企业的角色数据。

在一个实施例中，如上所述的装置还包括判断模块。该判断模块用于判断是否存在标识信息对应的审批关系，若为否，则根据标识信息对应的历史审批人生成审批人数据，若为是，则通知关系获得模块1030。

在另一个实施例中，如上所述的装置如图16所示，还包括设置请求接收模块1210、请求信息获得模块1230和存入模块1250，其中：

设置请求接收模块1210，用于接收应用发送的审批设置请求包。

请求信息获得模块1230，用于从审批设置请求包获得企业标识和审批人设置信息。

存入模块1250，用于通过审批人设置信息生成企业的审批关系，并以企业标识为索引存储审批关系。

还相应地提供了一种应用中实现审批的装置，如图17所示，包括申请侦听模块1310、申请组包模块1330、响应接收模块1350和自动设置模块1370，其中：

申请侦听模块1310，用于侦听得到企业社交网络应用中触发的申请审批指令。

申请组包模块1330，用于响应于申请审批指令生成申请审批请求包，将申请审批请求包发送至服务器。

响应接收模块1350，用于接收服务器对申请审批请求包进行的响应，得到服务器自动匹配的审批人数据。

自动设置模块1370，用于通过审批人数据在应用中自动设置审批人。

在一个实施例中，如上所述装置如图18所示，还包括用户添加侦听模块1410、用户添加组包模块1430和更新模块1450，其中：

用户添加侦听模块1410，用于侦听应用中触发进行的用户添加和用户添加中的身份设置，获得企业标识和用户所有信息字段。

用户添加组包模块1430，用于根据企业标识和用户所有信息字段生成用户添加请求包，发送用户添加请求包至服务器。

更新模块1450，用于通过用户添加请求包在服务器执行相应企业的用户添加操作并更新企业标识对应的角色数据。

进一步的，在本实施例中，用户添加侦听模块1410进一步用于侦听应用中触发进行的用户添加，根据用户添加中进行的身份字段设置和其它字段完善生成用户所有信息字段，并获取企业标识。

在另一个实施例中，如上所述的装置如图19所示，还包括审批人管理侦听模块1510、审批设置请求组包模块1530和关系生成模块1550，其中：

审批人管理侦听模块1510，用于侦听应用中触发进行的审批人管理，获取企业标识和审批人设置信息。

审批设置请求组包模块1530，用于根据企业标识和审批人设置信息生成审批设置请求包，发送审批设置请求包至服务器。

关系生成模块1550，用于通过审批设置请求包在服务器生成企业的审批关系。

进一步的，在本实施例中，审批人管理侦听模块1510如图20所示，包括审批人获得单元1511和设置信息形成单元1513，其中：

审批人获得单元1511，用于侦听应用中触发进行的审批人管理，得到审批人选择中选定的上级关系审批人和/或指定的审批人。

设置信息形成单元1513，用于由上级关系审批人和/或指定的审批人形成审批人设置信息，并获取企业标识。

图21示出了本发明实施例提供的一种服务器的结构，该种服务器1600可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器（central processing units，CPU）1610（例如，一个或一个以上处理器）和存储器1620，一个或一个以上存储应用程序1631或数据1633的存储介质1630（例如一个或一个以上海量存储设备）。其中，存储器1620和存储介质1630可以是短暂存储或持久存储。存储在存储介质1630的程序可以包括一个或一个以上模块（图示未示出），每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1610可以设置为与存储介质1630通信，在服务器1600上执行存储介质1630中的一系列指令操作。服务器1600还可以包括一个或一个以上电源1650，一个或一个以上有线或无线网络接口1670，一个或一个以上输入输出接口1680，和/或，一个或一个以上操作系统1635，例如Windows ServerTM，Mac OS XTM，UnixTM, LinuxTM，FreeBSDTM等等。

此外，通过硬件电路或者硬件电路结合软件指令也能同样实现本发明，因此，实现本发明并不限于任何特定硬件电路、软件以及两者的结合。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

虽然已参照几个典型实施方式描述了本发明，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本发明能够以多种形式具体实施而不脱离发明的精神或实质，所以应当理解，上述实施方式不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。