Procedure

1. In the Red Hat OpenShift Container Platform web cluster console menu, select Catalog → Installed operators or Operators → Installed operators.
2. Click the name of the operator that contains businessautomation. Information about this operator is displayed.
3. Click the Installer link located on the right side of the window.
4. If prompted, log in with your OpenShift credentials.

Procedure

1. In the Application Name field, enter a name for the OpenShift application. This name is used in the default URLs for all components.

2. In the Environment list, select the type of environment. This type determines the default configuration; you can modify this configuration as necessary. The following types are available for Red Hat Decision Manager:

   • rhdm-trial: A trial environment that you can set up quickly and use to evaluate or demonstrate developing and running assets. Includes Business Central and a KIE Server. This environment does not use any persistent storage, and any work you do in the environment is not saved.
   • rhdm-authoring: An environment for creating and modifying services using Business Central. It consists of pods that provide Business Central for the authoring work and a KIE Server for test execution of the services. You can also use this environment to run services for staging and production purposes. You can add KIE Servers to the environment and they are managed by the same Business Central.

   • rhdm-authoring-ha: An environment for creating and modifying services using Business Central. It consists of pods that provide Business Central for the authoring work and a KIE Server for test execution of the services. This version of the authoring environment supports scaling the Business Central pod to ensure high availability.

     Important

     In Red Hat Decision Manager 7.13, high-availability Business Central functionality is for Technology Preview only. For more information about Red Hat Technology Preview features, see Technology Preview Features Support Scope.

   • rhpam-production-immutable: An alternate environment for running existing services for staging and production purposes. You can configure one or more KIE Server pods that build services from source or pull them from a Maven repository. You can then replicate each pod as necessary.

     You cannot remove any service from the pod or add any new service to the pod. If you want to use another version of a service or to modify the configuration in any other way, deploy a new server image to replace the old one. You can use any container-based integration workflows to manage the pods.

     When configuring this environment, in the KIE Servers tab you must customize KIE Server and either click the Set immutable server configuration button or set the KIE_SERVER_CONTAINER_DEPLOYMENT environment variable. For instructions about configuring KIE Server, see Section 3.2.5, “Setting custom KIE Server configuration of the environment”.

3. If you want to enable automatic upgrades to new versions, select the Enable Upgrades box. If this box is selected, when a new patch version of Red Hat Decision Manager 7.13 becomes available, the operator automatically upgrades your deployment to this version. All services are preserved and normally remain available throughout the upgrade process.

   If you also want to enable the same automatic upgrade process when a new minor version of Red Hat Decision Manager 7.x becomes available, select the Include minor version upgrades box.

   Note

   Disable automatic updates if you want to use a custom image for any component of Red Hat Decision Manager.

4. If you want to use image tags for downloading images, select the Use Image Tags box. This setting is useful if you use a custom registry or if you are directed by Red Hat support.

5. If you want to disable SSL connections to your deployment, select the Disable SSL Routes box. In this case, all routes that are externally exposed use clear-text (HTTP) connections.

   Note

   If this box is not selected, only secure (HTTPS) routes are exposed externally.

6. If you want to use a custom image registry, under Custom registry, enter the URL of the registry in the Image registry field. If this registry does not have a properly signed and recognized SSL certificate, select the Insecure box.

   For instructions about configuring the image registry to use specific images, see Section 3.2.2.1, “Configuring the image registry to use specific images”.

7. Under Admin user, enter the user name and password for the administrative user for Red Hat Decision Manager in the Username and Password fields.

   Important

   If you use RH-SSO or LDAP authentication, the same user must be configured in your authentication system with the kie-server,rest-all,admin roles for Red Hat Decision Manager.

8. Optional: Select the startup strategy. The OpenShiftStartupStrategy setting is enabled by default.

   In some authoring environments, you might need to ensure that several users can deploy services on the same KIE Server at the same time. By default, after deploying a service onto a KIE Server using Business Central, the user must wait a few seconds before more services can be deployed. The OpenShiftStartupStrategy setting is enabled by default and causes this limitation. To remove the limitation, select the ControllerBasedStartupStrategy setting from the Startup Strategy list.

   Note

   Do not enable the controller-based startup strategy in an environment with a high-availability Business Central.

9. Optional: If you want to use the OpenShift CA bundle as the trust store for HTTPS communication, select the Use OpenShift CA Bundle box.

