Apply Janas suggestions

Author: GitHub Actions

assemblies/assembly-orchestrator-rhdh.adoc

@@ -35,6 +35,9 @@ include::modules/orchestrator/con-orchestrator-plugin-dependencies-operator.adoc
 // installing the components for the orchestrator plugin
 include::modules/orchestrator/con-orchestrator-plugin-components.adoc[leveloffset=+1]
 
+// enabling orchestrator plugins components
+include::modules/orchestrator/proc-enabling-orchestrator-plugins.adoc[leveloffset=+1]
+
 // Orchestrator Infrastructure for {product} Helm chart
 include::modules/orchestrator/proc-helm-install-components-orchestrator-plugin.adoc[leveloffset=+2]
 

images/rhdh/container-diagram-orch.png

@@ -3,44 +3,25 @@
 [id="con-architecture-overview.adoc_{context}"]
 = Architecture overview
 
-You can use Orchestrator to design, run, and monitor workflows that automate key tasks. The Orchestrator relies on core components, such as SonataFlow and OpenShift Serverless, to provide the necessary runtime environment and event-driven capabilities needed to power your workflows.
-
-image::rhdh/system-context-diagram-orch.png[]
-
-The Orchestrator architecture is composed of several integral components, each contributing to the seamless execution and management of workflows.
-
-image::rhdh/container-diagram-orch.png[]
-
-The following is a breakdown of these components:
+The Orchestrator architecture is composed of several integral components, each contributing to the seamless running and management of workflows.
 
 {product} ({product-very-short}):: Serves as the primary interface. {product-custom-resource-type} fulfills the following roles:
 
-* Orchestrator Plugins: Both frontend and backend present deployed workflows for execution and monitoring.
-* Notifications Plugin: Inform users about workflow events.
+* Orchestrator Plugins: Both frontend and backend plugins provide the interface and necessary data retrieval for users to run and monitor workflows within {product-very-short}.
+* Notifications Plugin: Informs users about workflow events.
 
-image::rhdh/orchestrator-plugins.png[]
+OpenShift Serverless Logic Operator:: Manages the Sonataflow custom resource (CR), where each CR represents a deployed workflow.
 
-OpenShift Serverless Logic Operator:: This controller manages the Sonataflow custom resource (CR), where each CR denotes a deployed workflow.
-
-Sonataflow Runtime/Workflow Application:: Functions as a deployed workflow. Sonataflow Runtime is managed as a Kubernetes (K8s) deployment by the Operator. It operates as an HTTP server catering to requests for executing workflow instances. Within the Orchestrator deployment, each Sonataflow custom resource (CR) corresponds to a singular workflow. However, outside this scope, Sonataflow Runtime can handle multiple workflows. The Orchestrator backend plugin facilitates the interaction with Sonataflow Runtime for workflow execution.
+Sonataflow Runtime/Workflow Application:: Functions as a deployed workflow. Operates as an HTTP server, catering to requests for running workflow instances. Sonataflow Runtime is managed as a Kubernetes (K8s) deployment by the Openshift Serverless Logic Operator. Within the Orchestrator deployment, each Sonataflow custom resource (CR) corresponds to a singular workflow. However, outside this scope, Sonataflow Runtime can handle multiple workflows. The Orchestrator backend plugin facilitates the interaction with Sonataflow Runtime for workflow execution.
 
 Data Index Service:: Serves as a repository for workflow definitions, instances, and associated jobs. It exposes a GraphQL API used by the Orchestrator backend plugin to retrieve workflow definitions and instances.
 
-Job Service:: Dedicated to orchestrating scheduled tasks for workflows.
-
-OpenShift Serverless:: This Operator furnishes serverless capabilities essential for workflow communication. It employs Knative eventing to interface with the Data Index service and uses Knative functions to introduce more intricate logic to workflows.
-
-PostgreSQL Server:: PostgreSQL Server provides a robust and reliable database solution essential for data persistence within the Orchestrator ecosystem. The system uses PostgreSQL Server for storing both Sonataflow information and {product-custom-resource-type} data.
-
-KeyCloak:: KeyCloak is essential for authentication and security services within applications. KeyCloak must be provisioned externally to manage authentication, as the Orchestrator Operator does not install it.
+Job Service:: Orchestrates scheduled tasks for workflows.
 
-OpenShift AMQ Streams (Strimzi/Kafka):: This Operator is crucial for ensuring the reliability of the eventing system. While the eventing can work without Kafka by using direct HTTP calls, this approach is not reliable. The AMQ Streams Operator is not natively present or integrated into the deployment current iteration.
+OpenShift Serverless:: Furnishes serverless capabilities essential for workflow communication. It employs Knative eventing to interface with the Data Index service and uses Knative functions to introduce more intricate logic to workflows.
 
-{product-very-short} includes the following Orchestrator plugin components in the `dynamic-plugins.default.yaml` file, but it disables them by default:
+PostgreSQL Server:: Provides a robust and reliable database solution essential for data persistence within the Orchestrator ecosystem. The system uses PostgreSQL Server for storing both Sonataflow information and {product-custom-resource-type} data.
 
-* `"backstage-plugin-orchestrator"`
-* `"backstage-plugin-orchestrator-backend-dynamic"`
-* `"backstage-plugin-scaffolder-backend-module-orchestrator-dynamic"`
-* `"backstage-plugin-orchestrator-form-widgets"`
+KeyCloak:: Provides authentication and security services within applications. KeyCloak must be provisioned externally to manage authentication, as the Orchestrator Operator does not install it.
 
-To enable these plugins, you must set the `plugins.disabled` parameter to `false`.
+OpenShift AMQ Streams (Strimzi/Kafka):: Ensures the reliability of the eventing system. While the eventing can work without Kafka by using direct HTTP calls, this approach is not reliable. The AMQ Streams Operator is not natively present or integrated into the deployment current iteration.

images/rhdh/orchestrator-plugins.png

@@ -0,0 +1,23 @@
+:_mod-docs-content-type: PROCEDURE
+
+[id="proc-enabling-orchestrator-plugins.adoc_{context}"]
+= Enabling Orchestrator plugins components
+
+{product} includes the following Orchestrator plugin components in the `dynamic-plugins.default.yaml` file, but they are disabled by default:
+
+* `"backstage-plugin-orchestrator"`
+* `"backstage-plugin-orchestrator-backend-dynamic"`
+* `"backstage-plugin-scaffolder-backend-module-orchestrator-dynamic"`
+* `"backstage-plugin-orchestrator-form-widgets"`
+
+.Procedure
+* To enable the Orchestrator plugins, locate your {product-short} configuration and set the `plugins.disabled` parameter to `false` for each required plugin package.
++
+For example, to enable the core Orchestrator frontend plugin:
++
+[source,yaml,subs="+attributes,+quotes"]
+----
+plugins:
+  - package: "@redhat/backstage-plugin-orchestrator@{product-chart-version}"
+    disabled: false
+----