标签: workflow-foundation-4

我负责一群即将开始开发轻量级保险索赔系统的开发人员.该系统涉及许多手动任务和业务工作流程,我们正在寻找使用Windows Workflow(.NET 4.0).

业务域的示例如下:保单持有人致电联络中心提出索赔.这个"事件"触发两个子任务,这两个子任务是并行手动操作的,可能需要很长时间才能完成;

1. 检查客户是否存在欺诈行为 - 操作员致电各信用公司以检查和评估欺诈客户的潜力的手动流程.从这里,子任务可以输入多个子状态(检查进度,参考检查失败,传递参考检查等)
2. 将物品发送到维修中心 - 手动过程中,保单持有人提出索赔的物品将被送到维修中心进行修理.从这里,子任务可以输入许多子状态(等待修复,进行中,修复,发布等).只有在每个子任务的状态达到预定义状态(基于业务规则)后,才能继续声明.

从表面上看,Workflow似乎确实是最好的技术选择; 但是我对使用WF 4.0有一些顾虑.

1. 技能组合 - 查看普通开发人员技能组合,我看不到很多了解或了解Workflow的开发人员.
2. 可维护性 - 社区内对WF 4.0项目的支持似乎很少,而且缺乏技能组合引起了对可维护性的担忧.
3. 进入障碍 - 我有一种感觉,Windows Workflow有一个陡峭的学习曲线,并不总是那么容易上手.
4. 新产品 - 由于Workflow已经完全重写为.NET 4.0,我将该产品视为第一代产品,可能没有必要的稳定性.
5. 声誉 - 以前版本的工作流程并不受欢迎,被认为难以开发并导致业务不佳.

所以我的问题是我们应该在这种情况下使用Windows Workflow(WF)4.0还是有替代技术(例如,简单状态机等)甚至是更好的工作流引擎？

我们正在评估Windows Workflow Foundation 4在基于MVC 3的Web应用程序中的使用.我们希望为不同的项目创建灵活的订单工作流程.
有没有人知道有关这种应用的一般架构或动手实验的良好信息？
一些具体问题是:

• 如何从工作流程激活特定的控制器/操作？
• 什么是工作流和Web应用程序(事件,wcf服务......)之间进行通信的最佳方式？

我一直在努力寻找一个引人注目的工作流用例(即:WF),而不是常规的命令式编程.每次我回到结论,我应该离开WF或推迟到晚些时候进入.但我一直有这种唠叨的感觉,有些东西不见了.

有谁知道任何真正为Workflow方式提供强有力理由的书？本书必须(i)很好地教授WF,以及(ii)使用适当的用例表明WF使实现变得容易,而不是我们只是进行常规的直接编码.

我会很感激的.

几乎所有Windows Workflow Foundation的教程/介绍似乎都针对4.0之前的版本,或者有些过于简单,并没有真正向我展示工作流程的真正优势.

有人能指点我一些稍微有点内容的教程(显然我的google-fu让我失望了),因为Workflow是我在VS中看过模板的东西之一,但从来没有时间或者没有时间一直玩到现在.

注意:请不要视频教程/介绍/指南.我发现他们无法学习.

我有一个问题,给定第三方WSDL,我可以从控制台应用程序轻松创建一个有效的服务代理,但从WF4 WF服务,我不是.在后一种情况下生成的代理显然是错误的,具体涉及2个问题:a)消息契约总是在未请求或需要时生成b)使用不正确的响应消息和xml包装器名称,导致空响应对象和反序列化失败

我面临的问题是在第三方WSDL的基础上实际生成Reference.cs类.在WSDL中有许多操作,按照出现的顺序,其中2个如下:

 <operation name="pu013">
      <documentation>
        <description>Check-response service</description>
        <help>The service handles (cut out)</help>
      </documentation>
      <input message="tns:pu013Request" />
      <output message="tns:SimpleResponse" />
 </operation>

...
 <operation name="mi102">
      <documentation>
        <description>Instruction insert to Matching System</description>
        <help>This service (cut out)</help>
      </documentation>
      <input message="tns:mi102Request" />
      <output message="tns:SimpleResponse" />
    </operation> 

Reference.cs中的结果是以下C#:

WorkflowService1.PSE.pu013Response pu013(WorkflowService1.PSE.pu013Request request);

...

WorkflowService1.PSE.pu013Response mi102(WorkflowService1.PSE.mi102Request request); 