10. Optional: If you want to use a secret that contains the credentials for the Admin user, complete the following tasks:

    1. From the Admin user configuration list, select Secret configuration.
    2. Under OpenShift admin credentials secret, in the Secret field, enter the name of the secret. If the Secret field is left blank, the default secret from kie-admin-credentials is used.
    3. Under OpenShift admin credentials secret, in the Username field, enter the username for the admin user to use in the secret. If the Username field is left blank, the default username from kie-admin-credentials is used.

    4. Under OpenShift admin credentials secret, in the Password field, enter the password for the admin user to use in the secret. If the Password field is left blank, the default password from kie-admin-credentials is used.

       Note

       If kie-admin-credentials is missing, kie-admin-credentials is generated with a default username and password.

Procedure

1. If the Installation tab is open, click Next to view the Security tab.

2. In the Authentication mode list, select one of the following modes:

   • Internal: You configure the initial administration user when deploying the environment. You can create a post-configuration script to add users in the Elytron security subsystem. For instructions about creating a post-configuration script, see Section 3.4, “Providing Elytron user configuration or other post-configuration settings”.
   • RH-SSO: Red Hat Decision Manager uses Red Hat Single Sign-On for authentication.
   • LDAP: Red Hat Decision Manager uses LDAP for authentication

3. Complete the security configuration based on the Authentication mode that you selected:

   If you selected RH-SSO, configure RH-SSO authentication:

   1. In the RH-SSO URL field, enter the RH-SSO URL.
   2. In the Realm field, enter the RH-SSO realm name.
   3. If you did not create RH-SSO clients for components of your environment enter the credentials of an administrative user for your RH-SSO system in the SSO admin user and SSO admin password fields.
   4. If your RH-SSO system does not have a proper signed SSL certificate, select the Disable SSL cert validation box.
   5. If you want to change the RH-SSO principal attribute used for the user name, in the Principal attribute field enter the name of the new attribute.

   If you selected LDAP, configure LDAP authentication:

   Important

   The baseFilter field is a legacy LDAP search filter used to locate the context of the user to authenticate. The input username or userDN obtained from the login module callback is substituted into the filter anywhere a {0} expression is used. A common example for the search filter is (uid={0}). For Elytron based subsystems, this property should be configured only with the search filter parameter, without any search expression. For example, search for uid instead of (uid={0}).

   1. In the LDAP URL field, enter the LDAP URL.

   2. Set LDAP parameters. These parameters configure LDAP authentication using the Elytron subsystem of Red Hat JBoss EAP. For more information about using the Elytron subsystem of Red Hat JBoss EAP with LDAP, see Configure Authentication with an LDAP-Based Identity Store.

      Note

      If you want to enable LDAP failover, you can set two or more LDAP server addresses in the AUTH_LDAP_URL parameter, separated by a space.

4. If you selected RH-SSO or LDAP, if your RH-SSO or LDAP system does not define all the roles required for your deployment, you can map authentication system roles to Red Hat Decision Manager roles.

   To enable role mapping, you must provide role mapping either as a single configuration string or as a role mapping configuration file. If you use a file for role mapping configuration, you must provide the file in an OpenShift configuration map or secret object in the project namespace.

   The string must use the role=role1,role2;another-role=role2 pattern, for example admins=kie-server,rest-all,admin;developers=kie-server,rest-all.

   The file must contain entries in the following format:

   ldap_role=product_role1, product_role2...

   For example:

   admins=kie-server,rest-all,admin

   To enable the use of this string or file, make the following changes:

   1. Under RoleMapper, in the Roles properties file field, enter the role configuration string or the fully qualified path name of the role mapping configuration file, for example /opt/eap/standalone/configuration/rolemapping/rolemapping.properties.
   2. Optional: Select the Roles keep mapped box or the Roles keep non mapped box. If you define role mapping, by default only the roles that you define in the mapping are available. If you want to keep the original roles that are defined in the authentication system and that your mapping maps to other roles, select the Roles keep mapped box. If you want to keep the original roles that are defined in the authentication system and not mentioned in your mapping,select the Roles keep non mapped box.

   3. If you are using a role configuration file, configure the fields under RoleMapper Configuration object:

      • Under the Kind label, select the kind of the object that provides the file (ConfigMap or Secret).
      • In the Name field, enter the name of the object. This object is automatically mounted on Business Central and KIE Server pods in the path that you specified for the role mapping configuration file.

