Support for AMQP.

Hi Gandolf,

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

Hi Playsted,

We have tools for Publishing and Consuming of messages on RabbitMQ which uses AMQP. What type of AMQP support are you looking for?

Thanks

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.

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?

Hi Playsted,

We will double check the documentation and make sure we add something in for POST if there isn't anything or make it easier to find.

This is something we also have planned, as we are looking to add a kind of "Management" screen to the studio to enable management of other server settings as well as what you have mentioned seeing what workflows are running, how long they have been running for, what tool\step they are currently at etc.

What information and functions would be important to you on a screen like this?

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

Thanks for the info Playsted. Really appreciate your insights. We actually had these sort's of features on the cards, including a simulation mode for manual testing and some idea's for automated testing, so it is good to hear these kinds of features are required. We will definitely look at these features, when prioritizing our backlog.

Thanks again, appreciate the feedback.