Chapter 7. Known issues in Red Hat Process Automation Manager 7.13

This section lists known issues with Red Hat Process Automation Manager 7.13.

7.1. Process Designer

The JavaScript language in an On Entry Action property produces an error after changing a node to multiple instances [RHPAM-3409]

Issue: When the language of the On Entry Action property is set to JavaScript and you change the node to Multiple Instance, you receive a system error.

Steps to reproduce:

  1. Create a new business process.
  2. Create a user task and set it to the Multiple Instance property.
  3. Enter any string to On Entry Action or On Exit Action.
  4. Select the JavaScript language.
  5. Select the Multiple Instance check box.

Actual result: You receive a system error.

Expected result: You do not receive an error either in the UI or in the server log file.

Workaround: None.

customCaseRoles metadata attribute is not added [RHPAM-4410]

Issue: It is not possible to add a new customCaseRoles metadata attribute in a case process definition.

Steps to reproduce:

  1. Create a case project.
  2. Create a case definition.
  3. Open Case Management in the Properties panel and add a new case role as owner:1.
  4. Save, close, and reopen the case.
  5. In the Properties panel, check the Metadata Attributes under the Advanced section.

Actual result: The Metadata Attributes section is empty.

Expected result: The Metadata Attributes section contains the customCaseRoles:owner:1.

Workaround: None.

DataObject from canvas is missing in assignments when the case file variable is present [RHPAM-4420]

Issue: The DataObject from the canvas is missing in assignments when the case file variable is present. This applies to both top-level nodes as well as nodes placed in sub-processes.

Steps to reproduce:

  1. Create a case project.
  2. Create a case definition.
  3. Add a case file variable to the process.
  4. Create a DataObject on the canvas.
  5. Create a node with assignments on the canvas or in the sub-process.
  6. Activate the node that has the assignments, open the assignments, and click Source/Target.

Actual result: The DataObject is missing from the listed items.

Expected result: Both the case file variable as well as the DataObject from the canvas is present in the listed items.

Workaround: None.

Custom data object in multiple variables causes error in case project [RHPAM-4422]

Issue: When you create a custom data object in multiple variables, you receive an error in a case project.

Steps to reproduce:

  1. Create a case project.
  2. Create a case definition.
  3. Create a custom data object in the same project.
  4. Add a process variable and a case file variable with the same CustomDataObject type.
  5. Create a multiple instance node or data object on the canvas.
  6. If you set a multiple instance node, set the MI Collection input/output and try to change Data Input/Output type.
  7. If you set a data object, try to change the data type.

Actual result: You receive an error.

Expected result: No errors occur.

Workaround: None.

7.2. Process engine

When you abort a process instance, the timer is not deleted [RHPAM-4380]

Issue: Aborting a process instance with an active timer does not delete the timer. The timer then fires at the defined trigger date, which is silently dismissed by the system, so this is not a functional problem. However, it populates the EJB timer subsystem with orphaned timers, especially if the timers are long-running and the number of aborted process instances is high.

Workaround: None.

When you use Spring Boot, the UserGroupCallback implementation is not injected into KIE Server [RHPAM-4281]

Issue: When you are using an engine embedded in a KIE Server packaged as a Spring Boot application, the bean defined as userGroupCallback is not injected into the engine. Then, when you try to call some of the rest endpoints fetching some tasks based on the user or groups assigned to them (such as potOwner, stakeHolders, businessAdmin, and so on) they do not work as expected because the UserGroupCallback implementation used in the engine is different from the one defined at the Spring boot application level. Note that this only applies to cases and not to processes.

Steps to reproduce:

  1. Start KIE Server as a Spring Boot app with a default identity provider and a UserGroupCallback implementation.
  2. Try to fetch some tasks assigned to a group by using some rest endpoints such as potOwner, stakeHolders, or businessAdmins.

Workaround: None.

Kafka-clients contain misalignment with any supported AMQ Streams version [RHPAM-4417]

Issue: Kafka dependencies for the community are not aligned with Red Hat Process Automation Manager 7.13. The current Kafka community version is 2.8.0 and it must be aligned with the version used by AMQ Streams 2.1.0 which is 3.1.0 for the community.

Workaround: None.

7.3. Spring Boot

Wrong managed version of Spring Boot dependencies [RHPAM-4413]

Issue: The Spring Boot version (2.6.6) in the Maven repository is not certified by Red Hat yet. Therefore, you will receive a mismatch for the Narayana starter in productized binaries.

Workaround: In your pom.xml file, define the following properties to override the current versions: 

<version.org.springframework.boot>2.5.12</version.org.springframework.boot>
<version.me.snowdrop.narayana>2.6.3.redhat-00001</version.me.snowdrop.narayana>

7.4. Red Hat build of Kogito

Red Hat build of Kogito is aligned with a non-supported Spring Boot version [RHPAM-4419]

Issue: Red Hat build of Kogito Spring Boot versions are managed in the kogito-spring-boot-bom file, which imports dependency management from the org.springframework.boot:spring-boot-dependencies BOM. The currently aligned version is 2.6.6, which does not map to any Red Hat supported versions. The latest supported version is 2.5.12. You must override dependency management with a BOM aligning to the Red Hat supported version which is 2.5.12.

Workaround:

  1. To maintain the order of the imported BOM files, first include the Spring Boot BOM and then include the Red Hat build of Kogito specific BOM file: 

    <dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>dev.snowdrop</groupId>
            <artifactId>snowdrop-dependencies</artifactId>
            <version>2.5.12.Final-redhat-00001</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>org.kie.kogito</groupId>
            <artifactId>kogito-spring-boot-bom</artifactId>
            <version>1.13.2.redhat-00002</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

  2. Align the version of spring-boot-maven-plugin to the same version in your project build configuration file: 

    <plugins>
      <plugin>
        <groupId>org.kie.kogito</groupId>
        <artifactId>kogito-maven-plugin</artifactId>
        <version>1.13.2.redhat-00002</version>
        <extensions>true</extensions>
      </plugin>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <version>2.5.12</version>
        <executions>
          <execution>
            <goals>
              <goal>repackage</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>

Red Hat build of Kogito on Spring Boot leads to misalignment of Kafka-clients version [RHPAM-4418]

Issue: The Kafka-clients dependency version for Red Hat build of Kogito Spring Boot is by default managed by the org.springframework.boot:spring-boot-dependencies BOM. Depending on which Spring Boot version is used, users might end up with an unsupported or vulnerable version of Kafka-clients. You must override the default dependency in your kogito-spring-boot-bom to make sure you have the expected Kafka-clients version.

Workaround: In your projects, define dependencyManagement explicitly for org.apache.kafka:kafka-clients dependency to use the version released by AMQ Streams.