数据处理方法、装置、服务器和存储介质制造方法及图纸

本公开提出一种数据处理方法、装置、服务器和存储介质，其中，方法包括：在服务器接收到客户端的业务请求后，结合业务请求中的应用程序标识，获取对应的业务类型，并根据该业务类型的处理逻辑，对业务请求进行处理，并向客户端返回业务请求对应的处理结果。由此，在通过服务器向多个应用程序提供业务管理服务时，结合不同应用程序所对应的业务类型，对客户端发送的业务请求进行管理，从而在实现一个服务器可以管理多个应用程序的业务的同时，可避免业务请求出现混乱情况的发生，避免了出现跨业务的数据安全问题。

【技术实现步骤摘要】
数据处理方法、装置、服务器和存储介质
本公开涉及数据
，尤其涉及一种数据处理方法、装置、服务器和存储介质。
技术介绍
应用内支付简称IAP(In-AppPurchase)，是一种简单、透明、公平、安全的支付手段，它具有灵活的计费策略，以及支持多类型的应用计费，不但充分尊重和保障用户的权利，同时也为开发者创造了可持续发展的条件。相关技术中，为了减少每个应用程序(APP，APPlication)接入IAP支付单独开发一套完整的支付系统，开发成本比较高，通常通过提供统一的端上支付SDK(SoftwareDevelopmentKit，软体开发工具包)和后端服务，将IAP支付的复杂性封装在平台之内。当IAP支付平台化之后，如何隔离各个业务请求，防止数据错乱是目前亟需要解决的问题。
技术实现思路
本公开旨在至少在一定程度上解决上述相关技术中的技术问题之一。为此，本公开的第一个目的在于提出一种数据处理方法，该方法在通过服务器向多个应用程序提供业务管理服务时，结合不同应用程序所对应的业务类型，对客户端发送的业务请求进行管理，从而在实现一个服务器可以管理多个应用程序的应用内支付的同时，可避免业务请求出现混乱情况的发生，避免了出现跨业务的数据安全问题。本公开的第二个目的在于提出一种数据处理装置。本公开的第三个目的在于提出一种服务器。本公开的第四个目的在于提出一种非临时性计算机可读存储介质。为达上述目的，本公开第一方面实施例提出了一种数据处理方法，包括：接收客户端的业务请求，其中，所述业务请求包括应用程序标识；根据所述应用程序标识，获取对应的业务类型；根据所述业务类型对应的处理逻辑，对所述业务请求进行处理，并向所述客户端返回所述业务请求对应的处理结果。本公开实施例的数据处理方法，在服务器接收到客户端的业务请求后，结合业务请求中的应用程序标识，获取对应的业务类型，并根据该业务类型的处理逻辑，对业务请求进行处理，并向客户端返回业务请求对应的处理结果。由此，在通过服务器向多个应用程序提供业务管理服务时，结合不同应用程序所对应的业务类型，对客户端发送的业务请求进行管理，从而在实现一个服务器可以管理多个应用程序的业务的同时，可避免业务请求出现混乱情况的发生，避免了出现跨业务的数据安全问题。为达上述目的，本公开第二方面实施例提出了一种数据处理装置，所述装置包括：第一接收模块，用于接收客户端的业务请求，其中，所述业务请求包括应用程序标识；第一获取模块，用于根据所述应用程序标识，获取对应的业务类型；处理模块，用于根据所述业务类型对应的处理逻辑，对所述业务请求进行处理，并向所述客户端返回所述业务请求对应的处理结果。本公开实施例的数据处理装置，在服务器接收到客户端的业务请求后，结合业务请求中的应用程序标识，获取对应的业务类型，并根据该业务类型的处理逻辑，对业务请求进行处理，并向客户端返回业务请求对应的处理结果。由此，在通过服务器向多个应用程序提供业务管理服务时，结合不同应用程序所对应的业务类型，对客户端发送的业务请求进行管理，从而在实现一个服务器可以管理多个应用程序的业务的同时，可避免业务请求出现混乱情况的发生，避免了出现跨业务的数据安全问题。为达上述目的，本公开第三方面实施例提出了一种服务器，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如上所述的数据处理方法。为了实现上述目的，本公开第四方面实施例提出了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上所述的数据处理方法。本公开附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本公开的实践了解到。附图说明本公开上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：图1是根据本公开一个实施例的数据处理方法的流程图；图2是根据本公开另一个实施例的数据处理方法的流程图；图3是根据本公开另一个实施例的数据处理方法的流程图；图4是根据本公开另一个实施例的应用程序、应用服务器、服务器和第三方渠道服务器之间的交互示意图；图5是根据本公开一个实施例的数据处理装置的结构示意图；图6是根据本公开另一个实施例的数据处理装置的结构示意图；图7是根据本公开一个实施例的服务器600的结构示意图。具体实施方式下面详细描述本公开的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本公开，而不能理解为对本公开的限制。下面参考附图描述本公开实施例的数据处理方法、装置、服务器和存储介质。图1是根据本公开一个实施例的数据处理方法的流程图。其中，需要说明的是，本实施例的数据处理方法的执行主体为数据处理装置，该装置可以由软件和/或硬件的方式实现，该装置设置在服务器侧，用于与应用程序中的客户端进行通信。如图1所示，该数据处理方法可以包括：步骤101，接收客户端的业务请求，其中，业务请求包括应用程序标识。具体地，在有业务需要客户端与服务器进行交互时，客户端可根据用户在应用程序的上的业务操作，生成业务请求，并向服务器发送对应业务请求，对应地，服务器接收客户端的业务请求。其中，需要说明的，本实施例中的客户端提供应用程序端上IAP支付集成能力，提供对IAP支付接口的封装、自动重试、端上监控、配置接收等功能。步骤102，根据应用程序标识，获取对应的业务类型。在本实施例中，为了隔离不同业务请求，避免数据错乱，本实施例在客户端和服务器间之间的请求，可通过应用程序标识锁定不同的业务类型。其中，可以理解的是，对于不同业务类型而言，服务器中保存了不同业务类型对应的处理逻辑，可以理解的是，通常不同业务类型其对应的处理逻辑是不同的。步骤103，根据业务类型对应的处理逻辑，对业务请求进行处理，并向客户端返回业务请求对应的处理结果。本公开实施例的数据处理方法，在服务器接收到客户端的业务请求后，结合业务请求中的应用程序标识，获取对应的业务类型，并根据该业务类型的处理逻辑，对业务请求进行处理，并向客户端返回业务请求对应的处理结果。由此，在通过服务器向多个应用程序提供业务管理服务时，结合不同应用程序所对应的业务类型，对客户端发送的业务请求进行管理，从而在实现一个服务器可以管理多个应用程序的业务的同时，可避免业务请求出现混乱情况的发生，避免了出现跨业务的数据安全问题。图2是根据本公开另一个实施例的数据处理方法的流程图。其中，需要说明的是，图2是对上述实施例的进一步细化和扩展。其中，本实施例中以业务请求包括订单创建请求为例进行描述。如图2所示，该方法包括：步骤201，接收客户端的订单创建请求，其中，订单创建请求包括客户端所在应用程序的应用程序标识以及本文档来自技高网...

