1.2.2 logs and documentation (#38)

* Accept a list of server in the BPMN list

* Documentation

* Change image to ghcr.io/camunda-community-hub/process-execution-automator:latest

README.md

@@ -79,7 +79,7 @@ The unit scenario describes one process instance execution. Creation and user ta
 This functionality is used to run regression tests, coverage tests, or just advance process instances in the process
 for the development.
 
-Visit (Unit Scenario)[doc/unitscenario/README.md]
+Visit [Unit Scenario](doc/unitscenario/README.md)
 
 ### Load test (flowscenario)
 
@@ -89,12 +89,12 @@ The flow scenario has a duration and objective to verify.
 
 You can specify objectives: produce 1000 Process Instances, end 500 process instances, and produce 300 tasks in a user task.
 
-Visit (Load Test Scenario)[doc/loadtestscenario/README.md] and the (Load test Tutorial) [doc/loadtestscenario/Tutorial.md]
+Visit [Load Test Scenario](doc/loadtestscenario/README.md) and the [Load test Tutorial](doc/loadtestscenario/Tutorial.md)
 
 ## Scenario
 
 This section references all the information to build a scenario.
-Visit (Scenario reference)[doc/scenarioreference/README.md]
+Visit [Scenario reference](doc/scenarioreference/README.md)
 
 
 ## Connect to a server

doc/applicationreference/README.md

@@ -1,9 +1,9 @@
 # Application reference
 
-This document gives the different parameter to use the application
+This document gives the different parameters to use the application.
 
-These parameters can be used in a the propertie file (YAML, PROPERTIE) or as a parameter 
-in the docker/kubernetes file.
+These parameters can be used in the properties file (YAML, PROPERTIES) or as a parameter
+in the docker/Kubernetes file.
 
 
 For example, for a variable  `automator.startup.scenarioPath`, you can define this like
@@ -26,7 +26,7 @@ env:
 
 ## general
 
-This section is dedicated to get main information
+This section is dedicated to getting the primary information.
 
 | Parameter           | Explanation                      | Type     | Default |
 |---------------------|----------------------------------|----------|---------|
@@ -36,15 +36,15 @@ This section is dedicated to get main information
 
 ## Startup
 
-These variable pilot the application at startup. 
+These variables pilot the application at startup.
 
-The policy Execution give action to execute at the startup:
-* DEPLOYPROCESS: scenario presents in the scenario are deployed. They must be accessible in the scenarioPath.
-This scenario path must be accessible by the image: using a PVC or a ConfigMap (See the Kubernetes part)
-* WARMINGUP: If the scenario declare a warming, this phase is executed
-* CREATION: if the scenario declare a process instance creation, this phase is executed
-* SERVICETASK: if the scenario declare service simulation task, they are executed. If a `filterService` is declared, only service matching the filter are executed
-* USERTASK: If the scenario declare user task, they are executed.
+The policy Execution gives action to execute at the startup:
+* DEPLOYPROCESS: The scenario presented in the scenario is deployed. They must be accessible in the scenarioPath.
+  This scenario path must be accessible by the image using a PVC or a ConfigMap (See the Kubernetes part)
+* WARMINGUP: If the scenario declares a warming, this phase is executed
+* CREATION: if the scenario declares a process instance creation, this phase is executed
+* SERVICETASK: if the scenario declares service simulation task, they are executed. If a `filterService` is declared, only services matching the filter are executed
+* USERTASK: If the scenario declares user task, they are executed.
 
 | Parameter                                   | Explanation                                                                               | Type   | Default |
 |---------------------------------------------|-------------------------------------------------------------------------------------------|--------|---------|
@@ -57,11 +57,11 @@ This scenario path must be accessible by the image: using a PVC or a ConfigMap (
 
 
 ### Load scenario from file
-A scenarioPath and a multiple scenarioFile are given, and are loaded from this part.
+A scenarioPath and a multiple scenarioFile are given and are loaded from this part.
 
 ### Load scenario from resource
 Passing the scenario file to a running container is more challenging.
-Check the  (Kubernetes manual)[doc/kubernetes/README.md] to see in detail.
+In detail, check the  (Kubernetes manual)[doc/kubernetes/README.md].
 
 The idea is:
 * to load the scenario in a config map
@@ -73,11 +73,10 @@ The idea is:
 
 ## Servers
 
-This section declared a list of servers. Each server has a name. In scenario, server are using: scenario declare the 
-scenario must be executed on the server "Diamond".
+This section declared a list of servers. Each server has a name. In a scenario, servers are using: it must be executed on the server "Diamond".
 This section declared how to connect the server "Diamond": is that a Camunda7 server or Camunda 8? What are the properties to connect to the server?
 
-There is two ways to declare a list of server:
+There ed is two ways to declare a list of server:
 a ServerString Connection.
 
 This is a list of <name>,CAMUNDA_7|CAMUNDA_8,(<property>)*
@@ -87,21 +86,21 @@ For Camunda 7:
 <name>,CAMUNDA_7,<url>
 ```
 
-For Camunda 8 Self manage
+For Camunda 8 to Self-manage
 ```
-<name>,CAMUNDA_8,ZeebeGatewayAddress,OperateUserName,OperateUserPassword,OperateUrl
+<name>,CAMUNDA_8,ZeebeGatewayAddress,OperateUserName,OperateUserPassword,OperateUrl,ExecutionThreads,MaxJobActive;
 ```
 
 For Camunda 8 Saas:
 ```
-<name>,CAMUNDA_8_SAAS,zeebeCloudRegister,zeebeCloudRegion,zeebeCloudClusterId,zeebeCloudClientId,clientSecret,OperateUserName,OperateUserPassword,OperateUrl
+<name>,CAMUNDA_8_SAAS,zeebeCloudRegister,zeebeCloudRegion,zeebeCloudClusterId,zeebeCloudClientId,clientSecret,OperateUserName,OperateUserPassword,OperateUrl,ExecutionThreads,MaxJobActive
 ```
 
 
 
 
-# other way to provide the list of server connection
-In the YAML, the list of server can by giving
+# Another way to provide the list of server connection
+In the YAML, the list of servers can be done by giving
 
 ```
 automator.servers:

doc/docker/README.md

@@ -4,7 +4,7 @@
 ## Manual
 
 ````
-> docker build -t pierreyvesmonnet/processautomator:1.0.0 .
+> docker build -t myGithubID/processautomator:1.0.0 .
 
-> docker push pierreyvesmonnet/processautomator:1.0.0
+> docker push myGithubID/processautomator:1.0.0
 ````

doc/kubernetes/README.md

@@ -29,7 +29,7 @@ spec:
     spec:
       containers:
         - name: camunda-8-processautomator-service
-          image: pierreyvesmonnet/processautomator:1.0.3
+          image: ghcr.io/camunda-community-hub/process-execution-automator:latest
           imagePullPolicy: Always
           env:
             - name: JAVA_TOOL_OPTIONS