Procedure

1. In your VS Code IDE, select the Extensions menu option and search for Red Hat Business Automation Bundle for DMN, BPMN, and test scenario file support.

   For DMN or BPMN file support only, you can also search for the individual DMN Editor or BPMN Editor extensions.

2. When the Red Hat Business Automation Bundle extension appears in VS Code, select it and click Install.
3. For optimal VS Code editor behavior, after the extension installation is complete, reload or close and re-launch your instance of VS Code.

Procedure

1. Install the standalone editors using one of the following methods:

   Download each JavaScript file manually: For this method, follow these steps:

   1. Download the JavaScript files.
   2. Add the downloaded Javascript files to your hosted application.

   3. Add the following <script> tag to your HTML page:

      Script tag for your HTML page for the DMN editor

      <script src="https://<YOUR_PAGE>/dmn/index.js"></script>

      Script tag for your HTML page for the BPMN editor

      <script src="https://<YOUR_PAGE>/bpmn/index.js"></script>

   Use the NPM package: For this method, follow these steps:

   1. Add the NPM package to your package.json file:

      Adding the NPM package

      npm install @kogito-tooling/kie-editors-standalone

   2. Import each editor library to your TypeScript file:

      Importing each editor

      import * as DmnEditor from "@kogito-tooling/kie-editors-standalone/dist/dmn"
      import * as BpmnEditor from "@kogito-tooling/kie-editors-standalone/dist/bpmn"

2. After you install the standalone editors, open the required editor by using the provided editor API, as shown in the following example for opening a DMN editor. The API is the same for each editor.

   Opening the DMN standalone editor

   const editor = DmnEditor.open({
     container: document.getElementById("dmn-editor-container"),
     initialContent: Promise.resolve(""),
     readOnly: false,
     origin: "",
     resources: new Map([
       [
         "MyIncludedModel.dmn",
         {
           contentType: "text",
           content: Promise.resolve("")
         }
       ]
     ])
   });

   Use the following parameters with the editor API:

   Table 2.1. Example parameters

   Parameter	Description
   container	HTML element in which the editor is appended.
   initialContent	Promise to a DMN model content. This parameter can be empty, as shown in the following examples: Promise.resolve("") Promise.resolve("<DIAGRAM_CONTENT_DIRECTLY_HERE>") fetch("MyDmnModel.dmn").then(content ⇒ content.text())
   readOnly (Optional)	Enables you to allow changes in the editor. Set to false (default) to allow content editing and true for read-only mode in editor.
   origin (Optional)	Origin of the repository. The default value is window.location.origin.
   resources (Optional)	Map of resources for the editor. For example, this parameter is used to provide included models for the DMN editor or work item definitions for the BPMN editor. Each entry in the map contains a resource name and an object that consists of content-type (text or binary) and content (similar to the initialContent parameter).

   The returned object contains the methods that are required to manipulate the editor.

   Table 2.2. Returned object methods

   Method	Description
   getContent(): Promise<string>	Returns a promise containing the editor content.
   setContent(path: string, content: string): void	Sets the content of the editor.
   getPreview(): Promise<string>	Returns a promise containing an SVG string of the current diagram.
   subscribeToContentChanges(callback: (isDirty: boolean) ⇒ void): (isDirty: boolean) ⇒ void	Sets a callback to be called when the content changes in the editor and returns the same callback to be used for unsubscription.
   unsubscribeToContentChanges(callback: (isDirty: boolean) ⇒ void): void	Unsubscribes the passed callback when the content changes in the editor.
   markAsSaved(): void	Resets the editor state that indicates that the content in the editor is saved. Also, it activates the subscribed callbacks related to content change.
   undo(): void	Undoes the last change in the editor. Also, it activates the subscribed callbacks related to content change.
   redo(): void	Redoes the last undone change in the editor. Also, it activates the subscribed callbacks related to content change.
   close(): void	Closes the editor.
   getElementPosition(selector: string): Promise<Rect>	Provides an alternative to extend the standard query selector when an element lives inside a canvas or a video component. The selector parameter must follow the <PROVIDER>:::<SELECT> format, such as Canvas:::MySquare or Video:::PresenterHand. This method returns a Rect representing the element position.
   envelopeApi: MessageBusClientApi<KogitoEditorEnvelopeApi>	This is an advanced editor API. For more information about advanced editor API, see MessageBusClientApi and KogitoEditorEnvelopeApi.

