JBoss jBPM实战指南：业务分析师的BPMS

需积分: 35 91 浏览量更新于2024-07-25 1 收藏 5.44MB PDF 举报

"jbpm业务管理，jboss技术文档，好东西，大家分享" jbpm（Java Business Process Management）是JBoss组织开发的一个开源的工作流和业务流程管理（BPM）框架，它允许开发者创建、执行和管理复杂的业务流程。这本书《BusinessProcessManagement with JBoss jBPM：A Practical Guide for Business Analysts》由Matt Cumberlidge撰写，主要面向业务分析师，旨在提供一个实践性的指南来帮助他们理解并应用jbpm进行业务流程建模和实施。 jbpm的核心特性包括： 1. **流程建模**：jbpm支持基于BPMN（Business Process Model and Notation）2.0标准的流程建模，这是一种图形化的流程设计语言，使得业务人员和开发人员可以更好地理解和交流流程逻辑。 2. **工作流引擎**：jbpm提供了一个强大的工作流引擎，能够执行定义好的流程模型，并处理流程中的任务分配、流转和异常处理。 3. **规则集成**：jbpm与Drools规则引擎紧密集成，可以在流程执行过程中嵌入业务规则，实现灵活的决策逻辑。 4. **事件驱动**：jbpm支持事件驱动的流程，可以响应外部事件并作出相应的流程变更。 5. **可视化监控**：jbpm提供了可视化工具，用于监控流程实例的执行状态，便于分析和优化流程。 6. **可扩展性**：jbpm设计为模块化，可以通过插件扩展功能，如与各种持久化存储（如JPA、Hibernate）的集成，以及与外部服务的交互。 7. **RESTful API**：jbpm提供REST接口，允许通过HTTP与流程引擎进行交互，便于与其他系统集成。 8. **社区支持**：jbpm有一个活跃的开发者社区，提供了丰富的文档、示例和问题解答，有助于用户快速上手和解决问题。这本书可能会涵盖如何使用jbpm进行流程设计、部署、执行和管理，包括如何创建流程模型、定义工作流任务、集成业务规则，以及如何使用监控工具进行性能分析和流程优化。此外，还可能涉及jbpm与其他技术（如Spring、EJB等）的集成，以及如何在实际项目中应用jbpm解决业务挑战。对于想要深入了解jbpm以及业务流程管理的读者来说，这本书将是一份宝贵的资源，能够帮助他们在实践中掌握jBPM框架，提升业务流程自动化的能力。同时，书中提到的商标信息和版权声明表明，虽然尽力确保了内容的准确性，但作者和出版方不对任何因使用本书内容造成的直接或间接损害负责。

Introduction

Business Process Management is one of the hottest topics in the fast-moving world

of business analysis and enterprise application development. Yet, it is curiously

difcult to pin down as a dened eld of work. You don't see job listings for "Process

Developer" and there are few, if any, ofcial courses that you can take in Business

Process Management.

The answer to this conundrum lies in the almost accidental way in which BPM

has come about, and in the speed with which the technology marketing machine

swings into action these days: usually before the technology is properly understood.

Business Process Management is at the start of the "hype curve" and it will be some

time before its key concepts become common currency among enterprise managers.

We will try to cut through this hype and the resultant barriers to adoption by

presenting a practical step-by-step approach to the successful implementation

of business process management. We won't spend a great deal of time on theory

in this book; instead we will concentrate on building something of value to your

business. Having said that, we won't simply throw together any old business process

management system, we will advocate a project lifecycle approach, so that we

implement business process management in the right way.

So what is Business Process Management anyway? Well, hopefully you are coming

to this book with some idea of the answer to that question. However, Business

Process Management, or BPM as we shall call it henceforth, means different things

to different people. Each person's denition probably has some element that falls in

the intersection of a Venn diagram of denitions, at the centre of which is the truth.

One of the rst things we have to do is to dene what BPM means for us, so that we

may set expectations about what will be achieved by reading and implementing the

suggestions in this book.

Introduction

