Skip to content

Latest commit

 

History

History
271 lines (186 loc) · 10.8 KB

README.md

File metadata and controls

271 lines (186 loc) · 10.8 KB
Raw

Process user task orchestration with custom life cycle

Description

A quickstart project shows very typical user task orchestration. It comes with two tasks assigned to human actors via groups assignments - managers. So essentially anyone who is a member of that group can act on the tasks. Though this example applies four eye principle which essentially means that user who approved first task cannot approve second one. So there must be always at least two distinct manager involved.

This example shows

  • working with user tasks

  • four eye principle with user tasks

  • In addition this quickstart also shows how to use custom life cycle for user tasks that uses custom life cycle phases compared to those supported by default.

  • Start
  • Complete - extended the default one that allows only to complete started tasks

Diagram Properties (top)

  • Diagram Properties (bottom)

  • First Line Approval (top)

  • First Line Approval (bottom)

  • First Line Approval (Assignments)

  • Second Line Approval

  • Second Line Approval (Assignments)

To learn more about custom lifecycle, look at the following classes:

  • org.acme.travels.config.CustomWorkItemHandlerConfig - responsible for registering work item handler to deal with user tasks
  • org.acme.travels.usertasks.CustomHumanTaskLifeCycle - defines actual the life cycle for user tasks
  • org.acme.travels.usertasks.Start - new life cycle phase
  • org.acme.travels.usertasks.CompleteStartedOnly - extended Complete life cycle phase to allow only started tasks and reuse all other logic

Build and run

Prerequisites

You will need:

  • Java 11+ installed
  • Environment variable JAVA_HOME set accordingly
  • Maven 3.8.6+ installed

When using native image compilation, you will also need:

Compile and Run in Local Dev Mode

mvn clean compile quarkus:dev

NOTE: With dev mode of Quarkus you can take advantage of hot reload for business assets like processes, rules, decision tables and java code. No need to redeploy or restart your running application.

Package and Run in JVM mode

mvn clean package
java -jar target/quarkus-app/quarkus-run.jar

or on windows

mvn clean package
java -jar target\quarkus-app\quarkus-run.jar

Package and Run using Local Native Image

Note that this requires GRAALVM_HOME to point to a valid GraalVM installation

mvn clean package -Pnative

To run the generated native executable, generated in target/, execute

./target/process-usertasks-quarkus-runner

Running with deadlines enabled

Kogito supports sending notifications when a task has been idle for a while, according to the information included in the process, in "NotStartedNotify" and "NotCompletedNotify" task input parameters

In this example we are going to use Kafka to publish these deadlines notifications to a certain topic and Kogito mail addon to subscribe a listener to that topic, so an e-mail will be sent if 30 seconds has passed after the task was created (but not transition was performed) or every minute till the task is not completed.

You need to link incoming (kogito-deadline-events) and outgoing (kogito-deadline-consumer) channels to a kafka topic and also define certain required propeties for using kafka and proper deserialization.

This is done in application.properties, below we are telling Kogito to use topic kogito-deadline-events

mp.messaging.outgoing.kogito-deadline-events.connector=smallrye-kafka
mp.messaging.outgoing.kogito-deadline-events.topic=kogito-deadline-events
mp.messaging.outgoing.kogito-deadline-events.value.serializer=io.quarkus.kafka.client.serialization.ObjectMapperSerializer


mp.messaging.incoming.kogito-deadline-consumer.connector=smallrye-kafka
mp.messaging.incoming.kogito-deadline-consumer.topic=kogito-deadline-events
mp.messaging.incoming.kogito-deadline-consumer.value.deserializer=org.kie.kogito.mail.DeadlineEventDeserializer

Finally, to send the mail you need to set up these properties with proper values. Refer to Quakus mailer configuration

quarkus.mailer.host=smtp.gmail.com
quarkus.mailer.port=587
quarkus.mailer.username=
quarkus.mailer.password=
quarkus.mailer.ssl=true

