ACTICO Platform - Engine. User Guide. Version

(1)

ACTICO Platform - Engine

User Guide

(2)

(3)

User Guide

1. About this document ... 1

1.1. Audience ... 1

1.2. Content ... 1

1.3. Conventions ... 1

2. Introduction ... 2

2.1. Feature Overview ... 2

2.2. Distribution ... 2

3. Getting Started ... 3

3.1. Add Engine Dependencies ... 3

3.2. Install Maven Dependencies ... 3

3.3. Basic Usage Examples ... 3

3.3.1. Working with the Engine ... 3

3.3.2. Complete Example ... 5

3.3.3. Connecting to Model Hub ... 5

3.3.4. Engine Configuration ... 5

4. Usage Examples ... 7

4.1. Example Prerequisites ... 7

4.2. Spring Boot Examples ... 7

4.2.1. Executing a Rule with a REST Controller ... 7

4.2.2. Executing a Rule with Kafka Integration ... 8

5. Concepts and Background ... 10

5.1. Model Hub Connection ... 10

5.2. Model Execution ... 10

5.2.1. Request Path ... 10

5.3. Engine Request ... 12

5.3.1. Engine Request Options ... 13

5.3.2. Engine Execution (Response of a Request) ... 13

(4)

Chapter 1. About this document

This document describes the usage of ACTICO Engine.

1.1. Audience

This document is intended for • Java Developers

1.2. Content

This document considers the following topics • Integration of Engine in a Java application

1.3. Conventions

The following text conventions are used in this document:

Table 1.1. Conventions

Convention Meaning

boldface Used for elements, labels and terms from the user interface.

(5)

Chapter 2. Introduction

The ACTICO Engine is a lightweight, efficient and easy to integrate execution engine for different types of

Models supported by the ACTICO Platform.

Models are parts of a software system that implement business logic of any kind. Business logic often requires more frequent changes than the software systems using it. The ACTICO Engine is ACTICOs core model execution engine, enabling dynamic altering of software systems through dynamic replacement of Models, without the need to rebuild or restart the software using it.

It consists of a set of Java libraries that can be integrated into a custom Java application. The Engine provides easy connectivity to Model Hub and provides APIs to load and execute Models. It can run standalone or in combination with ACTICO Model Hub.

2.1. Feature Overview

Main features are:

• Lightweight execution engine for models

• Easy connectivity to Model Hub as Deployment Environment to pick-up new or updated model deployments and activations (optional)

• Dynamic dependency resolution ("late binding") • Full traceability of all models used for every execution

• Optimized classloading and smaller memory footprint to simultaneaously handle many large models • Java API to integrate into all execution environments

• Build-in XML and JSON serialization

2.2. Distribution

The ACTICO Engine is distributed as Java libraries and dependencies. The distribution zip file contains the following contents:

Folder Content

install/maven-dependencies ACTICO Engine and dependencies in a Maven repository layout, together with scripts for depeloying into a Maven repsitory.

manuals The user guide as PDF and HTML.

manuals\engine-examples Examples describing the use of ACTICO Engine.

manuals\engine-user-guide-html

The user guide in HTML format.

manuals\engine-apidocs The apidoc of the ACTICO Engine.

legal-notice Legal information about third party libraries. release notes Information about changes in ACTICO Engine.

(6)

Chapter 3. Getting Started

This chapter describes basic APIs and steps how the Engine can be integrated into a Java application.

3.1. Add Engine Dependencies

The Engine distribution contains all jar files necessary for integration into a custom Java application. The jar files are located in the install/maven-dependencies of the distribution zip using the Maven repository layout. Therefore, it is recommended to integrate the Engine using Maven or a build tool that supports Maven repository layouts. The engine-core-9.1.0.jar and its dependencies are required on the classpath.

An application may already have a classpath containing the dependencies in the same or a different version. In that case it is advisable to adjust the dependencies such that only one version of a dependency is on the classpath.

To enable the Engine to execute models of specific types the following additional libraries are required on the classpath:

rules engine-rules-9.1.0.jar

3.2. Install Maven Dependencies

In order to use the Engine in Maven projects, the required jars need to be installed or deployed to your Maven repository. The distribution zip comes with all required dependency jars the Engine requires on the classpath in the install/maven-dependencies directory.

For local development it is sufficient to copy and paste the contents install/maven-dependencies to the location where your local maven repository resides (Typically \{user.home}/.m2/repo).

