I want to use Publish Event to launch a new workflow. I want the new workflow to communicate back to the original task with its Publish Event. The first workflow will use Receive to catch this new event.

My question is this. For both Publish Event and Receive I need to set a Criterion. It's unclear what to use, so I chose "User." It works fine and I am able to pass data between the two tasks through the two Events. However, I want to know if this is the right choice. If so, why?

Thanks.

Andrew,

'User' is the good choice. The subscription and publication of the events flowing between your new workflow and Receive task is based on the User id mapped in the event.

You say that it is working... but I am concerned a bit about your flow here. You have Workflow-A that publishes an Event-A using the Publish Event task. There is a workflow with this Event-A in Start and it gets kicked off. Let us call it Workflow-B. Now, you have another Publish Event task in Workflow-B. What event does it publish? I am assuming you have a Receive Task after the Publish Task in Workflow-A that will wait for the Publish Event to send the event in question. If it is again Event-A, then you will have an endless loop of Workflow-A and Workflow-B. If it is not happening for you, then my understanding may be wrong. Just a precaution though. If Workflow-B publishes the same Event-A, you will have another instance of Workflow-B kicked off.

Just checking...

Thank you.

Workflow 1 publishes Event A. It then waits on a Receive for Event B.

Workflow 2 has Event A as its Start criteria. It publishes Event B.

Ok... that clears it. So when you publish Event B to get back to Workflow 1, you may want to use a different criterion there: Instance. Because, User may work for one call - because you have only one workflow going for your testing, but when you have a series of calls, you will need to identify which instance of the Workflow1 you want to get back to.

Joel and I had a phone conversation just now, so he may post a reply as well. As always, you can reach out for a live discussion if you like.

Thank you. I probably need more. The help for Publish tells me very little and while Receive says more, it's not very clear. For Instance it says:

Instance – The task receives the event based on the Workflow Instance (WFI) id. To use this Criterion, you must set the Workflow Instance (WFI) id as the correlation id on the event.

However, I don't know what this WFI is and where I would find it.

Hi Andrew, here's a bit more info on how to robustly handle this on a large scale.

First, a bit of information on what this Criterion stuff means. The Breeze Eventing Framework cannot filter on event bodies. This is because we wanted to allow for free-form event bodies, not even mandating XML at the EF level. The EF can only filter on event metadata. The trick here is to get the correct event metadata populated on the publisher side, and get the right filter ctieria specified on the subscribing side. That's what this "Criterion" business is about. It's telling the Publish Task event what to populate as event metadata, and telling the Receive task what to populate as filter criteria in the subscription.

There is no need to do any sort of correlation / filtering on Event A, because you want to kick off a new "Workflow 2" every time that event is published. The trickier bit is in making sure that Event B makes its way back to the correct instance of Workflow 1. The most reliable way to do this is to use Instance ID to correlate. There are some subtelties here. Here's what I think you'll need to do:

1) Add an "instanceId" element to the JSON schema for Event A.
2) In the input mapping for the Publish Event task in Workflow 1, map the System.instanceId variable to your instanceId element.
- There is no need to select a Criterion here.
3) On the Receive Event in Workflow 1. select Instance as your Criterion
4) Here's where things get a bit tricky. In the Publish Event from Workflow 2, you can't use Instance as your criterion, because that will cause ED to populate the Intance ID of Workflow 2. We want Workflow 1's Instance ID (sent in Event A message body). Instead, use a Criterion of CorrelationKey. This lets you populate a free-form string that will be populated as the key for the event metadata. In this case, use a correlation key of "Instance". Since you are using the CorrelationKey mechanism, you will now be free to populate whatever data you want as the value for "Instance". So...
5) On the Input Mapping form for Publish Event, you SHOULD now see "Instance" as something you can map a value to. However, I don't see that in my lab. We may need to get Prakash or somebody else from the ED team to help if you see the same thing.

Does that all make sense?

Thanks, Joel.

It mostly makes sense until the end where I can't see how to populate the CorrelationKey in Workflow 2, either. I am assuming that I would populate it with the instanceId that was passed to Workflow 2 in Event A. Is that correct?

I don't see is how the Receive in Workflow 1 knows when to fire. Should I set a Correlation Key value in Receive? If so, should it be set to the same value I pass in Event A (System.instanceId)? It appears that I can map it using the Filter object of Receive.

Hi Andrew. I hope you had a good weekend.

It looks like something might be broken in the current version of Engagement Designer with the Correlation Key mechanism on the Publish Event task. The specified key is supposed to be visible on the input mapping screen, but it is not. The Engagement Designer team is looking into this. We'll be back with you as soon as we can.

For what it's worth, I can't set it in either 3.2 or 3.3.

Yes, that's not surprising. I submitted a bug report. Core members of the team are aware of the issue and know that you are impacted by it. Hopefully we'll have a fix or a workaround for you soon.