Activiti7 探索系列一部署和运行业务流程(二)

本文为翻译文章，如有不合理处请查看原文：https://community.alfresco.com/community/bpm/blog/2018/12/10/getting-started-with-activiti-7-beta，且此文章接Activiti7  探索系列一部署和运行业务流程(一)

安装并启用必要的软件

本节将介绍如何安装和启用所需的软件，特别是有关Kubernetes的软件

检查Docker版本

如开头所述，您需要拥有Docker安装程序。 但这还不是全部，你需要拥有Kubernetes附带的Docker版本。 您可以通过查看Docker安装的“关于”对话框来检查这一点，您应该看到如下内容：

该对话框应列出Kubernetes作为支持的软件（即在右下角）。 这意味着我们不需要在本地安装Kubernetes，例如Minikube，我们已经准备好将东西部署到我们的Docker安装提供的Kubernetes集群中。

这些本地Kubernetes部署将精确反映生产部署在AWS中的样子，这很好。

启用Kubernets

Docker for Desktop附带Kubernetes，但我们仍然需要启用它。 要执行此操作，请转到Docker首选项...，然后单击Kubernetes选项卡，您应该看到以下内容：

单击Enable Kubernetes，然后单击Kubernetes单选按钮。 如果我们没有专门选择Kubernetes，它默认运行Swarm。 单击“应用”以安装Kubernetes群集。 您应该在几分钟后看到以下配置对话框：

这意味着我们已准备好将内容部署到Kubernetes中。

现在检查您是否拥有正确的kubectl上下文。 我在我的Mac上运行minikube，如下我没有正确的上下文：

$ kubectl config current-context

Minikube

更改为Docker for Desktop上下文使用

$ kubectl config use-context docker-for-desktop

Switched to context "docker-for-desktop".

再次检查：

$ kubectl config current-context

docker-for-desktop

现在检查kubectl版本（不需要安装kubectl，它附带Docker）：

$ kubectl version

Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T10:09:24Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}

Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:05:37Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

您可能已经注意到我的服务器和客户端版本不同。 我使用的是先前手动安装的kubectl，服务器来自Docker for Desktop安装。

 

让我们获取一些关于Kubernetes集群的信息：

$ kubectl cluster-info

Kubernetes master is running at https://localhost:6443

KubeDNS is running at https://localhost:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

 

让我们看一下我们在集群中获得的节点

 

$ kubectl get nodes

NAME                 STATUS ROLES AGE       VERSION

docker-for-desktop   Ready master 1h        v1.10.3

 

我们还可以使用以下命令找出我们在Kubernetes系统中获得的POD：

$ kubectl get pods --namespace=kube-system

NAME                                         READY STATUS RESTARTS AGE

etcd-docker-for-desktop                      1/1 Running 0 1h

kube-apiserver-docker-for-desktop            1/1 Running 0 1h

kube-controller-manager-docker-for-desktop   1/1 Running 0 1h

kube-dns-86f4d74b45-4jw6f                    3/3 Running 0 1h

kube-proxy-zwwpx                             1/1 Running 0 1h

kube-scheduler-docker-for-desktop            1/1 Running 0 1h

Docker和Kubernetes配置内存

我们要部署的应用程序很可能需要比默认分配的内存更多的内存。 我将我的设置从4GB更新为7GB：

更新内存设置将重新启动Docker和Kubernetes，因此您必须等待一段时间才能继续下一步。

安装Kubernetes仪表板

我们在这里看不到的是Kubernetes Dashboard POD它是一个Webapp，在与Kubernetes工作时非常方便。我们可以使用此处提供的Kubernetes Dashboard YAML并将其提交给Kubernetes Master，如下所示：

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml

secret "kubernetes-dashboard-certs" created

serviceaccount "kubernetes-dashboard" created

role "kubernetes-dashboard-minimal" created

rolebinding "kubernetes-dashboard-minimal" created

deployment "kubernetes-dashboard" created

service "kubernetes-dashboard" created

再次检查POD：

$ kubectl get pods --namespace=kube-system

NAME                                         READY STATUS RESTARTS AGE