You need to have Kafka cluster installed and available over the network. Refer to Kafka Apache site to more information about how to install.

Once Kafka is up and running you can build this project with -Pnotification to enable additional required dependencies during the build.

OpenAPI (Swagger) documentation

Specification at swagger.io

You can take a look at the OpenAPI definition - automatically generated and included in this service - to determine all available operations exposed by this service. For easy readability you can visualize the OpenAPI definition file using a UI tool like for example available Swagger UI.

In addition, various clients to interact with this service can be easily generated using this OpenAPI definition.

When running in either Quarkus Development or Native mode, we also leverage the Quarkus OpenAPI extension that exposes Swagger UI that you can use to look at available REST endpoints and send test requests.

Submit a request to start new approval

To make use of this application it is as simple as putting a sending request to http://localhost:8080/approvals with following content

{
    "traveller" : {
        "firstName" : "John",
        "lastName" : "Doe",
        "email" : "[email protected]",
        "nationality" : "American",
        "address" : {
          	"street" : "main street",
          	"city" : "Boston",
          	"zipCode" : "10005",
          	"country" : "US"
      	}
    }
}

Complete curl command can be found below:

curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"traveller" : { "firstName" : "John", "lastName" : "Doe", "email" : "[email protected]", "nationality" : "American","address" : { "street" : "main street", "city" : "Boston", "zipCode" : "10005", "country" : "US" }}}' http://localhost:8080/approvals

Show active approvals

curl -H 'Content-Type:application/json' -H 'Accept:application/json' http://localhost:8080/approvals

Show tasks

curl -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/tasks?user=admin&group=managers'

where {uuid} is the id of the given approval instance

Start first line approval task

curl -X POST -d '{"approved" : true}' -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/firstLineApproval/{tuuid}?phase=start&user=admin&group=managers'

where {uuid} is the id of the given approval instance and {tuuid} is the id of the task instance

Complete first line approval task

curl -X POST -d '{"approved" : true}' -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/firstLineApproval/{tuuid}?user=admin&group=managers'

where {uuid} is the id of the given approval instance and {tuuid} is the id of the task instance

Show tasks

curl -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/tasks?user=admin&group=managers'

where {uuid} is the id of the given approval instance

This should return empty response as the admin user was the first approver and by that can't be assigned to another one.

Repeating the request with another user will return task

curl -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/tasks?user=john&group=managers'

Start second line approval task

curl -X POST -d '{"approved" : true}' -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/secondLineApproval/{tuuid}?phase=start&user=john&group=managers'

where {uuid} is the id of the given approval instance and {tuuid} is the id of the task instance (careful - it is different one for different user)

Complete second line approval task

curl -X POST -d '{"approved" : true}' -H 'Content-Type:application/json' -H 'Accept:application/json' 'http://localhost:8080/approvals/{uuid}/secondLineApproval/{tuuid}?user=john&group=managers'

where {uuid} is the id of the given approval instance and {tuuid} is the id of the task instance

This completes the approval and returns approvals model where both approvals of first and second line can be found, plus the approver who made the first one.

{
	"approver":"admin",
	"firstLineApproval":true,
	"id":"2eeafa82-d631-4554-8d8e-46614cbe3bdf",
	"secondLineApproval":true,
	"traveller":{
		"address":{
			"city":"Boston",
			"country":"US",
			"street":"main street",
			"zipCode":"10005"},
		"email":"[email protected]",
		"firstName":"John",
		"lastName":"Doe",
		"nationality":"American"
	}
}

You should see a similar message after performing the second line approval after the curl command

{"id":"f498de73-e02d-4829-905e-2f768479a4f1", "approver":"admin","firstLineApproval":true, "secondLineApproval":true,"traveller":{"firstName":"John","lastName":"Doe","email":"[email protected]","nationality":"American","address":{"street":"main street","city":"Boston","zipCode":"10005","country":"US"}}}

Deploying with Kogito Operator

In the operator directory you'll find the custom resources needed to deploy this example on OpenShift with the Kogito Operator.