5. Configure other passwords, if necessary:

   • AMQ password and AMQ cluster password are passwords for interaction with ActiveMQ using the JMS API.
   • Keystore password is the password for the keystore files used in secrets for HTTPS communication. Set this password if you created secrets according to instructions in Section 2.2, “Creating the secrets for KIE Server” or Section 2.3, “Creating the secrets for Business Central”.
   • Database password is the password for database server pods that are a part of the environments.

Procedure

1. If the Installation or Security tab is open, click Next until you view the Console tab.
2. If you created the secret for Business Central according to the instructions in Section 2.3, “Creating the secrets for Business Central”, enter the name of the secret in the Keystore secret field.

3. Optional: If you want to use a custom image for the Business Central deployment, complete the following additional steps:

   1. Set the custom registry in the Installation tab. If you do not set the custom registry, the installation uses the default Red Hat registry. For more information about setting the custom registry value, see Section 3.2.2, “Setting the basic configuration of the environment”.

   2. In the Console tab, set the following fields:

      • Image context: The context of the image in the registry.
      • Image: The name of the image.

      • Image tag: The tag of the image. If you do not set this field, the installation uses the latest tag.

        For example, if the full address of the image is registry.example.com/mycontext/mycentral:1.0-SNAPSHOT, set the custom registry to registry.example.com, the Image context field to mycontext, the Image field to mycentral, and the Image tag field to 1.0-SNAPSHOT.

4. Optional: To set a custom hostname for the external route, enter a domain in the Custom hostname to be used on the Business Central external Route field, formatted as in the following example:

   `businesscentral.example.com`

   Note

   The custom hostname must be valid and resolvable.

   To change the custom hostname, you can modify the routeHostname property.

5. Optional: To enable and set the Edge termination route, complete the following steps:

   1. Under Change route termination, select Enable Edge termination.
   2. Optional: In the Key field, enter the private key.
   3. Optional: In the Certificate field, enter the certificate.
   4. Optional: In the CaCertificate field, enter the CaCertificate.

6. Optional: Configure Git hooks.

   In an authoring environment, you can use Git hooks to facilitate interaction between the internal Git repository of Business Central and an external Git repository. If you want to use Git hooks, you must prepare a Git hooks directory in an OpenShift configuration map, secret, or persistent volume claim object in the project namespace. You can also prepare a secret with the SSH key and known hosts files for Git SSH authentication. For instructions about preparing Git hooks, see Section 2.5, “Preparing Git hooks”.

   To use a Git hooks directory, make the following changes:

   1. Under GitHooks, in the Mount path field, enter a fully qualified path for the directory, for example, /opt/kie/data/git/hooks.
   2. In the fields under GitHooks Configuration object, select the Kind of the object that provides the file (ConfigMap, Secret, or PersistentVolumeClaim) and enter the Name of the object. This object is automatically mounted on the Business Central pods in the path that you specified for the Git hooks directory.
7. Optional: In the SSH secret field enter the name of the secret with the SSH key and known hosts files.
8. Optional: To configure KIE Server for decision management only capabilities so that jBPM and case management features are disabled, select Execute Kie Server only with Decisions capabilities.
9. Optional: Enter the number of replicas for Business Central or Business Central monitoring in the Replicas field. Do not change this number in a rhpam-authoring environment.
10. Optional: To set the Business Central persistent volume size pvSize, on the Console component page, enter the desired size in the Persistent Volume Size field. The default size is 1Gi for Business Central and 64Mb for Business Central Monitoring.
11. Optional: Enter requested and maximum CPU and memory limits in the fields under Resource quotas.
12. If you want to customize the configuration of the Java virtual machine on the Business Central pods, select the Enable JVM configuration box and then enter information in any of the fields under Enable JVM configuration. All fields are optional. For the JVM parameters that you can configure, see Section 3.5, “JVM configuration parameters”.

13. If you selected RH-SSO authentication, configure RH-SSO for Business Central:

    1. Enter the client name in the Client name field and the client secret in the Client secret field. If a client with this name does not exist, the deployment attempts to create a new client with this name and secret.
    2. If the deployment is to create a new client, enter the HTTP and HTTPS URLs that will be used for accessing Business Central into the SSO HTTP URL and SSO HTTPS URL fields. This information is recorded in the client.
14. Optional: If you are configuring a high-availability environment, set the user name and password for the DataGrid component in the DataGrid username and DataGrid password fields. By default, the user name is infinispan and the password is generated automatically.