etcd-docker-for-desktop                      1/1 Running 0 1h

kube-apiserver-docker-for-desktop            1/1 Running 0 1h

kube-controller-manager-docker-for-desktop   1/1 Running 0 1h

kube-dns-86f4d74b45-4jw6f                    3/3 Running 0 1h

kube-proxy-zwwpx                             1/1 Running 0 1h

kube-scheduler-docker-for-desktop            1/1 Running 0 1h

kubernetes-dashboard-7b9c7bc8c9-d7dcz        0/1 ContainerCreating 0 39s

等待仪表板POD加载，您将STATUS视为正在运行。 从ContainerCreating更改为Running可能需要一些时间，所以请耐心等待。 一旦它处于运行状态，那么您可以设置到该特定Pod的转发端口。 我们将通过定义NodePort类型的服务以更永久的方式执行此操作，因此使用以下内容创建名为k8s-dashboard-nodeport-service.yaml的YAML文件：

 

请注意nodePort属性值31234，它是Kubernetes仪表板可用的外部端口（范围是30000-32767）

创建服务如下：

$ kubectl apply -f k8s-dashboard-nodeport-service.yaml

service "kubernetes-dashboard-nodeport" created

现在，通过https:// localhost:31234 /#!? login URL从浏览器访问仪表板。您将收到一些警告但继续操作，直到您看到以下对话框（如果您收到401未经过身份验证的错误，您可以从仪表板右上角的下拉菜单中访问此对话框）：

 

现在，您需要一个令牌才能登录。 您可以通过执行以下命令来实现：

 

单击对话框中的令牌单选按钮，然后将令牌复制并粘贴到下面的字段中。 然后单击SIGN IN按钮，这将导致仪表板如下所示：

单击节点，您将看到单个Kubernetes节点，如下所示：

安装Helm

Helm软件包管理器将用于将容器解决方案（例如Activiti 7）部署到Kubernetes集群。 它由客户端和服务器组成。 在此处为您的操作系统找到合适的安装包

Tiller是Helm的服务器部分，通常在您的Kubernetes集群内部运行。 将分蘖安装到集群中的最简单方法就是运行helm init。 这将验证是否正确设置了helm的本地环境（并在必要时进行设置）。 然后它将连接到kubectl默认连接的任何集群。 连接后，它会将分蘖安装到kube-system名称空间中。

我按如下方式进行了群集内安装：

查看Tiller 运行：

添加Activiti 7 Helm存储库

添加Activiti Helm存储库，以便我们可以提取Activiti 7 Charts并部署Activiti 7应用程序。

列出您有权访问的helm存储库，如下所示：

要查看可用的charts，请执行以下搜索：

我们可以在上面的列表中看到，我们可以访问所有Activiti 7 Cloud应用程序charts，包括我们将稍微部署的activiti-cloud-full-example。

Activiti 7概述

Activiti 7实现为Cloud Native应用程序，其针对不同云服务的主要抽象层（如消息队列和服务注册表）是Spring Cloud框架。 通过使用它，Activiti团队不必重新发明并为云服务提出新的抽象层。

为了支持全球扩展，Activiti团队选择了Kubernetes容器编排引擎。 Kubernetes受到主要云提供商的支持，例如亚马逊和谷歌

可以使用以下图片描述Activiti 7基础架构：

基础设施中的不同构建块可以解释为：

Activiti Keycloak –SSO-单点登录所有服务

Activiti Keycloak - IDM -身份管理因此Activiti知道组织结构是什么样的，团体和用户是谁，谁被允许做什么

Activiti Modeler - BPMN 2.0建模应用程序，开发人员可以使用一个或多个流程定义定义新流程应用程序

API Gateway-给用户提供接口允许其他系统访问流程应用程序

Service Registry 一个服务注册表，允许所有服务和应用程序注册并以动态方式发现。

Config Server-可供所有其他服务使用的集中式和分布式配置服务。

Zipkin -是一种分布式跟踪系统。 它有助于收集解决微服务架构中的延迟问题所需的时序数据。

