Align get-started tutorials with Operaton Modeler

docs/get-started/archive/java-process-app/forms.md

@@ -17,7 +17,7 @@ In the next step, we want to add a task form to the application.
 
 ## Add a Start Form
 
-Create a new form in Camunda Modeler and set its id to `request-loan`.
+Create a new form in Operaton Modeler and set its id to `request-loan`.
 
 Add a **Text Field**, set the **Field Label** to `Customer ID` and the **Key** to `customerId`.
 

docs/get-started/archive/java-process-app/service-task.md

@@ -18,7 +18,7 @@ In the last section of this tutorial we learn how to invoke a Java class from a
 
 ## Add a Service Task to the Process
 
-Use the Camunda Modeler to add a service task after the user task. To do so, select the activity shape (rectangle) and drag it onto a sequence flow (see screenshot). Name it *Process Request*. Change the activity type to *Service Task* by clicking on it and using the wrench button.
+Use the Operaton Modeler to add a service task after the user task. To do so, select the activity shape (rectangle) and drag it onto a sequence flow (see screenshot). Name it *Process Request*. Change the activity type to *Service Task* by clicking on it and using the wrench button.
 
 
 ![Example image](/img/get-started/archive/java-process-app/modeler-service-task1.png)

docs/get-started/archive/javaee7/complete-process.md

@@ -57,7 +57,7 @@ A new conversation is started again before the view is rendered and the task is
 
 ![Example image](/img/get-started/archive/javaee7/pizza-order-process-prepare-pizza.png)
 
-Open the process with Camunda Modeler. Click on the prepare pizza user task. In the properties view, set the `Form Key` property to `app:preparepizza.jsf`.
+Open the process with Operaton Modeler. Click on the prepare pizza user task. In the properties view, set the `Form Key` property to `app:preparepizza.jsf`.
 
 When you are done, save all resources, [perform a Maven build](../deploy/#build-the-process-application), and [redeploy](../deploy/#deploy-to-wildfly) the process application.
 
@@ -98,11 +98,11 @@ public class OrderBusinessLogic {
 
 ![Example image](/img/get-started/archive/javaee7/pizza-order-process-send-rejection-email.png)
 
-Open the process with Camunda Modeler. Click on the reject email service task. In the properties view, set the `Expression` property to `${orderBusinessLogic.rejectOrder(execution)}`.
+Open the process with Operaton Modeler. Click on the reject email service task. In the properties view, set the `Expression` property to `${orderBusinessLogic.rejectOrder(execution)}`.
 
 When you are done, save all resources, [perform a Maven build](../deploy/#build-the-process-application) and [redeploy](../deploy/#deploy-to-wildfly) the process application. You can now approve and reject an order in [Tasklist](http://localhost:8080/operaton/app/tasklist). The output of the `Send Rejection Email` task can be checked by looking into the logfile of the WildFly server. It should state that a rejection email has been sent:
 
 <pre class="console">
   Sending Email:
   Dear asdf, your order 2 of a Margarita pizza has been rejected.
-</pre>
+</pre>

docs/get-started/dmn/drg.md

@@ -13,10 +13,10 @@ menu:
 aliases: [/dmn/drg/]
 ---
 
-In this step, we extend the previous example by a second decision *Beverages* which uses the *Dish* decision table as input. We model this dependency between the decisions within a Decision Requirements Graph (DRG) using the Camunda Modeler. Then, we adjust the Application class to evaluate the *Beverages* decision, deploy the web application to Apache Tomcat and verify the result in Cockpit.
+In this step, we extend the previous example by a second decision *Beverages* which uses the *Dish* decision table as input. We model this dependency between the decisions within a Decision Requirements Graph (DRG) using the Operaton Modeler. Then, we adjust the Application class to evaluate the *Beverages* decision, deploy the web application to Apache Tomcat and verify the result in Cockpit.
 
 :::note[Decision Requirements Graph vs. Decision Requirements Diagram]
-The visual representation of a Decision Requirements Graph (DRG) is called Decision Requirements Diagram (DRD). In the context of the Camunda Modeler, we name it DRD because we use the visual representation to model the DRG.
+The visual representation of a Decision Requirements Graph (DRG) is called Decision Requirements Diagram (DRD). In the context of the Operaton Modeler, we name it DRD because we use the visual representation to model the DRG.
 :::
 
 ## Switch from Decision Table to DRD
@@ -143,4 +143,4 @@ Note that the *Dish* decision is evaluated as part of the evaluation of the *Bev
 Next,
 
 * learn more about DRG by reading the [DMN Reference](/docs/documentation/reference/dmn/drg),
-* learn more about [DMN in Cockpit](https://docs.operaton.org/docs/documentation/webapps/cockpit/dmn/)
+* learn more about [DMN in Cockpit](/docs/documentation/webapps/cockpit/dmn/)

docs/get-started/dmn/model.md

@@ -8,14 +8,14 @@ menu:
     name: "Create a Decision Table"
     parent: "get-started-dmn"
     identifier: "get-started-dmn-model"
-    description: "Learn the basics of handling the Camunda Modeler and learn how to create and configure a fully executable decision table."
+    description: "Learn the basics of handling the Operaton Modeler and learn how to create and configure a fully executable decision table."
 
 aliases: [/dmn/model/]
 ---
 
-In this section you learn how to create your first [DMN Decision Table](/docs/documentation/reference/dmn/decision-table/) with the Camunda Modeler. The table will contain the decision logic about the desired dish for a given season and guest count.
+In this section you learn how to create your first [DMN Decision Table](/docs/documentation/reference/dmn/decision-table/) with the Operaton Modeler. The table will contain the decision logic about the desired dish for a given season and guest count.
 
-Now start up the Camunda Modeler.
+Now start up the Operaton Modeler.
 
 ## Create a new Decision Diagram