15. Optional: Depending on your needs, set environment variables. To set an environment variable, click Add new Environment variable, then enter the name and value for the variable in the Name and Value fields.

    • Optional: If you want to configure the proxy settings, use the following environment variables:

      • https_proxy: The location of the https proxy. This takes precedence over HTTPS_PROXY, http_proxy, and HTTP_PROXY, and is used for both Maven builds and Java runtime. For example: myuser:mypass@127.0.0.1:8080.
      • HTTPS_PROXY: The location of the https proxy. This takes precedence over http_proxy and HTTP_PROXY, and is used for both Maven builds and Java runtime. For example: myuser@127.0.0.1:8080.
      • http_proxy: The location of the http proxy. This takes precedence over HTTP_PROXY and is used for both Maven builds and Java runtime. For example: http://127.0.0.1:8080.
      • HTTP_PROXY: The location of the http proxy. This is used for both Maven builds and Java runtime. For example: 127.0.0.1:8080.
      • no_proxy: A comma separated lists of hosts, IP addresses, or domains that can be accessed directly. This takes precedence over NO_PROXY and is used for both Maven builds and Java runtime. For example: *.example.com.
      • NO_PROXY: A comma separated lists of hosts, IP addresses, or domains that can be accessed directly. This is used for both Maven builds and Java runtime. For example: foo.example.com,bar.example.com.

    • If you want to use an external Maven repository, set the following variables:

      • MAVEN_REPO_URL: The URL for the Maven repository
      • MAVEN_REPO_ID: An identifier for the Maven repository, for example, repo-custom
      • MAVEN_REPO_USERNAME: The user name for the Maven repository

      • MAVEN_REPO_PASSWORD The password for the Maven repository

        Important

        In an authoring environment, if you want Business Central to push a project into an external Maven repository, you must configure this repository during deployment and also configure exporting to the repository in every project. For information about exporting Business Central projects to an external Maven repository, see Packaging and deploying an Red Hat Decision Manager project.

    • If your OpenShift environment does not have a connection to the public Internet, configure access to a Maven mirror that you set up according to Section 2.9, “Preparing a Maven mirror repository for offline use”. Set the following variables:

      • MAVEN_MIRROR_URL: The URL for the Maven mirror repository that you set up in Section 2.9, “Preparing a Maven mirror repository for offline use”. This URL must be accessible from a pod in your OpenShift environment.

      • MAVEN_MIRROR_OF: The value that determines which artifacts are to be retrieved from the mirror. For instructions about setting the mirrorOf value, see Mirror Settings in the Apache Maven documentation. The default value is external:*. With this value, Maven retrieves every required artifact from the mirror and does not query any other repositories.

        If you configure an external Maven repository (MAVEN_REPO_URL), change MAVEN_MIRROR_OF to exclude the artifacts in this repository from the mirror, for example, external:*,!repo-custom. Replace repo-custom with the ID that you configured in MAVEN_REPO_ID.

        If your authoring environment uses a built-in Business Central Maven repository, change MAVEN_MIRROR_OF to exclude the artifacts in this repository from the mirror: external:*,!repo-rhpamcentr.

    • In some cases, you might want to persist the Maven repository cache for Business Central. By default, the cache is not persisted, so when you restart or scale a Business Central pod, all Maven artifacts are downloaded again and all projects within Business Central must be built again. If you enable persistence for the cache, the download is not necessary and startup time can improve in some situations. However, significant additional space on the Business Central persistence volume is required.

      To enable persistence for the Maven repository cache, set the KIE_PERSIST_MAVEN_REPO environment variable to true.

      If you set KIE_PERSIST_MAVEN_REPO to true, you can optionally set a custom path for the cache using the KIE_M2_REPO_DIR variable. The default path is /opt/kie/data/m2. Files in the /opt/kie/data directory tree are persisted.

Procedure

1. If the Installation, Security, or Console tab is open, click Next until you view the KIE Servers tab.
2. Click Add new KIE Server to add a new KIE Server configuration.
3. In the Id field, enter an identifier for this KIE Server instance. If the KIE Server instance connects to a Business Central or Business Central Monitoring instance, this identifier determines which server group the server joins.
4. In the Name field, enter a name for the KIE Server.
5. In the Deployments field, enter the number of similar KIE Servers that are to be deployed. The installer can deploy several KIE Servers with the same configuration. The identifiers and names of the KIE Servers are modified automatically and remain unique.
6. If you created the secret for KIE Server according to the instructions in Section 2.2, “Creating the secrets for KIE Server”, enter the name of the secret in the Keystore secret field.
7. Optional: To configure KIE Server for decision management only capabilities so that jBPM and case management features are disabled, select Execute Kie Server only with Decisions capabilities.
8. Optional: Enter the number of replicas for the KIE Server deployment in the Replicas field.

