背景：
为什么学习camunda，公司原有的定制化流程审批系统在设计之初和市面上许多低代码平台一样做了许多定制化的需求，但不同的是没有使用常见的流程引擎，而是在表设计和流程节点设计等方面使用固定值，提前固定配置好流程各节点信息和对应表单。这使得流程配置不够灵活和可复用，同时复杂的表设计也让处理人员查询流程任务耗时较长。而出于预算也不使用低代码平台，于是我收到了调研流程引擎以及兼容现有系统的需求。
为什么使用camunda
其实市面上常见流行的流程引擎都是同根同源，也就是jbpm框架。常见的activi、flowable、camunda如网上流传都是初创的技术大佬自立门户重新开发的。这几个框架的对比我就不重复了，基本上任一介绍的帖子都有详细对比，我也是根据这些帖子的介绍选择了功能最丰富和理论性能最快的camunda进行调研，同时其他同事也对另外几个框架做了调研工作，也许是我的调研报告和演示demo做的比较好吧，并且camunda也确实没有太多可挑剔的地方，最后大家投票通过了使用camunda做兼容的决定。例举一篇对比的帖子。https://cloud.tencent.com/developer/article/2088469?from=15425
学习路线
直接百度搜索camunda很容易找到大量学习笔记的帖子，也很容易搜到英文原版camunda官网，如果尝试阅读英文文档不仅非常容易头痛，也很容易对那些指导的demo、学习笔记一头雾水，也不推荐0基础的直接拉github上成熟的camunda项目，层层封装的业务也许让功能变得容易实现但对于熟悉框架基础并无益处，因为我就是这么干的。
这是camunda官网的中文版翻译，本来以为只是翻译成中文，仔细阅读后发现译者不仅做了通俗易懂人性化的翻译，还非常友好对入门的新手准备了入门教程。
http://camunda-cn.shaochenfeng.com/
从项目下载、编辑bpmn流程图到rest api使用、发起完成流程都有详细图示指导，网上许多入门帖子也是引用的这里，向原创的大佬致敬。
基本上跟随教程学习完入门实例，对camunda就有初步认识了，我当时对它的印象就是经典的工作流审批引擎，而且功能比较“基础”，实际上是因为国内外的工作流差异太大，但基本上国内公司审批用到的功能都能通过camunda的基础拓展出来，例如会签、或签、加签、撤销、定时，只是需要做一些适配，而我接下来就要用camunda模拟一个现有的系统里的流程，顺便一提在写下这篇文章的时候我已经顺利完成了模拟任务。
后续的笔记里会记录一些使用的技巧和踩过的坑。
