4 Workflow Designer is a [pluggable SDC designer](https://wiki.onap.org/display/DW/Generic+Designer+Support) that allows
5 a user to design a workflow, save it, and attach it to a SDC service as an artifact. Workflow Designer also manages
6 the definitions of activities, which can be later used as parts of the designed workflows.
11 The designer is comprised of the following deployment units:
13 - Designer backend is the core component. It exposes RESTful APIs for managing workflow and activity data. The backend
14 is agnostic to the type of a workflow artifact — its main concerns are workflow inputs and outputs, and metadata.
15 One of the APIs enables to attach a certified workflow artifact to a SDC service, therefore the designer must be able
16 to call an API on SDC. In order to do so, the location of a SDC server, and
17 [SDC consumer](https://wiki.onap.org/display/DW/Consumer+creation) credentials are required.
19 - Designer frontend serves static content of a Web application for creating and managing workflows, and forwards API
20 requests to the backend. The static content includes JavaScript, images, CSS, etc. A major part of the Web application
21 is Workflow Composition View — a graphical interface for arranging a workflow sequence. The Web application also
22 produces a workflow artifact that will be sent to the backend, saved along with other data, and later used by a
23 service. The architecture allows for different implementations of the frontend component. For example, a different
24 technology can be used for the Composition View, which will probably also result in a different type of the artifacts
25 (e.g. Bpmn.io vs. Camunda).
27 - Cassandra database is used by the designer backend as the main storage for workflow data. A dedicated instance of
28 Cassandra can be deployed, or an existing cluster may be used.
30 - Database initialization scripts run once per deployment to create the necessary Cassandra keyspaces and tables,
31 pre-populate data, etc.
36 The procedure below describes manual deployment on plain Docker for development or a demo.
40 Create a dedicated instance of Cassandra. This step is optional if you already have a Cassandra cluster.
41 The designer is not expected to have problems working with Cassandra 3.x, but has been tested with 2.1.x because this
42 is the version used by SDC.
44 An easy way to spin up a Cassandra instance is using a Cassandra Docker image as described in the
45 [official documentation](https://hub.docker.com/_/cassandra/).
49 `docker run -d --name workflow-cassandra cassandra:2.1`
51 ## 2. Database Initialization
53 **WARNING**: *This step must be executed only once.*
55 Workflow Designer requires two Cassandra namespaces:
60 By default, these keyspaces are configured to use a simple replication strategy (`'class' : 'SimpleStrategy'`)
61 and the replication factor of one (`'replication_factor' : 1`). In order to override this configuration, override
62 the *create_keyspaces.cql* file at the root of the initialization container using
63 [Docker volume mapping](https://docs.docker.com/storage/volumes/). Include `IF NOT EXISTS` clause in the keyspace
64 creation statements to prevent accidental data loss.
66 `docker run -ti -e CS_HOST=<cassandra-host> -e CS_PORT=<cassandra-port> -e CS_AUTHENTICATE=true/false
67 -e CS_USER=<cassandra-user> -e CS_PASSWORD=<cassandra-password> nexus3.onap.org:10001/onap/workflow-init:latest`
69 ### Environment Variables
71 - CS_HOST — Cassandra hostname or IP address.
73 - CS_PORT — Cassandra Thrift client port. If not specified, the default of 9160 will be used.
75 - CS_AUTHENTICATE — whether password authentication must be used to connect to Cassandra. A *false* will be
76 assumed if this variable is not specified.
78 - CS_USER — Cassandra username if CS_AUTHENTICATE is *true*.
80 - CS_PASSWORD — Cassandra password if CS_AUTHENTICATE is *true*.
84 Assuming you have created a dedicated Cassandra container as described in Database section, and the access to it is not
85 protected with a password, the following command will initialize the database:
87 `docker run -d --name workflow-init
88 -e CS_HOST=$(docker inspect workflow-cassandra --format={{.NetworkSettings.IPAddress}})
89 nexus3.onap.org:10001/onap/workflow-init:latest`
93 In order to see if the Workflow Designer was successfully initialized, make sure the console does not contain error
94 messages. You can also see the logs of the initialization container using `docker logs workflow-init` command.
98 `docker run -d -e SDC_PROTOCL=http/https -e SDC_ENDPOINT=<sdc-host>:<sdc-port> -e SDC_USER=<sdc-username>
99 -e SDC_PASSWORD=<sdc-password> -e CS_HOSTS=<cassandra-hosts> -e CS_PORT=<cassandra-port>
100 -e CS_AUTHENTICATE=true/false -e CS_USER=<cassandra-user> -e CS_PASSWORD=<cassandra-password>
101 -e CS_SSL_ENABLED=true/false --volume <cassandra-truststore-path_container>:<cassandra-truststore-path_local>
102 -e CS_TRUST_STORE_PATH=<cassandra-truststore-path_container> -e CS_TRUST_STORE_PASSWORD=<cassandra-truststore-password>
103 -e SERVER_SSL_ENABLED=true/false -e SERVER_SSL_KEY_PASSWORD=<ssl_key_password>
104 -e SERVER_SSL_KEYSTORE_PATH=<ssl_keystore_path> -e SERVER_SSL_KEYSTORE_TYPE=<ssl_keystore_type>
105 -e JAVA_OPTIONS=<jvm-options> nexus3.onap.org:10001/onap/workflow-backend:latest`
107 ### Environment Variables
109 - SDC_PROTOCOL — protocol to be used for calling SDC APIs (http or https).
111 - SDC_ENDPOINT — the base path of SDC external API, in the format `host:port`, where *host* is a SDC backend
112 server, and *port* is usually 8080.
114 - SDC_USER — Workflow consumer username
116 - SDC_PASSWORD — Workflow consumer password
118 - CS_HOSTS — comma-separated list of Cassandra hostnames or IP addresses.
120 - CS_PORT — CQL native client port. If not specified, the default of 9042 will be used.
122 - CS_AUTHENTICATE — whether password authentication must be used to connect to Cassandra. A *false* will be
123 assumed if this variable is not specified.
125 - CS_USER — Cassandra username if CS_AUTHENTICATE is *true*.
127 - CS_PASSWORD — Cassandra password if CS_AUTHENTICATE is *true*.
129 - CS_SSL_ENABLED — whether ssl authentication must be used to connect to Cassandra. A *false* will be
130 assumed if this variable is not specified.
132 - CS_TRUST_STORE_PATH — Cassandra Truststore path if CS_SSL_ENABLED is *true*.
134 - CS_TRUST_STORE_PASSWORD — Cassandra Truststore password if CS_SSL_ENABLED is *true*.
136 - SERVER_SSL_ENABLED — whether ssl authentication must be used to connect to application. A *false* will be
137 assumed if this variable is not specified.
139 - SERVER_SSL_KEY_PASSWORD — SSL key password if SERVER_SSL_ENABLED is *true*.
141 - SERVER_SSL_KEYSTORE_PATH — SSL Keystore path if SERVER_SSL_ENABLED is *true*.
143 - SERVER_SSL_KEYSTORE_TYPE — SSL Keystore type if SERVER_SSL_ENABLED is *true*.
145 - JAVA_OPTIONS — optionally, JVM (Java Virtual Machine) arguments.
149 Assuming you have a dedicated Cassandra container as described in Database section, and the access to it is not
150 protected with a password. The following command will start a backend container without SSL support:
152 `docker run -d --name workflow-backend -e SDC_PROTOCOL=http
153 -e SDC_ENDPOINT=$(docker inspect sdc-BE --format={{.NetworkSettings.IPAddress}}):8080
154 -e CS_HOSTS=$(docker inspect workflow-cassandra --format={{.NetworkSettings.IPAddress}})
155 -e SDC_USER=workflow -e SDC_PASSWORD=<secret> -e JAVA_OPTIONS="-Xmx128m -Xms128m -Xss1m"
156 nexus3.onap.org:10001/onap/workflow-backend:latest`
160 In order to verify that the Workflow Designer backend has started successfully, check the logs of the
161 backend container. For example, by running `docker logs workflow-backend`. The logs must not contain any
164 Application logs are located in the */var/log/ONAP/workflow-designer/backend* directory of a workflow backend
165 container. For example, you can view the audit log by running
166 `docker exec -ti workflow-backend less /var/log/ONAP/workflow-designer/backend/audit.log`.
170 `docker run -d -e BACKEND=http://<backend-host>:<backend-port> -e JAVA_OPTIONS=<jvm-options>
171 nexus3.onap.org:10001/onap/workflow-frontend:latest`
173 - BACKEND — root endpoint of the RESTful APIs exposed by a workflow backend server.
175 - JAVA_OPTIONS — optionally, JVM (Java Virtual Machine) arguments.
179 `docker run -d --name workflow-frontend
180 -e BACKEND=http://$(docker inspect workflow-backend --format={{.NetworkSettings.IPAddress}}):8080
181 -e JAVA_OPTIONS="-Xmx64m -Xms64m -Xss1m" -p 9088:8080 nexus3.onap.org:10001/onap/workflow-frontend:latest`
183 Notice that port 8080 of the frontend container has been
184 [mapped]( https://docs.docker.com/config/containers/container-networking/#published-ports) to port 9088 of the host
185 machine. This makes the Workflow Designer Web application accessible from the outside world via the host machine's
190 In order to check if the Workflow Designer frontend has successfully started, look at the logs of the
191 frontend container. For example, by running `docker logs workflow-frontend`. The logs should not contain
194 Workflow frontend does not have backend logic, therefore there are no application logs.
196 Deployment Using Docker Compose
197 ===============================
199 [Docker Compose](https://docs.docker.com/compose/) further simplifies the deployment of Workflow Designer.
200 The Docker Compose files can be find in the workflow designer Git repository, under _docker-compose_ directory.
202 > In order to use this deployment method, you need to install Docker Compose as described on
203 [Install Docker Compose](https://docs.docker.com/compose/install/) official page.
205 ## 1. Cassandra Database
207 Instantiation of a Cassandra database is not part of the the Docker Compose service. You may already have a running
208 instance of Cassandra you want to use. It can be in a Docker container, on a VM, or a physical machine.
210 If you want to spin up a Cassandra database alongside the Workflow Designer service for development purposes,
211 use the following command:
213 `docker-compose -p workflow -f cassandra.yml up -d`
215 > Note, that since the database was created under the same project (`-p workflow`), but as a separate service, it will
216 keep running when you shut down the workflow designer service. This will cause an error message
217 _ERROR: network workflow_default id <......> has active endpoints_.
219 ## 2. Environment Variables
221 Edit _.env_ file located in _docker-compose_ directory. Here is a brief overview of some variables.
223 - IMAGE_TAG — enables to try other versions of the Docker images
225 - REGISTRY — allows to use any Docker registry; leave it blank for locally built images
227 - CS_HOST — Cassandra host name or IP address. Keep in mind that the host must be accessible from the
228 [Docker Compose network](https://docs.docker.com/compose/networking/) created for the workflow service.
229 Use `CS_HOST=cassandra` if you created the database as described in the previous section.
231 - SDC_HOST — usually, IP address of the Docker host (if you are using the SDC deploy script).
233 - CASSANDRA_INIT_PORT — Cassandra Thrift port, usually 9160.
235 - CASSANDRA_PORT — Cassandra CQL native client port, usually 9042.
237 - BACKEND_DEBUG_PORT — *host* port used to debug the backend server (see below).
239 - FRONTEND_DEBUG_PORT — *host* port used to debug the frontend server (see below).
241 - FRONTEND_PORT — *host* port Workflow Designer UI will be accessible at.
243 > Other variables are described in _Deployment on Docker_ section.
245 ## 3. Starting Workflow Designer Service
247 Assuming the database is up and running, execute the following in the command line:
249 `docker-compose -p workflow up -d`.
251 It is easy to restart or recreate the entire service or a selected component using Docker Compose commands, for example
252 to pick up new versions of the Docker images. Keep in mind that the database may remain unchanged, so that the new
253 service will continue to work with old data.
255 For example, you can restart just the frontend by issuing the command:
257 `docker-compose -p workflow restart workflow-frontend`
259 Keep in mind that changes to the _docker-compose.yml_ configuration or environment variables
260 [will not be reflected](https://docs.docker.com/compose/reference/restart/) when using `restart`. For that, you will
261 need to recreate the container (e.g. to change the image version):
263 `docker-compose -p workflow up -d --no-deps workflow-frontend`
265 For more advanced features and commands, please refer to
266 [Docker Compose documentation](https://docs.docker.com/compose/).
268 ## 4. Stopping Workflow Designer Service
270 You can shut down the entire stack of Workflow Designer components using
271 `docker-compose -p workflow down`.
273 ## 5. Starting Workflow Designer in Debug Mode
275 It is possible to start the service in debug mode, when both the front-end and the back-end are accessible from a
276 remote debugger at mapped host ports. Run:
278 `docker-compose -p workflow -f docker-compose.yml -f debug.yml up -d`.
280 SDC Plugin Configuration
281 ========================
283 In order to run as an SDC pluggable designer, Workflow Designer must be added to SDC configuration as described in
284 [Generic plugin support](https://wiki.onap.org/display/DW/Generic+Designer+Support).
286 If you are deploying SDC using a standard procedure (OOM or the
287 [SDC shell script](https://wiki.onap.org/display/DW/Deploying+SDC+on+a+Linux+VM+for+Development)),
288 the easiest way to configure the Workflow plugin is to edit the *plugins-configuration.yaml*.
292 The main endpoint to load Workflow Designer Web application is defined by `"pluginSourceUrl": "http://<host>:<port>"`.
294 Keep in mind that the URL **must be accessible from a user's browser**. In most cases, `<host>` will be the hostname or
295 IP address of the machine that runs Docker engine, and `<port>` will be a host port to which you have published port
296 8080 of the Workflow frontend container.
300 In order to check the availability of a plugin, SDC uses `"pluginDiscoveryUrl"`. For Workflow the value is
301 `http://<host>:<port>/ping`.
305 Let's assume that hostname of the machine that runs Docker containers with the Workflow application is
306 *workflow.example.com*, and port 8080 of the Workflow frontend is mapped to 9088 on the host. In this case the
307 corresponding section of *plugins-configuration.yaml* will look like below:
312 pluginDiscoveryUrl: "http://workflow.example.com:9088/ping"
313 pluginSourceUrl: "http://workflow.example.com:9088"
314 pluginStateUrl: "workflowDesigner"
315 pluginDisplayOptions:
317 displayName: "WORKFLOW"
318 displayRoles: ["DESIGNER", "TESTER"]
322 In a development or demo environment, Workflow Designer will run on the same host as SDC, so that its IP address will
323 be the one of the Docker host.