In order to deploy the dependencies to a Maven repository server (like Artifactory or Nexus) the deploy.cmd or deploy.sh scripts can be used. Open the script valid for your operating system using a text editor, set variables in the header of the script and execute it on the command line.

Once added to a Maven repository, the Engine dependencies can be added to the pom.xml of your project.

Engine Maven Dependencies.

<dependency> <groupId>com.actico.engine</groupId> <artifactId>engine-core</artifactId> <version>9.1.0</version> </dependency> <dependency>

<groupId>com.actico.engine</groupId> <artifactId>engine-rules</artifactId> <version>9.1.0</version>

</dependency>

3.3. Basic Usage Examples

3.3.1. Working with the Engine

The following chapter introduces basic APIs required to execute Model services using the Engine. It covers • how to instantiate the Engine

(7)

• execute the request and process the result

STEP 1: Instantiate the Engine.

IEngine engine = EngineConfig.builder() ❶

.homeDirectory(Paths.get("target/engine-home")) .build()

.newEngine(); engine.start(); ❷

this.engineInstance = engine;

❶ Use the EngineConfig.builder() to build the Engine configuration. This example sets the home directory on the configuration builder to target/engine-home.

❷ Start the Engine. The Engine instance is thread-safe and should be re-used. Singleton pattern can be used to store the configured Engine instance.

STEP 2: Create an Engine request.

IRequestPath movieTicketPricingRequestPath = RequestPath.requestPath( ❶ "actico.example.movie-ticket-pricing",

"stream-1.x",

"movie-ticket-pricing",

"Movie Ticket Pricing/Pricing");

Map<String, Object> inputData = getPricingInputData(); return EngineRequests.java(movieTicketPricingRequestPath) ❷ .withInputData(() -> inputData)

.build(options -> options.withExecutionTraceLevel(ExecutionTraceLevel.OFF)); ❸

A Engine request consists of a IRequestPath defining what to execute, some input data and optionally request-specific options which can be configured.

❶ Create the RequestPath pointing to the Pricing Rule in the Movie Ticket Pricing Example Module (see image above). The request path uniquely identifies what to execute. See Request Path for details about the components of a request path

❷ Having the RequestPath, now a IEngineRequest object can be created using the EngineRequests class. In this example we create a simple java request, which takes a java.util.Map as input parameter and produces an output of the same type and provide the input parameter map. The Engine also supports json and xml to process serialized requests.

