Question about the queue-ing mechanism and event handling about workflow-core HOT 12 CLOSED

By "dynamic data" do you mean any .NET object? What is your use case for this?
By letting to publish process discover the subscribers, it is more conservative in terms of resources, since the subscribers can go to sleep rather than continually polling and checking. Do you think there would be a specific advantage to polling?

from workflow-core.

Our solution would need to have the user upload a picture, then this picture would go through several states until it becomes available to download.
I tried to model using your framework, and I found that when I am declaring a step where it is waiting for an event, I would need some sort of mechanism that does for example WaitFor("PictureReadyEvent", "UniquePictureId"), now this picture Id would be the dynamic data. Dynamic as in it would be a parameter, and I find it impossible to make it a parameter as it is now, it may be that I am missing something though. Besides this I would use the PublishEvent("PictureReadyEvent",uniquePictureId) to emit it.
The other issue I was having is also related to this, if I have a workflow with 3 steps/states, each step involves waiting for an event, if I emit the events fast enough sequentially, there would be 3 events, first step1 => step2 would be okay, since it is subscribed to wait for it, but if step2 => step3 follows quickly, the workflow is not yet subscribed to this event, and this event would be wasted and the same for step3 =. finish. If the event would enter a queue, and stood there until someone consumes it, this would be solved I think.

from workflow-core.

For your first issue, would it make sense to use a compound key in string format, eg. "PictureReadyEvent:101"?
For your second issue, I could possibly look at making it possible to specify if a subscribed step should look at past events... let me think about this one - I will get back to you.

from workflow-core.

Yes, a compound key would also do the trick, but the parameter in this case, has to be declared at compile time, when the workflow is being constructed, there is no way I can pass in a parameter at runtime as EventKey, or is it?

from workflow-core.

Ok, sorry I missed that... I think I need to change the .WaitFor method to take a lambda expression instead of a static value for the event key. I've just published a new version with this functionality, let me know if this helps.

from workflow-core.

Yes, that solved it, thank you!
I am curious about your findings regarding the event handling.

from workflow-core.

Hi, unfortunately I have not had a chance to apply myself properly to this yet, I should hopefully get some time to work on it this weekend, but I definitely will look into it

from workflow-core.

Hi, I have added functionality to define an effective date for both events and subscribing steps, which should make it possible to also respond to historic events and post date future events.
I'm currently about 90% done, you can view the changes so far in the "finalize-v1" branch.

I hope to release this branch and deploy a new version to nuget.org in the next week or so.

• I'm also in the process of moving to VS 2017, which means you will need VS 2017 to build the source in the branch at the moment.

from workflow-core.

@Radigeco new version is out... documentation to follow

from workflow-core.

Wow, nice!
I will have a look at it tomorrow!

from workflow-core.

Hi,
Sorry for my huge delay, I've done some testing for the use cases that I am interested in, and they seem to be working just fine now. I've tested with having 500 instances of one workflow, each workflow containing multiple steps, all step transitions via events and I mixed the order in which the events are published, so they are not consecutive as they should be and it worked fine. I've used SQL Server as persistence provider and RabbitMQ as queue provider. I will do some more testing in the coming days and keep you posted.
Thank you for your fine work!

from workflow-core.

If you are only running 1 node, then you can use the built-in memory queues. If you want to run multiple nodes, you will need an external queue provider (such as RabbitMQ) and a distributed lock provider (the only one right now is the redis Redlock provider)

from workflow-core.