BPMS 还是只是简单的编程？
在实现业务流程时，您更喜欢什么（从开发人员的角度来看）？
业务流程管理系统 (BPMS) 还是您最喜欢的带有所需工具和框架（例如报告工具）的 IDE？
从您的角度来看，与具有您个人工具和框架的 IDE 相比，BPMS 的最大优势是什么？
好的。也许我应该更具体……我了解了一种特定的 BPMS，它应该可以通过配置规则轻松实现业务流程。但对于我作为一名开发人员来说，使用该系统很难。我希望使用可以重构的文本文件，并且我希望能够为我必须做的工作选择正确的技术或框架。相反，系统强制我进行配置。
有一些规则我可以使用java，但即使这样我也必须坚持使用没有智能感知等的系统编辑器。
所以这让我找到了我自己问题的答案 - 我想使用我习惯的工具而不是拥有学习如何使用 BPMS（至少是我所知道的），因为它对我的限制多于它的帮助。我所知道的BPMS是一个很难摆脱的框架！目前，我更喜欢像 Grail 这样的框架，而不是我所知道的任何 BPMS。
因此，也许更具体的问题是：您是否有同样的感觉，或者是否有 BPMS 支持您成为一名开发人员并像开发人员一样思考，或者它们中的大多数会迫使您以不同的方式完成工作？
What do you prefer (from your developer's point of view) when it comes to implement a business process?
A Business Process Management System (BPMS) or just your favorite IDE with the needed tools and frameworks (a reporting tool for example)?
What is from your point of view the greatest Benefit of a BPMS compared to an IDE with your personal tools and frameworks?
OK. Maybe I should be more specific... I got to know one specific BPMS which should make it easy to implement a business process by configuring rules. But for me as a developer it is hard to work with the system. I would like to work with text files which I can refactor and I would like to be able to choose the right technology or framework for the job I have to do. Instead the system forces me to configure.
There are rules where I can use java, but even then I have to stick to the systems editor without intellisense etc.
So this leads me to the answer of my own question - I would like to use the tools I am used to instead of having to learn how to work with a BPMS (at least the one I know) because it limits me more than it helps. The BPMS I know is a framework from which it is hard to escape! At this time, I would prefer a framework like Grail over any BPMS I know.
So maybe the more specific question is: do you feel the same or are there BPMSes which support you in beeing a developer and think like a developer or do most of them force you to do your job a different way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据我的经验，BPMS 系统提供的开发环境是三流的、低效的，并且实际上迫使您编写难以维护、设计糟糕的代码（由于其局限性）。我所熟悉的 BPMS 系统（该公司以数据库命名的系统出售的系统）提供的几乎所有“功能”（UI、集成等）都不值得我们付的钱。
如果您被迫使用 BPMS，作为开发人员，我的建议是在传统开发环境（例如 Java 或 .Net）中构建尽可能多的应用程序，在 BPMS 环境本身中构建尽可能少的内容，然后集成两个。 BPMS 中唯一应该包含的内容是使业务流程正常运行的最低要求。
In my experience the development environments provided by BPMS systems are third rate, unproductive, and practically force you to write hard to maintain, poorly designed code (due to their limitations). Almost all the "features" (UI, integrations, etc) provided by the BPMS system I'm familiar with (the one sold by that company named for its database) were not worth the money we paid.
If you're forced to use BPMS, as a developer, my advice would be to build as much of your application in a conventional development environment, such as Java or .Net, build as little as possible in the BPMS environment itself, and integrate the two. The only things that should go in the BPMS is the minimum to make the business process work.
不确定您到底问什么，但选择 BPM 与普通编程将取决于需求。 “业务流程”是软件工程中一个相对模糊的术语。
以下是评估您的需求的一些标准：
根据这些问题的答案，您可能会意识到您的流程更接近于简单状态图表一些可以按顺序执行的操作和决策，或者您可能意识到您需要更详细的东西，并且您不想自己重新实现所有这些。
在简单编程和成熟的BPM解决方案之间（例如Oracle BPM 套件，其中包含 BPEL、规则引擎等），还有中间解决方案，例如jBPM 或 Windows Workflow Foundation 以及可能还有很多其他的。这些中间解决方案通常是很好的权衡。
Not sure what exactly you ask, but the choice BPM vs. plain programming will depend on the requirements. A "business process" is a relatively vague term in software engineering.
Here are a few criterion to evaluate your needs:
Depending on the answer to these questions, you may realize that your process is closer to a simple state chart with a few actions and decisions that can be executed in a sequence, or you may realize that you need something more elaborated, and that you don't want to re-implement all that yourself.
Between plain programming and a full-fledge BPM solution (e.g. Oracle BPM suite which contains BPEL, rule engine, etc.), there are intermediate solutions such as jBPM or Windows Workflow Foundation and probably a lot of others. These intermediate solution are frequently good trade-off.
我过去曾与 Biztalk 合作过，最近又与 JBPM 合作过。我的观点对 BPM 有偏见，原因如下：
陡峭的学习曲线：为了使流程正常工作，我必须了解系统和编辑器的工作原理。对于开发人员来说，理解这个系统已经够困难的了，更不用说业务用户了。拖放和可视化表示是一个很棒的演示工具。它确实给经理留下了深刻的印象（他们最终为此付出了代价），但开发人员的生产力却下降了。
非开发人员改变工作流程：我还没有见过任何一个 BPM 解决方案能够完美地做到这一点。虽然它看起来不像代码，但右键单击该框，您必须输入一些代码，否则它将无法工作。所以你肯定需要一个开发人员来做这件事。最好的部分是，它既不适合开发人员，也不适合业务用户，而只是演示用户友好。
可测试性和重构：测试 BPMS 实际上是不可能的。您确实宣传了“单元测试框架”，但其中大多数都是黑客行为并且难以使用。最近我尝试了JBPM；我最终编写了大量粘合代码和伪造的工作流程处理程序以使其正常工作。但对我来说，最大的问题是重构。如果业务从根本上改变了对业务流程应该如何呈现的想法，那么重新排列盒子就祝你好运了，因为仅仅重新排列它们是行不通的，绑定到盒子的所有变量也需要重新排列。我更喜欢 IDE 和测试的强大功能来重构我的业务流程。
如果您的应用程序有工作流，那么您可以尝试工作流库（有或没有持久状态）。它仍然可以管理您的工作流程，而不会带来 BPM 带来的臃肿。如果业务用户需要理解代码，那么就让业务准备好的流程图并将其转化为好的领域驱动代码。使用黄瓜风格的验收测试将开发人员和业务人员结合在一起。 BPM 就是试图做太多事情但最终却做得很糟糕的东西。
I have worked with Biztalk in the past and more recently with JBPM. My opinion is biased against BPMs for the following reasons:
Steep learning curve : To make a process work, I have to understand how the system and the editor works. It is hard enough for a developer to understand the system, let alone a business user. The drag and drop and visual representation is a great demo tool. It certainly impresses managers (who ultimately pay for it), but a developer's productivity just drops.
Non developers changing the workflow : I haven't seen one BPM solution do it flawlessly. Though it doesn't look like code, right click on the box and you do have to put some code, otherwise it is not going to work. So you definitely need a developer to do it. The best part is that it is neither developer friendly nor business user friendly, just demo user friendly.
Testablity and refactoring : It is virtually impossible to test drive a BPMS. You do have 'unit test frameworks' advertised, but most of them are hacks and hard to use. Recently I tried the JBPM one; I ended up writing a lot of glue code and fake workflow handlers to make it work. The deal breaker for me though is refactoring. If the business radically changes it's mind about how a business process should look, then good luck re-arranging the boxes, because just re-arranging them won't work, all the variables bound to the boxes also need to be re-arranged. I would prefer the power of the IDE and tests to refactor my business process.
If your application has workflow, then you could try a workflow library (with or without persistent state). It will still manage your workflows without all the bloat that comes with a BPM. If a business user needs to understand the code, then let the business prepare good process flowcharts and translate them into good domain driven code. Use cucumber style acceptance tests to make bring the developers and business together. A BPM is just something that tries to do too many things and ends up doing all those things badly.
BPMS——很多常见的业务案例、用例已经实现。所以你只需要知道如何使用它。对于常见的工作流程，您甚至不需要编写一行代码，尽管大多数情况下您必须编写一些脚本来覆盖尚未实现的内容。
简单的编程——只需使用 IDE 来破解代码即可。积极的一面：更多的控制。负面的？很多时间都花在重写样板代码上。你必须维护它们。
简而言之，我更喜欢业务流程管理系统。我推荐的一个是 ProcessMaker。它具有直观的流程设计器，允许您通过拖放来设计工作流程。您始终可以编写触发器来扩展流程功能。它也是开源的。
BPMS-- a lot of common business case, use case are already implemented. So you just have to know how to use it. For common workflow, you don't even need to write a single line of code, though mostly you would have to write some scripts to cover things that are not yet implemented.
Plain programming-- just use the IDE to hack out the code. The positive side: more control. The negative? A lot of times are spent on rewriting boilerplate code. And you have to maintain them.
So in a nutshell, I would prefer a Business Process Management System. One that I would recommend is ProcessMaker. It features an intuitive process designer that allows you to design workflow with drag and drop. And you can always write trigger to extend the process functionalities. It's open source as well.