From a200797180eaf7c11e14ad68cae21aa8860eb978 Mon Sep 17 00:00:00 2001 From: mkl <158037696+mk-software-pl@users.noreply.github.com> Date: Mon, 3 Jun 2024 19:34:50 +0200 Subject: [PATCH] docs links fixes (#6123) --- CONTRIBUTING.md | 8 ++++---- README.md | 10 +++++----- designer/client/src/components/AddProcessForm.tsx | 4 ++-- dockerhub/nussknacker-lite-runtime-app/README.md | 2 +- docs/LicenseInfo.md | 2 +- docs/developers_guide/Basics.md | 4 ++-- docs/installation_configuration_guide/Common.md | 12 ++++++------ .../ScenarioDeploymentConfiguration.md | 14 +++++++------- .../model/ModelConfiguration.md | 10 +++++----- docs/integration/KafkaIntegration.md | 2 +- docs/operations_guide/Common.md | 2 +- docs/scenarios_authoring/DataSourcesAndSinks.md | 2 +- docs/scenarios_authoring/Enrichers.md | 2 +- docs/scenarios_authoring/Intro.md | 2 +- 14 files changed, 38 insertions(+), 38 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3a12d2fe4d1..4851310e942 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -52,18 +52,18 @@ When writing documentation please follow these instructions: ``` [main configuration file](./Common#configuration-areas) ``` -* all links to `https://nussknacker.io/documentation/`, but other than `Documentation` section in that page, e.g. to `About` or `Quickstart` sections: +* all links to `https://nussknacker.io/documentation/`, but other than `Documentation` section in that page, e.g. to `Quickstart` sections: * should **not** point to `md` or `mdx` files * should **not** be relative example of correct link: ``` - [Components](/about/GLOSSARY#component) + [Components](/quickstart/GLOSSARY#component) ``` example of incorrect links: ``` - [Components](/about/GLOSSARY.md#component) - [Components](../about/GLOSSARY#component) + [Components](/quickstart/GLOSSARY.md#component) + [Components](../quickstart/GLOSSARY#component) ``` ### Automatic Screenshots Updates in Documentation diff --git a/README.md b/README.md index 65e40eac189..38a768d5a51 100644 --- a/README.md +++ b/README.md @@ -35,9 +35,9 @@ An essential part of Nussknacker is a visual design tool for decision algorithms The way the data are processed and features available depend on the processing mode and engine used. -Nussknacker supports three [processing modes](https://nussknacker.io/documentation/about/ProcessingModes/): streaming, request-response and batch (planned in version 1.16). In streaming mode, Nussknacker uses Kafka as its primary interface: input streams of data and output streams of decisions. In request-response mode, it exposes HTTP endpoints with OpenAPI definitions. +Nussknacker supports three [processing modes](https://nussknacker.io/documentation/docs/about/ProcessingModes/): streaming, request-response and batch (planned in version 1.16). In streaming mode, Nussknacker uses Kafka as its primary interface: input streams of data and output streams of decisions. In request-response mode, it exposes HTTP endpoints with OpenAPI definitions. -There are two engines to which scenarios can be deployed: Flink and Light. Check out [this document](https://nussknacker.io/documentation/about/engines/) to understand which of the two fits fits your use case better. +There are two engines to which scenarios can be deployed: Flink and Light. Check out [this document](https://nussknacker.io/documentation/docs/about/engines/) to understand which of the two fits fits your use case better. ## Why Nussknacker @@ -46,11 +46,11 @@ Nussknacker promises to make developing and deploying real-time decision algorit We discovered that several factors heavily influence the development of algorithms that work with real-time data, including expectations placed on the tools used: - **Domain experts** - often, these are domain experts who conceptualize the algorithms, and the expertise required is very domain specific. Without proper tools for converting algorithms to code, domain experts have to delegate this work to programmers who are proficient in multiple tools, programming languages, and technologies. This approach costs money and takes time. With Nussknacker, domain experts build the algorithm from prefabricated blocks. The trick is to make these prefabricated blocks infinitely flexible to allow for any data transformation and flow control condition. Nussknacker achieves this by using [SpEL](https://nussknacker.io/documentation/docs/scenarios_authoring/Intro/#spel), an easy-to-learn expression language. - **Experimentation** - the algorithms may require a lot of experimentation before one gets them right. If so, the iteration time required to implement a change, deploy it, and see the result should be in single minutes if not seconds. With Nussknacker, non-technical users can achieve iteration time below one minute. -- **Productivity** - if low-code solutions want to be considered tools rather than toys, they must offer features available in professional developer toolkits. Nussknacker Designer has built-in [syntax checking, code completion ](https://nussknacker.io/documentation/about/KeyFeatures/#smart-code-suggestions-and-validation), versioning, [debugging, and testing support](https://nussknacker.io/documentation/docs/next/scenarios_authoring/TestingAndDebugging/). +- **Productivity** - if low-code solutions want to be considered tools rather than toys, they must offer features available in professional developer toolkits. Nussknacker Designer has built-in [syntax checking, code completion ](https://nussknacker.io/documentation/docs/about/KeyFeatures/#smart-code-suggestions-and-validation), versioning, [debugging, and testing support](https://nussknacker.io/documentation/docs/next/scenarios_authoring/TestingAndDebugging/). - **Observability** - experimenting with algorithms requires insights going beyond pure technical metrics like throughput, Kafka topics lag, etc. Out of the box, Nussknacker comes with an integrated and ready-to-use monitoring subsystem which allows monitoring not only technical aspects of the running scenario but also its internal behavior - for example [events count](https://nussknacker.io/documentation/docs/next/scenarios_authoring/TestingAndDebugging/#watching-nodes-filtering-behaviour-with-counts) per scenario step. You will not need to spend developers' time on this functionality. - **Architecture** - last but not least, the fundamentals on which you build matter. Nussknacker achieves exceptional throughput, horizontal scalability, resilience, and high availability through the use of tools and platforms known for their rock-solid architecture - Kafka, Flink, and Kubernetes, which handle all processing tasks. -Check out [this document](https://nussknacker.io/documentation/about/KeyFeatures/) for a concise summary of Nussknacker features. +Check out [this document](https://nussknacker.io/documentation/docs/about/KeyFeatures/) for a concise summary of Nussknacker features. ## Use cases @@ -70,7 +70,7 @@ Nussknacker is typically used as a component of a larger system, but it can be u ## Where to learn more -- [Typical deployment](https://nussknacker.io/documentation/about/TypicalImplementationStreaming/) +- [Typical deployment](https://nussknacker.io/documentation/docs/about/typical%20implementation/Streaming/) - [Authoring scenarios with Nussknacker](https://nussknacker.io/documentation/docs/scenarios_authoring/Intro/) - [Customer success story](https://nussknacker.io/case-studies/real-time-marketing-for-a-telecom-service-provider/) diff --git a/designer/client/src/components/AddProcessForm.tsx b/designer/client/src/components/AddProcessForm.tsx index 46ed621d3b4..dae6dd27805 100644 --- a/designer/client/src/components/AddProcessForm.tsx +++ b/designer/client/src/components/AddProcessForm.tsx @@ -120,7 +120,7 @@ export function AddProcessForm({ Processing mode defines how scenario deployed on an engine interacts with the outside world. Click here to @@ -201,7 +201,7 @@ export function AddProcessForm({ To read more about engines, diff --git a/dockerhub/nussknacker-lite-runtime-app/README.md b/dockerhub/nussknacker-lite-runtime-app/README.md index d183d93a6c7..d0f9166a0c8 100644 --- a/dockerhub/nussknacker-lite-runtime-app/README.md +++ b/dockerhub/nussknacker-lite-runtime-app/README.md @@ -10,7 +10,7 @@ latest-staging - developer build with latest, not released yet features # How to use -This image is not designed to be used from command line at first place. The main purpose of it is to be used programmatically by [Nussknacker K8s Deployment Manager](https://nussknacker.io/documentation/about/engines/LiteArchitecture/). +This image is not designed to be used from command line at first place. The main purpose of it is to be used programmatically by [Nussknacker K8s Deployment Manager](https://nussknacker.io/documentation/docs/about/engines/LiteArchitecture/). If you want to check it manually, the invocation will look like: ``` diff --git a/docs/LicenseInfo.md b/docs/LicenseInfo.md index c8fe6013259..7a360e4ece1 100644 --- a/docs/LicenseInfo.md +++ b/docs/LicenseInfo.md @@ -7,7 +7,7 @@ All the **Nussknacker** code available on [GitHub](https://github.com/TouK/nussk ### Enterprise edition -The [Nussknacker Enterprise](/about/NussknackerEnterprise) version is subject to different license terms. Contact info@nussknacker.io for more information. +The [Nussknacker Enterprise](about/NussknackerEnterprise) version is subject to different license terms. Contact info@nussknacker.io for more information. Additionally, the ML Enricher enterprise component uses [JPMML-Evaluator](https://github.com/jpmml/jpmml-evaluator) library licensed under the BSD 3-Clause License reproduced below: diff --git a/docs/developers_guide/Basics.md b/docs/developers_guide/Basics.md index 9598913f663..1a6015b5379 100644 --- a/docs/developers_guide/Basics.md +++ b/docs/developers_guide/Basics.md @@ -1,6 +1,6 @@ # Overview -Please make sure you know common [Glossary](/documentation/about/GLOSSARY) and [SpEL](../scenarios_authoring/Spel.md) (especially the Data types section) before proceeding further. +Please make sure you know common [Glossary](../about/GLOSSARY) and [SpEL](../scenarios_authoring/Spel.md) (especially the Data types section) before proceeding further. This part of the documentation describes various ways of customizing Nussknacker - from adding own Components to adding listeners for various Designer actions. The main way of adding customizations to Nussknacker is [ServiceLoader](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.html) @@ -21,7 +21,7 @@ We also handle union types (again, similar to [Typescript](https://www.typescrip ## Components and ComponentProviders -[Components](/about/GLOSSARY#component) are main method of customizing Nussknacker. Components are created by configured `ComponentProvider` instances. +[Components](../about/GLOSSARY#component) are main method of customizing Nussknacker. Components are created by configured `ComponentProvider` instances. There are following types of components: - `SourceFactory` - `SinkFactory` diff --git a/docs/installation_configuration_guide/Common.md b/docs/installation_configuration_guide/Common.md index 1caf605d6de..7e2587cbe22 100644 --- a/docs/installation_configuration_guide/Common.md +++ b/docs/installation_configuration_guide/Common.md @@ -17,15 +17,15 @@ Details of K8s based configuration can be found in [Nussknacker Helm chart docu Nussknacker configuration is divided into several configuration areas, each area addressing a specific aspect of using Nussknacker: -* [Designer](/about/GLOSSARY#nussknacker-designer) configuration (web application ports, security, various UI settings, database), +* [Designer](../about/GLOSSARY#nussknacker-designer) configuration (web application ports, security, various UI settings, database), * Scenario Types configuration, comprising of: - * [Model](/about/GLOSSARY#model) configuration. + * [Model](../about/GLOSSARY#model) configuration. * [Scenario Deployment](./ScenarioDeploymentConfiguration.md) configuration, * [Category](./DesignerConfiguration.md/#scenario-type-categories) configuration -[Model](/about/GLOSSARY#model) configuration defines which components and which [Processing Mode](/about/ProcessingModes) will be available for the user. -[Scenario Deployment](./ScenarioDeploymentConfiguration.md) configuration defines how scenario using these components will be deployed on the [Engine](/about/engine). -[Category](./DesignerConfiguration.md/#scenario-type-categories) defines who has access to the given combination of [Model](/about/GLOSSARY#model) and [Scenario Deployment](./ScenarioDeploymentConfiguration.md). +[Model](../about/GLOSSARY#model) configuration defines which components and which [Processing Mode](../about/ProcessingModes) will be available for the user. +[Scenario Deployment](./ScenarioDeploymentConfiguration.md) configuration defines how scenario using these components will be deployed on the [Engine](../about/engine). +[Category](./DesignerConfiguration.md/#scenario-type-categories) defines who has access to the given combination of [Model](../about/GLOSSARY#model) and [Scenario Deployment](./ScenarioDeploymentConfiguration.md). The Scenario Type is a convenient umbrella term that groups all these things. Diagram below presents main relationships between configuration areas. @@ -69,7 +69,7 @@ scenarioTypes {"{"}
It is worth noting that one Nussknacker Designer may be used to work with multiple Scenario Types and allow user: * To use different set of components depending on the category -* To deploy scenarios on different [Engines](/about/engine) +* To deploy scenarios on different [Engines](../about/engines) See [development configuration](https://github.com/TouK/nussknacker/blob/staging/nussknacker-dist/src/universal/conf/dev-application.conf#L33) (used to test various Nussknacker features) for an example of configuration with more than one Scenario Type. diff --git a/docs/installation_configuration_guide/ScenarioDeploymentConfiguration.md b/docs/installation_configuration_guide/ScenarioDeploymentConfiguration.md index ee89626acd9..5b980516d2f 100644 --- a/docs/installation_configuration_guide/ScenarioDeploymentConfiguration.md +++ b/docs/installation_configuration_guide/ScenarioDeploymentConfiguration.md @@ -5,12 +5,12 @@ sidebar_position: 3 # Scenario Deployment configuration -In order to deploy scenario on the given [Engine](/about/engines), you need to configure the deployment. +In order to deploy scenario on the given [Engine](../about/engines), you need to configure the deployment. -Deployment of a scenario is managed by Designer's extension called [Deployment Manager](/about/GLOSSARY#deployment-manager). -To enable given [Deployment Manager](/about/GLOSSARY#deployment-manager) you need to place its jar package in the Designer's classpath. -Nussknacker is distributed with three default [Deployment Managers](/about/GLOSSARY#deployment-manager) (`flinkStreaming`, `lite-k8s`, `lite-embedded`). Their jars are located in the `managers` -directory. Depending on which [Deployment Manager](/about/GLOSSARY#deployment-manager) you've selected, you should provide parameters values for it specifically - see sections below to find out available parameters. +Deployment of a scenario is managed by Designer's extension called [Deployment Manager](../about/GLOSSARY#deployment-manager). +To enable given [Deployment Manager](../about/GLOSSARY#deployment-manager) you need to place its jar package in the Designer's classpath. +Nussknacker is distributed with three default [Deployment Managers](../about/GLOSSARY#deployment-manager) (`flinkStreaming`, `lite-k8s`, `lite-embedded`). Their jars are located in the `managers` +directory. Depending on which [Deployment Manager](../about/GLOSSARY#deployment-manager) you've selected, you should provide parameters values for it specifically - see sections below to find out available parameters. Section with `deploymentConfig` needs to be placed in the correct place in the Designer's configuration. Check [configuration areas](./Common.md#configuration-areas) to understand the structure of the configuration. @@ -27,12 +27,12 @@ deploymentConfig { ``` Parameters: -- `type` parameter determines the type of the [Deployment Manager](/about/GLOSSARY#deployment-manager). Possible options are: `flinkStreaming`, `lite-k8s`, `lite-embedded` +- `type` parameter determines the type of the [Deployment Manager](../about/GLOSSARY#deployment-manager). Possible options are: `flinkStreaming`, `lite-k8s`, `lite-embedded` - `engineSetupName` parameter is optional. It specifies how the engine will be displayed in the GUI. If not specified, default name will be used instead (e.g. `Flink` for `flinkStreaming` Deployment Manager). ## Kubernetes native Lite engine configuration -Please check high level [Lite engine description](https://nussknacker.io/documentation/about/engines/LiteArchitecture/#scenario-deployment) before proceeding to configuration details. +Please check high level [Lite engine description](https://nussknacker.io/documentation/docs/about/engines/LiteArchitecture/#scenario-deployment) before proceeding to configuration details. Please note, that K8s Deployment Manager has to be run with properly configured K8s access. If you install the Designer in K8s cluster (e.g. via Helm chart) this comes out of the box. If you want to run the Designer outside the cluster, you have to configure `.kube/config` properly. diff --git a/docs/installation_configuration_guide/model/ModelConfiguration.md b/docs/installation_configuration_guide/model/ModelConfiguration.md index 9ff2f65f2c1..aa7051af1fa 100644 --- a/docs/installation_configuration_guide/model/ModelConfiguration.md +++ b/docs/installation_configuration_guide/model/ModelConfiguration.md @@ -5,9 +5,9 @@ sidebar_position: 1 # Model configuration Model definition is part of a scenario type definition. There can be multiple scenario types in one Nussknacker installation, consequently there will also be multiple model definitions in such a case. -Check [configuration areas](docs/installation_configuration_guide/Common.md#configuration-areas) to understand where Model configuration should be placed in the Nussknacker configuration. If you deploy to K8s using Nussknacker Helm chart, check [here](../ScenarioDeploymentConfiguration.md#overriding-configuration-passed-to-runtime) how to supply additional model configuration. +Check [configuration areas](../Common.md#configuration-areas) to understand where Model configuration should be placed in the Nussknacker configuration. If you deploy to K8s using Nussknacker Helm chart, check [here](../ScenarioDeploymentConfiguration.md#overriding-configuration-passed-to-runtime) how to supply additional model configuration. -Model defines how to configure [components](/about/GLOSSARY#component) and certain runtime behavior (e.g. error handling) for a given scenario type. Model configuration is processed not only at the Designer but also passed to the execution engine (e.g. Flink), that’s why it’s parsed and processed a bit differently: +Model defines how to configure [components](../../about/GLOSSARY#component) and certain runtime behavior (e.g. error handling) for a given scenario type. Model configuration is processed not only at the Designer but also passed to the execution engine (e.g. Flink), that’s why it’s parsed and processed a bit differently: * Some Components can use a special mechanism which resolves and adds additional configuration during deployment, which is then passed to the execution engine. Such configuration is read and resolved only at the Designer. Example: OpenAPI enrichers need to read its definition from external sites - so e.g. Flink cluster does not have to have access to the site with the definition. * There is additional set of defaults, taken from `defaultModelConfig.conf` if it exists on the classpath. The standard Nussknacker installation uses the one from [here](https://github.com/TouK/nussknacker/blob/staging/defaultModel/src/main/resources/defaultModelConfig.conf), installations using certain code customizations may use a different one. @@ -42,9 +42,9 @@ Nussknacker comes with a set of provided components. Some of them (e.g. `filter` predefined and accessible by default. Others need additional configuration - the most important ones are enrichers, where you have to set e.g. JDBC URL or external service address. Check Integration documentation for the details on how to configure the following components: -- [OpenAPI](docs/integration/OpenAPI.md) Supports accessing external APIs directly from scenario -- [SQL](docs/integration/Sql.md) Supports access to SQL database engines -- [Machine Learning](docs/integration/MachineLearning.md) Infers ML models +- [OpenAPI](../../integration/OpenAPI.md) Supports accessing external APIs directly from scenario +- [SQL](../../integration/Sql.md) Supports access to SQL database engines +- [Machine Learning](../../integration/MachineLearning.md) Infers ML models ### Configuration of component providers diff --git a/docs/integration/KafkaIntegration.md b/docs/integration/KafkaIntegration.md index cb3a722d202..2712638546b 100644 --- a/docs/integration/KafkaIntegration.md +++ b/docs/integration/KafkaIntegration.md @@ -8,7 +8,7 @@ sidebar_position: 1 To better understand how Nussknacker works with Kafka, it's recommended to read the following first: * [Kafka introduction](https://kafka.apache.org/intro) -* [Role of Schema Registry](/about/TypicalImplementationStreaming/) +* [Role of Schema Registry](../about/typical%20implementation/Streaming.md) * [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html) If you want to use Flink engine, this is also recommended: diff --git a/docs/operations_guide/Common.md b/docs/operations_guide/Common.md index d9900d19900..84aba409f33 100644 --- a/docs/operations_guide/Common.md +++ b/docs/operations_guide/Common.md @@ -9,7 +9,7 @@ The parts describing scenario management and tuning should be accessible also fo To better understand the documentation below one needs to grasp some concepts of metrics, etc. We won’t go into much detail here, only give references to worthy resources. -Some of them are external, but it also helps to read about important Nussknacker concepts in [glossary](/about/GLOSSARY) and [scenario authoring](../scenarios_authoring/Intro.md). +Some of them are external, but it also helps to read about important Nussknacker concepts in [glossary](../about/GLOSSARY) and [scenario authoring](../scenarios_authoring/Intro.md). ### Integration with Apache Kafka diff --git a/docs/scenarios_authoring/DataSourcesAndSinks.md b/docs/scenarios_authoring/DataSourcesAndSinks.md index 5d31ccfb609..d335d2a2b75 100644 --- a/docs/scenarios_authoring/DataSourcesAndSinks.md +++ b/docs/scenarios_authoring/DataSourcesAndSinks.md @@ -8,7 +8,7 @@ sidebar_position: 3 This page covers topics specific to the Streaming processing mode. Please read the [common introduction](Intro.md) before proceeding. The components which implement aggregates in the time windows (Flink engine only) are covered [here](AggregatesInTimeWindows.md). -In the Streaming processing mode the scenario processes events. They are read from Kafka topics and processed by the [engine](/about/engines/) of choice: Flink or Lite. At the end of the scenario, events which represent results or decisions are written to Kafka topic(s). +In the Streaming processing mode the scenario processes events. They are read from Kafka topics and processed by the [engine](../about/engines/) of choice: Flink or Lite. At the end of the scenario, events which represent results or decisions are written to Kafka topic(s).   ## Prerequisites diff --git a/docs/scenarios_authoring/Enrichers.md b/docs/scenarios_authoring/Enrichers.md index 4aad5b6a0c0..1619f1fb857 100644 --- a/docs/scenarios_authoring/Enrichers.md +++ b/docs/scenarios_authoring/Enrichers.md @@ -11,7 +11,7 @@ Usually not all required data are in the data record - some data may reside in a ## Concepts -Please check [Glossary](/about/GLOSSARY) to understand difference between component and the node (and between configuration of a component and configuration of a node). Understanding the role of [SpEL](/docs/scenarios_authoring/Intro#spel) will greatly accelerate your first steps with Nussknacker. +Please check [Glossary](../about/GLOSSARY) to understand difference between component and the node (and between configuration of a component and configuration of a node). Understanding the role of [SpEL](/docs/scenarios_authoring/Intro#spel) will greatly accelerate your first steps with Nussknacker. Enricher components need to be added to the Model configuration first; once they are added they will become available in the Designer's components toolbox. Check [configuration areas](/docs/installation_configuration_guide/ModelConfiguration/#components-configuration) for the overview of the configuration and [configuration of extra components](../integration/OpenAPI.md) for details of how to configure enricher components. diff --git a/docs/scenarios_authoring/Intro.md b/docs/scenarios_authoring/Intro.md index 32232d13235..b5c670a0767 100644 --- a/docs/scenarios_authoring/Intro.md +++ b/docs/scenarios_authoring/Intro.md @@ -24,7 +24,7 @@ Every scenario has to start with a datasource - we have to specify what kind of The nodes affect the data records as they flow through the scenario. In a typical scenario, you first check if a particular situation (data record) is of interest to you (you [filter](./BasicNodes.md#filter) out the ones that aren't). Then you fetch additional information needed to make the decision ([enrich](./Enrichers.md) the event) and add some conditional logic based on that information ([choice](./BasicNodes.md#choice)). If you want to explore more than one alternative, you can at any point [split](./BasicNodes.md#split) the flow into parallel paths. At the end of every scenario is a sink node (or nodes if there are parallel paths which haven't been [merged](./BasicNodes.md#union)). -In the **Streaming** [processing mode](/about/ProcessingModes) the data records processed by a scenario are called events. They are read from Kafka topics and processed by an [engine](/about/engines/) of choice: Flink or Lite. Events enter the scenario "via" a source node. The nodes process events; once the node finishes processing of an event, it hands it over to the next node in the processing flow. If there is a [split](./BasicNodes.md#split) node, the event gets "multiplied" and now two or more events "flow" in parallel through branches of the scenario. There are also other nodes which can "produce" events; for example the [for-each](./BasicNodes.md#foreach) node or [time aggregate](AggregatesInTimeWindows.md) nodes. Finally, some nodes may terminate an event - for example the [filter](./BasicNodes.md#filter) node. The important takeaway here is that a single event that entered a scenario may result in zero, one or many events leaving the scenario (being written to Kafka topic). +In the **Streaming** [processing mode](../about/ProcessingModes) the data records processed by a scenario are called events. They are read from Kafka topics and processed by an [engine](/about/engines/) of choice: Flink or Lite. Events enter the scenario "via" a source node. The nodes process events; once the node finishes processing of an event, it hands it over to the next node in the processing flow. If there is a [split](./BasicNodes.md#split) node, the event gets "multiplied" and now two or more events "flow" in parallel through branches of the scenario. There are also other nodes which can "produce" events; for example the [for-each](./BasicNodes.md#foreach) node or [time aggregate](AggregatesInTimeWindows.md) nodes. Finally, some nodes may terminate an event - for example the [filter](./BasicNodes.md#filter) node. The important takeaway here is that a single event that entered a scenario may result in zero, one or many events leaving the scenario (being written to Kafka topic). In the **Request-Response** processing mode it is a request data record which enters a scenario. The best and easiest way to understand how this request will be processed by Nussknacker's scenario is to think of it as of Streaming mode with a singular event. All the considerations from the previous paragraph apply. The most important trait of a **Request-Response** scenario is that it's synchronous: some other computer system sends a request to Nussknacker and awaits a response. That request is the input to the scenario and the output - the decision - is a response. Since the other system is awaiting a response, there has to be exactly one. The natural question to ask is what will happen when there are nodes in the scenario which "produce" additional data records - for-each or split. The topic of how to handle such situations is covered [here](RRDataSourcesAndSinks.md#scenario-response-in-scenarios-with-split-and-for-each-nodes).