Activity application-每个应用程序代表一个或多个业务流程实现。 因此，一个应用程序可以是作业应用程序的HR流程，而另一个应用程序可以用于贷款应用程序。 云连接器用于在业务流程之外进行调用

更具体地说，An Activiti 7应用程序包含以下服务：

Runtime bundles-将为不同的业务模型提供不同的运行时。第一个可用的运行时用于业务流程。Process Runtime可与之前称为Activiti Process Engine相似。 运行时尽可能小且高效。 运行时捆绑包包含许多流程定义，并且是不可变的。 这意味着它将只运行许多不可变的流程定义（实例）

Query Service-用于聚合数据，并以有效的方式使用数据。 Activiti应用程序中可能有多个运行时捆绑包，查询服务将汇总其中的每个数据库

Notification Service-可以提供有关不同运行时捆绑包中发生的情况的通知。

Audit Service-这是你在BPM系统中的标准审计日志，它提供了执行进程时确切发生的事件的日志

Cloud Connectors-关于系统到系统的交互。 它现在不是将所有代码都与流程定义实现和流程运行时中的外部系统进行对话，而是将其解耦并作为具有单独SLA的单独服务实现。一个服务任务通常将实现为云连接器

部署和运行业务流程

本节将向您展示如何使用Helm和Kubernetes使用Activiti 7产品部署和运行业务流程。 我们不会开发任何新流程，只需通过使用提供的示例了解Activiti 7的工作原理。 请注意，Activiti 7没有附带UI，这意味着您必须通过ReST API与系统进行交互

为此，我们将使用开箱即用的其中一个示例。 Activiti 7 Full Example完整示例，它包含符合Activiti 7应用程序的所有构建块，例如

1. API Gateway (Spring Cloud)
2. SSO/IDM (Keycloak)
3. Activiti 7 Runtime Bundle (Example)
4. Activiti 7 Cloud Connector (Example)
5. Activiti 7 Query Service
6. Activiti 7 Audit Service

下图说明：

实际的示例流程定义包含在所谓的Runtime Bundle，服务任务实现和监听器实现包含在所谓的Cloud Connector，在这种情况下，客户端只能通过Postman集合于与服务进行交互。 Activiti 7 Beta目前没有进程和任务管理用户界面。

Activiti Modeler应用程序可以与示例的其余部分同时部署，但您需要手动启用它，因为默认情况下它不可用。

Activiti 7应用程序部署创建Kubernetes命名空间

我们将为Activiti 7应用程序部署创建一个单独的命名空间。 这意味着我们在此命名空间内使用的任何名称都不会与其他命名空间中的相同名称冲突

检查我们现在拥有的命名空间：

安装Ingress控制器以在外部公开服务

在我们开始安装Activiti 7组件之前，我们需要安装Ingress，前端，代理，网关或任何您想要调用的内容，以便在外部公开所有Activiti 7 Kubernetes服务。 如果使用通配符DNS公开服务并且在安装之前将DNS映射到Ingress，则Activiti示例安装过程会更简单。

在我们安装Ingress之前，更新本地helm Charts repo / cache总是一个好主意,确保我们不使用旧版本的Chart：

要安装Ingress，我们安装一个名为Kubernetes Ingress Controller的东西，它会自动创建我们想要公开的内部服务的路由。 运行以下命令：

$ helm install stable/nginx-ingress --namespace=activiti7

NAME:   intent-deer

E1119 07:45:11.270800   52554 portforward.go:303] error copying from remote stream to local connection: readfrom tcp4 127.0.0.1:61100->127.0.0.1:61103: write tcp4 127.0.0.1:61100->127.0.0.1:61103: write: broken pipe

LAST DEPLOYED: Mon Nov 19 07:45:10 2018

NAMESPACE: activiti7

STATUS: DEPLOYED

RESOURCES:

==> v1/ConfigMap

NAME                                  DATA AGE

intent-deer-nginx-ingress-controller  1 0s

==> v1/ServiceAccount

NAME                       SECRETS AGE

intent-deer-nginx-ingress  1 0s

==> v1beta1/ClusterRole

NAME                       AGE

intent-deer-nginx-ingress  0s

