Known issues and limitations for OpenPages

The following known issues and limitations apply to OpenPages.

Known Issues
Limitations

Known issues

Upgrading or provisioning causes error while configuring RabbitMQ

Applies to: 5.1.1 and later

Fixed in: 5.2.0

After you upgrade OpenPages on Cloud Pak for Data from version 4.8.x to 5.1.2, the instance pod status remains incomplete, with only 1 of the 2 instances running:

# oc get pod -A| grep  openpages-openpagesinstance-cr
thanos                                             openpages-openpagesinstance-cr-sts-0                                              2/2     Running     0                3d15h
thanos                                             openpages-openpagesinstance-cr-sts-1                                              1/2     Running     0                3m11s
Check the OpenPages STS pod log for an error similar to the following:
oc logs openpages-${openpages_instance_name}-sts-1 -n thanos
For example:
oc logs openpages-openpagesinstance-cr-sts-1     -n thanos
Also, check for the following message:
ERROR
The following exception occurred:
[Default Executor-thread-3](CacheMessageProcessor.java:86)

javax.jms.JMSException: Error while confiquring RabbitMQ for OpenPages. 
  exchangeName = op.private.${openpages_instance_id}
 queueName = op.private.CacheSyncBridgeTopic.${openpages_instance_id}.openpages-openpagesinstance-cr-sts-1 
 routingKey = CacheSyncBridgeTopic.${openpages_instance_id}
 rabbitMQHost = openpages-${openpages_instance_name}--5356-ibm-rabbitmq-svc 
 rabbitMQUser = a*m*n 
 rabbitMQPassword = ***** 
 rabbitMQAMQPSPort = 5671. 
 Exception message is null
        at com.openpages.aurora.cache.RabbitMQJMSCacheSynchronizer.configureRabbitMQForOpenPages(RabbitMQJMSCacheSynchronizer.java:216)
        at com.openpages.aurora.cache.RabbitMQJMSCacheSynchronizer.init(RabbitMQJMSCacheSynchronizer.java:80)
        at com.openpages.aurora.cache.CacheMessageProcessor.sta
Workaround
To work around the problem, do the following steps:
  1. Scale down the OpenPages STS pods:
    oc scale sts openpages-${openpages_instance_name}-sts --replicas=0 -n ${OPENPAGES_INSTANCE_NAMESPACE}
  2. Scale down the RabbitMQ STS pods:
    oc -n zen-ns scale sts -l icpdsupport/addOnId=openpages,icpdsupport/app=rabbitmq-server --replicas=0
  3. Scale up the RabbitMQ STS pods:
    oc -n zen-ns scale sts -l icpdsupport/addOnId=openpages,icpdsupport/app=rabbitmq-server --replicas=3
  4. Scale up the OpenPages STS pods:
    oc scale sts openpages-${openpages_instance_name}-sts --replicas=${number_of_replicas_needed} -n ${OPENPAGES_INSTANCE_NAMESPACE}
Provisioning fails with a RabbitMQ error

Fixed in: 5.1.3

When you provision an OpenPages instance, the instance is in an InstallError state and you see the following error:
Failed to gather information about RabbitMQCluster(s) even after waiting for 300 seconds
openpagesinstance role has failed. See earlier output for exact error.
When you view the RabbitMQ cluster details, you see an error about Helm annotations.
$ oc describe rabbitmqcluster openpages-<instance_name>-<instance_id>
...
message: 'failed to install release: rendered manifests contain a resource that
  already exists. Unable to continue with install: ServiceAccount "openpages-<instance_name>-<instance_id>-ibm-rabbitmq"
  in namespace "<namespace>" exists and cannot be imported into the current release:
  invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by":
  must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name":
  must be set to "openpages-<instance_name>-<instance_id>"; annotation validation error:
  missing key "meta.helm.sh/release-namespace": must be set to "<namespace>"'
To resolve the issue, do the following steps:
  1. View the ServiceAccount by running the following command:
    oc get sa openpages-<instance_name>-<instance_id>-ibm-rabbitmq -o yaml
  2. Verify that Helm is missing from the annotations.
  3. Delete the ServiceAccount by running the following command:
    oc delete sa openpages-<instance_name>-<instance_id>-ibm-rabbitmq

