工作流程结构、促销优惠流程
Workflow Structure, Promotion Offer Flow
非常感谢您在实施细节方面的帮助,以及我在下面提出的 2 个澄清问题:
上下文:
正在创建优惠促销工作流程。报价有截止日期(我们在报价被接受后开始倒计时。)
用户可以选择拒绝报价(工作流程随后停止)
一旦报价被接受,他们将有 7 天的时间尝试兑换现金返还积分。一旦他们满足返现积分要求,我们会将积分记入他们的账户
第一个问题:下面的逻辑是否正确?我正在使用信号。
第二个问题:我正在听 'parentSignal' 频道上的父工作流中的信号。监听“接受”、“拒绝”、“取消”。
在子工作流程中,我正在监听“10%CASHBACK”、“50%CASHBACK”、“100%CASHBACK”以及“CANCELLED”,因为管理员可以随时取消 he/she。这是触发工作流程的正确方式吗?
我是如何考虑编写工作流程的(但是,当我尝试发出不同的信号时,我似乎无法让它在 Cadence GUI 中正常工作)
Parent workflow (OfferWorkflow)
Listen for signal (signal received from external service)
if accept, start execute Child Workflow (cashback workflow)
if reject, end workflow
if cancelled (by admin, end workflow, cancel any cashback progress)
child workflow (cashbackWorkflow, with expiration time)
Listen for signal, once 10% of cashback requirement is met (send email)
Listen for signal, once 50% cashback is met (send email)
Listen for 100% cashback is met
// Perform credit (make call to external function)
将有一个将发送信号的外部服务。外部服务知道进度。例如,如果用户花费了高达 10% 的现金返还,那么我们会向 cadence 工作流程发送一个信号。
第一个问题:逻辑上是正确的。我没发现问题。
第二问:这个可以,但是需要注意如何给childWF发送取消信号。如果你让外部服务来做,它可能是一个一致的问题。如果让parentWF来做,需要确保父WF没有关闭。
总的来说,您的设计可行,但还可以改进。
您设计的主要问题是关于使用childWF。如果您不使用 childWF,您的工作流程将大大简化,从而节省大量边缘情况。从概念上讲,如果您的 parentWF 太复杂以至于您想分解,并且还可以从 childWF 获得结果,则 childWF 很有用。有关何时应使用 childWF 的更多详细信息,请参见此处:
如果不使用childWF,伪代码变成这样:
OfferWorkflow(input)
1. init offer state(local variable object), and you can register a [query][1] handler for this object.
2. In a loop, listen for signals for operation:
2.1 accept: check state, if not accepted, then accepted, and start a timer with a future operation:
2.1.1:
when the timer fires, check state, if accepted, then end workflow(accepted->end)
2.2 reject: check state, if not accepted, then end workflow(accepted->end), if accepted, you may ignore or end workflow
2.3 cancel: end workflow(accepted->end)
2.4 10% or 59%: check state, if accepted, then send email
2.5 100% : check state, if accepted then perform credit and then change state accepted->credited.
For error handling in above, eg, 100% for a unaccepted offer, you may emit logs/metrics for monitoring.
非常感谢您在实施细节方面的帮助,以及我在下面提出的 2 个澄清问题:
上下文:
正在创建优惠促销工作流程。报价有截止日期(我们在报价被接受后开始倒计时。)
用户可以选择拒绝报价(工作流程随后停止) 一旦报价被接受,他们将有 7 天的时间尝试兑换现金返还积分。一旦他们满足返现积分要求,我们会将积分记入他们的账户
第一个问题:下面的逻辑是否正确?我正在使用信号。
第二个问题:我正在听 'parentSignal' 频道上的父工作流中的信号。监听“接受”、“拒绝”、“取消”。 在子工作流程中,我正在监听“10%CASHBACK”、“50%CASHBACK”、“100%CASHBACK”以及“CANCELLED”,因为管理员可以随时取消 he/she。这是触发工作流程的正确方式吗?
我是如何考虑编写工作流程的(但是,当我尝试发出不同的信号时,我似乎无法让它在 Cadence GUI 中正常工作)
Parent workflow (OfferWorkflow)
Listen for signal (signal received from external service)
if accept, start execute Child Workflow (cashback workflow)
if reject, end workflow
if cancelled (by admin, end workflow, cancel any cashback progress)
child workflow (cashbackWorkflow, with expiration time)
Listen for signal, once 10% of cashback requirement is met (send email)
Listen for signal, once 50% cashback is met (send email)
Listen for 100% cashback is met
// Perform credit (make call to external function)
将有一个将发送信号的外部服务。外部服务知道进度。例如,如果用户花费了高达 10% 的现金返还,那么我们会向 cadence 工作流程发送一个信号。
第一个问题:逻辑上是正确的。我没发现问题。
第二问:这个可以,但是需要注意如何给childWF发送取消信号。如果你让外部服务来做,它可能是一个一致的问题。如果让parentWF来做,需要确保父WF没有关闭。
总的来说,您的设计可行,但还可以改进。
您设计的主要问题是关于使用childWF。如果您不使用 childWF,您的工作流程将大大简化,从而节省大量边缘情况。从概念上讲,如果您的 parentWF 太复杂以至于您想分解,并且还可以从 childWF 获得结果,则 childWF 很有用。有关何时应使用 childWF 的更多详细信息,请参见此处:
如果不使用childWF,伪代码变成这样:
OfferWorkflow(input)
1. init offer state(local variable object), and you can register a [query][1] handler for this object.
2. In a loop, listen for signals for operation:
2.1 accept: check state, if not accepted, then accepted, and start a timer with a future operation:
2.1.1:
when the timer fires, check state, if accepted, then end workflow(accepted->end)
2.2 reject: check state, if not accepted, then end workflow(accepted->end), if accepted, you may ignore or end workflow
2.3 cancel: end workflow(accepted->end)
2.4 10% or 59%: check state, if accepted, then send email
2.5 100% : check state, if accepted then perform credit and then change state accepted->credited.
For error handling in above, eg, 100% for a unaccepted offer, you may emit logs/metrics for monitoring.