==> v1beta1/PodDisruptionBudget

NAME                                       MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS  AGE

intent-deer-nginx-ingress-controller       1 N/A 0          0s

intent-deer-nginx-ingress-default-backend  1 N/A 0          0s

==> v1/Pod(related)

NAME                                                        READY STATUS RESTARTS AGE

intent-deer-nginx-ingress-controller-9b5fb9b4f-4985v        0/1 ContainerCreating 0 0s

intent-deer-nginx-ingress-default-backend-6f7884d594-85dph  0/1 ContainerCreating 0 0s

==> v1beta1/ClusterRoleBinding

NAME                       AGE

intent-deer-nginx-ingress  0s

==> v1beta1/Role

NAME                       AGE

intent-deer-nginx-ingress  0s

==> v1beta1/RoleBinding

NAME                       AGE

intent-deer-nginx-ingress  0s

==> v1/Service

NAME                                       TYPE CLUSTER-IP EXTERNAL-IP PORT(S)                     AGE

intent-deer-nginx-ingress-controller       LoadBalancer 10.98.10.209 80:30006/TCP,443:30107/TCP  0s

intent-deer-nginx-ingress-default-backend  ClusterIP 10.111.24.254 80/TCP                      0s

==> v1beta1/Deployment

NAME                                       DESIRED CURRENT UP-TO-DATE AVAILABLE AGE

intent-deer-nginx-ingress-controller       1 1 1 0 0s

intent-deer-nginx-ingress-default-backend  1 1 1 0 0s

 

NOTES:

The nginx-ingress controller has been installed.

It may take a few minutes for the LoadBalancer IP to be available.

You can watch the status by running 'kubectl --namespace activiti7 get services -o wide -w intent-deer-nginx-ingress-controller'

An example Ingress that makes use of the controller:

 apiVersion: extensions/v1beta1

 kind: Ingress

 metadata:

   annotations:

     kubernetes.io/ingress.class: nginx

   name: example

   namespace: foo

 spec:

   rules:

     - host: www.example.com

       http:

         paths:

           - backend:

               serviceName: exampleService

               servicePort: 80

             path: /

   # This section is only required if TLS is to be enabled for the Ingress

   tls:

       - hosts:

           - www.example.com

         secretName: example-tls

If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:

 apiVersion: v1

 kind: Secret

 metadata:

   name: example-tls

   namespace: foo

 data:

   tls.crt:

   tls.key:

 type: kubernetes.io/tls

通过创建Ingress Controller，可以稍后从群集外部访问服务。 要通过Ingress Controller访问任何内容，我们需要找到它的IP地址：

在这种情况下，外部IP地址是localhost，这意味着IP 127.0.0.1。 我们不能使用localhost，因为它在Docker容器内外都不起作用。 我们将使用主机的IP和公共nip.io服务进行DNS。

请注意，您可能需要多次运行kubectl get services ...直到您可以看到Ingress Controller的EXTERNAL-IP。 如果看到PENDING，请等待几秒钟再次运行命令

克隆Activiti 7 Helm Charts源代码

对于完整的示例，我们需要在Helm charts中做一些更改，因此让我们克隆源代码，如下所示：

这将克隆所有Activiti 7示例的Helm Chart源代码

实例配置

下一步是参数化完整示例部署。 可以自定义Helm Chart以打开和关闭完整示例中的不同功能，但是需要提供一个必需参数，即此安装将使用的Ingress Controller的外部IP地址。

当我们在本地运行时，我们需要找出当前的IP地址。 我们不能使用localhost（127.0.0.1），因为容器无法相互通信，例如与Keycloak容器通信的Runtime Bundle容器。 因此，例如，通过以下方式查找IP：

确保这不是桥接IP地址。 在做ifconfig时寻找像en0这样的东西。

已自定义配置在位于 https://github.com/Activiti/activiti-cloud-charts/blob/master/activiti-cloud-full-example/values.yaml的values.yaml文件（您可以复制此 提交或直接更改）。 我们可以在之前克隆的Helm Chart源代码中更新此文件。