9. Optional: To set a custom hostname for the external route, enter a domain in the Custom hostname to be used on the KIE Server external Route field, formatted as in the following example:

   `kieserver.example.com`

   Note

   The custom hostname must be valid and resolvable.

   To change the custom hostname, you can modify the routeHostname property.

10. Optional: To enable and set the Edge termination route, complete the following steps:

    1. Under Change route termination, select Enable Edge termination.
    2. Optional: In the Key field, enter the private key.
    3. Optional: In the Certificate field, enter the certificate.
    4. Optional: In the CaCertificate field, enter the CaCertificate.

11. Optional: If you want to use a custom KIE Server image, complete the following additional steps:

    1. Click Set KIE Server image.
    2. From the Kind list, select ImageStreamTag if you want to pull the image from an OpenShift image stream or select DockerImage if you want to pull the image from any Docker registry.

    3. Set the image name by completing one of the following steps:

       • If you selected the ImageStreamTag kind, enter the image stream tag name of the image in the Name field, for example, my-custom-is-tag:1.0.

         If a corresponding image stream does not exist in your environment, the operator creates this image stream using the default Red Hat registry and tags. If you configured a custom registry in the Installation tab, the operator uses this registry for creating the image stream.

       • If you selected the DockerImage kind, enter the fully qualified image name for the image in the Name field, for example, registry.io/test/testing:1.0.

         You can configure an image from any registry that your environment can access.

    4. If you want to use an image stream that is not in the openshift namespace, enter the namespace in the Namespace field.

       For instructions about creating custom images, see Section 3.7, “Creating custom images for KIE Server”.

12. Optional: If you want to configure an immutable KIE Server using a Source to Image (S2I) build, complete the following additional steps:

    Important

    If you want to configure an immutable KIE Server that pulls services from the Maven repository, do not click Set Immutable server configuration and do not complete these steps. Instead, set the KIE_SERVER_CONTAINER_DEPLOYMENT environment variable.

    1. Click Set Immutable server configuration.
    2. In the KIE Server container deployment field, enter the identifying information of the services (KJAR files) that the deployment must extract from the result of a Source to Image (S2I) build. The format is <containerId>=<groupId>:<artifactId>:<version> or, if you want to specify an alias name for the container, <containerId>(<aliasId>)=<groupId>:<artifactId>:<version>. You can provide two or more KJAR files using the | separator, as illustrated in the following example: containerId=groupId:artifactId:version|c2(alias2)=g2:a2:v2.
    3. If your OpenShift environment does not have a connection to the public Internet, enter the URL of the Maven mirror that you set up according to Section 2.9, “Preparing a Maven mirror repository for offline use” in the Maven mirror URL field.
    4. In the Artifact directory field, enter the path within the project that contains the required binary files (KJAR files and any other necessary files) after a successful Maven build. Normally this directory is the target directory of the build. However, you can provide prebuilt binaries in this directory in the Git repository.
    5. If you want to use a custom base KIE Server image for the S2I build, click Set Base build image and then enter the name of the image stream in the Name field. If the image stream is not in the openshift namespace, enter the namespace in the Namespace field. If you want to use a Docker image name and not an OpenShift image stream tag, change the Kind value to DockerImage.

    6. Click Set Git source and enter information in the following fields:

       • S2I Git URI:The URI for the Git repository that contains the source for your services.
       • Reference: The branch in the Git repository.

       • Context directory: (Optional) The path to the source within the project downloaded from the Git repository. By default, the root directory of the downloaded project is the source directory.

         Note

         If you do not configure a Git source, the immutable KIE Server does not use an S2I build. Instead, it pulls the artifacts that you define in the KIE Server container deployment field from the configured Maven repository.

    7. If you are using S2I and want to set a Git Webhook so that changes in the Git repository cause an automatic rebuild of the KIE Server, click Add new Webhook. Then select the type of the Webhook in the Type field and enter the secret string for the Webhook in the Secret field.
    8. If you want to set a build environment variable for the S2I build, click Add new Build Config Environment variable and then enter the name and value for the variable in the Name and Value fields.
13. Optional: Enter requested and maximum CPU and memory limits in the fields under Resource quotas. If you are configuring several KIE Servers, the limits apply to each server separately.