【技术保护点】
1.一种数据处理方法，其特征在于，所述方法包括：/n接收客户端的业务请求，其中，所述业务请求包括应用程序标识；/n根据所述应用程序标识，获取对应的业务类型；/n根据所述业务类型对应的处理逻辑，对所述业务请求进行处理，并向所述客户端返回所述业务请求对应的处理结果。/n

【技术特征摘要】
1.一种数据处理方法，其特征在于，所述方法包括：
接收客户端的业务请求，其中，所述业务请求包括应用程序标识；
根据所述应用程序标识，获取对应的业务类型；
根据所述业务类型对应的处理逻辑，对所述业务请求进行处理，并向所述客户端返回所述业务请求对应的处理结果。


2.如权利要求1所述的方法，其特征在于，所述业务请求包括订单创建请求，其中，所述订单创建请求还包括商家标识，所述根据所述业务类型对应的处理逻辑，对所述业务请求进行处理，并向所述客户端返回所述业务请求对应的处理结果，包括：
判断所述商家标识与所述业务类型是否对应；
如果所述商家标识与所述业务类型对应，则根据所述订单创建请求创建订单，并将所创建的订单信息返回所述客户端。


3.如权利要求2所述的方法，其特征在于，所述方法还包括：
如果所述商家标识不与所述业务类型对应，则向所述客户端返回订单创建失败的提示信息。


4.如权利要求2所述的方法，其特征在于，在所述将所创建的订单信息返回所述客户端之后，所述方法还包括：
接收所述客户端发送的业务确认请求，其中，所述业务确认请求包括令牌信息和第一支付信息，其中，所述令牌信息是所述客户端通过第三方渠道服务器完成所述订单信息的支付后，所述第三方渠道服务器提供给所述客户端的；
从所述第三方渠道服务器中获取与所述令牌信息对应的第二支付信息；
如果所述第一支付信息和所述第二支付信息一致，则向所述客户端返回业务确认结果。


5.如权利要求4所述的方法，其特征在于，在所述从所述第三方渠道服务器中获取与所述...

【专利技术属性】
技术研发人员：张树凡，周文，王新华，杨季佳，
申请(专利权)人：北京字跳网络技术有限公司，
类型：发明
国别省市：北京;11