首页> 中国专利> 脚本驱动环境下的远程调用方法和远程调用装置

脚本驱动环境下的远程调用方法和远程调用装置

摘要

本发明提供了一种脚本驱动环境下的远程调用方法和一种脚本驱动环境下的远程调用装置,其中,所述脚本驱动环境下的远程调用方法,包括:在接收到对前台任一控件的操作时,判断所述操作的类别;在判定所述操作为修改所述任一控件属性和/或行为的操作时,不执行对后台的远程调用;在判定所述操作为获取所述任一控件属性的操作时,判断所述任一控件的属性和/或行为是否被修改,若否,则不执行对后台的远程调用。通过本发明的技术方案,可以避免不必要的远程调用,降低了远程调用的次数,优化了系统的性能,提升了用户的体验。

著录项

  • 公开/公告号CN104077139A

    专利类型发明专利

  • 公开/公告日2014-10-01

    原文格式PDF

  • 申请/专利权人 用友软件股份有限公司;

    申请/专利号CN201410318899.1

  • 发明设计人 张乐龙;

    申请日2014-07-04

  • 分类号

  • 代理机构北京友联知识产权代理事务所(普通合伙);

  • 代理人尚志峰

  • 地址 100094 北京市海淀区北清路68号用友软件园

  • 入库时间 2023-12-17 01:49:17

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2017-11-24

    授权

    授权

  • 2015-12-02

    著录事项变更 IPC(主分类):G06F9/44 变更前: 变更后: 申请日:20140704

    著录事项变更

  • 2014-10-29

    实质审查的生效 IPC(主分类):G06F9/44 申请日:20140704

    实质审查的生效

  • 2014-10-01

    公开

    公开

说明书

技术领域

本发明涉及计算机技术领域,具体而言,涉及一种脚本驱动环境下的 远程调用方法和一种脚本驱动环境下的远程调用装置。

背景技术

在脚本驱动环境下,脚本引发会引发远程调用,这常常引发远程调用 过多(例如打开界面有近100个远程调用)。

商业智能或者其他业务系统可能需要实现更灵活的定制功能,而引入 脚本是实现这种需求的一种途径。但是,在实现最大的灵活性的同时,也 带来了更大的技术挑战:因为脚本之间互相调用而产生大量的远程调用, 从而影响系统的性能。具体地,如图1所示的界面,需要编写如下的脚 本:

脚本1:系统初始化脚本:

var默认组织=获得默认组织远程API();//引发远程调用

组织控件.设置默认组织(默认组织);

脚本2:组织控件的内容变更事件脚本:

var组织id=组织控件.获得值();//引发远程调用

var产品分类数组=产品分类API.根据条件获得产品分类(组织id);

产品分类控件.设置产品分类值(产品分类数组[0]);

脚本3:产品分类控件的内容变更事件脚本

var产品分类id=产品分类控件.获得值();

var产品数组=产品API.根据条件获得产品(产品分类id);//引发 远程调用

产品控件.设置产品值(产品数组[0]);

脚本4:产品控件的内容变更事件脚本

var产品id=产品控件的值;

销售统计图.刷新();//引发远程调用

库存统计图.刷新();//引发远程调用

占比分析.刷新();//引发远程调用

组合分析.刷新();//引发远程调用

本月销量表.刷新();//引发远程调用

在如图1所示的简单实例中,远程调用一共发生了至少9次(考虑到 这个界面的打开),而在其他实例中,可能引发的远程调用会达到几十 次,严重这影响了系统性能和用户的体验。

因此,如何避免不必要的远程调用,降低远程调用的次数,以优化系 统的性能和用户的体验成为亟待解决的技术问题。

发明内容

本发明正是基于上述技术问题,提出了一种新的脚本驱动环境下的远 程调用方案,可以避免不必要的远程调用,降低了远程调用的次数,优化 了系统的性能,提升了用户的体验。

有鉴于此,本发明提出了一种脚本驱动环境下的远程调用方法,包 括:在接收到对前台任一控件的操作时,判断所述操作的类别;在判定所 述操作为修改所述任一控件属性和/或行为的操作时,不执行对后台的远 程调用;在判定所述操作为获取所述任一控件属性的操作时,判断所述任 一控件的属性和/或行为是否已被修改,若是,则不执行对后台的远程调 用。

在该技术方案中,通过在对前台控件执行修改控件属性和/或行为的 操作时,以及在对属性和/或行为已修改的控件执行获取属性的操作时, 不执行对后台的远程调用,可以避免不必要的远程调用,降低了远程调用 的次数,优化了系统的性能,提升了用户的体验。