请注意,由于某种原因,mi102操作是使用pu013Response的INCORRECT响应消息生成的,该消息声明为:

 [System.Diagnostics.DebuggerStepThroughAttribute()]
    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
    [System.ServiceModel.MessageContractAttribute(WrapperName="pu013Response", WrapperNamespace="http://pse/", IsWrapped=true)]
    public partial class pu013Response { 

请注意,WrapperName阻止XML序列化程序识别响应,即mi102Response,因此对于非pu013的所有操作,我总是得到NULL响应.

此外,如果我从控制台应用程序添加引用,则不会发生这种情况.这不会生成消息契约,在这种情况下,调用和响应工作.

有什么不同吗？svcutil是否在幕后调用？如果是这样,使用的参数有什么不同？是否可以使用svcutil来生成xamlx活动,以便我可以找到命令行解决方法？

这看起来像VS /添加服务引用错误.另一种方法是手动纠正Reference.cs中的许多操作.

理想情况下,我正在寻找一种方法来轻松,自动地运行svcutil或Add Service Reference,以便Reference类正确并生成xamlx活动.一个很好的解释是为什么存在差异,以及在幕后发生的事情.

更新:在控制台应用程序中生成的消息合同导致相同的问题 - 不正确的响应声明.如果使用参数而不是WF服务应用程序无法提供的消息,问题就会消失.

任何人都可以解释以下WorkflowApplication方法之间的区别:

中止取消终止

我需要在asp.net网页中显示文档审批工作流任务的当前状态,并突出显示特定活动.

我已经看过Visual工作流跟踪器示例(在wf和wcf示例中),但我有两个问题,

1. 我必须在asp.net中渲染工作流而不是在WPF应用程序中.

2. 我不需要显示工作流运行的当前状态,所有需要突出显示的活动都是需要用户输入的活动.例如"等待部门主管批准"等

如果我可以通过活动ID"创建书签并等待恢复书签"突出显示特定活动后将工作流XAML转换为JPG,那么它将完成工作.

检查附件中是否要在asp.net页面上呈现所需的工作流图像:

突出显示当前活动的工作流程(等待恢复)

我想通过一些特定的活动访问工作流程中的服务总线队列和主题.

我找不到适合这种情况的任何东西(这篇MSDN文章和Roman Kiss的这篇文章)是最接近的.

我想设计一个自定义活动,使用QueueClient异步接收代理消息,使用使用async/await模式实现的BeginReceive方法(请参阅我的问题).

首先,我想问一下,为什么我更喜欢建议的方法(改编的WCF)而不是我想要的方法(使用QueueClient).

然后,我将非常感谢以持久友好的方式设计它.

更新:

这是我到目前为止所尝试的:

public class AsyncReceiveBrokeredMessage : AsyncCodeActivity<BrokeredMessage>
{
    [RequiredArgument]
    public InArgument<string> ConnectionString { get; set; }

    [RequiredArgument]
    public InArgument<string> Path { get; set; }

    protected sealed override IAsyncResult BeginExecute(AsyncCodeActivityContext context, AsyncCallback callback, object state)
    {
        var connectionString = this.ConnectionString.Get(context);
        var path = this.Path.Get(context);
        var queueClient = QueueClient.CreateFromConnectionString(connectionString, path);
        var cts = new CancellationTokenSource();
        context.UserState = new ReceiveState
                                {
                                    CancellationTokenSource = cts,
                                    QueueClient = queueClient
                                };
        var task = …

我有一个问题 - BizTalk或WF？让我澄清一下,我意识到前三个工件背后的类似技术,并意识到我可以构建它们,但我没有发现它们是内置于WF,所以我试图理解为什么我会使用一个技术优于其他.

1. 转换
2. 绑定
3. 端口/适配器
4. BizTalk未来

转换

BizTalk本身支持的功能非常好,增强的设计人员可以启动,生成模式和地图的能力.此外,我喜欢所有内容都已转换的事实,因为我不必担心我的工作流程中的集成点,因为它始终采用一致的格式,这可以降低我的风险,因为我的集成变异 - 我只需要重构模式和映射.

相比之下,对于WF,我没有内置的豪华,所以我错过了什么或BizTalk在这里有+1？

绑定

绑定是BizTalk中另一个完全封装的功能.我可以将我的工作流设置为具有我想要的任何绑定,因为上述工件意味着在测试期间我可以绑定到文件系统并且在生产期间我可以绑定到服务.

相比之下,对于WF,我没有内置的豪华,所以我错过了什么或BizTalk在这里有+2？

端口/适配器

这很可能是BizTalk中存在的最大工件 - 恕我直言.将物理连接抽象为众多具体实现所需的工作量,特别是在一个非常庞大的组织中,其中一些具体的内容通过基本的文件系统而不是SOAP/REST,以及像IBM Mainframe和MSMQ这样的东西.BizTalk的物理端口适配器在向工作流发送消息之前通过转换自动运行原始数据,非常简单,优雅.

相比之下,对于WF,我没有内置的豪华,所以我错过了什么或BizTalk在这里有+3？

BizTalk未来

最后,我想提一下,根据我的研究,构建BizTalk的同一团队正在构建WF - 这太棒了!此外,微软的长期愿景是这个新的流行词"集成服务器",实际上是一大堆松散耦合的框架,提供了BizTalk今天的功能.由于Azure的努力,这项工作对我来说很有意义 - 我肯定会为此做出贡献.但是,我今天需要实现一个解决方案,这个解决方案将在15年后开始工作,但是如果我利用WF而不是BizTalk,我还需要了解我必须使用哪些部分来组合它.请告诉我你的经历.

我正在使用RX扩展和WF4来创建一个工作流程,该工作流程对可观察的消息作出反应以推进工作流程.为此,我引入了一个包含IObservable的对象(ModuleMessage是我的抽象类.)我遇到的问题是.Subscribe无法识别任何扩展方法,即lambda extpressions /方法组.在以下代码中,我有参考:

using System.Activities;
using System.Activities.Hosting;
using System.Collections.Generic;
using System.Reactive.Linq;

还有以下代码行:

    internal void AddModuleCallback(IModule module)
    {
        if (!addedCallback)
        {
            addedCallback = true;
            module.Messages.Where(m => m is MemberLeftModuleMessage || m is MemberRemovedModuleMessage).Subscribe(m => this.OnMemberExit(m)); // This line errors
        }
    }

    internal void OnMemberExit(ModuleMessage message)
    {
        // Gizmo was fired, resume the bookmark
        this.instance.BeginResumeBookmark(
            new Bookmark(ModuleVisit.BookmarkName),
            message is MemberLeftModuleMessage,
            r => this.instance.EndResumeBookmark(r),
            null);
    }

编译时错误:

Error   1   Cannot convert lambda expression to type 'System.IObserver<Components.Messages.ModuleMessage>' because it is not a delegate type …