❸ The example shows the build(options#options.with) pattern which can be used to set request options different from default. This is optional. Simply use build() to use default options.

STEP 3a: Invoke the Engine and process result (try-catch).

EngineExecution<Map<String, Object>> result = engine.execute(javaRuleRequest); ❶ try

{

Map<String, Object> pricingResult = result.getOutput(); processResult(pricingResult); ❷ } catch (EngineExecutionException e) { handleException(e); }

Having the IEngine as well as the EngineRequestJava created, we have everything in place to invoke the Model service. The Example shows a more traditional coding style using a try-catch block.

❶ Now a simple call to engine.execute(request) invokes the Pricing rule, resulting in a

EngineExecution object, which provides access to the output or an exception in case the execution resulted in a error. Optionally, a ExecutionTrace object can be accessed (if enabled).

❷ The rule output can be accessed and processed by the application using.

(8)

EngineExecution<Map<String, Object>> result = engine.execute(javaRuleRequest); result.ifSuccess(this::processResult).ifException(this::handleException); ❶

Having the IEngine as well as the EngineRequestJava created, we have everything in place to invoke the Model service. The Example shows a more traditional coding style using a try-catch block.

❶ This example shows how to handle the output or error avoiding the try-catch block usign method reference and ifSuccess, ifException construct, resulting in a more compact syntax.

3.3.2. Complete Example

For reference the complete example can be found in the distribution examples

com.actico.engine.documentation.examples.standalone.EngineBasicConceptsExample

3.3.3. Connecting to Model Hub

The following example shows how to connect the Engine instance to a Model Hub as Environment. Please refer to the ACTICO Model Hub documentation, to find out how to create an Environment and an API Key for it.

Connect to Model Hub.

EnvironmentRegistrationProperties envRegistration = EnvironmentRegistrationProperties.builder() ❶ .serverUrl("http://localhost:8080") .environmentIdentifier("dev") .apiKey("RW52aXJvbm1lbnQtZGV2X2NocmlzdG9mfkFDVElDT1BsYXRmb3JtSXNDb29s") .engineName("DEV Environment") ❷ .build(); EngineConfig.builder() .environmentRegistration(envRegistration) ❸ .build() .newEngine();

❶ In order connect to the Model Hub, the Engine can be configured using properties object configuring the connection parameters. Required parameters are: serverUrl, environmentIdentifer and apiKey. ❷ The engineName is optional. It is used as label in the Model Hub UI. It defaults to a generated value. ❸ The created properties object can be set to the EngineConfig, when building the Engine.

3.3.4. Engine Configuration

The following options can be configured when building the EngineConfig:

environmentRegistration Registers the Engine to Model Hub. Model Hub lists all registered engines for an environment.

environmentIdentifier Environment identifier used for execution traces if environment registration is not configured.

simpleRemoteConnection Connection to Model Hub, if deployments should not be considered and Model Hub should only serve as remote repository to obtain release and libraries.

homeDirectory Default: {user.home}/.actico/actico-engine.

workDirectory Default: subdirectory work of home directory.

localRepository The path used by the Engine to resolve releases and libraries from. Default: subdirectory repository of home directory. enableLocalDevelopment(repositoryPath) Puts the engine into local (offline) development mode,

effectively disabling a configured server connection. The given repositoryPath should point to the same

(9)

repository the Modeler uses e.g. in path/to/modeler-workspace/.actico/repository

The Engine will pick up the changes immediately, when "Release to FileSystem" is triggered in Modeler. The local development mode can be enabled, when working with a Modeler workspace for fast feedback development cycles.

(10)

Chapter 4. Usage Examples

This chapter provides hands-on examples how the use ACTICO Engine in a standalone environment or in combination with a Model Hub. Furthermore, one example shows how the Engine can be integrated into a custom Spring Boot application.

4.1. Example Prerequisites

The folder manuals\examples in the distribution zip contains an example project describing how the ACTICO Engine can be integrated and used in Java applications.

• The examples in package com.actico.engine.documentation.examples.standalone demonstrates how to instantiate the engine in standalone mode, load a Jar-file and execute a rule.

• The example in package com.actico.engine.documentation.examples.springboot demonstrates how to integrate the ACTICO Engine into a custom Spring Boot application and connect it to Model Hub. Additionally it is shown how to execute a rule through a REST endpoint as well as through Apache Kafka integration.

• For every example as test is provided, that shows how to execute the example.

The examples are provided as a Maven project. The following preparatory steps are neccessary to execute the examples:

• Prerequisites an installation of Maven 3

• Requires Engine libraries installed in a Maven repository. See Install Maven Dependencies

• Import the example project as a Maven project into your IDE.

The Spring Boot dependencies required for the Spring Boot example are not contained in install\maven-dependencies. These dependencies can be obtained through Maven Central.

4.2. Spring Boot Examples

This chapter provides a hands-on example how to integrate an 'Engine' into a custom Spring Boot application and execute a Rule with a REST controller as well as through a Kafka integration.

4.2.1. Executing a Rule with a REST Controller

(11)

@RestController @Source

public class Controller {

private static final String MODULE_ID = "actico.example.movie-ticket-pricing"; private static final String RULE_PROJECT_ID = "movie-ticket-pricing";

private static final String VERSION = "stream-1.0";

private static final String MODEL_PATH = "Movie Ticket Pricing/Pricing"; private IEngine engine;

@Autowired

public Controller(IEngine engine) {

this.engine = engine; }

@Source

@PostMapping(consumes = MediaType.APPLICATION_JSON_VALUE, value = "/executions") ❶ public ResponseEntity<Object> executePricing(@RequestBody byte[] modelInput) {

// Create the request path of the Movie Ticket Pricing Model.

RequestPath movieTicketPricingPath = RequestPath.requestFixedVersion( ❷ MODULE_ID,

VERSION,

RULE_PROJECT_ID, MODEL_PATH);

try (InputStream dataInputStream = new ByteArrayInputStream(modelInput)) ❸ {

// Create the JSON rule request by specifying the model path to execute // and a `java.util.Supplier` supplying the input data for the rule request. EngineRequestJson jsonRequest = EngineRequests.json(

movieTicketPricingPath, () -> dataInputStream) .build(); ❹

// Execute rule by passing the request to the engine and fetch the result. EngineExecution<OutputStream> result = engine.execute(jsonRequest); // (5) byte[] modelOutput = result.resultToBytes(); ❺

return ResponseEntity.ok(new String(modelOutput)); }

catch (IOException e) {

throw new UncheckedIOException(e); }

} }