在上述技术方案中,优选地,在判定所述操作为修改所述任一控件属 性和/或行为的操作时,还包括:响应所述修改所述任一控件属性和/或行 为的操作,并设置对应于所述任一控件的标识位;判断所述任一控件的属 性和/或行为是否被修改的步骤具体为:判断是否存在对应于所述任一控 件的标识位,若存在,则判定所述任一控件的属性和/或行为已被修改。

在该技术方案中,通过在对控件的属性和/或行为进行修改之后,设 置对应于该控件的标识位,使得能够通过判断该控件是否存在标识位方便 地判断该该控件的属性和/或行为是否被修改。

在上述技术方案中,优选地,还包括:将所述前台的初始化业务逻辑 转移到所述后台执行。

在上述技术方案中,优选地,还包括:若所述前台需要对所述后台进 行远程调用,则将触发所述远程调用的操作添加至执行队列中,以对添加 至所述执行队列中的操作进行合并。

在该技术方案中,通过将触发远程调用的操作添加至执行队列中,以 进行合并,使得可以最大限度地降低远程操作的次数。

在上述技术方案中,优选地,对添加至所述执行队列中的操作进行合 并包括:合并所述执行队列中的操作的执行接口、合并所述执行接口的实 现注册表、合并所述执行队列中的操作的执行服务。

根据本发明的另一方面,还提出了一种脚本驱动环境下的远程调用装 置,包括:判断单元,用于在接收到对前台任一控件的操作时,判断所述 操作的类别,以及在判定所述操作为获取所述任一控件属性的操作时,判 断所述任一控件的属性和/或行为是否已被修改;处理单元,用于在判定 所述操作为修改所述任一控件属性和/或行为的操作时,不执行对后台的 远程调用,以及在所述判断单元判定所述操作为获取所述任一控件属性的 操作,且判定所述任一控件的属性和/或行为已被修改时,不执行对后台 的远程调用。

在该技术方案中,通过在对前台控件执行修改控件属性和/或行为的 操作时,以及在对属性和/或行为已修改的控件执行获取属性的操作时, 不执行对后台的远程调用,可以避免不必要的远程调用,降低了远程调用 的次数,优化了系统的性能,提升了用户的体验。

在上述技术方案中,优选地,还包括:响应单元,用于在所述判断单 元判定所述操作为修改所述任一控件属性和/或行为的操作时,响应所述 修改所述任一控件属性和/或行为的操作,并设置对应于所述任一控件的 标识位;所述判断单元具体用于:判断是否存在对应于所述任一控件的标 识位,若存在,则判定所述任一控件的属性和/或行为已被修改。

在该技术方案中,通过在对控件的属性和/或行为进行修改之后,设 置对应于该控件的标识位,使得能够通过判断该控件是否存在标识位方便 地判断该该控件的属性和/或行为是否被修改。

在上述技术方案中,优选地,所述处理单元还用于:将所述前台的初 始化业务逻辑转移到所述后台执行。

在上述技术方案中,优选地,所述处理单元还用于:在所述前台需要 对所述后台进行远程调用时,将触发所述远程调用的操作添加至执行队列 中,以对添加至所述执行队列中的操作进行合并。

在该技术方案中,通过将触发远程调用的操作添加至执行队列中,以 进行合并,使得可以最大限度地降低远程操作的次数。

在上述技术方案中,优选地,对添加至所述执行队列中的操作进行合 并包括:合并所述执行队列中的操作的执行接口、合并所述执行接口的实 现注册表、合并所述执行队列中的操作的执行服务

通过以上技术方案,最大限度地避免不必要的远程调用,降低了远程 调用的次数,优化了系统的性能,提升了用户的体验。

附图说明

图1示出了基于脚本生成的界面示意图;

图2示出了根据本发明的实施例的脚本驱动环境下的远程调用方法的 示意流程图;

图3示出了根据本发明的实施例的脚本驱动环境下的远程调用装置的 示意框图;

图4示出了根据本发明的实施例的前台和后台逻辑结构示意图;

图5示出了根据本发明的实施例的前台合并的逻辑结构示意图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附 图和具体实施方式对本发明进行进一步的详细描述。需要说明的是,在不 冲突的情况下,本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是, 本发明还可以采用其他不同于在此描述的其他方式来实施,因此,本发明 的保护范围并不受下面公开的具体实施例的限制。

