我正在构建一个将在Azure上运行工作流的应用程序。
我已经看到了构建演示文稿Building Applications with Workflow and Azure – BUILD 2011，它讨论了今天的功能，以及未来的可能性。讨论的一件事是称为“Azure工作流服务”，据我所知，计划在2012年进行预览。但是，我还没有找到更多有关它的信息。
此外，还有一个早期的演示文稿Workflow in Windows Azure AppFabric，它讨论了有关Azure中工作流的更多信息，重点介绍了Windows Azure AppFabric CTP。本演示文稿中讨论了许多很酷的功能，但我不确定是否有任何功能现在可用，如果没有，何时可用。
所以有两个问题：
如果我今天需要构建应用程序，那么在Azure上实现工作流的建议方法是什么？
如果应用程序不需要在一年之后完成，那么在Azure上实现工作流的建议方法是什么？
我给出的官方建议是将Azure Logic应用程序和Azure功能应用程序相互结合使用，使用Logic App进行编排和功能应用程序提供您的工作流程功能。
关于channel9的这个视频详细讲述了它......
https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK3179
...我发现的问题是Logic Apps引擎是一个编排引擎而不是可扩展的，所以为了完成解决方案，我认为最终的解决方案就像是一个Azure Logic App，用于为每个工作流调用一个Function的业务流程需要运行。
我已经构建了我自己的工作流引擎，我在Azure功能中托管，没有MS的指导......他们最好的建议是“获得与Premier Field Engineers计划的50,000英镑/年合同，让他们进来和你一起建造它“。
在我们的例子中，我们的流程/业务流程由我们的客户定义，因此我们不能只是硬编码任何有关业务逻辑如何运行的代码（例如，通过在函数中编写固定的代码块）以及将函数视为工作流程活动（想想这里的WF）您将遵循MS最佳实践，但我们发现我们的流程足够复杂，以这种方式执行流程的成本将花费我们每次执行的真实资金。
这就是我最终得出关于在函数内运行整个流程的结论。在您的情况下，您可以从函数执行WF流以实现我们所拥有的相同解决方案。
所有这些都失败的地方是MS对功能的指导说它们应该是一个快速短暂的REST调用来做一小部分工作（完全适合一个活动），所以没有人知道当我们嵌入一个整个流程时会发生什么在这一点上执行你的支持，除了你每年拿下5万英镑的合同之外，我可以告诉他们基本上“靠你自己”。
我的想法是......尝试它，测试限制，将它们放在你的代码中以防止功能框架崩溃。
鉴于此，我通过反馈社区提出，MS将函数嵌入到逻辑应用程序中，直接消除了开销和我们实现单独的流引擎的需要。
https://feedback.azure.com/forums/34192--general-feedback/suggestions/36979045-workflow-solution
...如果获得批准，我们可以将业务流程设计为逻辑应用程序，这些应用程序可以调用流程，这些应用程序可以构建为其他逻辑应用程序，将完整的解决方案完全堆叠在MS基础架构上“开箱即用”，而无需我们在后台跳过当逻辑应用程序无法执行某些操作时，循环使所有这些东西都适合。