业务处理方法及系统的制作方法
【专利摘要】本申请公开了业务处理方法及系统，其中，所述方法可以包括：确定各个功能模块中分别使用的第三方应用程序；在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址；所述回调地址根据写入到所述目标第三方应用程序代码的统一资源定位符方案字段的信息生成，所述目标第三方应用程序已在所述服务器中对所述统一资源定位符方案字段的信息进行注册；按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序，进行相应的业务处理。通过本申请，能够实现应用间数据交互，帮助打通多应用不同阶段电子商务流程。
【专利说明】业务处理方法及系统
【技术领域】
[0001]本申请涉及电子商务【技术领域】，特别是涉及业务处理方法及系统。
【背景技术】
[0002]随着移动互联网和电子商务开放平台的发展，越来越多的卖家从线上固定办公转变成为移动办公。当前电商移动化需求主要分成几大类:
[0003]第一，业务诉求。电商大军中有很大一部分中小卖家都处于兼职状态，因此不能长期固守在电脑前操作，但是，每一分钟离开都可能会由于买家用户得不到及时的沟通和交流，订单确认处理而使得交易无法形成，因此，如何能够在离开电脑后依然保持沟通及业务处理，就成为中小卖家的业务命脉。
[0004]第二，职能细分。随着更多垂直行业的中大型企业进入电商，原来电商的小规模经营角色已经产生了非常大的变化，有更多层次的管理流程需求融入到了电商管理需求中，这些流程的操作角色都因为业务和身份的差异对操作可移动性要求很高，因此，在新的电商环境下，中大型电商不同角色的移动需求凸显出来。
[0005]第三，环境因素。随着移动互联网的发展，移动办公成本被大大降低，而移动办公会带来的整体电商流程效能提升，例如，利用移动终端的照片功能结合二维码或者条形码处理软件，就可以在不移动商品的过程中做到货物入库归档，提高效率，降低操作成本。
[0006]以上只是罗列了很小一部分的移动诉求，但从上述需求可以发现，电商移动化管理需求非常旺盛，同时会牵涉到电商的各个环节，例如，供货、分销、营销、导购、交易管理、物流发货、售后回访、绩效考核等等。
[0007]当前电商开放平台开放了大量数据类的服务，很多开发者已经基于服务开发了大量的工具类软件，开发者通过线下渠道将软件推广给卖家，卖家可以尝试性的使用一个或者多个工具类软件来满足其移动办公的需求。
[0008]可见，当前对于卖家无线需求的满足主要还是靠应用开发者单独开发某一类工具，然后通过不同的渠道向卖家推广，因此，当前的情况就是，通过离散的应用市场来满足卖家需求。但这种模式至少存在以下问题:
[0009]由于应用的开发者不同，用户在使用应用时，需要分别针对各个应用进行用户授权，同时，连贯的管理需求也被应用切割的支离破碎，应用的风格千差万别，用户体验差异跳跃。另外，不同工具类应用关注的业务阶段不同，每个阶段的数据无法关联分析(例如，导购效果取决于交易部分的分析)，这就会导致工具纯粹就为了降低工作成本，开发者开发重复度高，同质竞争严重，同时也无法帮助卖家真实解决整体交易的关键问题。
【发明内容】
[0010]本申请提供了业务处理方法及系统，能够实现应用间数据交互，帮助打通多应用不同阶段业务流程。
[0011]本申请提供了如下方案:[0012]—种业务处理方法,包括:
[0013]确定各个功能模块中分别使用的第三方应用程序；其中，所述功能模块为按照电子商务流程中各个阶段的使用场景划分的功能模块；
[0014]在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址；所述回调地址根据写入到所述目标第三方应用程序代码的统一资源定位符方案字段的信息生成，所述目标第三方应用程序已在所述服务器中对所述统一资源定位符方案字段的信息进行注册；
[0015]按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序，进行相应的业务处理。
[0016]可选地，所述在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址包括:
[0017]接收到系统提醒消息时，根据所述系统提醒消息确定需要调用的功能模块；
[0018]根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址。
[0019]可选地，所述在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址包括:
[0020]接收当前第三方应用程序发出的调用指定功能模块的请求；
[0021]根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址；
[0022]所述按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序包括:
[0023]将获取到的回调地址发送给当前第三方应用程序，以便所述当前第三方应用程序按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序。
[0024]可选地，如果调用发起方需要所述目标第三方应用程序返回响应信息时，所述按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序包括:
[0025]所述调用发起方创建会话，并在本地保存会话序列号与会话之间的对应关系；
[0026]所述调用发起方按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序，将调用发起方的回调地址、事件、需要处理的业务参数及所述会话序列号发送给所述目标第三方应用程序；
[0027]所述目标第三方应用程序根据所述事件及业务参数得到处理结果，并根据所述调用发起方的回调地址将处理结果以及所述会话序列号返回给所述调用发起方；
[0028]所述调用发起方根据所述目标第三方应该程序返回的会话序列号查找到对应的会话，将所述处理结果放回该会话中，根据所述目标第三方应用程序返回的处理结果进行处理操作。
[0029]可选地，所述将调用发起方的回调地址、事件、需要处理的业务参数及所述会话序列号发送给所述目标第三方应用程序之后还包括:
[0030]将调用发起方中发起调用的线程阻塞；
[0031]所述根据所述目标第三方应用程序返回的处理结果进行处理操作包括:
[0032]通知所述发起调用的线程根据所述目标第三方应用程序返回的处理结果进行处理操作。
[0033]可选地，所述根据所述目标第三方应用程序返回的处理结果进行处理操作包括:
[0034]调用发起方在新创建的线程中根据所述目标第三方应用程序返回的处理结果进行处理操作。
[0035]可选地，还包括:
[0036]接收目标第三方应用程序发起的单点登录请求；
[0037]将目标第三方应用程序的身份标识以及本地保存的用户id发送到服务器，向所述服务器获取与目标第三方应用程序身份标识及用户id对应的用户授权信息；
[0038]将服务器返回的用户授权信息发送给目标第三方应用程序，以便目标第三方应用程序利用所述用户授权信息进行相应的业务处理。
[0039]可选地，所述将目标第三方应用程序的身份标识以及本地保存的用户id发送到服务器包括:
[0040]获取本地保存的用户id ；
[0041]如果所述本地保存的用户id为至少两个，则将所述至少两个id展现出来供用户选择；
[0042]将目标第三方应用程序的身份标识以及用户选择的用户id发送到服务器。
[0043]可选地，所述将目标第三方应用程序的身份标识以及本地保存的用户id发送到服务器，向所述服务器获取与目标第三方应用程序身份标识及用户id对应的用户授权信息包括:
[0044]将目标第三方应用程序的身份标识以及本地保存的用户id发送到服务器，在服务器已保存的信息中查询目标第三方应用程序身份标识以及本地保存的用户id对应的用户授权信息；
[0045]所述将服务器返回的用户授权信息发送给目标第三方应用程序包括:
[0046]判断查询到的用户授权信息是否有效，如果有效，则发送给目标第三方应用程序;
[0047]如果无效，则请求服务器为根据目标第三方应用程序的身份标识以及用户id进行用户授权，并将重新接收到的用户授权信息发送给目标第三方应用程序。
[0048]可选地于，所述确定各个功能模块中分别使用的应用程序包括:
[0049]展示各个功能模块中分别可供选择的应用程序，并为用户提供选择操作入口 ；
[0050]根据用户的选择结果，确定各个功能模块中分别使用的应用程序。
[0051]一种业务处理系统,包括:
[0052]程序确定单元，用于确定各个功能模块中分别使用的第三方应用程序；其中，所述功能模块为按照电子商务流程中各个阶段的使用场景划分的功能模块；
[0053]回调地址获取单元，用于在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址；所述回调地址根据写入到所述目标第三方应用程序代码的统一资源定位符方案字段的信息生成，所述目标第三方应用程序已在所述服务器中对所述统一资源定位符方案字段的信息进行注册；
[0054]调用单元，用于按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序，进行相应的业务处理。
[0055]根据本申请提供的具体实施例，本申请公开了以下技术效果:
[0056]通过本申请，能够实现不同应用程序之间的相互通信，从而可以在一个平台中深度集成多个第三方应用，使得电商在一个平台上实现完整的电商流程操作，从应用协同到流程串联都让用户感觉是同一个应用程序，实现应用间数据交互，帮助打通多应用不同阶段电子商务流程，实现平台应用与第三方应用数据安全交互，帮助电子商务全链路安全开放。
[0057]进一步地，可以实现应用程序的授权互通，降低多应用使用成本，另外，还可以实现个性化可插拔模式的应用植入，帮助电商一站式应用挑选集成使用，有利于实现满足不同用户的个性化需求。
[0058]当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
【专利附图】
【附图说明】
[0059]为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0060]图1是本申请实施例提供的方法的流程图；
[0061]图2是本申请实施例提供的方法中的应用间通信方法的流程图；
[0062]图3是本申请实施例提供的方法中同步双向通信方法的流程图；
[0063]图4是本申请实施例提供的方法中异步双向通信方法的流程图；
[0064]图5是本申请实施例提供的第一系统的示意图；
[0065]图6是本申请实施例提供的第二系统的示意图；
[0066]图7是本申请实施例提供的第三系统的示意图。
【具体实施方式】
[0067]下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
[0068]本申请实施例提供了 一种无线应用集成平台，可以深度集成多个第三方应用，使得电商可以便利的选择多应用在一个平台上实现完整的电商流程操作，从应用协同到流程串联都让用户感觉是同一个应用程序。实现授权互通降低多应用使用成本，实现应用间数据交互，帮助打通多应用不同阶段电子商务流程；实现平台应用与第三方应用数据安全交互，帮助电子商务全链路安全开放；实现个性化可插拔模式的应用植入，帮助电商一站式应用挑选集成使用。下面对具体的实现方式进行详细地介绍。
[0069]参见图1，本申请实施例首先提供了一种业务处理方法，该方法可以包括以下步骤:
[0070]SlOl:确定各个功能模块中分别使用的第三方应用程序；其中，所述功能模块为按照电子商务流程中各个阶段的使用场景划分的功能模块；
[0071]从产品角度而言，本申请实施例提供的业务处理方法可以通过一个应用程序的形式来实现(由于是应用在移动终端中，因此，为了便于描述，以下均将该应用程序称为“移动工作台”)，该移动工作台的功能并不是为电子商务流程的某个具体环节提供解决方案，而是能够将多个第三方开发的应用程序集成起来，各个第三方应用程序的功能才是为电子商务流程的各个具体环节提供解决方案。为了能够将第三方应用程序串联起来，在本申请实施例中，首先可以按照电子商务流程中各个阶段的使用场景划分为多个功能模块，例如，可以包括商品管理、交易管理、物流管理、数据统计、即时通信管理等等，每个功能模块上可以有一个第三方应用程序来实现对应的功能。
[0072]其中，对于各个功能模块上所使用的第三方应用程序，可以是预先设定的，也就是说，可以预先为各个功能模块选择第三方应用程序，用户安装本申请实施例中的应用程序可自动绑定功能模块与第三方应用程序之间的对应关系，因此，直接根据该对应关系就可以确定各个功能模块中分别使用的第三方应用程序。
[0073]但是，考虑到在实际应用中，第三方应用程序的开发商众多，开发出的第三方应用程序中可能存在一些功能相同或者相近的，如果预先为各个功能模块指定固定的第三方应用程序，则不利于满足不同用户的个性化需求，整个系统也显得不够灵活。因此，在本申请实施例中，可以将各个第三方应用程序按照这些功能模块进行分类，这样，一个功能模块可能对应一个或多个第三方应用程序，这些第三方应用程序均能实现对应的功能。此时，可以通过本申请实施例的应用程序分别将各个功能模块可供选择的第三方应用程序展示给用户，用户可以根据自己的需要、爱好、使用习惯等来选择。例如，对于“商品管理”这一功能模块，有应用程序A和应用程序B可以选择，对于“物流管理”这一功能模块，有应用程序C和应用程序D可以选择，等等；在将这些信息展示给用户之后，同时还可以为用户提供选择操作入口，用户就可以进行选择，例如，对于“商品管理”这一功能模块，选择使用应用程序A，对于“物流管理”这一功能模块，选择使用应用程序D，等等。在用户选择了之后，就可以记录下用户的选择结果，根据用户的选择结果确定出各个功能模块分别使用的第三方应用程序是哪个。
[0074]S102:在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址；所述回调地址可根据写入到所述目标第三方应用程序代码的统一资源定位符方案url schema字段的信息生成，并且，所述目标第三方应用程序可以是已经在所述服务器中对所述url schema字段的信息进行过注册；
[0075]在本申请实施例中，将多个第三方应用程序集成到移动工作台中来，与普通的推荐类应用的区别在于，移动工作台本身是深度集成卖家功能的应用，而非无业务功能的信息黄页；与市场上单一的卖家类无线工具应用的区别在于，移动工作台能够既满足开放集成的需求，又让用户能够感觉操作一体化，而非割裂的堆砌应用。为了达到该目的，则需要实现应用程序之间的通信，以实现应用程序之间自动的数据交互，而不需要或者减少用户的手动参与。这种应用程序之间的通信，包括移动工作台与第三方应用程序之间的通信(因为移动工作台本身也是一种应用程序)，还包括各个第三方应用程序之间的通信。
[0076]但是，不论iOS操作系统中的应用，还是Android操作系统中的应用，在应用之间都没有提供完整的应用交互和寻址的方式。尤其是iOS操作系统中，采用ipa格式的安装方式，即全部ipa都会解包安装在/var/mobile/Applications目录下，ipa解包后并非直接放置于Applications目录下，而是放在一串由随机码构成的目录下，其作用在于，只允许这个软件运行在一个特定的沙盒(Sandbox)中，不能干扰其他软件。也就是说，每个应用程序都是一个自我封闭的沙盒，与其他应用程序之间的交互通信基本不可能，这样如果要深度融合多个应用就不可能，因为应用如果不能把当前的业务数据带给另一个应用，另一个应用自然不会对用户在上一个应用的操作做任何反映。例如，用户在商品管理应用中查看自己的架上商品，这时候如果需要看看该商品的交易情况，跳转到交易管理应用，此时，首先要解决如何跳转到对方应用(IOS和android不能对应用寻址)的问题。
[0077]具体实现时，为了实现从一个应用程序向另一个目标应用程序进行消息传递，第三方应用程序在开发目标应用程序的过程中，需要为目标应用程序定制的统一资源定位符方案URL Schemes字段信息。具体定制URL Schemes字段信息时可以有多种方式，例如，其中一种方式可以是在目标程序的Inf0.Plist中指定目标程序的URL Schemes字段，具体的，可以通过以下步骤实现:
[0078]步骤1:创建一个新的基于视图的应用程序,将其保存为URLSchemeExample ；
[0079]步骤2:在Xcode Groups&Files面板中，展开Resource部分，并且选择<app>-1nf0.plist 文件；
[0080]步骤3:鼠标右键点击Information Property List键,并点击添加箭头从列表中选择“URL types”;
[0081]步骤4:展开Iteml,用鼠标右键点击URL identifier,并且再次选择添加箭头从列表中选择URL Schemes ；
[0082]步骤5:选择Iteml,并且将其值设置为myapplication ；
[0083]步骤6:打开 URLSchemeExampIeView Controller, m,取消对 viewDidLoad 方法的注释，并且编写如下代码:
[0084][self, view setBackgroundColor:[UIColor redColor]]；
[0085]通过以上步骤就可以实现为目标应用程序提供定制的URL Schemes,当然，如果需要实现当前应用程序与目标应用程序之间的相互调用，也可以同时为当前应用程序实现上述定制的URL Schemes,甚至,对于集成到本申请移动工作台中的各个第三方应用程序而言，都可以按照以上方式实现定制的URLSchemes。
[0086]在实现了定制的URL Schemes之后,各个第三方应用程序还可以将各自定制的URLSchemes向移动工作台的服务器端进行注册，这样就可以在服务器端记录下各个第三方应用程序的URL Schemes字段与身份标识之间的对应关系。这样，在需要调用某指定功能模块时，就可以根据该功能模块中使用的目标第三方应用程序的身份标识，向移动工作台的服务器发起查询请求，服务器就可以将该第三方应用程序的URL Schemes字段信息返回给移动工作台，移动工作台便可以据此获知目标第三方应用程序的回调地址。
[0087]例如，URL= [NSURL URLWithString http://***.com"]，其中，URL 表示目标第三方应用程序的回调地址，http://#*.com就是目标第三方应用程序的URL Schemes字段信息，用于标识想要载入的应用程序。另外，该URL中还可以包括发起调用的当前应用程序信息，或者还可以包括从当前应用程序传递给目标应用程序的值，等等。例如，某回调地址 URL = MobiIeTestB://fromapp = MobileTestA&level = officer,其中 MobileTestB为目标第三方应用程序，fromapp = MobileTestA为当前应用程序，level = officer为当前应用程序向目标第三方应用程序传递的值。
[0088]S103:按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序，进行相应的业务处理。
[0089]在获知了目标第三方应用程序的回调地址之后，就可以基于该回调地址，调用目标第三方应用程序，进行相应的业务处理。例如，具体实现时，可以以目标第三方应用程序的回调地址为参数,调用UIAppI ication类的openURL方法来调用目标第三方应用程序。例如，对于步骤S102的例子中提到的目标第三方应用程序，则可以通过以下代码来调用:
[0090]ur I = [Mobi IeTestB: / / fromapp = MobileTestA&level = officer]；[[UIApplication sharedAppIication]openURL:urI]
[0091]在运行该代码之后，就可以调用目标第三方应用程序，还可以切换至目标第三方应用程序的显示界面，目标第三方应用程序还可以在-(BOODapplication:(UIApplication*)application openURL: (NSURL*)url sourceApplication: (NSString*)sourceApplication annotation: (id)annotation函数中，解析该消息传入的回调地址，由于该例子中还存在从源应用程序传递过来的值，因此，目标第三方应用程序还可以对传递过来的值进行存储，或者根据传递值执行相应的业务处理，等等。
[0092]其中，针对实际应用中的不同场景，向目标第三方应用程序发起调用的，可能是移动工作台，也可能是移动工作台中集成的另一第三方应用程序。对于前者，一般是移动工作台首先接收到某系统提醒消息，然后移动工作台可以根据系统提醒消息确定出需要调用的功能模块，然后再向该功能模块中使用的第三方应用程序发起调用。这种应用场景体现的是一种基于系统消息驱动的用户行为融合，换言之，基于系统消息驱动的方式主要是针对业务场景都是由外部事件触发的场景。比如卖家的商品售出，产生了一笔交易，此时会在移动工作台收到一条消息提醒，在移动工作台可以初步看到消息的情况，具体要处理业务，则会根据消息属性选择需要调用的功能模块。在这种情况下，移动工作台在从服务端获取到目标第三方应用程序的回调地址之后，直接向目标第三方应用程序发起调用即可。
[0093]而对于第二种情况，向目标第三方应用程序发起调用的另一第三方应用程序一般是当前处于焦点状态的第三方应用程序，为便于描述，将其简称为当前第三方应用程序。也就是说，在用户使用当前第三方应用程序进行业务处理的过程中，可能需要调用另一功能模块的功能，则该当前第三方应用程序就会向移动工作台发送调用指定功能模块的请求，移动工作台在接收到该请求之后，就可以根据指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取目标第三方应用程序的回调地址。在移动工作台获取到目标第三方应用程序的回调地址之后，就可以将该回调地址发送给当前第三方应用程序，当前第三方应用程序就可以根据该回调地址向目标第三方应用程序发起调用，实现相应的业务处理。
[0094]也就是说，这是一种基于业务模块的功能驱动方式，当用户在某一个第三方应用程序中进行业务处理的时候，需要与另一第三方应用之间进行业务交互，然后产生的应用交互跳转。例如，用户在商品管理功能模块中查看商品，这时候希望将商品推荐给一个买家，此时，从商品列表中点击跳转到移动工作台的聊天功能中，同时带有商品Id，移动工作台可向服务器端获取到聊天功能中的第三方应用程序的回调地址，将其返回给商品管理功能模块中的当前第三方应用程序，由商品管理功能模块中的当前第三方应用程序向聊天功能中的目标第三方应用程序发起调用，相应的，买家直接可以看到商品描述，如果买家确认需要，可以直接下单，然后移动工作台会收到交易消息，此时用户被引导到交易模块中进行
处理，等等。
[0095]在两个应用程序之间进行通信的过程中，可能存在需要进行数据交互的情况，也即，调用发起方(可能是移动工作台，也可能是另一第三方应用程序)在调用目标第三方应用程序时，可能需要目标第三方应用程序返回响应信息，例如，返回业务处理结果，等等。但是，不论是iOS还是Android应用，都只支持单向数据通信，不支持全双工交互通信，因此，在这种情况下，还要解决如何实现应用间同步或异步的双向通信的问题。
[0096]为此，在本申请实施例中，可以通过以下方式实现:
[0097]调用发起方在向目标第三方应用程序发起调用时，创建一会话(Session)，Session创建中得到的随机会话序列号sequence作为会话唯一标示,本地会话队列保存sequence和Session的对应关系；调用发起方按照目标第三方应用程序的回调地址调用目标第三方应用程序，将调用发起方的回调地址、事件、需要处理的业务参数及会话序列号发送给目标第三方应用程序。
[0098]目标第三方应用程序根据事件及业务参数得到处理结果，并根据调用发起方的回调地址将处理结果以及会话序列号返回给调用发起方；调用发起方根据目标第三方应该程序返回的会话序列号查找到对应的会话，将处理结果放回该会话中，然后根据目标第三方应用程序返回的处理结果进行处理操作。
[0099]上述过程中，可以采用阻塞模式或者非阻塞模式来实现。其中，在采用阻塞模式实现时，由于手机等移动终端设备应用通信当前都是靠应用的单工模式来实现，因此需要模拟阻塞模式，此时，可采用线程的等待(wait)和通知(notify)方式来实现。具体的，发起调用请求的应用程序(调用发起方)向目标第三方应用程序发起调用请求，然后本地用于发起调用的线程caller thread开始阻塞(block);目标第三方应用程序在接收到调用请求并处理完毕以后，向调用发起方的回调地址ca 11 backur I发起响应，返回处理结果及会话序列号sequence。调用发起方接收到响应返回,根据sequence获取session,将处理结果放回session,然后通知(notify) caller thread, caller thead根据处理结果同步处理响应。
[0100]当然，调用发起方也可以选择以异步模式来实现与目标应用程序的交互。与同步模式交互差别在于发起调用的线程不必再阻塞，目标第三方应用程序返回处理结果以后，调用发起方根据session的回调函数，创建新的线程来进行后续的业务处理。
[0101]以上对应用程序间进行通信的实现方式进行了详细地介绍，在实际应用中，在使用某第三方应用程序时，一般还需要向第三方应用程序进行用户授权，第三方应用程序在获取到经过用户授权的“令牌”之后，才能调用系统提供的API，进行具体的业务处理操作。而现有技术中，一般要求用户分别对各个第三方应用程序进行用户授权，包括需要用户输入密码、列举出需要获取的商品数据交易数据等之后询问用户是否允许访问等等，在用户操作完成之后，会为该第三方应用程序生成令牌，该第三方应用程序便可以在持有该令牌的情况下，执行自己的业务处理。其他第三方应用程序也要重复上述操作。[0102]而在本申请实施例中，由于将多个第三方应用程序集成到了本申请实施例的移动工作台中，这也就意味着，在用户安装使用该移动工作台的情况下，就证明用户运行集成在其中的各个第三方应用程序访问相应的数据。因此，在本申请实施例中，可以通过移动工作台实现各个第三方应用程序的授权互通，使得用户一次登陆授权之后就可以使用多个第三方应用程序，实现应用间任意登录，第三方应用程序的一体化使用。具体实现时，可以由第三方应用程序在需要获取用户授权时，可以首先获取本地保存的用户id(用户在本地使用该id登录过，则第三方应用程序就可以获取到该用户id)，然后向移动工作台发起SSO (Single Sign On,单点登录)请求,请求中携带第三方应用程序的身份标识(app key)以及用户id。移动工作台在接收到该请求之后，可以向服务器发起请求，请求获得该用户对该第三方应用程序的授权信息；服务器可以对该第三方应用程序以及用户的授权进行验证，并返回授权结果；移动工作台在收到授权结果之后可以对其有效性进行验证(授权信息具有时效性，如果超时，则无效；另外，授权信息的有效性还与用户与应用之间的访问契约、订购时长等有关)，如果有效，则可直接发送给第三方应用程序使用；否则，如果授权信息无效，则可以引导进行用户授权，请求服务器执行该用户对该第三方应用程序进行授权，并在接收到服务器返回的授权信息之后，发送给第三方应用程序使用。其他第三方应用程序可以均可以通过上述方式进行授权，可见，在这种方式下，不再需要用户分别对各个第三方应用程序进行用户授权，使用户获得一个应用中的多个功能的用户体验。
[0103]当然，在实际应用中，用户可能在同一个终端上使用多个用户id登录过，此时，在获取用户id时，就可能会获取到多个，因此，可以将这多个用户id以列表等形式展现给用户，由用户选择一个当前需要使用的用户id，然后根据用户选择的这个用户id获取用户授权信息。
[0104]需要说明的是，为了能够按照前述方式实现应用程序之间的相互通信以及授权互通，各个第三方应用程序需要实现规定模块的消息接口，这样当收到其他应用程序发送的消息以后才可以做业务处理，包括通过SSO模式获取到用户授权，通过集成的SDK来调用远端服务处理业务，当业务处理完毕以后，则通过集成的工具条(Toolbar)回到主应用某个功能中或者回到第三方应用继续业务处理，等等。总之，在本申请实施例中，是基于消息流驱动用户行为，同时用户行为会跨多个第三方应用程序，并且会和移动工作台有很多数据交互，因此重点就是应用寻址交互和模块间业务协议定义，下面列举了应用间交互的基础协议和业务协议范例。
[0105]首先，参见表1，其中列举了一些系统协议的定义。
[0106]表1
[0107]
【权利要求】
1.一种业务处理方法，其特征在于，包括: 确定各个功能模块中分别使用的第三方应用程序；其中，所述功能模块为按照电子商务流程中各个阶段的使用场景划分的功能模块； 在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址；所述回调地址根据写入到所述目标第三方应用程序代码的统一资源定位符方案字段的信息生成，所述目标第三方应用程序已在所述服务器中对所述统一资源定位符方案字段的信息进行注册； 按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序，进行相应的业务处理。
2.根据权利要求1所述的方法，其特征在于，所述在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址包括: 接收到系统提醒消息时，根据所述系统提醒消息确定需要调用的功能模块； 根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址。
3.根据权利要求1所述的方法，其特征在于，所述在需要调用指定功能模块时，根据所述指定功能模块中使 用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址包括: 接收当前第三方应用程序发出的调用指定功能模块的请求； 根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址； 所述按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序包括:将获取到的回调地址发送给当前第三方应用程序，以便所述当前第三方应用程序按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序。
4.根据权利要求1至3任一项所述的方法，其特征在于，如果调用发起方需要所述目标第三方应用程序返回响应信息时，所述按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序包括: 所述调用发起方创建会话，并在本地保存会话序列号与会话之间的对应关系； 所述调用发起方按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序，将调用发起方的回调地址、事件、需要处理的业务参数及所述会话序列号发送给所述目标第三方应用程序； 所述目标第三方应用程序根据所述事件及业务参数得到处理结果，并根据所述调用发起方的回调地址将处理结果以及所述会话序列号返回给所述调用发起方； 所述调用发起方根据所述目标第三方应该程序返回的会话序列号查找到对应的会话，将所述处理结果放回该会话中，根据所述目标第三方应用程序返回的处理结果进行处理操作。
5.根据权利要求4所述的方法，其特征在于，所述将调用发起方的回调地址、事件、需要处理的业务参数及所述会话序列号发送给所述目标第三方应用程序之后还包括: 将调用发起方中发起调用的线程阻塞；所述根据所述目标第三方应用程序返回的处理结果进行处理操作包括: 通知所述发起调用的线程根据所述目标第三方应用程序返回的处理结果进行处理操作。
6.根据权利要求4所述的方法，其特征在于，所述根据所述目标第三方应用程序返回的处理结果进行处理操作包括: 调用发起方在新创建的线程中根据所述目标第三方应用程序返回的处理结果进行处理操作。
7.根据权利要求1至3任一项所述的方法，其特征在于，还包括: 接收目标第三方应用程序发起的单点登录请求； 将目标第三方应用程序的身份标识以及本地保存的用户id发送到服务器，向所述服务器获取与目标第三方应用程序身份标识及用户id对应的用户授权信息； 将服务器返回的用户授权信息发送给目标第三方应用程序，以便目标第三方应用程序利用所述用户授权信息进行相应的业务处理。
8.根据权利要求7所述的方法，其特征在于，所述将目标第三方应用程序的身份标识以及本地保存的用户id发送到服务器包括: 获取本地保存的用户id ； 如果所述本地保存的用户id为至少两个，则将所述至少两个id展现出来供用户选择； 将目标第三方应用程序的身份标识以及用户选择的用户id发送到服务器。
9.根据权利要求7所述的方法，其特征在于，所述将目标第三方应用程序的身份标识以及本地保存的用户id发送到服务器，向所述服务器获取与目标第三方应用程序身份标识及用户id对应的用户授权信息包括: 将目标第三方应用程序的身份标识以及本地保存的用户id发送到服务器，在服务器已保存的信息中查询目标第三方应用程序身份标识以及本地保存的用户id对应的用户授权信息； 所述将服务器返回的用户授权信息发送给目标第三方应用程序包括: 判断查询到的用户授权信息是否有效，如果有效，则发送给目标第三方应用程序； 如果无效，则请求服务器为根据目标第三方应用程序的身份标识以及用户id进行用户授权，并将重新接收到的用户授权信息发送给目标第三方应用程序。
10.根据权利要求1至3任一项所述的方法，其特征在于，所述确定各个功能模块中分别使用的应用程序包括: 展示各个功能模块中分别可供选择的应用程序，并为用户提供选择操作入口 ； 根据用户的选择结果，确定各个功能模块中分别使用的应用程序。
11.一种业务处理系统，其特征在于，包括: 程序确定单元，用于确定各个功能模块中分别使用的第三方应用程序；其中，所述功能模块为按照电子商务流程中各个阶段的使用场景划分的功能模块； 回调地址获取单元，用于在需要调用指定功能模块时，根据所述指定功能模块中使用的目标第三方应用程序的身份标识，向服务器获取所述目标第三方应用程序的回调地址；所述回调地址根据写入到所述目标第三方应用程序代码的统一资源定位符方案字段的信息生成，所述目标第三方应用程序已在所述服务器中对所述统一资源定位符方案字段的信息进行注册； 调用单元，用于按照所述目标第三方应用程序的回调地址调用所述目标第三方应用程序，进行相应的业务处理。
【文档编号】G06Q30/00GK103942093SQ201310024468
【公开日】2014年7月23日 申请日期:2013年1月23日 优先权日:2013年1月23日
【发明者】岑文初, 王文彬, 冯光, 墙辉, 李 杰, 李继斌, 朱成夷 申请人:阿里巴巴集团控股有限公司