我对B端任务中心功能的设计思考
如果大家留意，在B端系统中，经常会看到一个任务中心的模块。那么这个模块的作用是什么，为什么要设计这个模块呢？今天笔者就从自身的工作经验出发，来给大家介绍一下我对OMS系统中任务中心模块的设计思考。
一、为什么需要任务中心
B端系统中任务中心的出现，和程序编程接口（API）的特性脱不开关系。应用程序接口API（Application Programming Interface），是提供特定业务输出能力、连接不同系统的一种约定。这里包括外部系统与提供服务的系统（中后台系统）或后台不同系统之间的交互点。包括外部接口、内部接口等。接口的响应机制类型有：
- 同步交互：即需等待服务端将请求处理完成，接口才会返回结果，业务才可以继续进行。如登录验证时，需要服务端验证通过账号密码时，接口才会返回成功，才能正常登录。
- 异步交互：接口返回成功仅表示请求行为成功了，对方系统收到请求后异步对业务进行操作，调用方无须等待每个请求的调用结果。如OMS请求发货，接口返回成功，仅表示WMS收到了这个请求，WMS系统还会异步的去生成对应的发货单进行操作。
一般来说用户登录、单据状态的变更等等，都会使用同步交互操作，其余情况都优先使用异步交互。但是无论同步交互还是异步交互，仍然会遇到以下问题：
同步交互： 接口调用超时或由于非业务原因导致的调用失败，需要重复调用，那么我们当请求失败时其实最好的选择是：
step1：界面提示：
- case1：请求成功
- case2：请求失败，系统自动重
- case3：请求失败，失败原因为：xxxx
step2：系统自动重试：
- if 达到一定的次数
- 自动停止，展示错误原因，通知用户允许用户手动重试
异步交互：接口调用成功了（如果失败，和同步交互的处理方式一致），但是实际业务没正常进行。
对方系统推送失败数据，进行界面提示：
- 根据预设的逻辑，系统根据失败原因自动处理
- 用户查看失败原因，手动处理
由此可见，多系统间的交互异常是频繁的，那么用户仍需要对这种情况进行处理，则提出了几点要求：
1、要方便感知：同步交互的方式下，异常反馈时，一般用户仍然会停留在业务发生界面，故可以使用弹窗的方式展示异常的原因或者详细的异常数据。但是由于长时间请求未响应的异常，用户可能就没有停留在当前界面了，同样的异步交互的方式下，异常反馈时，一般用户都已经离开了业务发生界面，这是使用弹窗提醒就不合适了；
2、要方便的重试：在一些业务中，用户发起一次操作需要提交很多参数，如果直接要求客户重新从头做该操作，肯定会降低用户的效率；
那么我们知道，人驱动系统、事体现过程、物记录结果、规则控制运行，我们需要有一个单据或者说任务来承载这些诉求。所以我们一般将这些请求任务聚合起来管理的模块叫做任务中心。
二、任务中心的设计案例
在网上看了很多文章，讲了太多的理论和最后的结果，却不清楚一个功能为什么设计成当前的样子，而不是另外的样子。那么接下来，我们以商家调整商品上下架操作为例，来给大家讲解一下任务中心如何设计。
拆解：
首先，我们习惯将一个大而复杂的场景，根据参与者等要素的不同，拆解成几个用例。用例怎么拆，可以参考《火球：UML大战需求分析》或者《大象：think in uml》两本书。拆解用例的目的，是为了清晰的确认参与者、前置条件、业务场景、后置条件，更方便我们分析一个复杂的业务场景，更有利于我们发现一些可以复用的场景。
如上图可以看到，我们发现其实用例3和用例4是可以多个业务场景是可以复用的，这就是我们在产品设计过程中划分功能模块的重要思路。
拆解：
我们需要有一种结构化的方式，来设计产品方案，一般来说，我习惯用《用例分析》的方式来进行拆解。
设计：
在复杂的业务设计中，一般都涉及到状态机的设计，那么我习惯优先设计业务的信息架构和状态机，然后进行页面的设计。
（本图仅为示意图，已做数据脱敏并简化了业务，仅做说明使用）
三、任务中的数据加工机制说明
一般来说，任务中的数据加工机制是有两种实现方式的：
方式1：在任务创建时，即把同步给平台的数据加工完成为一个数据包，当任务执行时，直接将数据包抛给对应平台。
方式2：在任务创建时，只记录基础的请求信息，当任务执行时，再根据需同步数据当前的值加工一个数据包抛给对应平台。
方式1适合字段值明确的任务，如同步订单发货的请求等业务，在这个业务中，{key:value}结构下，value的值是确定的，故可以直接在任务创建时，就将数据包加工出来。
方式2适合同步范围明确的任务，如同步当前OMS系统中的商品上下架状态到外卖平台，在这个业务中，目的是保证平台上的商品上下架状态和OMS中商品的上下架状态一致，如果在任务创建时，就将数据包加工出来，如果此时商品的上下架状态发生变化，由于任务是按创建顺序依次执行的，可能出现平台上的商品上下架状态与OMS系统中短暂不一致的情况，造成一些业务问题。
四、任务中心的适用范围
不能立刻反馈操作结果的业务：如商家向平台同步商品上下架的请求，平台需依次校验后返回是否调用成功，需要一段时间。
需要预定时间执行的业务：如一些商品的特价活动，需要限定时间内生效，故可以放入任务中心统一管理。
业务执行结果较复杂不方便查看的业务：如商品信息同步到外卖平台，由于平台有多种校验机制，可能部分商品由于敏感词等原因出现各种不同的失败原因，需要用户多次查看，依次解决，故需要有一个地方能够进行查看。
需要重复执行的业务：如一些任务异常后，仍需要再次执行的任务。
五、任务中心设计的原则
入口统一，贴近业务：应培养客户心智，将系统中所有涉及的任务都放入一个入口，可将此功能设计到左侧导航栏或其他全局导航中。引导用户从请求反馈弹窗中进入任务中心查看。
进度可视化：防止客户因不知道业务还在进行，而重复发起操作。
支持异常原因的查看：允许查看执行失败和部分数据执行异常的原因，异常原因需进行翻译，尽量不要直接将接口返回的报错显示出来，因为用户无法根据异常的原因，直接做出相应的调整。正确的异常原因应该是【因为XX导致上传未成功，需做XX操作】。
控制数据量：异常数据要长久保存，正常数据可以稍微短一点，防止出现查询性能问题，已经浪费存储空间。
注意重试机制的设计：控制好重试的用户权限一个任务是否支持重试，需考虑实际业务允不允许重试，控制好哪些状态的任务支持重试。
注意异常的提醒设计：可参考文章《我对B端通知提醒功能的设计思考 | @kathic 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