14. If you selected RH-SSO authentication, configure RH-SSO for the KIE Server:

    1. Enter the client name in the Client name field and the client secret in the Client secret field. If a client with this name does not exist, the deployment attempts to create a new client with this name and secret.
    2. If the deployment is to create a new client, enter the HTTP and HTTPS URLs that will be used for accessing this KIE Server instance into the SSO HTTP URL and SSO HTTPS URL fields. This information is recorded in the client.

15. If you want to interact with the KIE Server through JMS API using an external AMQ message broker, enable the Enable JMS Integration setting. Additional fields for configuring JMS Integration are displayed and you must enter the values as necessary:

    • User name, Password: The user name and password of a standard broker user, if user authentication in the broker is required in your environment.
    • Executor: Select this setting to disable the JMS executor. The executor is enabled by default.
    • Executor transacted: Select this setting to enable JMS transactions on the executor queue.
    • Enable signal: Select this setting to enable signal configuration through JMS.
    • Enable audit: Select this setting to enable audit logging through JMS.
    • Audit transacted: Select this setting to enable JMS transactions on the audit queue.
    • Queue executor, Queue request, Queue response, Queue signal, Queue audit: Custom JNDI names of the queues to use. If you set any of these values, you must also set the AMQ queues parameter.
    • AMQ Queues: AMQ queue names, separated by commas. These queues are automatically created when the broker starts and are accessible as JNDI resources in the JBoss EAP server. If you are using any custom queue names, you must enter the names of all the queues uses by the server in this field.
    • Enable SSL integration: Select this setting if you want to use an SSL connection to the AMQ broker. In this case you must also provide the name of the secret that you created in Section 2.4, “Creating the secrets for the AMQ broker connection” and the names and passwords of the key store and trust store that you used for the secret.
16. If you want to customize the configuration of the Java virtual machine on the KIE Server pods, select the Enable JVM configuration box and then enter information in any of the fields under Enable JVM configuration. All fields are optional. For the JVM parameters that you can configure, see Section 3.5, “JVM configuration parameters”.

17. Optional: If you want to configure the proxy settings, use the following environment variables:

    • https_proxy: The location of the https proxy. This takes precedence over HTTPS_PROXY, http_proxy, and HTTP_PROXY, and is used for both Maven builds and Java runtime. For example: myuser:mypass@127.0.0.1:8080.
    • HTTPS_PROXY: The location of the https proxy. This takes precedence over http_proxy and HTTP_PROXY, and is used for both Maven builds and Java runtime. For example: myuser@127.0.0.1:8080.
    • http_proxy: The location of the http proxy. This takes precedence over HTTP_PROXY and is used for both Maven builds and Java runtime. For example: http://127.0.0.1:8080.
    • HTTP_PROXY: The location of the http proxy. This is used for both Maven builds and Java runtime. For example: 127.0.0.1:8080.
    • no_proxy: A comma separated lists of hosts, IP addresses, or domains that can be accessed directly. This takes precedence over NO_PROXY and is used for both Maven builds and Java runtime. For example: *.example.com.
    • NO_PROXY: A comma separated lists of hosts, IP addresses, or domains that can be accessed directly. This is used for both Maven builds and Java runtime. For example: foo.example.com,bar.example.com.

