5.0 (Major Release)

Consolidated Administration, Containerization, and More!

Overview

• With this release, all platform functions are now accessed in a single configuration / management console. This includes workflow and bridge activities.
• Kinetic Agent replaces Bridgehub and Filehub and introduces additional integration capabilities between a cloud-hosted implementation and customer-managed applications
• All Task API calls now go through the core/platform API; no calls are made to the native Task API.
• Additionally, some console functions were simplified / reimagined to help make them more intuitive.This includes components as advanced as the Bridge Model and Mapping functionality, and items as simple as the kapp menu.
• A code highlighter / editor has been implemented across the console to help define and populate areas where code / script or parameters could be used.
• Significantly enhanced log review and search capabilities
• Terminology changes / introductions include:
  • Platform Components now include
    • Kinetic Task
    • Kinetic Agent (includes capabilities of former Kinetic Bridgehub and Kinetic Filehub)
  • Plugins collectively represent
    • Bridge Adapters
    • Task Handlers
    • Task Sources

Details

Main Navigation

With the adding of Kinetic Task functions into the main console and the introduction of new terminology, the left navigation has changed.

Summary of Main Navigation Changes

• Global Workflow: New item allows access to most of Kinetic Task’s previous functionality. This includes Trees, Routines, Runs, Triggers, and Errors
• Plugins: Access to Bridge end-point, Task Handler and Task Source configurations
• Users & Teams: Combination of the previously separate entries
• Bridge Models: Where you access the simplified Bridge Models and Mappings
• Webhooks: Includes the previously separate Jobs area

Kinetic Task Integration / Global Workflow

One of the biggest changes for Kinetic administrators in Platform V5 is there is no longer a separate Kinetic Task interface. Kinetic Task is now more native to the platform, and all existing functionality now resides in various areas of the main console.

Starting with Platform V5, only one task environment is configured for a given Space. As before, the Task environment can be made up of multiple Task servers in various configurations. The connected Task environment is identified in the Settings > Platform Components area. Previously, the strategy was to use custom space attributes to make the URL dynamic, or hardcoded URLs within Webhooks. This results in a simpler webhook definition strategy as well (see later section).

You’ll find Trees, Routines, Runs, Triggers, and Errors under Global Workflow in the console. Handler and Task Source configuration are under Plugins. Policy rules, Categories, License, and the ability to stop / start the engine are under Space > Settings > Workflow.

Global Workflow: Accessing Trees, Routines, Runs, Triggers, and Errors

• 

  Plugins: Accessing Handler and Task Source Configurations
  

Kinetic Agent

Platform V5 introduces the Kinetic Agent. One capability of this agent is to function as a combination and replacement for the previously separate Kinetic-Bridgehub and Kinetic-Filehub components. The platform console integrates with the Agent, allowing space administrators to define bridge end-points directly without the need to access the Agent Console directly.

Another advancement is that Kinetic Agent lets you run individual task handlers. This is part of the integration strategy for integrating cloud-hosted environments with customer-managed systems. Handlers within a locally-installed agent can integrate with customer-managed systems without having to open up firewall ports for each integrated system. A new handler has been written allowing workflow to call the Agent and execute a specified handler.

A space may connect to multiple Agents as needed. Cloud-hosted environments that will integrate with customer-managed applications will typically use multiple agents, one would be part of the cloud environment (providing file handling and bridges to the cloud system), and the other would be installed locally.

See this article for additional information on the Kinetic Agent.

Example of defining a bridge end point

Example of configuring a handler installed on an Agent

Bridge Models

The Bridge strategy has been simplified in Platform V5. Previously the steps to define a Bridge Model were separate from a Bridge Mapping. With the new release, these steps are collapsed to make defining bridges more intuitive. Bridge Attributes are defined and mapped in the same step; Bridge Qualifications are named and defined in one step -- along with any dynamic parameters.

Additionally, a new Testing capability has been introduced allowing administrators to test bridges direct from the console.

Bridge Model Definition

Attribute Definition

Qualification Definition

Testing

Webhooks

Because of the new tighter integration with Kinetic Task, webhooks no longer include references to a Task server. Instead, they reference a Core API endpoint which directs the activity to the integrated Task system. The API parameters still include the Source, Group, and Tree Name.

Log Changes

For all kinops customers and customers with customer-managed installations using Kubernetes, Logs now includes logs across all platform components, across all servers -- including Core, Task, and Agent. In addition to downloading the logs, the display lets you set various timeframes, apply various filters, and return specific attributes.

Task API Proxy

Task Workflow) API integration is now proxied through the Core application. All activity is now directed to Core through the API route. This impacts any Task handlers integrating directly to task (e.g., Kinetic Task API v1 and Kinetic Task API v2 handlers) as well as 3rd party integrations direct to Task.

Handlers

For cloud-hosted (kinops) customers, the Task Handler API locations are automatically updated to the following:

• Task API v1: https://<space>.kinops.io/app/components/task/app/api/v1
• Task API v2: https://<space>.kinops.io/app/components/task/app/api/v2
  The changes are made automatically for these task handlers.

For customer-managed customers, coordinate handler updates with your implementation. The URL may be slightly different based on local configurations.

• Task API v1: http[s]://<server>[:port]/kinetic/<space-slug>/app/components/task/app/api/v1
• Task API v2: http[s]://<server>[:port]/kinetic/<space-slug>/app/components/task/app/api/v2

If using the kinetic_task_tree_run_v2 handler within the kinetic agent, the kinetic_task_location API path is as follows.

• Kinops customers:
  https://<space slug>.kinops.io/app/components/task
• Customer-managed customers:
  http[s]://<server>[:port]/kinetic/<space-slug>/app/components/task

Other Task integrations

For other integrations to third party systems, coordinate those updates during your implementation. Usually, the URLs to use match one of the scenarios above.

Code Editor

All areas in the console where parameter values can be used now use a code editor style field. This field offers syntax highlighting as well as providing quick access to the possible parameters.

• Pressing the dollar sign ($), or the </> icon in the upper right of the fields will display a context-sensitive pick list of property values.
• The field grows as necessary, so there’s no scrolling through fields

Bundle Changes

A couple of changes in the Platform V5 implementation necessitate Bundle updates.

• Bridge end-points are referenced differently
• Routes to access the form builder from the default Datastore UI was changed

For customers in the cloud-hosted (kinops) environment, these changes have been made for you.

For customer-managed customers, coordinate bundle changes with your implementation. Contact Kinetic Support for further guidance.