Our current in-house workflow solution allows us to cancel/pause/resume workflows in addition to manually step forward and backward for debugging like tasks.

For example if a workflow is running we can pause and view the state of all variables, modify variables (for this specific workflow run), move forwards and backward a single step. If it's stuck on an external process/service we can cancel that and try again, or modify inputs before re-running that specific step. This allows us to manually walk workflows through in the chance something isn't behaving as expected. This behavior is meant to emulate the debugging experience in visual studio and similar IDEs. This is an important feature that would likely be required if we eventually adopt Warewolf to orchestrate our workflows. A lot of our workflows rely on external inputs that we can't control completely. No matter how much validation and error handling we put in some computationally intensive tasks will have issues in the middle of a workflow that we wouldn't want to have the restart from the beginning.

Thanks

Genie,

I didn't see any documentation on the POST but after playing around with sending JSON objects via post and adding it as an "input object" it works as expected. Thank you!

One last question. How can I manage workflows that are running? If I'm logging information I can see what is running but don't see any options in the designer to view running workflows. If a process hangs (for example stuck in loop etc) how would I go about killing that workflow?

This is somewhat separate from AMQP alone but I think it's important that workflows can be triggered in methods other than an HTTP get. Few examples:

1. HTTP post: this would require workflows accepting objects as input (JSON as post body), but I think it's important to be able to send structured data to microservices.

2. Message queues / events: AMQP or even by just HTTP . Workflows need to be able to subscribe to queues and listen to events for triggering. This is a requirement for properly scaling microservices. This is so fundamental it would make sense for every microservices called from within a workflow to go through a message queue by default. This way workflows can scale by simply spooling up another werewolf instance with the particular microservice on it listening to the applicable queue.

Hi Gandolf,

V1 has just been released. Any updates on schedule for AMQP support? Still planned?