We are currently trying to implement workflow functionality in our product (.NET 4.5). To do this, consider using Microsoft Workflow Foundation 4.5. However, at this early stage, we were faced with the technical problem of something that seemed very doable.
Simply put, this is what we want to achieve in our client / server setup:
- Based on a specific event, the server starts a workflow.
- The workflow performs some actions until it reaches an activity that requires interaction with a person. Then he must wait for a message from the client.
- One client (there are several clients) becomes the owner and therefore must send its unique identifier or address to the workflow.
- The workflow sends a message to this client indicating that it requires information to continue (for example, email settings such as recipient, subject, and body).
- After a few minutes (from several minutes to several hours), the client sends information to the workflow so that it can continue (for example, send an e-mail message).
- If another interaction with a person is required, the server again sends a request to the client, so that it knows that it should request information from the user, and then the client will again send a message to the workflow (for example, above).
For what I understand, a βnormalβ workflow does not have an endpoint for receiving messages. On the other hand, a workflow service, but with WF services, workflow instances will be created based on incoming requests, and not control the workflow creation server (right?).
At this point, it seems to me that we need a combination of workflow and workflow service.
I struggled with this for a while and searched high and low, but cannot find useful information about it.
I think we have two options:
workflow services; If we use workflow services, we could get a receive operation at the beginning of the workflow that starts the workflow. However, how can customers communicate with this particular workflow? The workflow service has one specific URL.
Work processes; The usual workflow hosted by the server application seems to be the most natural way of choosing. However, then we need a way to send data to it. So, is it possible to update the normal workflow so that the receive operation can be used? And if so, how? And how do messages end up in the right instance of a workflow?
My questions: Does anyone have a helpful guide or information on how to solve the above problem? Are there any interesting alternatives (without using WF?) To achieve this? Does anyone have documentation on how WCF messages are routed to the correct workflow instance in WF?
PS: We have a WCF service available on the client. Workflow can exchange data. For short launch requests, this is not a problem, but the fact is that the requests can take a long time before the client "answers" them. In addition, the client can request information only if the user clicks the Continue button (users should not receive a popup only in the middle of something because the server wants to receive information)
source share