is it planned to extend the receive task funcionality so that it's actually possible to receive data? now the task acts more like a wait state. adding a map to the signal arguments could be powerful regarding asynchronous behaviour.
yes, the map could be used to create or update the process variables. that would allow for a pragmatic asynchronous solution by combining service and receive task.
I am very interesting at your topic. Is it possible, that you contact me for a short talk about my ideas/needs. Sry i cannot post here my topic, because it is part of my master thesis and i will post it soon.
Sure, send me a mail (bernd.ruecker@camunda.com). I added some first docs for PSI last week, but didn't have much time yet to improve it. Currently we finish the Activiti Binding for PSI, which is not fully working. But we already have a couple of customer projects start using it 🙂
that sounds pretty interesting! at least for the big enterprise applications. for a small use case it might be a little overkill. isn´t there any native way of getting data into a running process? (besides the service task). as service tasks are not persisted, this is not an option for long running operations. for me, the receive task makes perfect sense for that. 🙂 but I´ll definitely have a closer look at psi!
Hi Thorsten. Yeah, the framework was created in a big enterprise environment. But the overhead is really small now, and we start using it in all projects and applications 🙂 Give me some time to extend the docs and write a quick tutorial, I hope than it doesn't look complex any more 🙂
Of course a plain receive task may be enough for you in your context. But then you definitely need to build some own infrastructure…
