工作流系统 [英] Workflow system
问题描述
我刚刚开始在一个新的通信公司，我们正在寻找一个工作流/内联网系统来管理作业和流程。
I've just started at a new communications company, and we're looking at a workflow / intranet system to manage jobs and processes.
基本上，我们从客户，我们再通过我们的系统处理接收的数据文件。
Basically, we receive data files from clients which we then process through our systems.
- 接收数据文件（FTP，电子邮件等）
- 处理数据文件（无论是通用的数据映射到文件，或定制ETL程序包脚本）。添加地址值
- 创建的PrintStream（发送处理过的数据文件为PostScript / PDF合成引擎），或者创建电子邮件输出
- 发送输出到生产车间（复制到打印机输入流，邮件机）
- 过程中的其他流（例如发送电子邮件/传真，上传到电子归档）
- 更新内部系统（如仓库库存，开票）
我们也有很多其他的内部业务流程（如后处理损坏的输出，处理死/返回邮件）。
We also have a lot of other internal business processes (e.g. reprocessing damaged output, processing dead/returned mail).
我试图保持分开的所有元素。有些人会是现成的（例如printstream参数组成，电子邮件发送/管理，CRM）。有些将建在内部（例如重新处理损坏的输出）。
I'm trying to keep all elements separated. Some will be off the shelf (e.g. printstream composition, email sending / management, CRM). Some will be built in house (e.g. reprocess damaged output).
不过，我正在寻找的东西绑到一起，并把业务工作流程英寸例如调度作业，按顺序拉开了数据处理任务和管理错误。很多这将对人类的步骤。此外，摆在SLA管理和业务活动监控/报告。
But, I'm looking for something to tie it all together, and put the business workflow processes in. E.g. scheduling jobs, kicking off data processing tasks in sequence and managing errors. A lot of this will have human steps. Also, put in SLA management and business activity monitoring / reporting.
一个关键要求是尽快自动化文件接收和处理（即目录看和匹配客户端/应用程序）。
One key requirement soon is for automated file receipt and processing (i.e. directory watching and matching to client / application).
我渴望的东西，很容易管理和维护（例如，在新的步骤添加到工作流，或有条件的逻辑，或其他）。
I'm keen for something that's easy to manage and maintain (e.g. adding in new steps to a workflow, or conditional logic, or whatever).
我意识到这是一项艰巨的任务，而且目前我们关注每个组件上，并把人工流程的地方，直到我们得到了一个系统来管理它。我们不希望设计一个庞大的定制系统，以配合在这一切，但宁愿看购买某种工作流或集成系统。
I realise this is a big job, and at the moment we're focusing on each individual component and putting manual processes in place until we get a system to manage it. We don't want to design a gargantuan bespoke system to tie it all in, but would rather look at buying some kind of workflow or integration system.
有什么建议？我有一个看看Biztalk的，但不知道这是否是矫枉过正，或不适合仅供内部使用的系统。另一种产品我一直在接触到是赛金自动化，但它看起来有点狱。
Any suggestions? I've had a look at Biztalk, but not sure if it's overkill or not suited for internal-only systems. Another product I've been exposed to is Sagent Automation, but it looks a little pokey.
- 编辑 -
忘了提，我们现有的技能主要是微软。因此，在微软技术的东西/基于.NET的将是preferable。但是，如果有一个很棒的产品，我们并不反对提高技能
Forgot to mention, our existing skillset is largely Microsoft. So anything in Microsoft technologies / .Net based would be preferable. But if there's a fantastic product, we're not adverse to upskilling
推荐答案
看看Apache的主动MQ 。它实现了Java消息服务1.1规范，层层上一个servlet API，并有大量的特性应该满足您的要求。您也可以在层骆驼，增加了丰富的实施许多的企业集成模式的。
Check out Apache's Active MQ. It implements the Java Message Service 1.1 specification, layers on a servlet API, and has tons of features that should address your requirements. You can also layer on Camel, which adds a rich implementation of many enterprise integration patterns.
通常情况下，JMS消息在事务数据库，可配置给你非常高的程度的容错能力的持续（如RAID，主数据库备份机双，事务日志文件的多个副本）。在数据库的顶部可以去多，负载均衡应用服务器的机器运行Active MQ，给你的可扩展性和高可用性。我想你会发现，如果你使用Active MQ作为您共同消息总线，你可以写你的组件在一个非常时尚的解耦
Typically, JMS messages are persisted in a transactional database, which can be configured to give you extremely high degrees of fault tolerance (eg, RAID, master-backup database machine pairs, multiple copies of transaction log files). On top of the database can go multiple, load-balanced app server machines running Active MQ, to give you scalability and high-availability. I think you'll find that you can write your components in a very decoupled fashion if you use Active MQ as your common message bus.
在JMS，当消息被消费者去排队，消费过程中必须后来确认该邮件已成功处理。如果确认没有及时进来，JMS系统将恢复该消息，以另一种耗时的过程可以尝试来处理它。这意味着，你可以运行你的应用程序来获得可靠性和容错性的多个副本。
In JMS, when a message is de-queued by a consumer, the consuming process must later confirm that the message was successfully handled. If a confirmation does not come in in time, the JMS system will revive the message so another consuming process can attempt to handle it. This means you can run multiple copies of your application to gain reliability and fault tolerance.
看看O'Reilly的 Java消息服务，第2版，刚刚出来的这一周
Take a look at O'Reilly's Java Message Service, 2nd Edition, which just came out this week.
一个不同的途径是寻找到 BPEL （业务流程执行Languge）。
A different avenue would be to look into BPEL (Business Process Execution Languge).
编辑：我不是很熟悉微软的产品，但是的 MSMQ 好像等同于JMS。
I'm not very familiar with Microsoft offerings, but MSMQ seems like the equivalent to JMS.
您应的能够在微软环境中使用ActiveMQ的。他们声称支持跨语言的客户端喜欢C＃和.NET。即使这应该是有问题的，因为ActiveMQ的具有用于排队和去排队消息的基于Java servlet的API时，外界仅必须能够使HTTP请求到ActiveMQ的服务器。这应该限制学习你的团队必须做的量。祝你好运，这听起来像一个真棒项目！
You should be able to use ActiveMQ in a Microsoft environment. They claim to support "cross language clients" like "C# and .NET". And even if that should be problematic, since ActiveMQ has a Java servlet-based API for queueing and de-queuing messages, the outside world only has to be able to make HTTP requests to the ActiveMQ server. That should limit the amount of learning your team would have to do. Good luck, this sounds like an awesome project!
这篇关于工作流系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
