服务API
Java API是与业务系统引擎进行交互的最常见方式。中心起点是ProcessEngine，可以按照配置部分中所述的几种方法创建它。从ProcessEngine，您可以获得包含工作流/ BPM方法的各种服务。ProcessEngine和服务对象是线程安全的。因此，您可以为整个服务器保留对其中之一的引用。
ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine();
RepositoryService repositoryService = processEngine.getRepositoryService();
RuntimeService runtimeService = processEngine.getRuntimeService();
TaskService taskService = processEngine.getTaskService();
IdentityService identityService = processEngine.getIdentityService();
FormService formService = processEngine.getFormService();
HistoryService historyService = processEngine.getHistoryService();
ManagementService managementService = processEngine.getManagementService();
FilterService filterService = processEngine.getFilterService();
ExternalTaskService externalTaskService = processEngine.getExternalTaskService();
CaseService caseService = processEngine.getCaseService();
DecisionService decisionService = processEngine.getDecisionService();
ProcessEngines.getDefaultProcessEngine()会在首次调用时初始化并构建一个流程引擎，此后始终返回相同的流程引擎。可以使用ProcessEngines.init()和正确创建和关闭所有流程引擎ProcessEngines.destroy()。
ProcessEngines类将扫描所有camunda.cfg.xml和activiti.cfg.xml和pangu.cfg.xml文件。对于所有pangu.cfg.xml文件，将以典型方式构建流程引擎：
ProcessEngineConfiguration
.createProcessEngineConfigurationFromInputStream(inputStream)
.buildProcessEngine()
对于所有activiti.cfg.xml文件，将以Spring方式构建流程引擎：首先创建Spring应用程序上下文，然后从该应用程序上下文中获取流程引擎。
所有服务都是无状态的。这意味着您可以轻松地在集群中的多个节点上运行盘古BPM，每个节点都访问同一数据库，而不必担心哪台计算机实际执行了先前的调用。无论在何处执行，对任何服务的任何调用都是幂等的。
该RepositoryService这是使用盘古BPM引擎时所需的第一项服务。此服务提供用于管理和操纵部署和流程定义的操作。此处无需赘述，流程定义是BPMN 2.0流程的Java对应项。它代表了流程中每个步骤的结构和行为。部署是引擎内包装的单位。一个部署可以包含多个BPMN 2.0 XML文件和任何其他资源。一个部署中包含哪些内容的选择取决于开发人员。它的范围可以从单个流程BPMN 2.0 XML文件到整个流程包和相关资源（例如，部署“ hr-processes”可以包含与hr流程相关的所有内容）。RepositoryService允许部署此类软件包。部署部署意味着将其上载到引擎，在这里将检查并解析所有进程，然后再将它们存储在数据库中。从那时起，系统便知道该部署，并且现在可以启动该部署中包括的任何过程。
此外，这项服务还可以
1、查询引擎已知的部署和流程定义。
2、挂起并激活流程定义。挂起表示无法对其进行进一步的操作，而激活是相反的操作。
3、检索各种资源，例如部署中包含的文件或引擎自动生成的流程图。
尽管RepositoryService涉及静态信息（即不变的数据，或至少没有很多变化的数据），但RuntimeService却相反。它处理启动流程定义的新流程实例。如上所述，过程定义定义了过程中不同步骤的结构和行为。流程实例是这种流程定义的一种执行。对于每个流程定义，通常有多个实例同时运行。RuntimeService还是用于检索和存储过程变量的服务。这是特定于给定流程实例的数据，并且可由流程中的各种构造使用（例如，专用网关通常使用流程变量来确定选择哪个路径来继续该流程）。RuntimeService还允许查询流程实例和执行。执行是BPMN 2.0的“令牌”概念的表示。基本上，执行是指向流程实例当前所在位置的指针。最后，只要流程实例正在等待外部触发器并且需要继续流程，就使用RuntimeService。一个流程实例可以具有各种等待状态，并且该服务包含各种操作以“信号”该实例，即接收到外部触发器并且可以继续该流程实例。
需要由系统的实际人类用户执行的任务是流程引擎的核心。任务周围的所有内容都分组在TaskService中，例如
1、查询分配给用户或组的任务。
2、创建新的独立任务。这些是与流程实例无关的任务。
3、操纵任务分配给哪个用户或该任务涉及某种用户。
4、声明并完成任务。声明是指某人决定担任该任务的受让人，这意味着该用户将完成任务。完成意味着“完成任务的工作”。通常，这是一种形式的填充。
该IdentityService是非常简单的。它允许对组和用户进行管理（创建，更新，删除，查询等）。重要的是要了解，核心引擎实际上在运行时不对用户进行任何检查。例如，可以将任务分配给任何用户，但是引擎不会验证系统是否知道该用户。这是因为引擎也可以与LDAP，Active Directory等服务结合使用。
该FormService是一个可选的服务。这意味着盘古BPM引擎在没有它的情况下可以完美使用，而不会牺牲任何功能。该服务介绍了启动表单和任务表单的概念。起始表单是在流程实例启动之前向用户显示的表单，而任务表单是在用户想要填写表单时显示的表单。您可以在BPMN 2.0流程定义中定义这些形式。该服务以一种简单的方式公开此数据。但是，这又是可选的，因为表单不需要嵌入流程定义中。
该HistoryService暴露了发动机收集的所有历史数据。在执行流程时，引擎可以保存很多数据（这是可配置的），例如流程实例的启动时间，谁执行了哪些任务，完成任务所花的时间，每个流程实例遵循的路径等。 。该服务主要公开查询功能以访问此数据。
对定制应用程序进行编码时，通常不需要ManagementService。它允许检索有关数据库表和表元数据的信息。此外，它公开了作业的查询功能和管理操作。引擎中的作业用于各种事情，例如计时器，异步继续，延迟的挂起/激活等。稍后，将更详细地讨论这些主题。
该FilterService允许创建和管理过滤器。过滤器是存储的查询，例如任务查询。例如，任务列表使用过滤器来过滤用户任务。
该ExternalTaskService可以访问外部任务实例。外部任务表示在外部独立于流程引擎处理的工作项。
CaseService就像RuntimeService但对于案件的情况。它处理启动案例定义的新案例实例并管理案例执行的生命周期。该服务还用于检索和更新案例实例的过程变量。
DecisionService允许评估部署到发动机的决定。另一种方法是在业务规则任务中评估独立于流程定义的决策。