我正在构建一个将在Azure上运行工作流的应用程序。
我已经看过构建演示文稿Building Applications with Workflow and Azure – BUILD 2011，它讨论了今天的功能，以及未来可能实现的目标。讨论的一件事就是所谓的“Azure工作流程服务”，据我所知，计划在2012年进行预览。但是，我还没有找到更多有关它的信息。
此外，还有一个早期的演示文稿Workflow in Windows Azure AppFabric，其中讨论了有关Azure中工作流的更多信息，重点介绍了Windows Azure AppFabric CTP。本演示文稿中讨论了许多很酷的功能，但我不确定这些功能现在是否可用，如果没有，可以使用。
所以有两个问题：
如果我今天需要构建应用程序，那么在Azure上实现工作流的建议方法是什么？
如果应用程序不需要在一年之后完成，那么在Azure上实现工作流的建议方法是什么？
答案 0 :(得分：3)
现在，在Windows Azure中托管工作流服务与在IIS上的Web应用程序中托管它没有太大的不同，而没有使用Windows Server AppFabric的好处。您可以使用SQL Azure作为实例存储。您将需要获得Microsoft .NET Framework 4 Platform Update 1，因为此更新将SQL脚本更改为与SQL Azure兼容。
见here。我在这个主题上做的另一篇文章是here，但请记住，脚本问题由Framework 4 Platform Update 1解决，并且还包括对所提到的瞬态连接条件的支持。
答案 1 :(得分：0)
我得到的官方建议是结合使用Azure Logic应用程序和Azure Function应用程序，让Logic App做业务流程和Function Apps提供工作流功能。
频道9上的这段视频详细介绍了它...
https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK3179
...我发现的问题是Logic Apps引擎是编排引擎并且不可扩展，因此为了完成该解决方案，我认为最终的解决方案将类似于用于调用功能的业务流程的Azure Logic App对于每个需要运行的工作流程。
我已经建立了自己的工作流引擎，并在没有MS指导的情况下托管在Azure函数中……他们的最佳建议是“与Premier Field Engineers计划签订一份50,000英镑/年的合同，让他们进来和你一起建立它。”
在我们的案例中，我们的流程/业务流程是由客户定义的，因此我们不仅可以对业务逻辑的运行方式进行硬编码（例如，通过在函数中编写固定的代码块），也不能对函数进行处理像工作流活动（在此处为WF）一样，您将遵循MS的最佳实践，但我们发现流程非常复杂，以这种方式执行流程的成本将使我们每次执行花费真金白银。
这就是我最终得出关于在函数内部运行整个流程的结论。 在您的情况下，您可以从函数执行WF流以实现与我们相同的解决方案。
所有这些下降的地方是，MS对功能的指导说，它们应该是一个短暂的REST调用，以完成一小部分工作（完全适合某项活动），因此无法确定嵌入时可能发生的情况此时，您可以从我所能告诉的人员那里获得整个流程执行，并且基本上是“自行完成”，除非您签订了每年50,000英镑的合同。
我的想法是...尝试一下，测试这些限制，并将这些限制放在您的代码中，以防止功能框架崩溃。
有鉴于此，我通过反馈社区提出了MS使功能可嵌入到逻辑应用程序中的功能，从而直接消除了开销以及实现单独的流引擎的需求。
https://feedback.azure.com/forums/34192--general-feedback/suggestions/36979045-workflow-solution
...如果获得批准，我们可以将业务流程设计为可调用流程的逻辑应用程序，这些流程将作为其他逻辑应用程序构建，以将完整的解决方案完全“开箱即用”地堆叠在MS基础架构上在逻辑应用无法执行某些操作时，幕后循环使所有这些内容变得合适。