Troubleshooting deployment issues with App Connect Designer

When you try to access a flow or an auto-save is attempted, you might see the following message:

Failed to retrieve flows
There was a problem retrieving your flows

Try to resolve this issue by checking whether the problem is certificate-related. To do so, examine the logs in the pod named designerName-fda-xxxxxx-yyyy (for example, des-01-quickstart-fda-7b656dfbbf-rpnkp), where designerName is the metadata.name value that defines the name of the Designer instance in the custom resource (CR), and xxxxxx and yyyy are generated sets of characters.

1. Check for the pod names for the Designer instance by running the following command.

   oc get pod -o name -l app.kubernetes.io/name=designerName -n namespaceName

   For example:

   oc get pod -o name -l app.kubernetes.io/name=des-01-quickstart -n ace-test

   The designerName-fda-xxxxxx-yyyy pod contains two containers that are named as follows:

   • designerName-fda (for example, des-01-quickstart-fda)
   • designerName-proxy (for example, des-01-quickstart-proxy)
2. View the log for the designerName-fda container.

   oc logs -f podName -c containerName

   For example:

   oc logs -f des-01-quickstart-fda-7b656dfbbf-rpnkp -c des-01-quickstart-fda

   Check the output for the following type of error:

   ERROR Failed to get document from flows DB for user: default [flowDB.js:1]
   dataObj: "{\"message\":\"The connection failed because the SSL certificate is not valid. To use a self-signed certificate, set the `disableSslVerification` parameter in the constructor options.\",\"name\":\"Error\",\"stack\":\"Error: The connection failed because the SSL certificate is not valid. To use a self-signed certificate, set the `disableSslVerification` parameter in the constructor options.\\

   If you see this error, there might be a mismatch between the certificates that are loaded by the microservices and by the CouchDB database that stores flow definition artifacts in the container’s file system. This mismatch can occur if the certificates have been updated or rotated. CouchDB automatically pick ups any new certificates, but the microservices need to be restarted to pick up new certificates.

3. To restart the microservices to pick up any new certificates, run the following commands in a bash shell (but not ksh).
   1. If necessary, switch to the namespace where the Designer instance is deployed.

      oc project designerNamespace

   2. Run the following command.

      
      oc get deployments -l appconnect.ibm.com/kind=DesignerAuthoring,app.kubernetes.io/name=designerName --no-headers |  awk '{print $1 }' |  xargs oc patch deploy $0 -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"appconnect-restart\":\"`date +'%s'`\"}}}}}"

      For example:

      
      oc get deployments -l appconnect.ibm.com/kind=DesignerAuthoring,app.kubernetes.io/name=des-01-quickstart --no-headers |  awk '{print $1 }' |  xargs oc patch deploy $0 -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"appconnect-restart\":\"`date +'%s'`\"}}}}}"

      This command triggers a rolling restart of all the pods (apart from the CouchDB pods) that are used by the Designer instance.

4. After all the pods have restarted, try to access the Designer UI.
5. If the issue is not resolved, open a case with IBM Support as described in Contacting IBM.

When creating an App Connect Designer instance, you are required to choose a storage class (spec.couchdb.storage.class) if the storage type (spec.couchdb.storage.type) for CouchDB is set to persistent-claim.

If a Designer instance is created with a spec.version value that resolves to 12.0.5.0-r1-lts or 12.0.5.0-r2, your specified storage class in the custom resource (CR) is not honored and the deployed instance instead uses the cluster's default storage class. This issue is resolved in 12.0.5.0-r3 or later, but if you upgrade from 12.0.5.0-r1-lts or 12.0.5.0-r2 to 12.0.5.0-r3 or later, the original default storage class will still be used with the Designer instance. To switch to the actual storage class that is defined in the CR, you must delete and then re-create your instance. (You will need to export any saved flows before you delete the instance, and then import the flows after re-creating the instance.)

For more information, see App Connect Designer reference: Creating an instance and Exporting and importing flows.