[ 8 ]

Nevertheless, Agile development and its ilk do have serious drawbacks and

limitations. The rst and most obvious limitation is that the Agile development

methodology does away with the Business Analyst. This is an important drawback,

because often the BA's interpretation of the requirements is more logical and more

far-sighted than that of the end user who species the original requirement. This

can mean that the developer can be led up blind alleys by an end user who doesn't

have the necessary perspective.

There is also the problem that although we are removing some layers of

interpretation, the layer of interpretation that we are leaving in place is the one that

causes the most signicant dissonance: the developer still has to interpret what the

end user means.

This can mean that time is unnecessarily wasted on honing a prototype that starts off

a long way from what the business needs. Indeed, some Agile developments have

turned into one extremely long prototyping process, with an end result never being

reached. This is an expensive way to develop software.

So what is the ideal, and where is Business Process Management in relation to

this? For some idealists, the best situation would be one where the business users

can build the software tools they need for themselves, without having to rely

on developers or analysts. Unfortunately, although programming languages

are becoming simpler all the time, we are still light years away from them

being abstracted enough for an end user to build their own software. Software

development is still hard.

Nevertheless, BPM does go some way towards this ideal, and given the right

scenario, it can successfully deliver valuable software in extremely short time scales.

In a similar fashion to Agile, BPM relies on cutting out the middle man as much as

possible, only this time the emphasis is on a strong partnership between the end user

and the BA working on iterations towards the nal software:

Modeled

requirement

True

requirement

Interpretation

End

software

Interpretation

Software

generation

End user

Business Analyst

Comparison

Modeling

Chapter 1

[ 9 ]

The reinstatement of the Business Analyst has several advantages:

Firstly, the BA is skilled in the interpretation of requirements, and so their

business process models are likely to be close to the original requirement.

Secondly, a BA's models are far easier for an end user to understand than

code or even prototype software, allowing for closer collaboration and

faster development.

Thirdly, the BA has the long term view and business skills to steer the end

user's expression of their requirements in the most benecial direction.

Last, and by no means least, models can usually be produced much more

quickly than working software. As the working software produced by a

BPM system is initially generated from the BA's process model, this is an

extraordinarily fast method of software development.

Don't be tempted to think that this means developers are no longer required,

however. The reality of BPM development is that it makes the working relationship

between end user, BA, and developer much more symbiotic and productive, but

does not make any of those roles redundant. BPM is a partnership approach to

software development; on one hand between the end user and the BA, and on the

other between the BA and the developer. The skills of a developer are very much

still required to take a BPM system all the way to implementation. Where a business

process calls for the integration of other systems, that integration work will almost

certainly involve an interface built by a developer. And while the software that is

generated by the BPM suite is good, it does still require some development to make

it properly t for purpose.

It would be foolhardy to suggest that the BPM approach is the right one in every

software development scenario, but it is a formidable new challenger to other

development methodologies. Later on in this chapter, we'll consider some of the

scenarios where a BPM approach is the most appropriate.

The emergence of key technologies

Workow software has been around since the early 90s, if not before. These systems

were most often used in document management scenarios, where a document (for

example, an insurance claim form) was passed between different departments as

work was done on it. This worked well because the workow system only had

to maintain a pointer to the document in order to pass it down the process chain.

Where things got more difcult was when the workow system met other,

task-specic systems.

•

剩余216页未读，继续阅读

dtouwxf

粉丝: 1
资源: 1

JBoss jBPM实战指南：业务分析师的BPMS

JBPM-学生管理系统

JBPM 公文管理快速入门程序

jbpm业务流程

用JBoss jBPM管理业务流程

使用JBoss.jBPM的业务流程管理

jbpm:业务流程管理（BPM）套件

ProcessAutomationWebDev:允许业务用户自动化 jBPM 业务流程并与之交互

jbpm-case-mgmt:jBPM案例管理模块

Java开发者指南：jBPM业务流程管理框架深度解析

Java开发者指南：深入理解jBPM业务流程管理框架

最新资源