Procedure

1. In a command terminal, navigate to a local folder where you want to store the new project.

2. Enter one of the following commands to generate a project using the starters or addons property:

   • To generate a project using the starters property, enter the following command:

     $ mvn archetype:generate \
         -DarchetypeGroupId=org.kie.kogito \
         -DarchetypeArtifactId=kogito-springboot-archetype \
         -DgroupId=org.acme -DartifactId=sample-kogito \
         -DarchetypeVersion=1.11.0.Final \
         -Dversion=1.0-SNAPSHOT
         -Dstarters=decisions

     The new project includes the dependencies required to run the decision microservices. You can combine multiple Spring Boot starters using a comma-separated list, such as starters=decisions,rules.

   • To generate a project containing Prometheus monitoring using the addons property, enter the following command:

     $ mvn archetype:generate \
         -DarchetypeGroupId=org.kie.kogito \
         -DarchetypeArtifactId=kogito-springboot-archetype \
         -DgroupId=org.acme -DartifactId=sample-kogito \
         -DarchetypeVersion=1.11.0.Final \
         -Dversion=1.0-SNAPSHOT
         -Dstarters=descisions
         -Daddons=monitoring-prometheus,persistence-infinispan

     Note

     When you pass an add-on to the property, the add-on name does not require the kogito-addons-springboot prefix. Also, you can combine the add-ons and starters properties to customize the project.

3. Open or import the project in your IDE to view the contents.

Procedure

1. In the src/main/resources folder of your example project, instead of using a DMN file, add the following PersonRules.drl file:

   Example PersonRules DRL file

   package org.acme
   unit PersonRules;
   
   import org.acme.Person;
   
   rule isAdult
   	when
   		$person: /person[ age > 18 ]
   	then
       modify($person) {
       	setAdult(true)
       };
   	end
   
   	query persons
   		$p : /person[ adult ]
   		end

   This example rule determines that any person who is older than 18 is classified as an adult. The rule file also declares that the rule belongs to the rule unit PersonRules. When you build the project, the rule unit is generated and associated with the DRL file.

   The rule also defines the condition using OOPath notation. OOPath is an object-oriented syntax extension to XPath for navigating through related elements while handling collections and filtering constraints.

   You can also rewrite the same rule condition in a more explicit form using the traditional rule pattern syntax, as shown in the following example:

   Example PersonRules DRL file using traditional notation

   package org.acme
   unit PersonRules;
   
   import org.acme.Person;
   
   rule isAdult
   	when
   		$person: Person(age > 18) from person
   	then
       modify($person) {
       	setAdult(true)
       };
   	end
   
   	query persons
   		$p : /person[ adult ]
   		end

Procedure

1. Create a file named META-INF/services/org.kie.kogito.add-on.cloudevents.message.MessagePayloadDecorator in your class path.
2. Open the file.
3. Enter the full name of your implementation class in the file.

4. Save the file.

   The MessagePayloadDecoratorProvider loads the file upon application start-up and adds the file to the decoration chain. When Red Hat build of Kogito calls the MessagePayloadDecoratorProvider#decorate, your implementation is part of the decoration algorithm.

5. To use the events add-on, add the following code to the pom.xml file of your project:

   Events smallrye add-on for {QAURKUS}

   <dependency>
     <groupId>org.kie.kogito</groupId>
     <artifactId>kogito-addons-quarkus-events-smallrye</artifactId>
     <version>1.15</version>
   </dependency>

   Events decisions add-on for {QAURKUS}

   <dependency>
     <groupId>org.kie.kogito</groupId>
     <artifactId>kogito-addons-events-decisions</artifactId>
     <version>1.15</version>
   </dependency>

   Events Kafka add-on for Spring Boot

   <dependency>
     <groupId>org.kie.kogito</groupId>
     <artifactId>kogito-addons-springboot-events-kafka</artifactId>
     <version>1.15</version>
   </dependency>

   Events decisions add-on for Spring Boot

   <dependency>
     <groupId>org.kie.kogito</groupId>
     <artifactId>kogito-addons-springboot-events-decisions</artifactId>
     <version>1.15</version>
   </dependency>