图2示出了根据本发明的实施例的脚本驱动环境下的远程调用方法的 示意流程图。

如图2所示,根据本发明的实施例的脚本驱动环境下的远程调用方 法,包括:步骤202,在接收到对前台任一控件的操作时,判断所述操作 的类别;步骤204,在判定所述操作为修改所述任一控件属性和/或行为的 操作时,不执行对后台的远程调用;步骤206,在判定所述操作为获取所 述任一控件属性的操作时,判断所述任一控件的属性和/或行为是否已被 修改,若是,则不执行对后台的远程调用。

在该技术方案中,通过在对前台控件执行修改控件属性和/或行为的 操作时,以及在对属性和/或行为已修改的控件执行获取属性的操作时, 不执行对后台的远程调用,可以避免不必要的远程调用,降低了远程调用 的次数,优化了系统的性能,提升了用户的体验。

在上述技术方案中,优选地,在判定所述操作为修改所述任一控件属 性和/或行为的操作时,还包括:响应所述修改所述任一控件属性和/或行 为的操作,并设置对应于所述任一控件的标识位;判断所述任一控件的属 性和/或行为是否被修改的步骤具体为:判断是否存在对应于所述任一控 件的标识位,若存在,则判定所述任一控件的属性和/或行为已被修改。

在该技术方案中,通过在对控件的属性和/或行为进行修改之后,设 置对应于该控件的标识位,使得能够通过判断该控件是否存在标识位方便 地判断该该控件的属性和/或行为是否被修改。

在上述技术方案中,优选地,还包括:将所述前台的初始化业务逻辑 转移到所述后台执行。

在上述技术方案中,优选地,还包括:若所述前台需要对所述后台进 行远程调用,则将触发所述远程调用的操作添加至执行队列中,以对添加 至所述执行队列中的操作进行合并。

在该技术方案中,通过将触发远程调用的操作添加至执行队列中,以 进行合并,使得可以最大限度地降低远程操作的次数。

在上述技术方案中,优选地,对添加至所述执行队列中的操作进行合 并包括:合并所述执行队列中的操作的执行接口、合并所述执行接口的实 现注册表、合并所述执行队列中的操作的执行服务。

图3示出了根据本发明的实施例的脚本驱动环境下的远程调用装置的 示意框图。

如图3所示,根据本发明的实施例的脚本驱动环境下的远程调用装置 300,包括:判断单元302,用于在接收到对前台任一控件的操作时,判 断所述操作的类别,以及在判定所述断所述操作为获取所述任一控件属性 的操作时,判断所述任一控件的属性和/或行为是否已被修改;处理单元 304,用于在判定所述操作为修改所述任一控件属性和/或行为的操作时, 不执行对后台的远程调用,以及在所述判断单元判定所述操作为获取所述 任一控件属性的操作,且判定所述任一控件的属性和/或行为已被修改 时,不执行对后台的远程调用。

在该技术方案中,通过在对前台控件执行修改控件属性和/或行为的 操作时,以及在对属性和/或行为已修改的控件执行获取属性的操作时, 不执行对后台的远程调用,可以避免不必要的远程调用,降低了远程调用 的次数,优化了系统的性能,提升了用户的体验。

在上述技术方案中,优选地,还包括:响应单元306,用于在所述判 断单元302判定所述操作为修改所述任一控件属性和/或行为的操作时, 响应所述修改所述任一控件属性和/或行为的操作,并设置对应于所述任 一控件的标识位;所述判断单元302具体用于:判断是否存在对应于所述 任一控件的标识位,若存在,则判定所述任一控件的属性和/或行为已被 修改。

在该技术方案中,通过在对控件的属性和/或行为进行修改之后,设 置对应于该控件的标识位,使得能够通过判断该控件是否存在标识位方便 地判断该该控件的属性和/或行为是否被修改。

在上述技术方案中,优选地,所述处理单元304还用于:将所述前台 的初始化业务逻辑转移到所述后台执行。

在上述技术方案中,优选地,所述处理单元304还用于:在所述前台 需要对所述后台进行远程调用时,将触发所述远程调用的操作添加至执行 队列中,以对添加至所述执行队列中的操作进行合并。

在该技术方案中,通过将触发远程调用的操作添加至执行队列中,以 进行合并,使得可以最大限度地降低远程操作的次数。

在上述技术方案中,优选地,对添加至所述执行队列中的操作进行合 并包括:合并所述执行队列中的操作的执行接口、合并所述执行接口的实 现注册表、合并所述执行队列中的操作的执行服务。