❶ Create a PostMapping for endpoint '/executions' that consumes JSON requests. ❷ Create the coordinate for the Movie Ticket Pricing Rule Model.

❸ Create an InputStream of the JSON formatted payload.

❹ Create the JSON rule request by specifying the model coordinates, the rule to execute, the request config and a java.util.Supplier supplying the input data for the rule request.

Execute the request by passing the request to the Engine. ❺ Fetch the result object.

4.2.2. Executing a Rule with Kafka Integration

(12)

@Source

@EnableBinding(Processor.class) public class KafkaService {

private static final String VERSION = "stream-1.0";

private static final String RULE_PROJECT_ID = "movie-ticket-pricing";

private static final String MODULE_ID = "actico.example.movie-ticket-pricing"; private static final String MODEL_PATH = "Movie Ticket Pricing/Pricing"; private IEngine engine;

public KafkaService(IEngine engine) {

this.engine = engine; }

@StreamListener(Processor.INPUT) ❶ @SendTo(Processor.OUTPUT) ❷

public String process(String payload) {

RequestPath movieTicketPricingPath = RequestPath.requestFixedVersion( ❸ MODULE_ID,

VERSION,

RULE_PROJECT_ID, MODEL_PATH);

try (InputStream inputStream = new ByteArrayInputStream(payload.getBytes())) ❹ {

EngineRequestJson jsonRequest = EngineRequests.json(movieTicketPricingPath) .withInputData(() -> inputStream)

.build(); ❺

EngineExecution<OutputStream> result = engine.execute(jsonRequest); ❻ return result.resultToString(); ❼

}

catch (IOException | EngineExecutionException e) {

return "Error while executing:" + movieTicketPricingPath; }

} }

❶ Bind the method to listen to the Kafka topic 'input'. Every message to this topic will execute the method. ❷ Bind the methods return value to the Kafka topic 'output'. Every return value of the method will be send

to this topic.

❸ Create the coordinate for the Movie Ticket Pricing Rule Model. ❹ Create an InputStream of the JSON formatted message.

❺ Create the JSON rule request by specifying the model coordinates, the rule to execute, the request config and a java.util.Supplier supplying the input data for the rule request.

❻ Execute the request by passing the request to the Engine. ❼ Fetch the result object.

(13)

Chapter 5. Concepts and Background

This chapter describes the most important concepts used by the ACTICO Engine.

5.1. Model Hub Connection

The ACTICO Engine can optionally be connected to an ACTICO Model Hub. HTTP is used as communication protocol to share information like online status and notifications about deployed releases and real-time updates. The Engine will automatically fetch required releases deployed to the environment it is connected to, and is able to execute them.

To connect and authenticate itself to Model Hub as a Deployment Environment, the Engine needs a valid URL, the environment identifier and the API key. The environment identifier and the API key for an Environment can both be obtained in the Model Hub environment screen.

To connect the Engine to a Model Hub, a

com.actico.engine.api.EnvironmentRegistrationProperties needs to be specified setting apiKey, serverUrl, environmentIdentifer and provided to the EngineConfig builder, when building the Engine. For further information about Environments and Deployments see Model Hub User Guide. A code example how to configure the connection to Model Hub can be found in Connecting to Model Hub

5.2. Model Execution

This chapter describes the most important concepts in the context of model execution using the Engine.

5.2.1. Request Path

As already seen in the usage examples, a RequestPath is used to identify what is being executed. For the model execution, the engine requires a RequestPath and the input data for the model. The RequestPath is composed of the following parts:

• moduleId

• version or stream • modelProjectId • modelPath

Each component narrows the scope until we reach the specific resource or service which can be executed using the Engine.

In the following the concept is explained using a the Movie Ticket Pricing example Module, which is shipped with ACTICO Modeler:

(14)

Figure 5.1. Movie Ticket Pricing Module

The image highlights components of the request path: Each component narrows the scope, until the Pricing Rule is identified. In this example the components are named as follows:

• moduleId: actico.example.movie-ticket-pricing • stream: stream-1

• modelProjectId: movie-ticket-pricing • modelPath: Movie Ticket Pricing/Pricing The RequestPath could also be written as

actico.example.movie-ticket-pricing/stream-1/movie-ticket-pricing/Movie Ticket Pricing/Pricing