打开activiti-cloud-charts / activiti-cloud-full-example / values.yaml文件，将字符串REPLACEME替换为10.244.50.42.nip.io，这是Ingress Controller的EXTERNAL IP。 我们使用nip.io作为DNS服务将我们的服务映射到此外部IP，该IP将遵循以下格式： .nip.io。

 注意!确保你能够ping同你地址（如这里的10.244.50.42.nip.io）

如果这不起作用，那么您的路由器可能会遇到DNS重新绑定保护问题。查看更多信息

如上所述，需要手动启用Activiti BPMN Modeler应用程序。 因此，将以下值更改为true：

你应该得到一个类似这样的文件（注意。我删除了所有被注释掉的东西）：

global:
 keycloak:
 url: "http://activiti-keycloak.10.244.50.42.nip.io/auth"
 gateway:
 host: &gatewayhost "activiti-cloud-gateway.10.244.50.42.nip.io"

activiti-cloud-modeling:
 enabled: true

application:
 runtime-bundle:
 enabled: true
 image:
 pullPolicy: Always

 activiti-cloud-query:
 image:
 pullPolicy: Always

 activiti-cloud-connector:
 enabled: true
 image:
 pullPolicy: Always

 activiti-cloud-audit:
 image:
 pullPolicy: Always

infrastructure:
 activiti-keycloak:
 keycloak:
 enabled: true
 keycloak:
 ingress:
 enabled: true
 path: /
 proxyBufferSize: "16k"
 hosts:
 - "activiti-keycloak.10.244.50.42.nip.io"
 annotations:
 kubernetes.io/ingress.class: nginx
 nginx.ingress.kubernetes.io/rewrite-target: /
 nginx.ingress.kubernetes.io/configuration-snippet: |
 more_set_headers 'Access-Control-Allow-Methods: "POST, GET, OPTIONS, PUT, PATCH, DELETE"';
 more_set_headers 'Access-Control-Allow-Credentials: true';
 more_set_headers 'Access-Control-Allow-Headers: "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,authorization"';
 more_set_headers 'Access-Control-Allow-Origin: $http_origin';
 nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
 preStartScript: |
 /opt/jboss/keycloak/bin/add-user.sh -u admin -p admin
 /opt/jboss/keycloak/bin/add-user-keycloak.sh -r master -u admin -p admin
 cp /realm/activiti-realm.json .
 sed -i 's/placeholder.com/*/g' activiti-realm.json

 activiti-cloud-gateway:
 ingress:
 enabled: true
 hostName: *gatewayhost
 annotations:
 kubernetes.io/ingress.class: nginx
 nginx.ingress.kubernetes.io/rewrite-target: /
 nginx.ingress.kubernetes.io/enable-cors: true
 nginx.ingress.kubernetes.io/cors-allow-headers: "*"
 nginx.ingress.kubernetes.io/x-forwarded-prefix: true

那么我们将使用此配置部署什么？ 下图说明：

我们可以在这里看到所有内容都是通过Ingress控制器10.244.50.42.nip.io访问的。 然后，您只需在其前面添加服务名称即可访问API网关和Keycloak服务。

部署示例

当我们自定义完整示例Helm Chart的配置时，我们准备通过运行以下命令来部署。 但是，在执行此操作之前，更新本地helm chart repo / cache总是一个好主意，确保我们使用最新版本：

现在，请确保在的本地正确项目目录下进行values.yaml文件的修改，然后按如下方式进行安装：

这将基于来自Activiti 7 Helm chart仓库的远程activiti-cloud-charts / activiti-cloud-full-example Helm chart以及本地values.yaml文件中的自定义配置安装完整示例。

现在，等待所有服务启动并运行，检查pod如下：

注意READY列，它应该在我们继续之前在所有pod中显示1/1。 如果某些pod没有启动，那么在Kubernetes Dashboard中查看它会很有用。 选择activiti7命名空间，然后单击Pods：

在这种情况下，我们可以看到没有足够的内存来加载所有pod。 如果您发现内存不足错误，则需要增加在Docker for Desktop中运行的Kubernetes的可用内存（首选项... |高级|内存）。 你还会看到很多这些准备”探测失败......”错误。 它们最终会消失，但需要5-10分钟。