18. Optional: Depending on your needs, set environment variables. To set an environment variable, click Add new Environment variable, then enter the name and value for the variable in the Name and Value fields.

    • If you want to configure an immutable KIE server that pulls services from the configured Maven repository, enter the following settings:

      1. Set the KIE_SERVER_CONTAINER_DEPLOYMENT environment variable. The variable must contain the identifying information of the services (KJAR files) that the deployment must pull from the Maven repository. The format is <containerId>=<groupId>:<artifactId>:<version> or, if you want to specify an alias name for the container, <containerId>(<aliasId>)=<groupId>:<artifactId>:<version>. You can provide two or more KJAR files using the | separator, as illustrated in the following example: containerId=groupId:artifactId:version|c2(alias2)=g2:a2:v2.
      2. Configure an external Maven repository.

    • If you want to configure an external Maven repository, set the following variables:

      • MAVEN_REPO_URL: The URL for the Maven repository
      • MAVEN_REPO_ID: An identifier for the Maven repository, for example, repo-custom
      • MAVEN_REPO_USERNAME: The user name for the Maven repository
      • MAVEN_REPO_PASSWORD: The password for the Maven repository

    • If your OpenShift environment does not have a connection to the public Internet, configure access to a Maven mirror that you set up according to Section 2.9, “Preparing a Maven mirror repository for offline use”. Set the following variables:

      • MAVEN_MIRROR_URL: The URL for the Maven mirror repository that you set up in Section 2.9, “Preparing a Maven mirror repository for offline use”. This URL must be accessible from a pod in your OpenShift environment. If you configured this KIE Server as S2I, you already entered this URL.

      • MAVEN_MIRROR_OF: The value that determines which artifacts are to be retrieved from the mirror. If you configured this KIE Server as S2I, do not set this value. For instructions about setting the mirrorOf value, see Mirror Settings in the Apache Maven documentation. The default value is external:*. With this value, Maven retrieves every required artifact from the mirror and does not query any other repositories.

        If you configure an external Maven repository (MAVEN_REPO_URL), change MAVEN_MIRROR_OF to exclude the artifacts in this repository from the mirror, for example, external:*,!repo-custom. Replace repo-custom with the ID that you configured in MAVEN_REPO_ID.

        If your authoring environment uses a built-in Business Central Maven repository, change MAVEN_MIRROR_OF to exclude the artifacts in this repository from the mirror: external:*,!repo-rhpamcentr.

    • If you want to configure your KIE Server deployment to use Prometheus to collect and store metrics, set the PROMETHEUS_SERVER_EXT_DISABLED environment variable to false. For instructions about configuring Prometheus metrics collection, see Managing and monitoring KIE Server.

    • If you are using Red Hat Single Sign-On authentication and the interaction of your application with Red Hat Single Sign-On requires support for cross-origin resource sharing (CORS), configure CORS Filters configuration:

      • To use CORS with the default configuration, ensure Default configuration is selected from the CORS Filters configuration list and select Enable CORS with Default values.
      • To use CORS with a custom configuration, select Custom configuration from the CORS Filters configuration list and enter the relevant values for the CORS filters.

Procedure

1. Create an rhpam-authoring environment with one replica for Business Central and KIE Server.

   Example rhpam-authoring:

   apiVersion: app.kiegroup.org/v2
   kind: KieApp
   metadata:
     name: rhpam-authoring
     annotations:
       consoleName: rhpam-authoring
       consoleTitle: PAM Authoring
       consoleDesc: Deploys a PAM Authoring environment
   spec:
     environment: rhpam-authoring
   objects:
     servers:
       - replicas: 1
     console:
       replicas: 1

2. Complete one of the following steps:

   • To open a specific ConfigMap with the oc tool, run the following command:

     $ oc edit cm/<CONFIGMAP_NAME>

     Note

     The oc tool is similar to the vim text editing tool.

   • To open a specific ConfigMap using the Red Hat OpenShift Container Platform console, navigate to kieconfigs-7.13.5 on the ConfigMaps page and edit it by opening it’s YAML version.

3. To modify the YAML file, add annotations fields that contain your changes, for example:

   Add the following to Console.deploymentConfigs.metadata:

              annotations:
                my.custom.annotation/v1: v1-rhpam-app-console

   To update KIE Server, add the following to the ## KIE Servers Start placeholder identifier:

                annotations:
                  my.custom.annotation/v1: v1-rhpam-app-kieserver

   Note

   You can also edit the Smart Router configuration using this ConfigMap.

4. To save the changes, complete one of the following steps:

   • In the oc tool editor, to save the change the change and exit, enter :wq!.
   • In the the Red Hat OpenShift Container Platform console, to save the change using the Red Hat OpenShift Container Platform console, click Save.

5. If an environment is running and the operator didn’t automatically start redeployment for the component that was changed, you must manually delete the DeploymentConfig of the target component by using oc command tool by completing the following steps:

   1. To return the DeploymentConfig, run the following command:

      $ oc get dc

      The output of oc get dc is returned.

      Example output of oc get dc:

      $ oc get dc
      NAME                          REVISION   DESIRED   CURRENT   TRIGGERED BY
      rhpam-authoring-kieserver            1         1         1         config
      rhpam-authoring-rhpamcentr           1         1         1         config

   2. To delete the DeploymentConfig of the target components, run the following commands:

      $ oc delete dc/rhpam-authoring-kieserver

      $ oc delete dc/rhpam-authoring-rhpamcentr

      The deployment is redeployed with the changes applied in the ConfigMap.

