You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+8-6
Original file line number
Diff line number
Diff line change
@@ -88,7 +88,7 @@ this way when handler finishes, 3 consequtive parallel tasks will be scheduled t
88
88
<br/>the string specified after name of each task will be passed as first `data` argument in their handler.
89
89
<br>you can return different tasks to publish in different cases, but if the handler is requeued after the `PublishNext` result was already stored internally, the new result will be ignored for sake of consistency, since some calls could have already been published before the requeue.
90
90
91
-
let's see now how can we join parallel processes by introducing events.
91
+
let's see now how we can join parallel processes by introducing events.
92
92
<br/>by defining event triggered task (returned as 2nd parameter) that will run once all 3 events `event_1`, `event_2` and `event_3` are emitted, more preciselly the task will run exactly once when the last of them is emitted:
once the joining task is run, it will receive string value (under `data`) specified right after task name in `PublishOnEvents`,
120
+
once the joining task runs, it will receive string value (under `data`) specified right after task name in `PublishOnEvents`,
121
121
and array of events (in our case of length 3) as second argument, each containing name of event and data passed right after that event name in `EmitEvents`:
in order to run task triggered by events, make sure that the last of the events is emitted in one of the subsequent tasks, it doesnt have to be in the tasks called directly after, but can also be emitted many subsequent tasks later.
128
+
in order to run task triggered by events, make sure that the last of the events is emitted in one of the subsequent tasks, it doesnt have to be directly after, but can also be emitted many steps later.
129
129
130
130
note on events: tasks are only tiggered by events emitted by task calls that can be traced back to same publish handler call as the task call that defined `PublishOnEvents`, meaning emitting event by calling another `wfInstance.Publish` won't trigger task in current one, this is because it would be hard to scale tasks globally between all workflow sessions, for this reason names of events can be static, next `wfInstance.Publish` will ignore all events called in previous publish handler calls.
131
-
<br/>Events do transcend microservice queues though, if you define a trigger and then call task from different microservice that emits triggering event few steps later, it will still trigger the task.
131
+
<br/>Events do transcend microservice queues though, if you define a trigger and then call task of different microservice that emits triggering event few steps later, it will still trigger the task.
132
132
133
133
in order to call task of other microservice that listens to different queue, provide its queue name before the dot as prefix:
0 commit comments