[发明专利]请求处理方法、装置及电子设备

说明书

本申请实施例公开了请求处理方法、装置及电子设备，所述方法包括：应用系统获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；确定支持所述目标业务身份标识信息的目标插件包；在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。通过本申请实施例，能够实现业务与平台代码的隔离，更好的实现业务对功能扩展点实现逻辑的定制。

技术领域

本申请涉及请求处理技术领域，特别是涉及请求处理方法、装置及电子设备。

背景技术

在一些平台化的应用系统中，通常会需要支持多个不同的业务系统。例如，商品对象信息服务系统中的交易应用系统、购物车应用系统等都属于这类应用系统，需要支持男装、女装、票务、家居等多个不同的业务系统的接入。而不同的业务系统通常会按照行业及市场的不同，要求平台的应用系统能够提供在不同的业务模式下支持不同的业务逻辑定制，实现业务独有的功能特性。这就要求同一个应用系统中，既有平台通用逻辑，同时又有各种不同的业务定制逻辑。

现有技术中，业务代码和平台代码混杂在一起。例如，在交易系统的下单流程中，通常会存在下单后如果未及时付款则订单关闭的功能，而不同的业务系统对于该功能的超时时间可能有不同的需求。例如，对于票务业务的付款时间，需要将超时时间定为30分钟，家居业务则需要将超时时间定为2小时，等等。在现有技术中，这种针对不同业务系统的不同需求，通常需要写在平台代码中。例如，在交易系统的平台代码中需要写入某段逻辑，该逻辑中，首先可以获取超时时间信息，然后执行判断逻辑，如果是票务业务，则超时时间为30分钟，如果是家居业务，则超时时间为2小时，然后再进行是否已经超时的判断，等等。

但是，在同一应用系统中，可定制的部分通常有很多，例如，简单如交易流程而言，除了前述的超时时间信息可以定制之外，关于最多可购买的数量，是否可用优惠券等多个环节上都可能可以定制。而在现有技术的实现方式中，这些不同业务系统的不同定制信息散落在数百万行的平台代码中。如果需要修改，则工作量会比较大，并且，一个业务的定制信息修改，可能会对其他业务的正常运行造成影响。

发明内容

本申请提供了请求处理方法、装置及电子设备，能够实现业务与平台代码的隔离，更好的实现业务对功能扩展点实现逻辑的定制。

本申请提供了如下方案：

一种请求处理方法，包括：

应用系统获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

确定支持所述目标业务身份标识信息的目标插件包；

在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

一种业务配置信息发布方法，包括：

接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。