一切顺利完成后，您应该在一段时间后看到以下内容：

我们还可以通过选择Cluster |nodes|docker-for-desktop来检查Kubernetes的状态：

重要的是要注意Helm创建了Chart的版本。 因为我们没有为这个版本指定一个名字Helm选择一个随机名称，在我的例子中是ignorant-bunny。 这意味着我们可以独立于我们执行的其他部署来管理此版本。

你可以运行helm ls 查看所有部署的应用：

要删除版本，请执行helm delete

检查可用的用户和组

在我们开始与已部署的示例应用程序进行交互之前，让我们看看我们在Keycloak中可用的用户和组。 这些可以在流程定义中使用，也可以在我们与应用程序交互时使用，访问以下URL（http://activiti-keycloak.10.244.50.42.nip.io/auth/admin/master/console）上的Keycloak管理控制台，登陆使用admin/admin,你就可以看到一个主页，例如：

在此页面中，我们可以访问左下角“管理”部分下的用户和组。 但首先请注意，已经有一个名为activiti的安全领域设置。 我们将稍微使用它。 还有一个Activiti客户端设置和以下角色：

ACTIVITI_ADMIN和ACTIVITI_USER角色非常重要，因为它们告诉Activiti 7用户可以访问的核心API的哪个部分。 在下一节中，我们将使用建模器用户登录Activiti Modeler，它是ACTIVITI_MODELER角色的成员，现在，单击Users |view all users，以便我们可以查看访问应用程序时必须使用的用户类型：

因此，有几个自定义用户配置。 我们可以使用例如testuser，因为它具有ACTIVITI_USER应用的角色：

现在，让我们继续看看我们如何与已部署的Activiti 7应用程序进行交互。 但首先，我们只是验证我们运行的Activiti BPMN Modeler应用程序。

快速浏览Activiti 7 Modeler

让我们快速浏览一下新的Activiti 7 Modeler。 所以我们可以确保它已经正确部署。 您可以通过http://activiti-cloud-gateway.10.244.50.42.nip.io/activiti-cloud-modeling URL访问BPMN Modeler应用程序。 使用modeler/password，因为此用户是ACTIVITI_MODELER角色的一部分，您现在应该看到：

到目前为止一切都很好，让我们创建一个Process Application，以确保它一直有效。 单击“Create new|Application” 并给它起名称和描述：

测试并验证环境设置

我们可以使用curl进行快速测试，以验证是否已正确部署Activiti 7完整示例。首先，从Keycloak请求testuser的访问令牌：

现在，使用此访问令牌为已部署的流程定义调用Runtime Bundle：

它完全正常工作，我们得到了一堆已经部署在Runtime Bundle中的流程定义。 我们现在可以通过启动流程实例等来进一步探索Runtime Bundle。

示例进行交互

所以现在部署了完整示例应用程序，但是如何与它进行交互以启动进程并为其管理任务？ 没有UI，但我们可以使用Postman Collection，它与完整示例的源代码一起提供，克隆下面的项目：

（确保获得主分支，否则我们将设置的环境变量不匹配）

在Postman中导入集合如下。 选择File|Import...如下图：

单击选择文件，然后导航并从我们刚刚克隆的项目中选择以下文件（即Activiti v7 REST API.postman_collection.json）：

在调用任何服务之前，您需要在Postman中创建一个新的环境。 您可以通过转到Manage Environment图标（右上角的齿轮）来完成此操作：

在“管理环境”中，单击“添加”按钮以添加新环境。 给它命名，如Activiti 7.然后为环境配置以下变量：gatewayUrl（value = activiti-cloud-gateway.10.244.50.42.nip.io），idmUrl（value = activiti-keycloak.10.244.50.42.nip .io）和realm（value = activiti）：

单击“添加”以添加此新的Activiti 7环境。 您将从我们在部署应用程序之前配置的values.yaml文件中识别的gatewayUrl和idmUrl变量值。 Keycloak 的realm预先配置为activiti。确保在右上角的下拉列表中选择环境。 另外，选择我们导入的集合：