Procedure

1. Go to Operators → Installed Operators and select RHPAM Kogito Operator.
2. To create the Red Hat build of Kogito build definition, on the operator page, select the Kogito Build tab and click Create KogitoBuild.

3. In the application window, use Form View or YAML View to configure the build definition.

   At a minimum, define the application configurations shown in the following example YAML file:

   Example YAML definition for a Red Hat build of Quarkus application with Red Hat build of Kogito build

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
   kind: KogitoBuild  # Application type
   metadata:
     name: example-quarkus  # Application name
   spec:
     type: RemoteSource
     gitSource:
       uri: 'https://github.com/kiegroup/kogito-examples'  # Git repository containing application (uses default branch)
       contextDir: dmn-quarkus-example  # Git folder location of application

   Example YAML definition for a Spring Boot application with Red Hat build of Kogito build

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
   kind: KogitoBuild  # Application type
   metadata:
     name: example-springboot  # Application name
   spec:
     runtime: springboot
     type: RemoteSource
     gitSource:
       uri: 'https://github.com/kiegroup/kogito-examples'  # Git repository containing application (uses default branch)
       contextDir: dmn-springboot-example  # Git folder location of application

   Note

   If you configured an internal Maven repository, you can use it as a Maven mirror service and specify the Maven mirror URL in your Red Hat build of Kogito build definition to shorten build time substantially:

   spec:
     mavenMirrorURL: http://nexus3-nexus.apps-crc.testing/repository/maven-public/

   For more information about internal Maven repositories, see the Apache Maven documentation.

4. After you define your application data, click Create to generate the Red Hat build of Kogito build.

   Your application is listed in the Red Hat build of KogitoBuilds page. You can select the application name to view or modify application settings and YAML details.

5. To create the Red Hat build of Kogito microservice definition, on the operator page, select the Kogito Runtime tab and click Create KogitoRuntime.

6. In the application window, use Form View or YAML View to configure the microservice definition.

   At a minimum, define the application configurations shown in the following example YAML file:

   Example YAML definition for a Red Hat build of Quarkus application with Red Hat build of Kogito microservices

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
   kind: KogitoRuntime  # Application type
   metadata:
     name: example-quarkus  # Application name

   Example YAML definition for a Spring Boot application with Red Hat build of Kogito microservices

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
   kind: KogitoRuntime  # Application type
   metadata:
     name: example-springboot  # Application name
   spec:
     runtime: springboot

   Note

   In this case, the application is built from Git and deployed using KogitoRuntime. You must ensure that the application name is same in KogitoBuild and KogitoRuntime.

7. After you define your application data, click Create to generate the Red Hat build of Kogito microservice.

   Your application is listed in the Red Hat build of Kogito microservice page. You can select the application name to view or modify application settings and the contents of the YAML file.

8. In the left menu of the web console, go to Builds → Builds to view the status of your application build.

   You can select a specific build to view build details.

   Note

   For every Red Hat build of Kogito microservice that you create for OpenShift deployment, two builds are generated and listed in the Builds page in the web console: a traditional runtime build and a Source-to-Image (S2I) build with the suffix -builder. The S2I mechanism builds the application in an OpenShift build and then passes the built application to the next OpenShift build to be packaged into the runtime container image. The Red Hat build of Kogito S2I build configuration also enables you to build the project directly from a Git repository on the OpenShift platform.

9. After the application build is complete, go to Workloads → Deployments to view the application deployments, pod status, and other details.

10. After your Red Hat build of Kogito microservice is deployed, in the left menu of the web console, go to Networking → Routes to view the access link to the deployed application.

    You can select the application name to view or modify route settings.

    With the application route, you can integrate your Red Hat build of Kogito microservices with your business automation solutions as needed.

Procedure

1. Build an application locally.
2. Go to Operators → Installed Operators and select RHPAM Kogito Operator.
3. To create the Red Hat build of Kogito build definition, on the operator page, select the Kogito Build tab and click Create KogitoBuild.