After a few minutes, the RabbitMQ cluster starts and the provisioning process completes.

The Roles By User and Roles By Domain reports do not run

Applies to: 5.1.0

Fixed in: 5.1.1

The following Cognos reports do not work and return an error:
  • Roles By User
  • Roles By Domain
Some reporting fragments might fail

Applies to: 5.0.0 and later

When you run reporting fragments that use a DQM reporting framework package with prompts, the process fails.
In OpenPages, you see the following message: 
OP-12013 The computation encountered an error.
In the Cognos logs, you see the following message: 
XQE-PLN-0537 The inverted parameter &apos;<PROMPT_VARBLE>&apos; can only be 
used in the context of an IN or IN_RANGE operator. Context is 
&apos;<QUERY_SUBLECT> = ?<PROMPT_VARBLE>?&apos;

For a workaround, see Running Reporting Fragment fails with OP-12013 The computation encountered an error exception.

The Risk Management for ESG dashboards fail to run

Applies to: 5.0.0 and later

When you open the ESG Compliance Dashboard or the Objective Dashboard, you get the following message: 
We can't load the Visualization, because its associated data set 'ESG Reporting' isn't available.
Or, you might see: 
Data source adapter error:com.ibm.db2.jcc.am.SqlException: 
Application raised error or warning with diagnostic text: "No_DATA_FOUND"

For a workaround, see ESG dashboards do not display.

Net Promoter Score (NPS) survey capability

Applies to: 5.0.0 and later

The OpenPages Net Promoter Score (NPS) survey capability is temporarily unavailable during the transition to a new NPS survey platform.

Net Promoter Score (NPS) survey functionality will not be available until the transition to the new NPS survey platform is complete and a later OpenPages release becomes available that supports the new NPS survey platform.

OpenPages StatefulSet replicas do not scale down automatically

Applies to: 5.0.0 and later

The application server replicas that Horizontal Pod Autoscaler (HPA) initiates are not scaled down by HPA when the application is not in use.

Workaround
Run the following command to scale down the replicas manually. Replace <instance_name> with the OpenPages instance name and <number_of_replicas_needed> with a number greater than or equal to 1:
oc scale sts openpages-<instance_name>-sts --replicas=<number_of_replicas_needed> -n ${OPENPAGES_INSTANCE_NAMESPACE}
Generating reports through Cognos Analytics causes page module error

Applies to: 5.0.x.

After integrating OpenPages with Cognos Analytics on the IAM cluster, you get the following error when generating reports: 
Page module error
scripterror: ../v1/ext/OpenPages/PageModule
Workaround
  1. Download the OpenPages module extension zip file from the container that shipped with the product.
    If using Oracle database:
    podman cp $(podman create --rm cp.stg.icr.io/cp/hub/openpages-cpd-opappdata:9.0.0.3.2-61):/opt/cognos-artifacts/ORACLE/OpenPages.zip .
    If using Db2 database:
    podman cp $(podman create --rm cp.stg.icr.io/cp/hub/openpages-cpd-opappdata:9.0.0.3.2-61):/opt/cognos-artifacts/OpenPages.zip .
  2. Import the zip file to Cognos Analytics:
    1. Navigate to Cognos Analytics UI > Manage > customizations.
    2. Upload the zip file.
After upgrading, RabbitMQ pod is stuck in CrashLoopBackOff state

Applies to: 5.1.0, 5.1.1

Fixed in: 5.1.2

After you upgrade OpenPages on Cloud Pak for Data from version 5.0.x to 5.1, the CPD-CLI*.log file contains an error similar to that in the following example:

CPD-CLI-<timestamp>.log:time=<timestamp> level=error msg=failed to wait for statefulset openpages--78c5-ib-12ce in namespace <cpd_instance_ns>: 
timed out waiting for the condition func=cpdbr-oadp/pkg/kube.waitForStatefulSetPods file=/a/workspace/oadp-upload/pkg/kube/statefulset.go:173

