In Kinetic Task, Sources are external applications that automate workflow using Task Trees. For example, Kinetic Request leverages Task to implement key functionality. In Kinetic Task 4 we have emphasized flexibility in order to allow Task to integrate with as many applications as possible. In this class we will cover the configuration and usage of an already published source. We will also dive into some of the code and see what makes sources in Task 4 work.
Download Kinetic Task by registering on our site. You will receive a link to download the file via email. Then follow the instructions in the installation guide.
The install files include both a stand-alone .war file and a full Tomcat to easily get up and running.
Kinetic Task can run in trial mode without applying a license. For production use please contact Kinetic Data sales to purchase a license or support to have a license generated for an existing purchase.
Task Sources are a brand new topic for training and it becomes an emphasis because of the development of Kinetic Task 4.0. There were a number of large enhancements made in the 4.0 release. The first change you will notice is that the interface has been completely rebuilt. We also rewrote the backend so that Kinetic Task can be installed directly on top of a relational database. And finally, a large amount of effort was dedicated to making Kinetic Task the workflow engine for any application. This is accomplished by leveraging Sources in Kinetic Task.
Before jumping right into Sources, lets take a high-level look at the Kinetic Task architecture and its relation with other applications. Kinetic Task is a workflow engine that can be used to automate all kinds of business processes. In Task we implement a process by creating a Task Tree. The tree contains nodes and connectors that define the technical implementation of our business process. Each node in the tree uses a Task Handler. A handler is a module of Ruby code that can perform some operation in an external system using an API (creating an approval, sending an email, etc.). If you have been to any training for Task before these were the two topics that were the focus of that training. So we know that we can build a process in Kinetic Task and it can interact with other applications, but how do we start that process? Some other application needs to be able to start the process, we refer to that application as a Source. Interaction between source applications and Kinetic Task will be the emphasis of this training session.
Below is a diagram of the high-level architecture and interaction described above. Note that there are some terms on the diagram that are not mentioned until later. We will be going over all of the terms in the diagram and come back to it multiple times throughout the session.
We will get Kinetic Task up and running (using the same distribution as the trial copy) and make sure everything is working.
Get familiar with creating and running trees and view runs in the new interface. Introduce the concept of "source data".
Demonstrate how a source application can trigger processes with Task. View resulting run and source data. Demonstrate need for sources in Task.
Introduce "source files" by adding one to the server and leveraging its features. Reason for "source groups".
Dive into the technical side of sources in Task. Make some simple modifications to the sample source file.
An application that uses Kinetic Task to implement an automated process. For example, we can configure Jira (shown below) to start a Task process whenever a new issue is created.
A configured item in Kinetic Task that represents a source application. All Task Trees belong to a source, and the source determines much of their functionality.
A code module that implements pieces Task functionality that are specific to the source application. For example, source files are responsible for telling the Tree Builder which pre-defined values are available for its source application.
The data passed from the source application to Kinetic Task when a process is triggered. The source data is used to drive logic throughout the automated process. We can view the source data by looking at the Run page and then selecting the Inputs tab.
A property of the Task Tree that relates the tree to some kind of object in the source application. How the source group is used is completely determined by the implementation of the source file. The Kinetic Request source uses the source group to relate the tree to a service item as an example.