4. In the application window, use Form View or YAML View to configure the build definition.

   At a minimum, define the application configurations shown in the following example YAML file:

   Example YAML definition for a Red Hat build of Quarkus application with Red Hat build of Kogito build

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
   kind: KogitoBuild  # Application type
   metadata:
     name: example-quarkus  # Application name
   spec:
     type: Binary

   Example YAML definition for a Spring Boot application with Red Hat build of Kogito build

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
   kind: KogitoBuild  # Application type
   metadata:
     name: example-springboot  # Application name
   spec:
     runtime: springboot
     type: Binary

5. After you define your application data, click Create to generate the Red Hat build of Kogito build.

   Your application is listed in the Red Hat build of KogitoBuilds page. You can select the application name to view or modify application settings and YAML details.

6. Upload the built binary using the following command:

   $ oc start-build example-quarkus --from-dir=target/ -n namespace

   • from-dir is equals to the target folder path of the built application.
   • namespace is the namespace where KogitoBuild is created.
7. To create the Red Hat build of Kogito microservice definition, on the operator page, select the Kogito Runtime tab and click Create KogitoRuntime.

8. In the application window, use Form View or YAML View to configure the microservice definition.

   At a minimum, define the application configurations shown in the following example YAML file:

   Example YAML definition for a Red Hat build of Quarkus application with Red Hat build of Kogito microservices

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
   kind: KogitoRuntime  # Application type
   metadata:
     name: example-quarkus  # Application name

   Example YAML definition for a Spring Boot application with Red Hat build of Kogito microservices

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
   kind: KogitoRuntime  # Application type
   metadata:
     name: example-springboot  # Application name
   spec:
     runtime: springboot

   Note

   In this case, the application is built locally and deployed using KogitoRuntime. You must ensure that the application name is same in KogitoBuild and KogitoRuntime.

9. After you define your application data, click Create to generate the Red Hat build of Kogito microservice.

   Your application is listed in the Red Hat build of Kogito microservice page. You can select the application name to view or modify application settings and the contents of the YAML file.

10. In the left menu of the web console, go to Builds → Builds to view the status of your application build.

    You can select a specific build to view build details.

11. After the application build is complete, go to Workloads → Deployments to view the application deployments, pod status, and other details.

12. After your Red Hat build of Kogito microservice is deployed, in the left menu of the web console, go to Networking → Routes to view the access link to the deployed application.

    You can select the application name to view or modify route settings.

    With the application route, you can integrate your Red Hat build of Kogito microservices with your business automation solutions as needed.

Procedure

1. Build an application locally.