为了能够进行任何ReST调用，我们需要从Keycloak获取访问令牌。 如果你转到Postman集合中的keycloak文件夹并选择getKeycloakToken，你将获得一个访问令牌：

您可以在此处看到如何在POST URL中使用环境变量（即{{idmUrl}} / auth / realms / {{realm}} / protocol / openid-connect / token）。 单击“发送”按钮进行ReST请求：

返回的访问令牌将用于验证进一步的请求。 查看Tests选项卡，您将看到一个脚本，用于设置访问令牌变量（即kcAccessToken），然后由其他ReST调用使用：

请注意，此令牌是时间敏感的，并且它会在某些时候自动失效，因此如果您开始收到未经授权的错误，可能需要再次请求它（您将在屏幕中间右侧看到401 Unauthorized错误）。

一旦我们获得了用户的令牌，我们就可以与所有用户端点进行交互。 例如，我们可以调用ReST调用来查看在Example Runtime Bundle（rb-my-app / getProcessDefinitions）中部署的Process Definitions：

现在，让我们使用其中一个流程定义启动流程实例。 如果我们查看Example Runtime Bundle的源代码，我们可以看到部署了许多流程定义，例如：

1. ConnectorProcess.bpmn20.xml  - 将服务任务实现为云连接器的流程
2. SignalCatchEventProcess.bpmn20.xml  - 等待事件的进程
3. SignalThrowEventProcess.bpmn20.xml  - 向外部服务发送消息的过程，类似于服务任务
4. Simple subprocess.bpmn20.xml  - 使用用户任务处理。 可以用作子进程
5. Subprocess Parent.bpmn20.xml  - 包含子流程的父流程
6. SimpleProcess.bpmn20.xml  - 用户任务的简单过程
7. SubProcessTest.fixSystemFailureProcess.bpmn20.xml  - 显示子进程使用情况的另一个进程
8. processWithVariables.bpmn20.xml  - 处理用户任务和流程变量

我们将使用具有一个User任务的SimpleProcess。 要基于此流程定义启动流程实例，我们可以使用rb-my-app文件夹中的startProcess Postman请求。 此请求定义为{{gatewayUrl}} / rb-my-app / v1 / process-instances POST ReST调用。 它专门针对由/ rb-my-app URL路径标识的Runtimes Bundle

单击“发送”按钮（但请确保您首先拥有有效的访问令牌，否则您将看到401未授权状态）。 您应该获得有关新流程实例的信息的响应：

接下来要做的就是列出活动任务。 我们可以使用getTasks请求来做到这一点。 它使用{{gatewayUrl}} / rb-my-app / v1 / tasks？page = 0＆size = 10 URL，该URL与rb-my-app Runtime bunlde相关联。 如果我们在rb-my-app文件夹中运行getTasks请求，我们应该会看到如下响应：

我们可以在这里看到任务的ID，它是ba485a1c-ec07-11e8-9efc-069f25afb347。 我们应该能够使用它来认领任务（我们需要在完成它之前认领它，因为它是一个池化任务）。 使用claimTask POST请求使用id为用户声明任务

在这里，我使用任务ID将URL更新为http：// {{gatewayUrl}} / rb-my-app / v1 / tasks / ba485a1c-ec07-11e8-9efc-069f25afb347 / claim？assignee = hruser。 该任务现在已分配给hruser，并且可由该用户使用completeTask请求完成，如下所示：

在这里，我还更新了URL以包含任务ID：{{gatewayUrl}} / rb-my-app / v1 / tasks / ba485a1c-ec07-11e8-9efc-069f25afb347 / complete。

这结束了交互式部分，我们通过其ReST API与运行时包进行通信。 如果您想知道如何在不使用Postman的情况下访问完整的ReST API，那么可以通过以下URL实现：http：//activiti-cloud-gateway.10.244.50.42.nip.io/rb-my-app /swagger-ui.html：

您可能还想查看审计和查询服务。在下一篇文章中，我们将使用Activiti Modeler来定义自定义流程定义。