ACTICO Execution Server uses the path shown above as part of the invocation URL for web-based Model service executions endpoint.

The com.actico.engine.api.RequestPath class can be used to create a request path. It distinguishes two flavors:

Fixed Version Path. The fixed version path always invokes the version exactly as specified.

A valid version string is any string containing a dot '.' character e.g. 1.0.0, 1.0-SNAPSHOT, stream-1.0, etc.

Active Stream Version Path. The active stream version path represents kind of a soft version, as the executed Model service version can change over time. The Engine will try to resolve the active version of the given stream name and execute it. The active stream version can be specified in ACTICO Model Hub.

When the Engine is not connected to ACTICO Model Hub, and a active stream version path is used, the active stream version resolves to the latest version found in the configured release repository by default. Where the latest version is determined using semantic version comparison.

A valid stream name can be referenced using the dot.x syntax. Having a stream named stream-1 it can also be referred to as stream-1.x, where the .x part is replaced with the current active version or latest version. Having a stream named 1.0 the stream has to be referenced as 1.0.x, otherwise it cannot be distinguished from a fixed version.

(15)

5.3. Engine Request

For easier handling of input data the Engine has a built in serialization for JSON and XML. Thus, the input data for model execution can be provided in JSON and XML format or as a simple java.util.Map.

Engine requests for different request formats can be created using the

com.actico.engine.api.EngineRequests class. Each request to the Engine gets a requestId UUID assigned to uniquely identify requests.

Requests can be grouped using a correlationId, which can be specified on the request object. This is very useful to relate Model service executions with externally defined IDs. For example to associate all Model service executions belonging to a process instance ID. The correlationId SHOULD be a UUID.

The following listing shows example payloads for the different supported request formats. The shown example input data works as input for Movie Ticket Pricing/Pricing Rule from the example above:

JSON Payload Example.

{ "student" : false, "show_date" : "2037-08-03T16:24:41Z", "seat_no" : 1, "coupon" : false, "bonus_card" : "SILVER", "auditorium_no" : 1 }

XML Payload Example with namespace.

<pric:input xmlns:pric="http://www.visual-rules.com/vrpath/Movie%20Ticket%20Pricing%20Maven/ Pricing/"> <pric:show_date>2037-08-03T16:24:41Z</pric:show_date> <pric:coupon>false</pric:coupon> <pric:auditorium_no>1</pric:auditorium_no> <pric:seat_no>1</pric:seat_no> <pric:student>false</pric:student>  <pric:bonus_card>SILVER</pric:bonus_card> </pric:input>

XML Payload Example without namespace.

<input> <show_date>2037-08-03T16:24:41Z</show_date> <coupon>false</coupon> <auditorium_no>1</auditorium_no> <seat_no>1</seat_no> <student>false</student>  <bonus_card>SILVER</bonus_card> </input> java.util.Map Example.

Map<String, Object> inputParams = new HashMap<>(); inputParams.put("student", Boolean.FALSE);

inputParams.put("show_date", new Date()); inputParams.put("seat_no", Integer.valueOf(1)); inputParams.put("coupon", Boolean.FALSE);

