分布式流处理是对无边界数据集进行连续不断的处理、聚合和分析。它跟MapReduce一样是一种通用计算，但我们期望延迟在毫秒或者秒级别。这类系统一般采用有向无环图（DAG）。
DAG是任务链的图形化表示，我们用它来描述流处理作业的拓扑。如下图，数据从sources流经处理任务链到sinks。单机可以运行DAG，但本篇文章主要聚焦在多台机器上运行DAG的情况。
关注点
当选择不同的流处理系统时，有以下几点需要注意的：
?运行时和编程模型：平台框架提供的编程模型决定了许多特色功能，编程模型要足够处理各种应用场景。这是一个相当重要的点，后续会继续。
?函数式原语：流处理平台应该能提供丰富的功能函数，比如，map或者filter这类易扩展、处理单条信息的函数；处理多条信息的函数aggregation；跨数据流、不易扩展的操作join。
?状态管理：大部分应用都需要保持状态处理的逻辑。流处理平台应该提供存储、访问和更新状态信息。
?消息传输保障：消息传输保障一般有三种：at most once，at least once和exactly once。At most once的消息传输机制是每条消息传输零次或者一次，即消息可能会丢失；A t least once意味着每条消息会进行多次传输尝试，至少一次成功，即消息传输可能重复但不会丢失；Exactly once的消息传输机制是每条消息有且只有一次，即消息传输既不会丢失也不会重复。
?容错：流处理框架中的失败会发生在各个层次，比如，网络部分，磁盘崩溃或者节点宕机等。流处理框架应该具备从所有这种失败中恢复，并从上一个成功的状态
（无脏数据）重新消费。
?性能：延迟时间（Latency），吞吐量（Throughput）和扩展性（Scalability）是流处理应用中极其重要的指标。
平台的成熟度和接受度：成熟的流处理框架可以提供潜在的支持，可用的库，甚至开发问答帮助。选择正确的平台会在这方面提供很大的帮助。
运行时和编程模型
运行时和编程模型是一个系统最重要的特质，因为它们定义了表达方式、可能的操作和将来的局限性。因此，运行时和编程模型决定了系统的能力和适用场景。
实现流处理系统有两种完全不同的方式：一种是称作原生流处理，意味着所有输入的记录一旦到达即会一个接着一个进行处理。
第二种称为微批处理。把输入的数据按照某种预先定义的时间间隔（典型的是几秒钟）分成短小的批量数据，流经流处理系统。
两种方法都有其先天的优势和不足。首先以原生流处理开始，原生流处理的优势在于它的表达方式。数据一旦到达立即处理，这些系统的延迟性远比其它微批处理要好。除了延迟性外，原生流处理的状态操作也容易实现，后续将详细讲解。一般原生流处理系统为了达到低延迟和容错性会花费比较大的成本，因为它需要考虑每条记录。原生流处理的负载均衡也是个问题。比如，我们处理的数据按key分区，如果分区的某个key是资源密集型，那这个分区很容易成为作业的瓶颈。
接下来看下微批处理。将流式计算分解成一系列短小的批处理作业，也不可避免的减弱系统的表达力。像状态管理或者join等操作的实现会变的困难，因为微批处理系统必须操作整个批量数据。并且，batch interval会连接两个不易连接的事情：基础属性和业务逻辑。相反地，微批处理系统的容错性和负载均衡实现起来非常简单，因为微批处理系统仅发送每批数据到一个worker节点上，如果一些数据出错那就使用其它副本。微批处理系统很容易建立在原生流处理系统之上。
编程模型一般分为组合式和声明式。组合式编程提供基本的构建模块，它们必须紧密结合来创建拓扑。新的组件经常以接口的方式完成。相对应地，声明式API操作是定义的高阶函数。它允许我们用抽象类型和方法来写函数代码，并且系统创建拓扑和优化拓扑。声明式API经常也提供更多高级的操作（比如，窗口函数或者状态管理）。后面很快会给出样例代码。
主流流处理系统
有一系列各种实现的流处理框架，不能一一列举，这里仅选出主流的流处理解决方案，并且支持Scala API。因此，我们将详细介绍Apache Storm，Trident，Spark Streaming，Samza和Apache Flink。前面选择讲述的虽然都是流处理系统，但它们实现的方法包含了各种不同的挑战。这里暂时不讲商业的系统，比如Google MillWheel或者Amazon Kinesis，也不会涉及很少使用的Intel GearPump或者Apache Apex。
Apache Storm最开始是由Nathan Marz和他的团队于2010年在数据分析公司BackType 开发的，后来BackType公司被Twitter收购，接着Twitter开源Storm并在2014年成为Apache顶级项目。毋庸置疑，Storm成为大规模流数据处理的先锋，并逐渐成为工业标准。Storm是原生的流处理系统，提供low-level的API。Storm使用Thrift来定义topology和支持多语言协议，使得我们可以使用大部分编程语言开发，Scala自然包括在内。
Trident是对Storm的一个更高层次的抽象，Trident最大的特点以batch的形式进行流处理。Trident简化topology构建过程，增加了窗口操作、聚合操作或者状态管理等高级操作，这些在Storm中并不支持。相对应于Storm的At most once流传输机制，Trident提供了Exactly once传输机制。Trident支持Java，Clojure和Scala。
当前Spark是非常受欢迎的批处理框架，包含Spark SQL，MLlib和Spark Streaming。Spark的运行时是建立在批处理之上，因此后续加入的Spark Streaming也依赖于批处理，实现了微批处理。接收器把输入数据流分成短小批处理，并以类似Spark作业的方式处理微批处理。Spark Streaming提供高级声明式API（支持Scala，Java和Python）。
Samza最开始是专为LinkedIn公司开发的流处理解决方案，并和LinkedIn的Kafka一起贡献给社区，现已成为基础设施的关键部分。Samza的构建严重依赖于基于log的Kafka，两者紧密耦合。Samza提供组合式API，当然也支持Scala。
最后来介绍Apache Flink。Flink是个相当早的项目，开始于2008年，但只在最近才得到注意。Flink是原生的流处理系统，提供high level的API。Flink也提供API来像Spark一样进行批处理，但两者处理的基础是完全不同的。Flink把批处理当作流处理中的一种特殊情况。在Flink中，所有的数据都看作流，是一种很好的抽象，因为这更接近于现实世界。
快速的介绍流处理系统之后，让我们以下面的表格来更好清晰的展示它们之间的不同：
Word Count
Wordcount之于流处理框架学习，就好比hello world之于编程语言学习。它能很好的展示各流处理框架的不同之处，让我们从Storm开始看看如何实现Wordcount：
TopologyBuilder builder = new TopologyBuilder();
builder.setSpout("spout", new RandomSentenceSpout(), 5);
builder.setBolt("split", new Split(), 8).shuffleGrouping("spout");
builder.setBolt("count", new WordCount(), 12).fieldsGrouping("split", new Fields("word")); ...
Map
public void execute(Tuple tuple, BasicOutputCollector collector) {
String word = tuple.getString(0);
Integer count = counts.containsKey(word) ? counts.get(word) + 1 : 1;
counts.put(word, count);
collector.emit(new Values(word, count));
}
首先，定义topology。第二行代码定义一个spout，作为数据源。然后是一个处理组件bolt，分割文本为单词。接着，定义另一个bolt来计算单词数（第四行代码）。也可以看到魔数5，8和12，这些是并行度，定义集群每个组件执行的独立线程数。第八行到十五行是实际的WordCount bolt实现。因为Storm不支持内建的状态管理，所有这里定义了一个局部状态。
按之前描述，Trident是对Storm的一个更高层次的抽象，Trident最大的特点以batch 的形式进行流处理。除了其它优势，Trident提供了状态管理，这对wordcount实现非常有用。
public static StormTopology buildTopology(LocalDRPC drpc) {
FixedBatchSpout spout = ...
TridentTopology topology = new TridentTopology();
TridentState wordCounts = topology.newStream("spout1", spout)
.each(new Fields("sentence"),new Split(), new Fields("word"))
.groupBy(new Fields("word"))
.persistentAggregate(new MemoryMapState.Factory(),
new Count(), new Fields("count"));
...
}
如你所见，上面代码使用higher level操作，比如each（第七行代码）和groupby（第八行代码）。并且使用Trident管理状态来存储单词数（第九行代码）。
下面是时候祭出提供声明式API的Apache Spark。记住，相对于前面的例子，这些代码相当简单，几乎没有冗余代码。下面是简单的流式计算单词数：
val conf = new SparkConf().setAppName("wordcount")
val ssc = new StreamingContext(conf, Seconds(1))
val text = ...
val counts = text.flatMap(line => line.split(" "))
.map(word => (word, 1))
.reduceByKey(_ + _)
counts.print()
ssc.start()
ssc.awaitTermination()
每个Spark Streaming的作业都要有StreamingContext，它是流式函数的入口。StreamingContext加载第一行代码定义的配置conf，但更重要地，第二行代码定义batch interval（这里设置为1秒）。第六行到八行代码是整个单词数计算。这些是标准的函数式代码，Spark定义topology并且分布式执行。第十二行代码是每个Spark Streaming作业最后的部分：启动计算。记住，Spark Streaming作业一旦启动即不可修改。
接下来看下Apache Samza，另外一个组合式API例子：
class WordCountTask extends StreamTask {
override def process(envelope: IncomingMessageEnvelope, collector: MessageCollector,
coordinator: TaskCoordinator) {
val text = envelope.getMessage.asInstanceOf[String]
val counts = text.split(" ").foldLeft(Map.empty[String, Int]) {
(count, word) => count + (word -> (count.getOrElse(word, 0) + 1))
}
collector.send(new OutgoingMessageEnvelope(new SystemStream("kafka", "wordcount"), counts))
}
Samza的属性配置文件定义topology，为了简明这里并没把配置文件放上来。定义任务的输入和输出，并通过Kafka topic通信。在单词数计算整个topology是WordCountTask。在Samza中，实现特殊接口定义组件StreamTask，在第三行代码重写方法process。它的参数列表包含所有连接其它系统的需要。第八行到十行简单的Scala代码是计算本身。
Flink的API跟Spark Streaming是惊人的相似，但注意到代码里并未设置batch interval。
val env = ExecutionEnvironment.getExecutionEnvironment
val text = env.fromElements(...)
val counts = text.flatMap ( _.split(" ") )
.map ( (_, 1) )
.groupBy(0)
.sum(1)
counts.print()
env.execute("wordcount")
上面的代码是相当的直白，仅仅只是几个函数式调用，Flink支持分布式计算。
结论
上面给出了基本的理论和主流流处理框架介绍，下篇文章将会更深入的探讨其它关注点。希望你能对前面的文章感兴趣，如果有任何问题，请联系我讨论这些主题。
在上篇文章中，我们过了下基本的理论，也介绍了主流的流处理框架：Storm，Trident，Spark Streaming，Samza和Flink。今天咱们来点有深度的topic，比如，容错，状态管理或者性能。除此之外，我们也将讨论开发分布式流处理应用的指南，并给出推荐的流处理框架。
容错性
流处理系统的容错性与生俱来的比批处理系统难实现。当批处理系统中出现错误时，我们只需要把失败的部分简单重启即可；但对于流处理系统，出现错误就很难恢复。因为线上许多作业都是7 x 24小时运行，不断有输入的数据。流处理系统面临的另外一个挑战是状态一致性，因为重启后会出现重复数据，并且不是所有的状态操作是幂等的。容错性这么难实现，那下面我们看看各大主流流处理框架是如何处理这一问题。
Apache Storm：Storm使用上游数据备份和消息确认的机制来保障消息在失败之后会重新处理。消息确认原理：每个操作都会把前一次的操作处理消息的确认信息返回。Topology 的数据源备份它生成的所有数据记录。当所有数据记录的处理确认信息收到，备份即会被安全拆除。失败后，如果不是所有的消息处理确认信息收到，那数据记录会被数据源数据替换。这保障了没有数据丢失，但数据结果会有重复，这就是at-least once传输机制。
Storm采用取巧的办法完成了容错性，对每个源数据记录仅仅要求几个字节存储空间来跟踪确认消息。纯数据记录消息确认架构，尽管性能不错，但不能保证exactly once消息传输机制，所有应用开发者需要处理重复数据。Storm存在低吞吐量和流控问题，因为消息确认机制在反压下经常误认为失败。
Spark Streaming：Spark Streaming实现微批处理，容错机制的实现跟Storm不一样的方法。微批处理的想法相当简单。Spark在集群各worker节点上处理micro-batches。每个micro-batches一旦失败，重新计算就行。因为micro-batches本身的不可变性，并且每个micro-batches也会持久化，所以exactly once传输机制很容易实现。
Samza：Samza的实现方法跟前面两种流处理框架完全不一样。Samza利用消息系统Kafka 的持久化和偏移量。Samza监控任务的偏移量，当任务处理完消息，相应的偏移量被移除。消息的偏移量会被checkpoint到持久化存储中，并在失败时恢复。但是问题在于：从上次checkpoint中修复偏移量时并不知道上游消息已经被处理过，这就会造成重复。这就是at least once传输机制。
Apache Flink：Flink的容错机制是基于分布式快照实现的，这些快照会保存流处理作业的状态（本文对Flink的检查点和快照不进行区分，因为两者实际是同一个事物的两种不同叫法。Flink构建这些快照的机制可以被描述成分布式数据流的轻量级异步快照，它采用Chandy-Lamport算法实现。）。如果发生失败的情况，系统可以从这些检查点进行恢复。Flink发送checkpoint的栅栏（barrier）到数据流中（栅栏是Flink的分布式快照机制中一个核心的元素），当checkpoint的栅栏到达其中一个operator，operator会接所有收输入流中对应的栅栏（比如，图中checkpoint n对应栅栏n到n-1的所有输入流，其仅仅是整个输入流的一部分）。所以相对于Storm，Flink的容错机制更高效，因为Flink的操作是对小批量数据而不是每条数据记录。但也不要让自己糊涂了，Flink仍然是原生流处理框架，它与Spark Streaming在概念上就完全不同。Flink也提供exactly once消息传输机制。
状态管理
大部分大型流处理应用都涉及到状态。相对于无状态的操作（其只有一个输入数据，处理过程和输出结果），有状态的应用会有一个输入数据和一个状态信息，然后处理过程，接着输出结果和修改状态信息。因此，我们不得不管理状态信息，并持久化。我们期望一旦因某种原因失败，状态能够修复。状态修复有可能会出现小问题，它并不总是保证exactly once，有时也会出现消费多次，但这并不是我们想要的。
据我们所知，Storm提供at-least once的消息传输保障。那我们又该如何使用Trident 做到exactly once的语义。概念上貌似挺简单，你只需要提交每条数据记录，但这显然不是那么高效。所以你会想到小批量的数据记录一起提交会优化。Trident定义了几个抽象来达到exactly once的语义，见下图，其中也会有些局限。
Spark Streaming是微批处理系统，它把状态信息也看做是一种微批量数据流。在处理每个微批量数据时，Spark加载当前的状态信息，接着通过函数操作获得处理后的微批量数据结果并修改加载过的状态信息。
1
Samza实现状态管理是通过Kafka来处理的。Samza有真实的状态操作，所以其任务会持有一个状态信息，并把状态改变的日志推送到Kafka。如果需要状态重建，可以很容易的
从Kafka的topic重建。为了达到更快的状态管理，Samza也支持把状态信息放入本地key-value存储中，所以状态信息不必一直在Kafka中管理，见下图。不幸的是，Samza 只提供at-least once语义，exactly once的支持也在计划中。
Flink提供状态操作，和Samza类似。Flink提供两种类型的状态：一种是用户自定义状态；另外一种是窗口状态。如图，第一个状态是自定义状态，它和其它的的状态不相互作
用。这些状态可以分区或者使用嵌入式Key-Value存储状态［文档一和二］。当然Flink 提供exactly-once语义。下图展示Flink长期运行的三个状态。
单词计数例子中的状态管理
单词计数的详细代码见上篇文章，这里仅关注状态管理部分。
让我们先看Trident：
public static StormTopology buildTopology(LocalDRPC drpc) {
FixedBatchSpout spout = ...
TridentTopology topology = new TridentTopology();
TridentState wordCounts = topology.newStream("spout1", spout)
.each(new Fields("sentence"),new Split(), new Fields("word"))
.groupBy(new Fields("word"))
.persistentAggregate(new MemoryMapState.Factory(), new Count(), new Fields("count")); ...
}
在第九行代码中，我们通过调用persistentAggregate创建一个状态。其中参数Count存储单词数，如果你想从状态中处理数据，你必须创建一个数据流。从代码中也可以看出实现起来不方便。
Spark Streaming声明式的方法稍微好点：
// Initial RDD input to updateStateByKey
val initialRDD = ssc.sparkContext.parallelize(List.empty[(String, Int)])
val lines = ...
val words = lines.flatMap(_.split(" "))
val wordDstream = words.map(x => (x, 1))
val trackStateFunc = (batchTime: Time, word: String, one: Option[Int],
state: State[Int]) => {
val sum = one.getOrElse(0) + state.getOption.getOrElse(0)
val output = (word, sum)
state.update(sum)
Some(output)
}
val stateDstream = wordDstream.trackStateByKey(
StateSpec.function(trackStateFunc).initialState(initialRDD))
首先我们需要创建一个RDD来初始化状态（第二行代码），然后进行transformations （第五行和六行代码）。接着在第八行到十四行代码，我们定义函数来处理单词数状态。函数计算并更新状态，最后返回结果。第十六行和十七行代码，我们得到一个状态信息流，其中包含单词数。
接着我们看下Samza，
class WordCountTask extends StreamTask with InitableTask {
private var store: CountStore = _
def init(config: Config, context: TaskContext) {
this.store = context.getStore("wordcount-store")
.asInstanceOf[KeyValueStore[String, Integer]]
}
override def process(envelope: IncomingMessageEnvelope,
collector: MessageCollector, coordinator: TaskCoordinator) {
val words = envelope.getMessage.asInstanceOf[String].split(" ")
words.foreach { key =>
val count: Integer = Option(store.get(key)).getOrElse(0)
store.put(key, count + 1)
collector.send(new OutgoingMessageEnvelope(new SystemStream("kafka", "wordcount"),
(key, count)))
}
}
首先在第三行代码定义状态，进行Key-Value存储，在第五行到八行代码初始化状态。接着在计算中使用，上面的代码已经很直白。
最后，讲下Flink使用简洁的API实现状态管理：
val env = ExecutionEnvironment.getExecutionEnvironment
val text = env.fromElements(...)
val words = text.flatMap ( _.split(" ") )
words.keyBy(x => x).mapWithState {
(word, count: Option[Int]) =>
{
val newCount = count.getOrElse(0) + 1
val output = (word, newCount)
(output, Some(newCount))
}
}
我们仅仅需要在第六行代码中调用mapwithstate函数，它有一个函数参数（函数有两个变量，第一个是单词，第二个是状态。然后返回处理的结果和新的状态）。
流处理框架性能
这里所讲的性能主要涉及到的是延迟性和吞吐量。
对于延迟性来说，微批处理一般在秒级别，大部分原生流处理在百毫秒以下，调优的情况下Storm可以很轻松的达到十毫秒。
同时也要记住，消息传输机制保障，容错性和状态恢复都会占用机器资源。例如，打开容错恢复可能会降低10％到15％的性能，Storm可能降低70%的吞吐量。总之，天下没有免费的午餐。对于有状态管理，Flink会降低25%的性能，Spark Streaming降低50%的性能。
也要记住，各大流处理框架的所有操作都是分布式的，通过网络发送数据是相当耗时的，所以进了利用数据本地性，也尽量优化你的应用的序列化。
项目成熟度
当你为应用选型时一定会考虑项目的成熟度。下面来快速浏览一下：
Storm是第一个主流的流处理框架，后期已经成为长期的工业级的标准，并在像
Twitter，Yahoo，Spotify等大公司使用。Spark Streaming是最近最流行的Scala代码实现的流处理框架。现在Spark Streaming被公司（Netflix, Cisco, DataStax, Intel, IBM等）日渐接受。Samza主要在LinkedIn公司使用。Flink是一个新兴的项目，很有前景。
你可能对项目的贡献者数量也感兴趣。Storm和Trident大概有180个代码贡献者；整个Spark有720多个；根据github显示，Samza有40个；Flink有超过130个代码贡献
者。
小结
在进行流处理框架推荐之前，先来整体看下总结表：
流处理框架推荐
工作流引擎 产品功能介绍V0.07
目录 1.1工作流引擎简介 (4) 1.1.1产生背景 (4) 1.1.2发展阶段 (5) 1.1.2.1EDF(电子数据流)阶段 (5) 1.1.2.2TPF(事务处理流)阶段 (5) 1.1.2.3IMF(整体集成管理流)阶段 (5) 1.1.2.4CPF(知识共享和持续改进)阶段 (6) 1.1.3主要特点 (6) 1.1.4流程定义和运行 (7) 1.1.5流程运转模式 (7) 1.1.6工作流引擎不等于OA系统 (9) 1.2XX工作流引擎 (10) 1.2.1XX工作流引擎简介 (10) 1.2.2产品设计 (11) 1.2.2.1工作流是XX电子政务平台的组件之一 (11) 1.2.2.2工作流引擎设计思想 (12) 1.2.2.3工作流引擎产品架构 (14) 1.2.3产品功能 (15) 1.2.3.1支持流程运转模式 (15) 1.2.3.2设计工具 (19) 1.2.3.3控制平台 (21) 1.2.3.4任务列表 (22) 1.2.3.5流程与用户 (24) 1.2.3.6工作流数据 (25) 1.2.3.7事务处理 (26) 1.2.3.8异常处理 (26) 1.2.4产品安全能力 (26) 1.2.5产品集成扩展 (26)
1.2.6运行环境 (27) 1.3XX工作流引擎适应复杂应用的要求 (27) 1.3.1多机构联合作业 (28) 1.3.2流程的定义集中管理 (29) 1.3.3嵌套子流程和和引用子流程 (29) 1.4XX工作流应用实施方法 (29) 1.4.1点面结合，全面推进 (29) 1.4.2分步实施，适当激励 (30) 1.4.3持续改进，形成文化 (30) 1.5XX工作流引擎成功案例 (30) 1.5.1广州移动广州公务机管理系统 (31) 1.5.1.1实现功能 (31) 1.5.1.2实施效果 (32) 1.5.2广州外经贸网上政务-发文管理 (33) 1.5.2.1实现功能 (33) 1.5.2.2实施效果 (35)
工作流系统功能列表 流程运转功能 1. 串行路由（Sequence Routing） 这个一般都比较容易理解，就是按照顺序的任务执行 2. 并行路由（Parallel Routing） 企业内部有许多作业必需平行处理以提高效率，举例来说：有5 位部门经理需要提出年 度预算报告，每一部门之报告为独立提出，故可将五位经理定义在同一步骤内，各自处理后再统一送到下一步骤。 3. 聚合路由（Merge Routing） 多个分支需要聚合成一个完整的流程 工作流系统功能列表系列 4. 条件路由（Conditional Routing） 在企业处理日常工作时，有许多步骤只有在特定条件成立时才会执行。工作流程自动化 软件因此必需提供此功能。 5. 条件跳跃（Conditional Jumps） 条件式跳跃指满足某些特定条件时，必须自动跳过中间数个步骤至指定人员处理。这也 是企业工作程序里屡见不鲜的状况。 6. 条件终止(Conditional Aborts) 在企业内常发生当遇到某些状况时，则整个流程实例便取消而不再流转。工作流程自动 化软件也必需相对提供这项功能。 7. 回退（Process Returns） 这项业务因为各种原因（文档不全、发送错误等等），当然处理人要求上一处理人重新 办理，或重新发送 8. 取回（Process Rollback） 业务人员依照客户要求填写订单后，订单送出往下继续传递，隔了一天后，客户临时决 定要更改订货的内容，您可以在不删除订单流程的情况下，使用反向回传的功能，可从有问题的步骤(订单输入)直接「取回」已流到后面数个步骤的该张订单，修改完毕后再送至下一步骤. 一般这种情况，实际系统实现中，会强制在后续处理人未处理的情况下可做出[取回]动作，否则不能取回。 9. 自循环（Self-Cycle） 在电子政务办公系统中，经常出现的“多处长联合审批”过程。多个处长（个人）属于 同一个处长角色（角色单元）。针对同一个审批过程，采用自循环（审批这个过程重复执行）就可以基本解决问题。 10. 发散路由（Emanative Routing） 一个任务拆分成多个任务，其分支状态基本相等，同时流程也因为发散操作而分为多个 分支流程 11. 抄送路由（Copy Routing） 比如一个发文，在交司局会签的时候，可能会抄送一份给另外的司局备案，这个过程就 或额外的激活一个不影响主会签流程的“抄送任务” 流程运转扩展功能 12. 关系路由（Relationship Based Routings） 大部分企业流程是构建在从属关系上的：申请差旅费需由部门经理核准、员工绩效由上
工作流引擎产品功能介绍
目录
1.1工作流引擎简介 1.1.1产生背景 随着我国信息化建设的不断深入，越来越多的政府部门和企事业单位都清醒地认识到信息化对于自身的生存与发展的重要性，以IT 系统建设为基础提高工作效率，增强竞争能力，已经成为共识。 在过去的若干年中，许多企业以当时的IT 发展水平为基础，针对不同的业务需求搭建了种类繁多的应用系统。回顾这一阶段，我们可以发现长期以来IT 系统的建设一直跟随着技术的革新和业务需求的增长而被动地发展着。不论技术手段如何变化，企业仍旧习惯于沿着功能分析的思路为特定的需求开发专有应用。随着时间的推移，企业内部逐渐积累了许多相互孤立的筒仓式应用系统。不可否认，正是这些应用系统共同构成了当今企业的主要IT 运行环境并有效地支撑了企业早期的业务发展，但是我们也必须清醒地认识到，在这些缺乏前期规划、互连性极差的应用系统之间信息不能被有效地共享且难于保持一致，业务过程也无法顺畅地流转，它们是造成“信息孤岛”现象的根源。一些企业也曾经尝试采用整理、合并各种需求、统一数据接口、规范业务过程等方式来降低集成的复杂度，但是在经过一番实践后，人们又发现仅仅依靠规范静态信息的交换格式，集合局部的需求等方法并不足以支持更大范围内的应用整合。因此当前的企业迫切需要一个能够支持在不同的应用系统之间完成协作任务的具有前瞻性的应用集成框架。 当前，企业面对的是一个多变且难以预测的市场，要在这样的环境中生存和
发展，就必需具备对外部变化做出迅速响应的能力。同样，政府部门也面临着转变工作职能，适应市场经济发展要求的压力，需要不断地为大众提供各种高效的公共服务。各项独立调查表明: 对业务系统和IT 基础设施进行快速调整和扩展一直是政府部门和企事业单位应对外部环境变化的重要手段。然而在早期的IT 系统设计过程中，人们往往更加关注于系统的稳定性而不是迅速应对变化的能力，原先那种僵硬的基于硬编码实现的系统功能扩展和集成方式已远远不能满足要求。“采用什么样的技术来搭建能够实现跨部门、跨企业、跨地理范围的支持流程协作和流程自动化的IT 基础设施”，“如何能够从被动地应对变化到预见变化进而实现前瞻性地主动变化”…这些都是当前每一个政府部门和企事业单位必须面对的挑战。 通过工作流系统把各业务部门的孤立应用系统整合起来是IT技术发展的必然趋势，而我国从上实际八十年代大量建设基础信息系统至今，工作流技术的发展可以分成以下几个阶段。 1.1.2发展阶段 1.1. 2.1EDF(电子数据流)阶段 此阶段的工作流在信息技术中的应用,仅着眼于利用信息技术减轻人们在流程中的计算强度最主要的特点是仅对企业单项业务进行处理,基本不涉及管理的内容。国内最早成功的产品是财务管理产品，为了配合产生正确的数据，可能要设计一个流程用来协调多个会计统计帐目。 此阶段仅仅停留在诸如文档处理、公文流转以及信息发布等这些简单的业务
主流三维引擎对比分析 随着计算机可视化、虚拟现实技术的飞速发展,人们对实时真实感渲染以及场景复杂度提出了更高的要求。传统的直接使用底层图形接口如OpenGL、DirectX开发图形应用的模式越来越暴露出开发复杂性大、周期性长、维护困难的缺陷。为此国外出现了许多优秀的三维渲染引擎,比如Delta3D,OGRE,OSG,Unity3d,VTK等。渲染引擎的作用就是要优化遍历与显示三维模型。本文主要对OGRE与OSG这两个三维图形渲染引擎做个简单的比较,介绍她们在运行效率、场景管理、功能支持、可扩展性等方面的异同。通过了解两者差异后,可以根据不同的项目需求,选择合适的渲染引擎。 ogre OGRE(Object-Oriented Graphics Rendering Engine,面向对象图形渲染引擎) 又叫做OGRE 3D。OGRE就是面向场景的、灵活的图像引擎。OGRE仍然在发展中,如果就功能与商业游戏引擎还有一定差距。在OGRE的论坛网站上您可以得到更多的信息,里面谈论到OGRE的一些格外的插件,如声音,UI ,物理检测,还有网络应用。采用C++开发,以MIT许可证发布,可以在Windows、Linux、Mac上运行。OGRE自己也说明本身不就是游戏引擎。 其主要特征如下: 面向对象,插件扩展架构,具有文档支持。 支持脚本。可以通过脚本管理材质资产并进行多路渲染。 支持物理碰撞检测。 支持顶点灯光、像素灯光、灯光映射。 支持阴影映射、三维阴影。 支持多纹理、凹凸贴图、多重材质贴图、立体投影。 支持顶点、像素、高级着色。 支持场景管理,具有多种数据结构。 支持逆向运动动画、骨架动画、变形动画、混合动画及姿态动画。 支持网格加载、皮肤、渐进网格。 支持环境映射、镜头眩光、公告牌、粒子、运动模糊、天空、水、雾、丝带轨迹、透明对象。支持XML文件转换。 引擎特性全面( ),稳定性好( ),支持全面( ),不容易上手与使用( )。
慧正工作流系统 设计器使用简明教程 目录 1.模块定制 (2) 1) 打开设计器 (2) 2) 新建模块 (2) 3) 创建数据表 (3) 4) 创建表单 (5) 5) 创建视图 (8) 6) 创建模块内部导航菜单 (13) 7) 添加应用菜单 (15) 8) 测试模块的增、删、改、查功能 (16) 9) 导出定制模块 (17) 10) 删除定制模块 (18) 11) 导入定制模块 (19) 2.定制工作流 (20) 1) 创建流程表单 (20) 2) 新建流程 (20) 3) 填写流程属性 (21) 4) 表单设置 (21) 5) 绘制流程图 (23) 6) 测试流程 (23) 7) 待办处理 (24) 8) 流程导出 (25) 9) 流程删除 (26) 10) 流程导入 (26)
1.模块定制 1)打开设计器 （登录时选择“设计端”，或登录后点击页面右上角的“设计”，均可进入设计器页面） 点击“应用设计” 2)新建模块 1.在这里点击鼠标“右键” 2.在弹出菜单点击 “新建模块”
在弹出的模块属性窗口进行如下操作： 3)创建数据表 1.模块名称录入“模块定制练习” 2. 模块分类录入“练习” 3.点击保存（弹出提示框选择OK） 4.关闭 1.点击“新建”
在弹出的“库表属性”页面，执行如下操作： 在“字段属性”页面执行如下操作：3.点击“字段属性”标签2.填写中文名称“练习表” 1.填写表名“tz_mytest” 1.点击“新增” 2.字段名录入“MYTXT” 3.数据类型选择“大文本” 4.中文名称录入“内容” 5.录入类型选择“大文本” 6.点击“确认” 7.点击“创建表”（弹出 提示框选择“是”） 8.点击“关闭”
概述 本章节讲述了实际应用场景下如何灵活使用活字格工作流，包括工作流流程条的使用，以及工作流命令与批量工作流命令的设置。 业务场景描述 为了让大家能够在实际应用场景中理解工作流中的状态，普通流程，审批流程，以请休假管理模块为例，企业员工在提交请假申请单时，根据部门的不同判断是否需要经过人力资源部核准剩余年假，然后根据请假天数提交部门领导审批，部门领导审批状态为审批流程：小于3天，提交到部门副经理，小于5天，提交到部门经理，小于7天，公司副经理，小于10天，公司经理，大于等于10天，集团董事长，部门领导审批结束后提交人力资源部扣除年假流程结束。在流程流转到人资部结算时，设置提醒，要求提交给人资部结算1个小时以内每20分钟提醒一次，直到人资部结算提交流程。管理员可以随意将流程撤转到对应的环节上。 流程图如下： 请休假申请流程（包含普通流程+部门领导审批流程）
部门领导审批流程
工作流设置
通过上一章节流程功能点的讲解，配合流程图，我们可以将请休假流程在活字格中得以体现。在学习应用场景时，建议大家先学习了解下工作流中所有的功能，那样更方便大家针对特定流程去设计。 表和页面的创建在这里我就不为大家一一介绍了，直入主题，开启请休假表的工作流。在请休假表开启工作流时，表名后会带一个工作流的小图标。操作步骤如下： 1. 新建状态，整个工作流包含了起草，人资部核准，部门领导审批，人资部结算以及结束5个状态。其中起草，人资部核准，人资部结算，结束均为普通流程，部门领导审批为审批流程。
2. 如流程图所示，起草环节根据创建者的部门区分流转环节，若创建者部门=活字格开发部，提交人资部核准，担当者为人力资源部经理，，若创建者部门=活字格业务部，提交部门领导审批。此时就需要在条件中添加不同的分支。条件中选择创建者的扩展属性部门。 3. 当创建者属于活字格开发部时，提交给人资部核准，人资部正常提交给部门领导审批。普通流程后跟审批流程，不用设置担当者。
工作流引擎平台解决方案 工作流引擎平台在实际系统中的应用一般分为三个阶段，即模型建立阶段、模型实例化阶段和模型执行阶段。模型建立阶段利用工作流建模工具完成各种企业经营过程或者项目管理流程模型的建立，将企业的实际经营过程或项目管理流程转化为计算机可处理的工作流模型。模型的实例化阶段为每个过程设定运行所需的参数，并分配每个活动执行所需的资源（设备、人员等）。模型执行阶段完成经营过程的执行，在这个过程中重要的任务是完成人机交互和应用的执行，并对过程与活动的执行情况进行监控与跟踪 WorkFlow的设计理念是致力于企业的业务流程自动化解决方案，为企业的业务流程自动化以及企业流程再造提供坚实的基础平台，成为业界领先的企业业务流程自动化的基础平台产品以及企业流程再造的核心产品。有力的简化应用开发的步骤，降低应用开发的难度，提高应用开发的效率及灵活性，节约应用开发的成本，从而极大的提高应用开发的生产力。WorkFlow产品构成分为三块：模型定义工具、工作流引擎、客户端应用。模型定义工具提供图形化的过程定义工具，而工作流引擎则实现了工作流的后台驱动。后台工作流引擎以COM组件方式实现，为应用系统的集成提供了方便的编程接口。客户端应用是人机交互的界面、与业务系统的具体应用。 1.模型定义工具 Workflow建模工具以图形界面为建模人员提供了一个友好、方便的建模环境。一个工作流的定义包括模板和实例两个部分，模板用于描述工作流定义，用于工作流应用的设计阶段；实例是将模板定义用于特定工作流程时对模板的拷贝。这样做是为了在模板使用过程中对模板可随时进行修改而不影响已启动的流程。一个工作流程称为一个工作（Job），组成工作的每个执行单元称为活动（Activity），组成活动的更小单位称为任务（Task），活动的入口称为主表单（MasterForm）。每个工作都是由一系列具有逻辑关系的活动组成，这些逻辑关系构成活动的路由信息。因此，一个工作实际上可以看作是一系列具体工作和它们之间的逻辑关系构成的一个有机整体。每个工作都有一个创建者，他是启动此工作的人。每个工作可以有多个拥有者，拥有者具有撤销、挂起、强行终止工作的权力。每个活动都有一个拥有者，他是模板中定义的活动执行人，活动拥有者
国内外主流工作流引擎及规则引擎分析2013年2月创新研发部
目录 国内外主流工作流引擎及规则引擎分析 (1) 一.背景 (4) 二.原则 (4) 三.工作流功能分析点 (6) 4.1.标准类 (6) 3.1.1BPMN2.0标准支持 (6) 4.2.开发类 (7) 3.1.1业务模型建模工具 (7) 3.1.2工作流建模工具 (7) 3.1.3人工页面生成工具 (8) 3.1.4仿真工具 (9) 4.3.功能类 (9) 4.1.1流程引擎 (9) 4.1.2规则引擎 (10) 4.1.3组织模型与日期 (10) 4.1.4对外API的提供 (11) 4.1.5后端集成/SOA (11) 4.1.6监控功能 (12) 四.中心已有系统工作流功能点分析 (13) 4.1.备付金系统工作流分析 (13) 4.1.1联社备付金调出流程 (13)
4.1.2联社备付金调入流程 (16) 4.1.3资金划入孝感农信通备付金账户业务流程 (18) 4.1.4备付金运用账户开立流程 (20) 4.1.5备付金沉淀资金运用流程 (23) 4.1.6备付金沉淀资金支取流程 (26) 4.2.多介质项目工作流分析 (28) 4.1.1开卡审批流程 (28) 4.3.新一代农信银资金清算系统工作流分析 (29) 4.4.电子商票系统工作流分析 (29) 4.5.OA系统工作流分析 (32) 五.工作流产品分析 (32) 六.分析结论 (44) 4.4.对比 (44) 4.5.建议 (45)
一.背景 目前中心建成的“一大核心系统，七大共享平台”以及OA系统，对工作流应用程度高，但各系统实现工作流程管理没有建立在统一的工作流平台上，导致流程割裂、重复开发、不易于管理等问题。 备付金管控项目涉及多个岗位之间工作的审核步骤，同时还要与多个系统进行交互，因此，为了提高管理效率，降低业务流转时间，同时还要结合农信银中心的总体IT战略规划，备付金管控项目技术组决定选择一款先进的工作流引擎和一款规则引擎，作为备付金管控项目的核心技术架构。 二.原则 备付金管控项目组通过梳理各信息系统流程现状和未来需求，形成农信银中心工作流平台的发展规划，从而更全面的满足农信银各项关键业务、更好的支撑现有和未来的信息系统建设。项目组充分研究国内外领先的工作流产品和案例，同厂商交流。从用户界面生成、流程建模、流程引擎、规则引擎、组织模型、模拟仿真、后端集成/SOA、变更及版本管理、移动设备解决方案、监控分析能力等多方面考察工作流产品，进行工作流产品选型。 目前国内外的工作流引擎层出不穷，行业标准多种多样，通过对比不同工作流公司产品，本次工作流技术选型决定分析商业工作流引擎4款，开源工作流引擎2款。其中国际知名厂商的商业工作流引擎2款，本土厂商的商业工作流引擎2款。由于本次技术选型是以工作流引擎为主，选型工作将不再单独分析规则
工作流系统功能介绍 目录 1概述 (2) 2流程系统设计总图 (4) 3建模工具 (4) 3.1组织机构管理 (5) 3.1.1主界面 (6) 3.1.2岗位管理界面 (7) 3.1.3部门管理界面 (8) 3.1.4员工管理界面 (9) 3.2权限管理 (10) 3.2.1主界面 (11) 3.2.2权限组管理界面 (12) 3.2.3权限设置界面 (14) 3.3流程管理 (14) 3.3.1流程管理主界面 (15) 3.3.2启动节点配置界面 (15) 3.3.3处理者配置界面 (19) 3.3.4流转条件配置界面 (19) 3.3.5控制节点配置界面 (20) 3.3.6子流程节点配置界面 (21) 3.4表单管理 (21) 3.4.1表单管理主界面 (22) 3.4.2选择用户控件界面 (23)
4工作流引擎 (23) 4.1基本功能 (23) 4.2任务节点类型 (25) 4.2.1启动节点 (25) 4.2.2结束节点 (26) 4.2.3交互节点 (26) 4.2.4子流程节点 (26) 4.2.5控制节点 (26) 4.2.6查看节点 (26) 5业务平台 (26) 5.1业务平台主界面 (27) 5.2例子:差旅费报销流程 (27) 5.3未认领任务 (29) 5.4已认领任务 (30) 5.5已完成任务 (30) 5.6查看流程图 (30) 6与门户sps系统的整合 (31) 7流程监控服务系统（即时消息和Email） (32) 1概述 随着计算机软件应用的普及，信息化系统发挥的作用也越来越大，企业信息化建设的不断深入，对系统功能和自动化程度要求越来越高。客户要求系统功能与实际的工作情景紧密结合，对每个业务环节的控制要求越来越精确。如何让我们的信息化系统更加贴近客户需求，满足客户不断变化的业务流程成了我们软件开发商不得不面对的问题。
A c t i v i t i工作流入门详 解完整教程 Prepared on 24 November 2020
Activiti入门教程详解完整教程 1.Activiti介绍 Activiti是由Alfresco软件在2010年5月17日发布的业务流程管理(BPM)框架,它是覆盖了业务流程管理，工作流，服务协作等领域的一个开源，灵活的，易扩展的可执行流程语言框架。 Activiti基于Apache许可的开源BPM平台，创始人TomBaeyens是JBossJBPM 的项目架构师，它的特色是提供了eclipse插件，开发人员可以通过插件直接绘画出业务流程图。 1.1工作流引擎 ProcessEngine对象，这是Activiti工作的核心。负责生成流程运行时的各种实例及数据，监控和管理流程的运行。 1.2BPMN 业务流程建模与标注（BusinessProcessModelandNotation,BPMN），描述流程的基本符号，包括这些图元如何组合成一个业务流程图(BusinessProcessDiagram) 2.准备环境 2.1Activiti软件环境 1)或者更高版本 2)支持的数据库有:h2,mysql,oracle,mysql,db2等 3)支持Activiti运行的jar包，可以通过maven依赖引入 4)开发环境为或者以上版本，myeclipse为版本 安装流程设计器(eclipse插件) 1）打开HelpInstallNewSoftwareAdd
输入Name:ActivitiDesigner designer/update/ 输入完成后，单击OK按钮等待下载完成后安装。 安装完成后在菜单选项中会出现Activiti的目录选项 设置eclipseactivit插件的画流程图选项 打开菜单Windows-->Preferences-->Activiti-->Save下流程图片的生成方式 勾选上Createprocessdefinitionimagewhensavingthediagram操作，勾选上这个操作后在画流程图后保存eclipse会自动生成对应的流程图片。 准备开发环境 Activiti依赖 在eclipse左边工作栏右键New选择创建MavenProject项目，创建一个名为ActivitiTest的项目 点击Finish完成。 右键项目选择Properties，选择ProjectFacets勾选上图中的选项，点击Apply，再点击OK 然后将项目转换成web项目,右键项目选择Properties,在ProjectFacets中做如下勾选,然后点击Appy应用和OK确定 然后右键项目Properties，选择DeploymentAssembly,将test相关目录Remove掉之保留main下面需要发布的内容，如下图 然后点击Appply和OK 然后在文件中添加以下依赖
国外主流工作流引擎及规则引擎分析2013年2月创新研发部
目录 国外主流工作流引擎及规则引擎分析 (1) 一. 背景 (3) 二. 原则 (3) 三. 工作流功能分析点 (5) 4.1. 标准类 (5) 3.1.1 BPMN2.0标准支持 (5) 4.2. 开发类 (6) 3.1.1 业务模型建模工具 (6) 3.1.2 工作流建模工具 (6) 3.1.3 人工页面生成工具 (7) 3.1.4 仿真工具 (8) 4.3. 功能类 (8) 4.1.1 流程引擎 (8) 4.1.2 规则引擎 (9) 4.1.3 组织模型与日期 (9) 4.1.4 对外API的提供 (10) 4.1.5 后端集成/SOA (10) 4.1.6 监控功能 (11) 四. 中心已有系统工作流功能点分析 (12) 4.1. 备付金系统工作流分析 (12) 4.1.1 联社备付金调出流程 (12) 4.1.2 联社备付金调入流程 (15) 4.1.3 资金划入农信通备付金账户业务流程 (17) 4.1.4 备付金运用账户开立流程 (19) 4.1.5 备付金沉淀资金运用流程 (22) 4.1.6 备付金沉淀资金支取流程 (25) 4.2. 多介质项目工作流分析 (27) 4.1.1 开卡审批流程 (27) 4.3. 新一代农信银资金清算系统工作流分析 (28) 4.4. 电子商票系统工作流分析 (28) 4.5. OA系统工作流分析 (31) 五. 工作流产品分析 (31) 六. 分析结论 (42) 4.4. 对比 (42) 4.5. 建议 (43)
一.背景 目前中心建成的“一大核心系统，七大共享平台”以及OA系统，对工作流应用程度高，但各系统实现工作流程管理没有建立在统一的工作流平台上，导致流程割裂、重复开发、不易于管理等问题。 备付金管控项目涉及多个岗位之间工作的审核步骤，同时还要与多个系统进行交互，因此，为了提高管理效率，降低业务流转时间，同时还要结合农信银中心的总体IT战略规划，备付金管控项目技术组决定选择一款先进的工作流引擎和一款规则引擎，作为备付金管控项目的核心技术架构。 二.原则 备付金管控项目组通过梳理各信息系统流程现状和未来需求，形成农信银中心工作流平台的发展规划，从而更全面的满足农信银各项关键业务、更好的支撑现有和未来的信息系统建设。项目组充分研究国外领先的工作流产品和案例，同厂商交流。从用户界面生成、流程建模、流程引擎、规则引擎、组织模型、模拟仿真、后端集成/SOA、变更及版本管理、移动设备解决方案、监控分析能力等多方面考察工作流产品，进行工作流产品选型。 目前国外的工作流引擎层出不穷，行业标准多种多样，通过对比不同工作流公司产品，本次工作流技术选型决定分析商业工作流引擎4款，开源工作流引擎2款。其中国际知名厂商的商业工作流引擎2款，本土厂商的商业工作流引擎2款。由于本次技术选型是以工作流引擎为主，选型工作将不再单独分析规则引擎，
基于OA系统的工作流引擎设计方案
1引言 1.1课题的背景与目标 工作流的概念起源于生产和办公自动化领域，是针对日常工作中具有固定流程的业务活动提出的一个概念。工作流管理联盟(WFMC)给出的工作流定义是：工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。该技术的目的是通过将工作分解成定义良好的任务、角色，按照一定的规则和过程来执行这些任务并对它们进行监控，达到提高工作效率、降低生产成本、提高企业生产经营管理水平和企业竞争力的目标。 工作流管理系统的核心部分是工作流引擎，引擎是驱动流程流动的主要部件，它负责解释工作流流程定义，创建并初始化流程实例，控制流程流动的路径，记录流程运行状态，挂起或唤醒流程，终止正在运行的流程，与其他引擎之间通讯等等工作。 目前，工作流技术还处于发展曲线的初级阶段，然而，关于这方面的研究十分活跃，形成了许多规标准。例如主要的有：工作流管理联盟（Workflow Management Coalition ，WfMC）在体系结构[6]、工作流相关术语[7]及应用程序接口[8]、管理控制接口[9]、过程语言描述[10]等方面提出的一系列规。还有Microsoft, BEA, IBM, SAP等公司联合提交发布的BPEL规等等。 在实际应用中开源产品占据了重要的地位，如JBoss 项目中的jBPM、由OpenSymphony组织开发的OSWorkflow、Enhydra组织开发的Shark。在国，交通大学的基于Petri网点分布是工作流管理的研究，大学的基于工作流过程定义语言（WPDL）的工作流建模平台，都取得了良好的研究成果。 但是工作流管理技术很多方面还不成熟，在使用过程中往往会遇到的一个重要问题是系统过于庞大复杂：一些工作流软件产品，特别是国外成熟的产品，经过多年的发展，功能强大，配置和接口多样灵活。对于国大部分初次使用工作流技术的中小型项目来说，这些工作流软件的功能特性大大超过了需要，客户需要承受漫长的学习周期、复杂的安装配置等带来的风险。 鉴于上述的原因，本课题的目标在于提出一个配置简单、使用方便、功能实用的工作流引擎的设计方案，并完成编码。该工作流引擎——OAworkflow是借鉴了已有的工作流引擎，对某些复杂功能进行简化后，重新设计的。与传统工作流管理系统相比，本工作流管理系统具有以下优点： 1)支持灵活的流程定制 该系统能够针对办公自动化系统中的典型流程案例对流程进行灵活定制，支持的流程路由包括：顺序路由、汇聚路由和分支路由。用户可以根据
开源ERP系统比较 https://www.doczj.com/doc/3c3110740.html,/zhanghaooy/blog/item/9a144f017114dadd277fb5d0.html 现在有许多企业将ERP项目，在企业中没有实施好，都归咎于软件产品不好。其实，这只是你们的借口。若想要将ERP软件真正与企业融合一体，首先得考虑企业的自身情况，再去选择适合的ERP软件。 如果你的企业是高速发展的中小企业，希望用IT给管理带来提升，对国内主流ERP产品几万元到几十万元的投入觉得风险过大，还恐惧购买成品ERP。你还有另外一种选择，选择免费且开放的开源ERP软件进行二次开发，根据自己的要求设定适合你企业的ERP。下载开源ERP的产品十分方便，在各大知名的开源网站上都可免费下载它们。注意哦！开源所有的产品都是对外开放的，且源代码都可任意查看，若您在实施ERP时遇到问题，可在开源社区上进行咨询讨论，当然，您也可以请软件开发商进行二次开发。 开源ERP和其它ERP软件比较，如图所示 下面介绍有哪些开源ERP？ Compiere Compiere ERP&CRM为全球范围内的中小型企业提供综合型解决方案，覆盖从客户管理、供应链到财务管理的全部领域，支持多组织、多币种、多会计模式、多成本计算、多语种、多税制等国际化特性。
Compiere ERP & CRM 通过申购 - 采购 - 发票 - 付款、报价 - 订单 - 发票 - 收款、产品与定价、资产管理、客户关系、供应商关系、员工关系、经营业绩分析等功能，将企业内部运营与外部客户相关的业务进行规范和优化，将企业由“ 人治” 转变为“ 法治” 的境界。 更好地管理您的业务 * 优化您的库存 * 输入销售订单 * 从 Web 接收订单 * 创建发票并记录发货单 * 收集收货单并与银行对账单核对 * 自动生成或手工输入采购订单 * 记录供应商收货和发票 * 供应商付款 * 输入手工日记帐 * 打印报表和对账单 Compiere ERP 的特色 报价至收款：为潜在客户或客户创建报价单；订单管理；发票；现金收据。它与供应链管理、客户管理高度集成。 申购至付款：创建申购单、采购订单、发票收据；付款处理。它与供应链管理高度集成。 客户关系管理：是所有客户与潜在客户相关活动的逻辑视图。它构成了全部业务流程的一分。 伙伴关系管理：将不同的实体相互链接起来，允许它们管理线索分发、服务请求、渠道以及营销费用。它允许您提供集中式服务。 供应链管理：包括有物料管理的活动，包括库存收货、发货，以及从实体、它的组织到供货商、客户之间的移库和盘存。 绩效分析：覆盖了应用程序的成本计算与会计维度。 网上商店 / 自助服务：提供了您运行 Web 业务所需的一切。信息通过标准的应用程序共享，因此无需同步或特别的集成工作。 Compiere 网上商店组件可被定制为与您的网站相一致的外观和感受。 管理仪表板：提供了一目了然的关键绩效指标（ KPI ）视图，它能够互动、实时地展现公司的总体经营业绩。仪表板使得高层管理者能够更有效地实现关键性业务战略，追踪公司与销售指标，达成公司的业绩目标。
第 1 页 工作流需求说明书 1 前言 为构架完整EDM 产品，更好满足特定用户需求，需要进行项目管理和工作流管理模块的开发。 此需求计划由公司内部提出，在需求讨论和编写过程中，总结PDM 组在“863”项目中开发工作流原型的经验，吸收部分企业对工作流的需求意见，参照国内外同类产品的现有系统，确定了我公司开发的要求和目标。 此工作流需求说明书作为项目组内部开发指导文件。 1.1 目的 开发项目管理和工作流模块，所有的过程逻辑控制在工作流中实现，并通过项目管理进行任务分发、任务提交、过程跟踪等。工作流系统中的服务模块（如工作流引擎）基于DCOM 实现，作为组件提供给系统使用。 本文档的预期读者为项目组开发人员、质量保证人员、市场销售人员及公司领导层。 1.2 范围 实现的项目管理（ProjectManage ）和工作流管理（WorkflowManage ）作为CEDM 的两个模块，不单独包装为产品。 工作流管理实现WfMC 定义的基本功能：工作流引擎、图形化定义工具、工作流客户端、工作流管理平台。但实现的功能为WfMC 定义功能的子集，不考虑异构工作流系统间的交互，不考虑数据对象在工作流上的传递，不考虑工作流结点上脚本的实现。 项目管理以工作流管理为核心。项目加载工作流模板后，对任务进行描述，包括设定项目承担人、任务截止日期、任务优先级等，进行工作流的启动、流转、操作。项目管理不包括对设备等其他非人力资源的调度，不负责对项目进度排程的优化和组合。 1.3 定义、缩写词、略语 WfMC(Workflow Management Coalition)工作流管理委员会，有关工作流的国际标准化组织。
国内市场主流专业的工作流(bpm)软件分析、比较及推荐 目前国内外的工作流系统层出不穷，行业标准多种多样，虽然工作流主要功能国内比较知名的工作流软件基本上都具备，但功能的侧重点各不相同,增加了企业对工作流或BPM选型难度，本人选用目前国内市场主流专业的工作流软件，从概念、工作流引擎、工作流过程建模工具、流程操作、工作流客户端架构、流程监控、表单设计器以及与应用程序的集成等方面进行分析和比较，帮助企业对工作流或BPM产品的选型。 一、概述： 工作流的思想最先起源于西方国家，一开始的目的主要是为了简化工作流程，为繁琐的工作提供依据。随着需求的不断延伸以及人们对企业信息化思想的不断普及，工作流越来越受到企业内部的使用推广，当然，工作流能满足的需求也在不断的优化。 工作流概念起源于生产组织和办公自动化领域，是针对日常工作中具有固定程序活动而提出的一个概念，目的是通过将工作分解成定义良好的任务或角色，按照一定的规则和过程来执行这些任务并对其进行监控，达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。尽管工作流已经取得了相当的成就，但对工作流的定义还没有能够统一和明确，不同学者从不同角度对工作流做出了不同的定义。 Georgakopoulos给出的工作流定义是：工作流是将一组任务组织起来以完成某个经营过程：定义了任务的触发顺序和触发条件，每个任务可以由一个或多个软件系统完成，也可以由一个或一组人完成，还可以由一个或多个人与软件系统协作完成。 IBM Almaden Research Center将工作流定义为：工作流是经营过程的一种计算机化的表示模式，定义了完成整个过程需要的所有参数；这些参数包括对过程中每一个步骤的定义、步骤的执行顺序和条件、步骤由谁负责以及每个活动所需要的应用程序等。 1993年工作流管理联盟(Workflow Management Coalition，WfMC)作为工作流管理的标准化组织而成立，标志着工作流技术逐步走向成熟。WfMC对工作流给出定义为：工作流是指一类能够完全自动执行的经营过程，根据一系列过程规则，将文档、信息或任务在不同的执行者之间进行传递与执行。 工作流从英文单词workflow而来，是工作work和流动flow的组合，是一种能够被计算机解释和执行的反映经营过程业务流动的计算机化模型。 二、BPM与工作流的区别 简单地说，BPM关注的业务流，工作流关注的是审批流，它们的区别如下: 1、业务流往往会跨多个业务系统，而审批流往往主要涉及到一个系统。 2、业务流往往会涉及到多个业务功能，多个业务对象，而审批流往往只涉及到一个关键业务对象。 3、业务流涉及到的是不同业务单据之间的流转，而审批流往往是同一业务单据状态的变化。 4、业务流中的活动既包括了人工活动也包括了自动的业务活动，而审批流一般为人工审批活动。
优秀工作流引擎标准 一般性功能(General Functions) 1. 免程序开发(No Programming or Scripting) 2. 可处理大量流程工作(Volume Transaction Processing) 3. 三层式弹性化架构(Three Tier, Scaleable Architecture) 4. 稳定的信息传递架构(Robust Message Transports) 5. 流程反向回传/抽单(Process Rollback) 6. 支持LDAP 目录服务 7. 支持企业级数据库(Support for Enterprise Databases) 8. 动态用户授权(Active User Licensing) 9. 统一的登入ID 与密码(Unified ID/Password) 10. 使用者网域安全性(User Domain Security) 流程与窗体设计功能(Designer) 11. 图形化工作流程图(Graphical Workflow Maps) 12. 基于角色的路由(Role Based Routing) 13. 平行会签(Parallel Routing) 14. 基于关系的路由(Relationship Based Routings) 15. 工作队列(Queues) 16. 图形化数据路由(Graphical Data Routing) 17. 动态会签(Dynamic Routing) 18. 条件化步骤(Conditional Steps) 19. 条件化步骤跳跃(Conditional Jumps) 20. 条件化取消流程(Conditional Aborts) 21. 条件化退回(Conditional Returns) 22. 条件化收件人(Conditional Recipients) 23. 条件定义清单(Event Condition Tables) 24. 条件定义清单与其它步骤互动(Status Variables in Event Condition Tables) 25. 退件(Return Step) 26. 动态定义群组(Dynamic Groups) 27. 整合智能型窗体设计工具(Integrated Intelligent Forms Designer) 28. 表格透过服务器端连接数据库(Server-Side Database Connectivity for Forms) 29. 表格通用变量(Global Variables in Forms) 30. 电子签章(Signatures) 31. 备注留言板(Memos) 32. 表格支持电子扩展表(Spreadsheet Grid in Forms) 33. 多页表格(Multiple Pages per Form) 34. 子表(Sub-Forms) 35. 必备与必读文档(Required and Must-Read Attachments) 36. 附件功能(Attachment) 37. 资料验证与格式化输入(Data Validation and Masking) 38. 支持URL 连结(URL Links) 39. 支持HTML/Java (Support DHTML/Java) 40. 支持第三方对象开发(Third-Party Objects (Controls))
SHARK工作流引擎的表结构 背景： Shark作为一个满足XPDL规范的开源工作流引擎，由于有JAWE作为定义工具，现有的很多流程表达，接口的定义都比较丰富。在数据库的数 据结构表达和代码结构上也有很多优点。 当然，Shark 还是在传统的关系数据库的基础上，提出了一个适用于关键业务开发的基于关系结构的工作流引擎的表结构。 关键词：表结构、工作流引擎、shark、数据结构 1数据库表的关系图 Shark中共含有44个表，分别表达不同的数据结构，对应表数据内容和功能的对应关系，分为用户管理、事件管理、包管理、流程流转的控制数据管理等部分。 1.1用户管理 系统的用户和用户组的基本信息 1.2事件管理 在流程运转过程中，针对流程启动和结束，上下文数据，状态数据的改变，任务结束等事件，都记录了变化的前后过程。
1.3包管理 1.4.1在流程定义的参与者和系统真正用户之间有对应关系
1.4.2应用和调用工具类之间的映射 1.5辅助表
1.6流程流转控制数据管理
2Shark持久层对表的封装
class=" usergroup.HibernateUser" table="usertable" hibernate.participantmappin g.cfg.xml HibernateParticipant.hbm.xml class =" partmappersistence.data.HibernateParticipant" table="participant"