本发明主要提出了通过前台逻辑后移和前台远程调用合并的方案实现 最大限度地降低远程调度的次数。具体地,以下结合图4至图5详细说明 本发明的技术方案。

图4示出了根据本发明的实施例的前台和后台逻辑结构示意图。

前台逻辑后移主要包括将本来在前台执行的初始化逻辑转移到后台, 相当于执行了合并。这需要在后台执行脚本和业务逻辑,此处的业务逻辑 仅初始化。

具体地,如图4所示,根据本发明的实施例的前台和后台逻辑,包 括:

用户界面,主要设置在前台,用于获取用户的各种操作。

后台执行器,用来在后台模拟前台执行环境,当然仅仅是业务逻辑上 的模拟,不包括前台控件本身的执行。后台执行器需要总控脚本引擎、事 件管理器、各种API、控件后台模型等。

脚本引擎,脚本引擎用来执行脚本。脚本中有对控件模型、API等的 调用,因此脚本引擎启动之前,需要由后台执行器设置对应的执行环境。 例如:脚本引擎必须知道脚本中对API的调用如何对应到到真正的组织 API运行期代码。

事件管理器,因为前台支持事件机制,因此后台要执行前台逻辑,也 必须执行事件代码。事件管理器支持各种定义好的前台事件。

控件后台模型,脚本对控件的操作通过控件模型进行,在后台也应建 立对应的控件后台模型。例如:脚本列表控件的设置值将导致控件发生 “选项变更”事件。

后台API,提供需要的API调用服务。是前台API在后台的体现。

UI元数据:用于描述UI环境,描述方式不限,例如使用XML描述 UI;逻辑处理和UI生成器:用于生成UI之前的逻辑处理(如获取数据、 权限过滤等),并生成UI(如HTML等)。

图5示出了根据本发明的实施例的前台合并的逻辑结构示意图。

其中,前台合并的原理主要是:1)对于修改控件属性或者控件行为 的操作(即set操作)不引发后台的刷新操作,并且在修改空间属性或控 件行为之后,将set操作置脏标记;2)对于获取控件属性的操作(即get 操作),需要判断脏标记是否被设置,如不是就应该刷新;3)每次刷新 都应该将全部待执行的操作(command)传递到后台服务,在后台服务中 执行全部操作。

如图5所示,前台合并的要点包括前台合并框架、后台合并框架、合 并执行的时机选择。

针对前台合并框架。该框架起到协调脚本、控件刷新、后台合并执行 服务的作用,是前台合并的核心,主要包括:

1)待执行队列,需要合并执行的操作会被放到待执行队列中。记录 的内容包括控件ID、API、参数及适当的附加信息;

2)添加合并执行API,将待执行操作添加到队列中,通常由set方法 调用;

3)激发执行API,通常由控件的set方法调用;

4)远程调用框架后台通讯执行远程调用,可以利用AJAX执行。

5)结果分发,后台合并执行的结果也是一个合并的结果,合并的结 果数据需要被分发到各个控件。

针对后台合并框架。提供根据待执行队列,调用各控件的合并执行接 口获取结果,并将结果返回前台。包括三个部分:合并执行接口、合并执 行接口实现注册表、合并执行服务。每个需要合并执行的控件都应该自己 实现合并接口。合并执行接口注册表是一个从控件类型到接口实现的映射 表。

针对合并执行时机选择。其中,时机的选择有两个:1)用户事件执 行完,合并执行队列中有待执行任务;2)脚本中调用了set之后,又调用 了其get方法。

普通的set方法不引发远程调用,而是进入全局合并执行队列。当需 要此数据时(如某get方法被调用),全局合并执行队列将被执行。此时队 列中的远程调用被合并为一个,打包后提交到后台。

通过上述技术方案,可以实现对使用了很多数据控件的UI的后台执 行次数进行优化,尽力降低后台执行的次数,提升用户感受,主要包括: UI第一次打开时,仅有一个远程调用;对UI的后续操作,大量减少远程 连接数量。

以上结合附图详细说明了本发明的技术方案,考虑到相关技术中,前 台对后台的远程调用较多,严重影响了系统的性能和用户的体验。因此, 本发明提出了一种新的脚本驱动环境下的远程调用方案,可以避免不必要 的远程调用,降低了远程调用的次数,优化了系统的性能,提升了用户的 体验。

以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于 本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精 神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明 的保护范围之内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号