To confirm that a pod is in the CrashLoopBackOff state, run the following command:

oc get pods -n ${PROJECT_CPD_INST_OPERANDS} | grep openpages
Example output:
openpages--78c5-ib-12ce-0                                1/1     Running                 0                 23h
openpages--78c5-ib-12ce-1                                0/1     CrashLoopBackOff        248 (3m57s ago)   23h
openpages-openpagesinstance-cr-sts-0                     1/2     Running                 91 (12m ago)      23h
openpages-openpagesinstance-cr-sts-1                     1/2     Running                 91 (12m ago)      23h
Workaround
To work around the problem, do the following steps:
  1. Log in to Red Hat® OpenShift® Container Platform as a cluster administrator.
    ${OC_LOGIN}
    Remember: OC_LOGIN is an alias for the oc login command.
  2. Check the OpenPages logs for the following error in the second RabbitMQ pod:
    ===========
Exception during startup:

exit:{boot_failed,{exit_status,1}}

    peer:start_it/2, line 639
    rabbit_peer_discovery:query_node_props/1, line 408
    rabbit_peer_discovery:sync_desired_cluster/3, line 189
    rabbit_db:init/0, line 65
    rabbit_boot_steps:-run_step/2-lc$^0/1-0-/2, line 51
    rabbit_boot_steps:run_step/2, line 58
    rabbit_boot_steps:-run_boot_steps/1-lc$^0/1-0-/1, line 22
    rabbit_boot_steps:run_boot_steps/1, line 23
  3. If you see this error, check the Erlang cookie value at the top of the OpenPages logs. For example, run the following command:
    oc logs -n ${PROJECT_CPD_INST_OPERANDS} openpages--78c5-ib-12ce-1
    Example output:
    Defaulted container "openpages-openpagesinstance-cr-<instance_id>-ibm-rabbitmq" out of: openpages-openpagesinstance-cr-<instance_id>-ibm-rabbitmq, copy-rabbitmq-config (init)
----------------------
+FkpbwejzK2RXfmPLQAnITroiieu3uGa3vkRA2k6t+8=
----------------------
<timestamp> [warning] <0.156.0> Overriding Erlang cookie using the value set in the environment

    The plus sign (+) at the beginning of the cookie value is the source of the problem.

  4. Regenerate a new token:
    openssl rand -base64 32 | tr -d '\\n' | base64 | tr -d '\\n'
  5. Decode from Base64 format, and make sure that the cookie value does not begin with a plus sign (+).
  6. Replace the cookie value in the auth secret.
    1. Edit the auth secret:
      oc -n ${PROJECT_CPD_INST_OPERANDS} edit secret openpages-openpagesinstance-cr-<instance_id>-rabbitmq-auth-secret
    2. Replace the rabbitmq-erlang-cookie value with the new value.
  7. Delete the StatefulSet, or scale down and then scale up to get all the pods to pick up the new cookie.

    To identify the StatefulSet, run the following command:

    oc -n ${PROJECT_CPD_INST_OPERANDS} get sts -licpdsupport/addOnId=openpages,icpdsupport/app=rabbitmq-server

    Example output:

    NAME                        READY      AGE
openpages--1e83-ib-12ce     3/3        28h

Limitations

Functional differences
The following OpenPages features are not supported in OpenPages for IBM® Software Hub
  • Field level encryption is not supported.
  • The ability to shorten the OpenPages application URL is not supported.
Long strings
If you're using an internal database, long string fields (string fields that contain more than 4000 bytes) have the following limitations:
  • Filtering on long string fields in views, dashboards, workflows, and calculations is not supported.
  • Creating public filters or personal filters that are based on long string fields is not supported.
  • Querying long string fields with the REST API is not supported.
Timestamps use Coordinated Universal Time

Timestamps use Coordinated Universal Time (Coordinated Universal Time). For example, when you run jobs in the Scheduler, the execution timestamp is in Coordinated Universal Time, rather than in local time.

Microsoft Office files

Users can't open and edit Microsoft Office files directly from OpenPages on IBM Software Hub.