Cadence workflow 工作流结构、促销活动流程

非常感谢您在实施细节方面的帮助，以及我下面提出的两个澄清问题：

背景：

创建促销工作流。报价有一个截止日期（我们在报价被接受后开始倒计时。）

用户可以选择拒绝报价（然后工作流停止） 一旦接受优惠，他们将有7天时间尝试兑换现金返还积分。一旦他们满足现金返还积分要求，我们将把积分记入他们的账户

第一个问题：下面的逻辑正确吗？我在使用信号

第二个问题：，我正在收听“家长信号”频道上的家长工作流程中的信号。收听“已接受”、“已拒绝”、“已取消”。 在子工作流中，我正在收听“10%现金返还”、“50%现金返还”、“100%现金返还”以及“取消”，因为管理员可以随时取消。这是触发工作流的正确方法吗

我是如何考虑编写工作流的（然而，当我试图发出不同的信号时，我似乎无法使它在Cadence GUI中正常工作）

---

将有一个发送信号的外部服务。外部服务了解进度。例如，如果一个用户花费了高达10%的现金返还，那么我们会向cadence工作流发送一个信号。

1st Q：从逻辑上讲，这是正确的。我看没问题

第二个问题：这可以工作，但是，您需要注意如何向childWF发送取消信号。如果您让外部服务来做，这可能是一个一致的问题。如果让parentWF执行此操作，则需要确保parentWF未关闭

总的来说，您的设计是可行的，但可以改进

设计的主要问题是关于使用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.

---

您可以删除

cadence

标记吗？我想这是另一个话题，我明白了，是的，我会的。谢谢你的详细回复！

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.