如何跟踪自定义 Windows Workflow Foundation 活动属性？
我想在我自己的跟踪服务中跟踪我的自定义活动的属性值，即我不需要在内置的 SQL 跟踪服务中使用它。我已经成功地重现了 SQL 跟踪服务，因为我可以看到工作流和活动状态等，但我还想查看属性值。
我们正在为文档管理系统 (DMS) 编写许多工作流程，该系统使用其自己的基于 MS WF 的工作流程引擎。因此，我无法更改工作流程运行时（如果需要）。该解决方案必须与底层 Microsoft 工作流运行时的嵌入式功能配合使用。
我们的工作流程通常通过我们编写的自定义活动进行数据库查找。然后，这些查找值会传递到其他活动以进行程序流或持久保存到 DMS 中。如果我们能够在运行时看到这些查找值是什么以及实际上 DMS 自己的活动属性的值，那就太好了。
I want to track my custom activities' property values in my own tracking service, .i.e. I don't need it in the built in SQL tracking service. I have been successful in reproducing the SQL tracking service in that I can see the worklfow and activity states etc. but I want to see property values also.
We are writing many workflows for a document management system (DMS) using its own workflow engine that is based on MS WF. I can therefore not change the workflow runtime (if it was needed). The solution has to work with the embedded functionality of the underlying Microsoft workflow runtime.
Our workflows typically do database lookups through custom activities we write. These lookup values are then passed on to other activities for program flow or for persistence into the DMS. It would be great if we can see what these lookup values are at runtime and in fact the values of the DMS own activities' properties.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据我对 MS 工作流程的了解（诚然有限），正确的方法是从工作流程内发布对跟踪服务的更新 - 即，如果您的工作流程执行了某些步骤，它应该转到跟踪服务并说“我做了 X ”。您的跟踪服务可以记录此信息，以回答有关工作流程执行的操作（以及当时的各种属性值是什么）的任何后续查询。
要点是 WF 引擎对于运行工作流非常有用，但不太擅长报告这些工作流的进度。
如果您确实对 WF 引擎有一定的控制权（您说它“基于 MS WF”），那么一种选择可能是让您的 WF 引擎为所有工作流程发布此类更新。这可能允许您放弃实际工作流程定义中的显式更新。但是，如果您确实无法对引擎进行任何更改，那么这将不起作用。
From my (admittedly limited) knowledge of MS's Workflow, the correct approach is to publish updates to your tracking service from within the workflow -- ie, if your workflow does some step, it should go to the tracking service and say "I did X". Your tracking service can record this information to answer any subsequent queries about what the workflow did (and what the various property values were at the time).
The essential point is that the WF engine is useful for running workflows - but is not very good at reporting on the progress of those workflows.
If you do have some control over the WF engine (you say its "based on MS WF") then one option may be to make your WF Engine publish such updates for all workflows. That may allow you to forgo explicit updates within your actual workflow definitions. However, if you really can't make any changes to the engine, then this won't work.