inputParams.put("auditorium_no", Integer.valueOf(

See Chapter 4, Usage Examples for code examples on how to create and execute an EngineRequest.

(16)

5.3.1. Engine Request Options

Each EngineRequest to execute a Model service can be configured using an options object. The options are dependent on the type of Request e.g. simple java.util.Map request or XML, JSON

See Working with the Engine for an example on how to configure options on the Request object.

Table 5.1. ExecutionTraceLevel

OFF Disable publishing of execution traces to listeners (default) ON Enable publishing of all execution traces to listeners

Table 5.2. ModelTraceLevel

OFF No trace data is collected. This is the default LEVEL1 For rule models, count the visits of rule elements LEVEL2 For rule models, measure the time spent in each rule

5.3.2. Engine Execution (Response of a Request)

The EngineExecution is the result type of an EngineRequest. It provides access to the output data of the Model service execution, the Exception in case the execution resulted in a error and a EngineExecutionTrace object.

For every Engine execution an EngineExecutionTrace data is collected and returned with the execution result. The trace holds meta-information about the Model service execution

correlationId(optional) The correlationId specified by the caller

requestId UUID of the request. When the requested Model service, calls another Model internally, the resulting request will get the same request id Therefore, the requestId is unique per API call to the Engine, but can be associated to multiple executions (when a Model calls other Models)

errorId (optional) The assigned error id in case of errors moduleId The id of the executed module

version The executed version, e.g. stream-1.0. stream The executed stream name, e.g. stream-1 modelProjectIdThe id of the executed model project modelName Name of the model that has been executed

modelPath (optional) Model related path to the executed Model. Depends on the executed Model type. dependencyResolutionNumberThe dependency resolution id of the executed deployment (Only in conjunction with

deployments on ACTICO Model Hub) modelProjectTypeThe type of the executed model project durationMillisDuration of the rule execution in milliseconds executionTimestampTimestamp of the execution start in UTC

(17)

Chapter 6. Glossary

This glossary defines the main terms and concepts of Model Hub:

Model

A Model is a isolated part of a software system usually implementing core business logic.

Specific Models can be modeled graphically using ACTICO Modeler, like a rule model or a DMN model. It can also be a machine learning model trained with the Machine Learning server or even be simple Java code.

Models can reuse other Models via dependencies defined between Model Projects.

Because Models usually implement important core business requirements, it is important to be able to update them more often than the software systems that use the models. Models in ACTICO Platform can be updated dynamically, enabling businesses to react faster to market changes, competitors and requlatory requirements.

Model Project

There are different types of Model Projects for different model types, e.g. Rule Project, DMN Project, and

Machine Learning Project. Every Model is contained inside a Model Project. These often contain just one

model, but are allowed to contain multiple models. Model Projects can optionally define dependencies to other required Model Projects. This is necessary when the contained Models want to reuse the Models contained in other Model Projects. Model Projects can also define Dependencies to Libraries in order to make them available at runtime.

Module

A Module is the collection of several related Model Projects. These projects can be of different types, i.e. rule projects, extension project, machine learning or others can be combined into a Module. Modules are the entities that are versioned, released and deployed. In other words, they represent the unit whose lifecycle is managed by Model Hub. There is exactly one internal Git repository per Module where every change to its contents (Model Projects with Models) is versioned. Executable Releases of a Module are stored in the Model Hub database.

Stream

Every Module contains one or multiple Streams. Streams are used to separate different streams of development (major versions) of a Module. The Stream name forms the first part of the version number of a release. Whenever a model changes in a major way, especially when the interface changes, it is recommended to start a new Stream. Model Hub and Engine allow multiple versions of modules from different streams to be available and used simultaneously. Streams therefore are also a good means for API versioning of decision services. Streams can also be used temporarily to make individual changes. E.g. one person can create their own Stream of a Module to add enhancements step by step. Once the enhancements are completed, they can be transferred (called Merging) to the main Stream (or any other

Stream).

Library

A Library is a technical component that may be required for model projects to be executed, e.g. custom functions, data models, or connectors can be implemented and packaged into a Library.

(18)

Chapter 6. Glossary

Dependency

There are two types of Dependencies: a Model Project Dependency, which points to another Model Project, and a Library Dependency that refers to a required Library. A Model Project Dependency to a Model Project located in a different Module must specify the Version of that Module. This can be either the full Version or just the Stream name. When the full Version is specified then it always means exactly that Release. When only the Stream name is specified then it means the currently active Release on that Stream. This allows

Modules to be updated and be automatically picked up by other Modules without having to create new Releases of these other Modules. This mechanism is called Late Binding, because the actual Version for

the Dependency is resolved during Deployment. A Dependency to a Library is always specified with the full version number.

Release

A Module must be released in order to be deployed and finally executed. A Release captures a certain point in the history of one Stream and is identified by a Version. When a Release is created, the Module and all its contents are packaged into their executable form. A Release can be replaced with another with the same Version as long as it is not finalized. A Finalized Release cannot be changed or replaced anymore. Version

A Version is a unique identifier for a Release. It is automatically created by Model Hub when a Release is created or uploaded and is composed of the Stream name and a unique Release Number, separated by a dot, e.g. mystream.15, 1.0). Model Hub also accepts imports of Releases that can have a different

Version format. In this case the part before the last dot is the Stream name (e.g. for version 1.2.5 the

stream name is 1.2). Environment

An Environment is a logical group of one or multiple execution engines where models are executed (e.g. Execution Server or Engine). Typically a single Environment denotes one stage like a "Development", "Test" and "Production" environment.

Deployment

A Deployment makes a specific Release available in an Environment. A Deployment contains the Release of a Module together with all its dependencies.

ACTICO Platform - Engine. User Guide. Version