6. To verify that the change was applied by checking the annotations for the KIE Server DeploymentConfig, run the following command:

   $ oc describe dc/rhpam-authoring-kieserver

   Example output of oc describe dc/rhpam-authoring-kieserver:

   Name:		rhpam-authoring-kieserver
   Namespace:	examplenamespace
   Created:	15 minutes ago
   Labels:		app=rhpam-authoring
   		application=rhpam-authoring
   		service=rhpam-authoring-kieserver
   		services.server.kie.org/kie-server-id=rhpam-authoring-kieserver
   Annotations:	my.custom.annotation/v1=v1-rhpam-app-kieserver

Procedure

1. Authenticate to the registry.redhat.io registry using the podman login command. For instructions about authenticating to the registry, see Red Hat Container Registry Authentication.

2. To download the supported KIE Server base image, enter the following command:

   podman pull registry.redhat.io/rhpam-7/rhpam-kieserver-rhel8:7.13.5

3. Create a Dockerfile that defines a custom image based on the base image. The file must change the current user to root, install the RPM package using the yum command, and then revert to USER 185, the Red Hat JBoss EAP user. The following example shows the content of the Dockerfile file:

   FROM registry.redhat.io/rhpam-7/rhpam-kieserver-rhel8:7.13.5
   USER root
   RUN yum -y install procps-ng
   USER 185

   Replace the name of the RPM file as necessary. The yum command automatically installs all dependencies from the Red Hat Enterprise Linux 8 repository. You might need to install several RPM files, in this case, use several RUN commands.

4. Build the custom image using the Dockerfile. Supply the fully qualified name for the image, including the registry name. You must use the same version tag as the version of the base image. To build the image, enter the following command:

   podman build . --tag registry_address/image_name:7.13.5

   For example:

   podman build . --tag registry.example.com/custom/rhpam-kieserver-rhel8:7.13.5

5. After the build completes, run the image, log in to it, and verify that the customization was successful. Enter the following command:

   podman run -it --rm registry_address/image_name:7.13.5 /bin/bash

   For example:

   podman run -it --rm registry.example.com/custom/rhpam-kieserver-rhel8:7.13.5 /bin/bash

   In the shell prompt for the image, enter the command to test that the RPM is installed, then enter exit. For example, for procps-ng, run the ps command:

   [jboss@c2fab36b778e ~]$ ps
   PID TTY          TIME CMD
     1 pts/0    00:00:00 bash
    13 pts/0    00:00:00 ps
   [jboss@c2fab36b778e ~]$ exit

6. To push the custom image into your registry, enter the following command:

   podman push registry_address/image_name:7.13.5 docker://registry_address/image_name:7.13.5

   For example:

   podman push registry.example.com/custom/rhpam-kieserver-rhel8:7.13.5 docker://registry.example.com/custom/rhpam-kieserver-rhel8:7.13.5

Procedure

1. Develop a custom library that works with KIE Server. You can use the following documentation and examples to develop the library:

   • KIE Server capabilities and extensions in Managing and monitoring KIE Server.
   • Domain-specific Prometheus metrics with Red Hat Process Automation Manager and Decision Manager
   • Extend KIE Server with additional transport
2. Build the library using Maven, so that the JAR file is placed in the target directory. This example uses the custom-kieserver-ext-1.0.0.Final.jar file name.
3. Authenticate to the registry.redhat.io registry using the podman login command. For instructions about authenticating to the registry, see Red Hat Container Registry Authentication.

4. To download the supported KIE Server base image, enter the following command:

   podman pull registry.redhat.io/rhpam-7/rhpam-kieserver-rhel8:7.13.5

5. Create a Dockerfile that defines a custom image based on the base image. The file must copy the JAR file (or several JAR files) into the /opt/eap/standalone/deployments/ROOT.war/WEB-INF/lib/ directory. The following example shows the content of the Dockerfile file:

   FROM registry.redhat.io/rhpam-7/rhpam-kieserver-rhel8:7.13.5
   COPY target/custom-kieserver-ext-1.0.0.Final.jar /opt/eap/standalone/deployments/ROOT.war/WEB-INF/lib/

6. Build the custom image using the Dockerfile. Supply the fully qualified name for the image, including the registry name. You must use the same version tag as the version of the base image. To build the image, enter the following command:

   podman build . --tag registry_address/image_name:7.13.5

   For example:

   podman build . --tag registry.example.com/custom/rhpam-kieserver-rhel8:7.13.5

7. To push the custom image into your registry, enter the following command:

   podman push registry_address/image_name:7.13.5 docker://registry_address/image_name:7.13.5

   For example:

   podman push registry.example.com/custom/rhpam-kieserver-rhel8:7.13.5 docker://registry.example.com/custom/rhpam-kieserver-rhel8:7.13.5