Hey guys.
Thanks for the quick feedback!
I think that a performance gain which will be leveraged by probably 5% of our users (or less) should not result in the other 95% of the users suffer from avoidable complexity when designing their workflows (which also increases learning curve, questions in the forum, support cases, consulting effort, …). Personally I would prefer to have that default of merging everything, but a checkbox to suppress it. In the docs we can make a clear statement that if you want to optimize for performance you should do the data flow like Thorben just described. This way we make it possible but the 5% of the performance users have to learn about it, all others can simply ignore this. Maybe that can be highlighted boldly in the docs - probably also in other places as I can imagine there are some more design decisions which differ for “normal folks” and high performance scenarios.
then it adds the complete task payload to the workflow payload under the key “result”.
I saw this, but it actually would mean that my resulting map gets cluttered a lot as for every attribute it gets nested into some other attribute (result1.pickId, result2.shipmentId, …).
For me the underlying question (which is also raised in https://forum.zeebe.io/t/output-mapping-on-start-event/119/2) boils down to usage patterns. Take e.g. the architecture alternatives in https://github.com/flowing/flowing-retail/tree/zeebe/zeebe (just started with that example, readme is still a todo). You could use Zeebe as work distribution (as it is currently advocated on the zeebe.io homepage) or you can use it as workflow engine within one service (as a typical microservice architecture would do). How you approach data flow and mappings is very different in this scenarios. In the “Zeebe as work distribution” scenario the services must not know any details of the workflow definition but act like they would send and receive messages. And here it gets more tricky.
Probably worth a F2F discussion? And with F2F I of course mean Skype or Goto or the like
Next week would work perfectly for me. Anybody interessted?
Cheers
Bernd