2. Create Containerfile in the project root folder with the following content:

   Example Containerfile for a Red Hat build of Quarkus application

   FROM registry.redhat.io/rhpam-7/rhpam-kogito-runtime-jvm-rhel8:7.11.0
   
   ENV RUNTIME_TYPE quarkus
   
   COPY target/quarkus-app/lib/ $KOGITO_HOME/bin/lib/
   COPY target/quarkus-app/*.jar $KOGITO_HOME/bin
   COPY target/quarkus-app/app/ $KOGITO_HOME/bin/app/
   COPY target/quarkus-app/quarkus/ $KOGITO_HOME/bin/quarkus/

   Example Containerfile for a Spring Boot application

   FROM registry.redhat.io/rhpam-7/rhpam-kogito-runtime-jvm-rhel8:7.11.0
   
   ENV RUNTIME_TYPE springboot
   
   COPY target/<application-jar-file> $KOGITO_HOME/bin

   • application-jar-file is the name of the JAR file of the application.

3. Build the Red Hat build of Kogito image using the following command:

   podman build --tag <final-image-name> -f <Container-file>

   In the previous command, final-image-name is the name of the Red Hat build of Kogito image and Container-file is name of the Containerfile that you created in the previous step.

4. Optionally, test the built image using the following command:

   podman run --rm -it -p 8080:8080 <final-image-name>

5. Push the built Red Hat build of Kogito image to an image registry using the following command:

   podman push <final-image-name>

6. Go to Operators → Installed Operators and select RHPAM Kogito Operator.
7. To create the Red Hat build of Kogito microservice definition, on the operator page, select the Kogito Runtime tab and click Create KogitoRuntime.

8. In the application window, use Form View or YAML View to configure the microservice definition.

   At a minimum, define the application configurations shown in the following example YAML file:

   Example YAML definition for a Red Hat build of Quarkus application with Red Hat build of Kogito microservices

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
   kind: KogitoRuntime # Application type
   metadata:
     name: example-quarkus # Application name
   spec:
     image: <final-image-name> # Kogito image name
     insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate

   Example YAML definition for a Spring Boot application with Red Hat build of Kogito microservices

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
   kind: KogitoRuntime # Application type
   metadata:
     name: example-springboot # Application name
   spec:
     image: <final-image-name> # Kogito image name
     insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate
     runtime: springboot

9. After you define your application data, click Create to generate the Red Hat build of Kogito microservice.

   Your application is listed in the Red Hat build of Kogito microservice page. You can select the application name to view or modify application settings and the contents of the YAML file.

10. After the application build is complete, go to Workloads → Deployments to view the application deployments, pod status, and other details.

11. After your Red Hat build of Kogito microservice is deployed, in the left menu of the web console, go to Networking → Routes to view the access link to the deployed application.

    You can select the application name to view or modify route settings.

    With the application route, you can integrate your Red Hat build of Kogito microservices with your business automation solutions as needed.

Procedure

1. Go to Operators → Installed Operators and select RHPAM Kogito Operator.
2. To create the Red Hat build of Kogito build definition, on the operator page, select the Kogito Build tab and click Create KogitoBuild.

3. In the application window, use Form View or YAML View to configure the build definition.

   At a minimum, define the application configurations shown in the following example YAML file:

   Example YAML definition for a Red Hat build of Quarkus application with Red Hat build of Kogito build

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
   kind: KogitoBuild  # Application type
   metadata:
     name: example-quarkus  # Application name
   spec:
     type: LocalSource

   Example YAML definition for a Spring Boot application with Red Hat build of Kogito build

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this service
   kind: KogitoBuild  # Application type
   metadata:
     name: example-springboot  # Application name
   spec:
     runtime: springboot
     type: LocalSource

   Note

   If you configured an internal Maven repository, you can use it as a Maven mirror service and specify the Maven mirror URL in your Red Hat build of Kogito build definition to shorten build time substantially:

   spec:
     mavenMirrorURL: http://nexus3-nexus.apps-crc.testing/repository/maven-public/

   For more information about internal Maven repositories, see the Apache Maven documentation.

4. After you define your application data, click Create to generate the Red Hat build of Kogito build.

   Your application is listed in the Red Hat build of KogitoBuilds page. You can select the application name to view or modify application settings and YAML details.

5. Upload the file asset using the following command:

   $ oc start-build example-quarkus-builder --from-file=<file-asset-path> -n namespace

   • file-asset-path is the path of the file asset that you want to upload.
   • namespace is the namespace where KogitoBuild is created.
6. To create the Red Hat build of Kogito microservice definition, on the operator page, select the Kogito Runtime tab and click Create KogitoRuntime.

7. In the application window, use Form View or YAML View to configure the microservice definition.

   At a minimum, define the application configurations shown in the following example YAML file:

   Example YAML definition for a Red Hat build of Quarkus application with Red Hat build of Kogito microservices

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
   kind: KogitoRuntime  # Application type
   metadata:
     name: example-quarkus  # Application name

   Example YAML definition for a Spring Boot application with Red Hat build of Kogito microservices

   apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice
   kind: KogitoRuntime  # Application type
   metadata:
     name: example-springboot  # Application name
   spec:
     runtime: springboot

   Note

   In this case, the application is built from a file and deployed using KogitoRuntime. You must ensure that the application name is same in KogitoBuild and KogitoRuntime.

8. After you define your application data, click Create to generate the Red Hat build of Kogito microservice.

   Your application is listed in the Red Hat build of Kogito microservice page. You can select the application name to view or modify application settings and the contents of the YAML file.

9. In the left menu of the web console, go to Builds → Builds to view the status of your application build.

   You can select a specific build to view build details.

   Note

   For every Red Hat build of Kogito microservice that you create for OpenShift deployment, two builds are generated and listed in the Builds page in the web console: a traditional runtime build and a Source-to-Image (S2I) build with the suffix -builder. The S2I mechanism builds the application in an OpenShift build and then passes the built application to the next OpenShift build to be packaged into the runtime container image.

10. After the application build is complete, go to Workloads → Deployments to view the application deployments, pod status, and other details.

11. After your Red Hat build of Kogito microservice is deployed, in the left menu of the web console, go to Networking → Routes to view the access link to the deployed application.

    You can select the application name to view or modify route settings.

    With the application route, you can integrate your Red Hat build of Kogito microservices with your business automation solutions as needed.

Procedure

1. Define the probes in the KogitoRuntime YAML file of your project, as shown in the following example:

1. Migrate existing external applications from the generic KIE Server API to a specific DMN REST endpoint using the KIE Server.
2. Migrate a KJAR that is deployed on the KIE Server to a Red Hat build of Kogito microservice.
3. Deploy the Red Hat build of Kogito microservice using Red Hat OpenShift Container Platform.
4. Reconnect the external application and migrate the REST API consumption from the specific DMN REST endpoint to the Red Hat build of Kogito deployment.

Procedure

1. If you are using the REST endpoints in your external application, retrieve the Swagger or OAS specification file of the KJAR using GET /server/containers/{containerId}/dmn/openapi.json (|.yaml) endpoint.

   For more information about REST endpoints for specific DMN models, see REST endpoints for specific DMN models.

2. In your external application, select the Java or JDK library to interact with the decision services. You can interact with the decision services using the REST endpoint for the specific KJAR.

Procedure

1. Create a Maven project for your Red Hat build of Kogito microservice.

   For the procedure about creating a Maven project, see Creating a Maven project for a Red Hat build of Kogito microservice.

   The Maven project creates Kogito artifacts.

2. Copy the DMN models from the src/main/resources folder of the KJAR to the src/main/resources folder of the Kogito artifact.

3. Copy the test scenarios from the src/test/resources folder of the KJAR to the src/test/resources folder of the Kogito artifact.

   Important

   You need to import the Red Hat build of Kogito dependency of test scenarios in the pom.xml file of your project and create a JUnit activator using the KIE Server REST API. For more information, see Testing a decision service using test scenarios.

4. Run the following command and ensure that the test scenario is running for the specified non-regression tests.

   mvn clean install

   After running the Red Hat build of Kogito application, you can retrieve the Swagger or OAS specification file. The Swagger or OAS specifications provide the same information as the REST endpoint along with the following implementation details:

   • Base URL of the server where the API is available
   • References Schemas names

   You can use the provided implementation details when your external application is re-routed to the new URL.

1. Migrate a KJAR that is deployed on the KIE Server to a Red Hat build of Kogito microservice.
2. Deploy the Red Hat build of Kogito microservice using Red Hat OpenShift Container Platform.
3. Modify the external application from client PMML API on the KIE Server to the REST API of the Red Hat build of Kogito deployment.

Procedure

1. Create a Maven project for your Red Hat build of Kogito microservice.

   For the procedure about creating a Maven project, see Creating a Maven project for a Red Hat build of Kogito microservice.

   The Maven project creates Kogito artifacts.

2. Copy the PMML models from the src/main/resources folder of the KJAR to the src/main/resources folder of the Kogito artifact.

3. Run the following command to execute the Red Hat build of Kogito application:

   mvn clean install

   After running the Red Hat build of Kogito application, you can retrieve the Swagger or OAS specification file. The Swagger or OAS specifications provide the same information as the REST endpoint along with the following implementation details:

   • Base URL of the server where the API is available
   • References Schemas names

   You can use the provided implementation details when your external application is re-routed to the new URL.

Procedure

1. Remove all the usage of the KIE Server client API and replace it with the HTTP communication. The following is an example of a non-Java request:

   

2. Ensure that any HTTP client Java library is used inside the external application to create a similar invocation and parse the result.

   The following is an example of Java 11 HTTP client and Gson to convert the input data to JSON:

   
   Note

   All the parameters that are required as the values of the parameters are embedded in the URL that is called.