补偿式工作流是Stf非常有意思的一个特性，它是一种简约的DSL，用以编排业务在异常下的补偿动作。同时，它又不是典型意义上的工作流，因为Stf希望程序的主控权是能够握于开发者手中的，主控方在coder（有匠心的工程师），辅控方可以是flow（冰冷的低代码）。
更多的介绍，后续还会撰文阐述。
下文将主要结合stun4j-stf-boot-sample工程，对补偿式工作流的使用进行说明。
来看sample中的配置片段，如下：
stfs {
local-vars { #允许自定义本地变量
dp = com.stun4j.stf.sample.domain
}
actions { #动作定义(亦即,方法定义)
acceptReq { #动作名,即方法名
args = [{use-in:{class:${dp}.Req}}] #方法参数 use-in表示入参类型为com.stun4j.stf.sample.domain.Req,dp变量简化了表达
}
step1Tx {
args = [{invoke-on-in:{method:getId, class:Long}}, {invoke-on-in:{method:getReqId, class:String}}] #invoke-on-in表示入参取值会通过施加在入参对象上的反射来获得,method和class是反射的必要元素,其义自现
#此处要额外说明的是,一些内置类型可以不给出类的全限定名
#目前Stf支持的主要是java.lang下的一些包装类型,如："Boolean", "Byte", "Character", "Double", "Float", "Integer", "Long", "Short", "String"
}
step2Tx {
args = [{use-in:{class:${dp}.Tx}}]
}
endTx {
args = [{use-in:{class:${dp}.Tx}}]
}
sendNotification {
oid = bizApp #oid是指方法的对象id,在spring容器中就是bean的id,目前还不支持静态方法的调用
args = [{use-in:{class:String}}]
timeout = 10s #自定义方法调用的超时时间,目前仅支持'秒'
}
}
forwards { #流程定义(亦即,上下游方法链)
acceptReq.to = step1Tx #acceptReq的 下一个动作(下游方法) 是step1Tx
step1Tx.to = step2Tx
step2Tx.to = endTx
endTx.to = sendNotification
}
}再看另外一个配置
stfs {
global { #全局定义区块
oid = entry
}
actions {
handle {
oid = bizOrphanStep
args = [{use-in:{class:com.stun4j.stf.sample.domain.Req}}]
timeout = 15s
}
}
forwards {
index.to = handle #因为global区块中配置了oid，所以index方法的oid就是entry了，而handle这个action定义了自己的oid，就不会沿袭global中的定义了
}
}一般只需将工作流相关的配置文件，放置于工程classpath下的stfs目录，就会被加载和读取。当然也可额外进行指定，参考此处。
在Stf中，一个action必须具备oid，否则是无法调用的。如果在一个stf-flow的配置中，没有为相应的action配置oid，那么其oid会按照如下顺序进行定位，如下：
配置文件名前缀 -> flow配置中'global区块'中定义的oid -> flow配置中'action区块'中定义的oid
右侧默认继承左侧，可override左侧，具体请看sample工程相关配置。
Stf框架运行需要的表结构位于stun4j-stf-core工程的src/test/resources/schema目录下。