给 Hangfire 的 webjob 增加 callback 和动态判断返回结果功能设计
通常业务中需要用到定时执行功能,我用hangfire搭建了一个调度服务,这个调度服务是独立于业务逻辑的,具体可以参考文章:https://github.com/yuzd/Hangfire.HttpJob/wiki
也就是说只要我有了这个调度服务后,只要提供给我的接口 我就可以调度它(比如在xx点xx分运行,或者每隔xx分运行,或者每周一8点运行等等)。
但是有一个问题,对方的接口是调用成功还是失败完全取决于对方的接口设计!
有的接口被设计成 请求的StatusCode 是200的是代表接口成功,非200的代表接口失败。
有的接口被设计成返回的json结构有一个特定的字段来代表接口调用成功还是失败,例如:success字段。比如返回的结构大概这样子: {"success":false,"data":"xxxx"}
等等,这些都是 case by case ,不同的写接口的人定的规则可能不一样,通过webjob的调用方式如何动态的验证成功还是失败呢?
如上面提到动态的验证结果,我分了2种情况处理:要么看Response返回的statuscode,要么是看返回的结果里面的指定字段来判断!
1. 根据Response返回的statuscode
statuscode 很好做,我在设计Hangfire.HttpJob这个扩展插件时是可以在外部设置一个验证委托
默认的返回的statuscode 小于 400 则认为http请求是成功的,否则失败
2. 返回的结果里面的指定字段来判断
我采用EL表达式来实现的,EL表达式将请求的返回体设置为json变量,然后在表达式中可以直接以属性的方式到值,表达式返回布尔类型。
针对不同的接口,我可以设置一个独立的表达式来进行判断!
首先在job添加的时候设置el表达式!如下图
如何写EL表达式:(很简单,返回的结构体是什么字段就可以用什么字段)
接口的返回体是一个string。我先将这个String转成json类型(dynamic)
然后是采用 Spring.EL 表达式实现的。 CallbackEL表达式的返回类型是布尔类型
返回体在表达式里面是有下面2个变量:
- #resultBody 是返回体的 string
- #result 是返回体的 json体(根据上面转的,如果上面是非json格式的那就不能使用这个变量了)
比如说我调用的httpjob 返回体是
{"Success":false,"Info":"test"}
那么我可以这么写
"CallbackEL": "#result.Success"
也可以这么写
"CallbackEL": "#result.Info.Equals('ok')"
表达式如何运行的?
Spring.EL是我从Spring.Net里面剥离出来的一个组件,可以从nuget里面引用,支持net45和netstandard2.0
//检查是否有设置EL表达式 if (!string.IsNullOrEmpty(item.CallbackEL)){ var elResult = InvokeSpringElCondition(item.CallbackEL, result, context, new Dictionary<string, object> { { "resultBody", result } }); if (!elResult){ throw new HttpStatusCodeException(item.CallbackEL, result); } RunWithTry(() => context.WriteLine($"【{Strings.CallbackELExcuteResult}:Ok 】" + item.CallbackEL)); } /// summary /// 用EL表达式动态判断是否执行成功 private static bool InvokeSpringElCondition(string placeholder,string result, PerformContext context,Dictionary<string, object> param){ try{ try{ param["result"] = JsonConvert.DeserializeObject(result); }catch (Exception){ //ignore } var parameterValue = ExpressionEvaluator.GetValue(null, placeholder, param); return (bool)parameterValue; } catch (Exception e){ context.WriteLine($"【{Strings.CallbackELExcuteError}】" + placeholder); context.WriteLine(e); return false; } }
调用对象 ExpressionEvaluator 传 Dictionary<string, object> param 作为参数,使用#参数来引用。如果你的参数是string 那么可以写c#中string的所有方法比如 StarsWith,EndsWith,Equals 等等
如果你的参数类型是一个dynamic,那你就可以直接像使用js的对象属性一样
Callback功能设计
举例:
我们调用了A接口,如果A接口成功我们想把A接口的返回值作为请求参数再去调用B接口。
如果A接口失败在调用C接口通知错误!
参考ajax的callback设计
如上图 可以自行添加 Success 或者 Fail 作为回调
如果定义了Success 那么父job执行成功没有报错则运行 Success回调
如果定义了Fail 那么父job执行失败 则运行 Fail回调
Success 里面还可以定义 Success 和 Fail
Fail 里面还可以定义 Success 和 Fail 如下图:
回调的Json参数
字段 | 说明 |
---|---|
Url | 请求Url |
Method | Post,Get |
Data | Post时可以填,支持占位符(具体请看下面的介绍) |
ContentType | application/json |
Timeout | 超时(毫秒) |
BasicUserName | basicauth用户名 |
BasicPassword | basicauth密码 |
AgentClass | 基于jobAgent开发的httpjob需要填 |
Headers | key:value 的jsonstring "{"key":,"value"}" |
回调执行的逻辑
注意:回调不是作为新的的HangfireHttpJob执行的,是依附在最顶级的父Job的!
举例:
如果:JobA -》 Fail B -> Success BB
JobA本身执行错误的话则会走重试逻辑(如果开启重试的话),重试到顶后 进入 Fail B, Fail B 执行成功 则进入 Success BB。如果Success BB 执行成功,那么 JobA 则认为是成功的,否则认为失败!
如果:JobA -》 Fail B -> Fail BB
JobA本身执行错误的话则会走重试逻辑(如果开启重试的话),重试到顶后 进入 Fail B, Fail B 执行失败 则进入 Fail BB 。Fail BB 执行失败,那么 JobA 认为失败!
Fail B 执行成功 进入 Success C, Success C,执行成功 认为 JobA 认为成功,否则 Job A 认为失败!
总结:如果回调 则会按照设置的回调一路走下去,看最后一个回调是否成功。如果成功 则认为整个链路执行成功,否则认为失败!
回调的代码实现是一个递归的方式调用
为了实现回调能够把上一个运行的结果最为参数,开发了占位符(placeholder)功能
也为了更好的扩展占位符功能,
首先要介绍下 dashbord里面的 全局配置 功能 如下图:
- 全局配置 :存储在当前目录下的 hangfire_global.json 文件(可以在StartUp代码修改HangfireHttpJobOptions.GlobalSettingJsonFilePath值指定其他地方
这个功能为了介绍重复的配置,可以集中配置一些参数,然后给各个job去使用!
占位符功能采用Spring.EL表达式实现的。
字符串中placeholder替换逻辑
- 第一步:把字符串中的 ${xxx} 的xxx全部替换成 全局配置里面的值
- 第二步:把字符串中的 #{yyy} 的yyy全部按照SpringEL表达式逻辑运行后的值进行替换
比如:上图中你在全局配置了一个参数叫test
Data:"你好呀:${test}"
在运行时会被替换成 =》 你好呀:1
例如:使用父job的返回值传给 callback
如果运行失败传给callback是报错信息
例如:使用时间替换
可以直接在 #{} 方法里面用DateTime这个变量 这个变量和c#一样的功能
比如
- #{DateTime.Now} 代表运行时的当前时间+时分秒
- #{DateTime.Today} 代表运行时的当天
- #{DateTime.Today.AddDays(-1)} 代表运行时的昨天
- #{DateTime.Today.AddDays(1)} 代表运行时的明天
总结:
以上 hangfire 的 webjob 调度扩展组件 https://github.com/yuzd/Hangfire.HttpJob/wiki
已经非常灵活了,基于hangfire的核心调度功能,加上webjob的调用方式,很方便的把业务逻辑分离出来!
不管业务接口如何写,基于EL表达式都可以准确的判断出来执行成功还是失败,根据回调功能很方便的执行链式调用和错误通知!