[Issue_595] Holistic review of non-quarkus persistence chapter (#656)

[Fixes_595] Holistic review of non-quarkus persistence chapter

serverlessworkflow/modules/ROOT/pages/cloud/operator/supporting-services.adoc

@@ -93,15 +93,15 @@ Additionally, using the `SonataFlowClusterPlatform` CR it's possible to configur
 [#ephemeral-persistence-configuration]
 === Ephemeral persistence configuration
 
-The ephemeral persistence of a service is supported by an embedded PostgreSQL database dedicated to it. That database, is re-created by the operator on every service restart.
+The ephemeral persistence of a service is supported by an embedded PostgreSQL database dedicated to it. That database is re-created by the operator on every service restart.
 And thus, it's only recommended for development and testing purposes.
 
 The ephemeral deployment of a service requires no additional configurations than the shown, <<supporting-services-configuration, here>>.
 
 [#postgresql-persistence-configuration]
 === PostgreSQL persistence configuration
 
-The PosgreSQL persistence of a service is supported by a PostgreSQL server instance, that you must previously install on the cluster.
+The PostgreSQL persistence of a service is supported by a PostgreSQL server instance that you must previously install on the cluster.
 The administration of that instance is totally independent of the {operator_name} scope, and to connect a supporting service with it, you must only configure the correct database connection parameters.
 
 The following `SonataFlowPlatform` CR fragment shows the configuration options that you must use:

serverlessworkflow/modules/ROOT/pages/data-index/data-index-service.adoc

@@ -13,7 +13,7 @@
 [#data-index-service]
 == {data_index_ref} service deployment
 
-{data_index_ref} service can be deployed referencing directly a distributed {data_index_ref} image. There are different images provided that take into account what persistence layer is required in each case.
+{data_index_ref} service can be deployed by referencing a distributed {data_index_ref} image directly. There are different images provided that take into account what persistence layer is required in each case.
 In each distribution, there are some properties to configure things like the connection with the database or the communication with other services.
 The goal is to configure the container to allow to process ProcessInstances and Jobs *events* that incorporate their related data, to index and store that in the database and finally, to provide the xref:data-index/data-index-core-concepts.adoc#data-index-graphql[{data_index_ref} GraphQL] endpoint to consume it.
 
@@ -29,7 +29,7 @@ There are several ways to deploy the {data_index_ref} service. But there are som
 
 . Reference the right {data_index_ref} image to match with the type of Database that will store the indexed data.
 . Provide the database connection properties, to allow data index store the indexed data. {data_index_ref} service does not initialize its database schema automatically. To initialize the database schema, you need to enable Flyway migration by setting QUARKUS_FLYWAY_MIGRATE_AT_START=true.
-. Define the `KOGITO_DATA_INDEX_QUARKUS_PROFILE` to set the way that the events will be connected (by default: `kafka-event-support`).
+. Define the `KOGITO_DATA_INDEX_QUARKUS_PROFILE` to set the way that the events will be connected (by default: `kafka-events-support` but could be also `http-events-support`).
 
 [NOTE]
 ====
@@ -187,7 +187,7 @@ spec:
             - name: QUARKUS_FLYWAY_MIGRATE_AT_START <4>
               value: "true"
             - name: KOGITO_DATA_INDEX_QUARKUS_PROFILE <3>
-              value: "http-events-support"
+              value: http-events-support
             - name: QUARKUS_HTTP_PORT
               value: "8080"
 ---

serverlessworkflow/modules/ROOT/pages/job-services/core-concepts.adoc

@@ -401,7 +401,7 @@ Using environment variables::
 |Variable | Description| Default value
 
 |`QUARKUS_PROFILE`
-|Set the quarkus profile with the value `kafka-events_support` to enable the kafka messaging based Job Service Eventing API.
+|Set the quarkus profile with the value `kafka-events-support` to enable the kafka messaging based Job Service Eventing API.
 |By default, the kafka eventing api is disabled.
 
 |`KOGITO_JOBS_SERVICE_KAFKA_JOB_STATUS_CHANGE_EVENTS`
@@ -414,11 +414,11 @@ Using environment variables::
 
 |`MP_MESSAGING_INCOMING_KOGITO_JOB_SERVICE_JOB_REQUEST_EVENTS_V2_TOPIC`
 |Kafka topic for events API incoming events. In general you don't need to change this value.
-|`kogito-job-service-job-request-events-v2` when the `kafka-events_support` profile is set.
+|`kogito-job-service-job-request-events-v2` when the `kafka-events-support` profile is set.
 
 |`MP_MESSAGING_OUTGOING_KOGITO_JOB_SERVICE_JOB_STATUS_EVENTS_TOPIC`
 |Kafka topic for job status change outgoing events. In general you don't need to change this value.
-|`kogito-jobs-events` when the `kafka-events_support` profile is set.
+|`kogito-jobs-events` when the `kafka-events-support` profile is set.
 
 |===
 
@@ -430,7 +430,7 @@ Using system properties with java like names::
 |Variable | Description| Default value
 
 |quarkus.profile
-|Set the quarkus profile with the value `kafka-events_support` to enable the kafka messaging based Job Service Eventing API.
+|Set the quarkus profile with the value `kafka-events-support` to enable the kafka messaging based Job Service Eventing API.
 |By default, the kafka eventing api is disabled.
 
 |`kogito.jobs-service.kafka.job-status-change-events`
@@ -443,11 +443,11 @@ Using system properties with java like names::
 
 |`mp.messaging.incoming.kogito-job-service-job-request-events-v2.topic`
 |Kafka topic for events API incoming events. In general you don't need to change this value.
-|`kogito-job-service-job-request-events-v2` when the `kafka-events_support` profile is set.
+|`kogito-job-service-job-request-events-v2` when the `kafka-events-support` profile is set.
 
 |`mp.messaging.outgoing.kogito-job-service-job-status-events.topic`
 |Kafka topic for job status change outgoing events. In general you don't need to change this value.
-|`kogito-jobs-events` when the `kafka-events_support` profile is set.
+|`kogito-jobs-events` when the `kafka-events-support` profile is set.
 
 |===
 

serverlessworkflow/modules/ROOT/pages/persistence/core-concepts.adoc

@@ -9,7 +9,7 @@
 SonataFlow provides two persistence mechanisms to store information about the workflow instances.
 The <<_workflow_runtime_persistence, Workflow runtime persistence>>, and <<_data_index_persistence, Data Index persistence>>.
 
-Each mechanism is intended for different a purpose:
+Each mechanism is intended for a different purpose:
 
 image::persistence/Persistence-Types.png[]
 
@@ -35,13 +35,16 @@ This is achieved by properly configuring and deploying the xref:data-index/data-
 To learn how to configure and deploy the Data Index Service we recommend that you read the following sections depending on your use case:
 
 * xref:cloud/operator/supporting-services.adoc[Deploying supporting services with {operator_name}]
-* xref:data-index/data-index-service.adoc/[Data Index standalone service]
+* xref:data-index/data-index-service.adoc[Data Index standalone service]
 
 To learn more about this service, examine the links in additional resources.
 
 == Additional resources
 
 * xref:data-index/data-index-core-concepts.adoc[]
-* xref:data-index/data-index-service.adoc[]
+* xref:use-cases/advanced-developer-use-cases/data-index/data-index-as-quarkus-dev-service.adoc[]
+* xref:use-cases/advanced-developer-use-cases/data-index/data-index-usecase-singleton.adoc[]
+* xref:use-cases/advanced-developer-use-cases/data-index/data-index-usecase-multi.adoc[]
+* xref:use-cases/advanced-developer-use-cases/data-index/data-index-quarkus-extension.adoc[]
 
 include::../../pages/_common-content/report-issue.adoc[]