App Connect Dashboard reference

Supported storage types

The following storage types are supported for allocating storage. Persistent storage, ephemeral storage, and Simple Storage Service (S3) storage can all be used to allocate storage for the content server.

Persistent storage

With this storage type, any BAR files that you upload to the App Connect Dashboard (while creating an integration server or runtime) or that you import (by using the "BAR files" page in the Dashboard) are stored in a persistent volume in the container’s file system. The persistent volume can be dynamically provisioned through a storage class that is available on the cluster, or can be requested through a claim name. Persistent storage is recommended for extra resilience because the BAR files are retained in the content server when pods restart and are deleted only when you delete the Dashboard.

The App Connect Dashboard requires a file-based storage class with ReadWriteMany (RWX) capability. If using IBM Cloud, use the ibmc-file-gold-gid storage class.

The file system must not be root-owned and must allow read/write access for the user that the Dashboard runs as. This user is a random unique identifier (UID) that is chosen by the Red Hat OpenShift cluster for all restricted pods in a given namespace.

If using Azure File storage, the owner user identifier (UID) of the Azure File mounted directory is different from the process UID of the container. From the Dashboard's pod YAML resource, get the uid value from the runAsUser field. For more information, see Considerations when using Azure File.

If you choose persistent storage, you will need to specify a storage class or the name of an existing claim, the storage size, and optionally, a label selector.

Ephemeral storage

With this storage type, an ephemeral volume is created when a Dashboard pod is started, and uploaded or imported BAR files are stored in this volume in the container’s file system. The ephemeral (emptyDir) volume exists only for the lifetime of the pod, so the BAR files will be lost when the pod restarts. You might typically choose this storage type if creating an environment for demonstration or testing.

If you choose ephemeral storage, you can specify a storage size limit for the volume.

Simple Storage Service (S3) storage

S3 storage offers an alternative option to persistent storage, and enables the content server to support the use of an object storage service for BAR file storage by using the S3 REST API.

Availability:

• S3 storage is applicable only if the spec.version value in the App Connect Dashboard custom resource resolves to 12.0.1.0-r1 or later.
• If you are using an App Connect Dashboard instance at version 13.0.3.0-r1 or earlier, only Amazon S3 and IBM Cloud Object Storage S3 are supported as S3 providers.
• If you are using an App Connect Dashboard instance at version 13.0.3.1-r1 or later, the supported S3 providers are as follows:
  • Amazon S3
  • IBM Cloud Object Storage S3
  • S3-compatible object stores in private domains (including on-premises systems) whose authentication is compatible with the authentication types that are supported for the S3Credentials configuration type
• S3 storage is not supported when the IBM App Connect Operator is installed in an air-gapped environment (or restricted network) because a cluster requires internet access to read and write BAR files from or to an S3 object store.

Any BAR files that you upload or import to the Dashboard will be stored with read/write access in a specified bucket in your S3 instance. These BAR files will all be visible on the "BAR files" page (which presents a view of the content server) and can also be viewed in the S3 bucket. An uploaded or imported BAR file is stored with a generated static token, which is hidden in the Dashboard UI, but visible as an object within the S3 bucket.

BAR files and associated tokens that are stored as objects in a bucket follow a naming convention, as shown in the following example for a BAR file named CustomerDatabaseV1.bar:

/mnt/data/content/CustomerDatabaseV1/bars/CustomerDatabaseV1.bar

/mnt/data/content/CustomerDatabaseV1/.token

If you choose S3 storage, you will need to specify the following storage settings for your provisioned S3 instance:

• The name of an existing bucket for storing uploaded or imported BAR files

  Although you are not restricted from using an S3 bucket that already contains other objects, a dedicated bucket for BAR file storage is recommended. If you decide to use a bucket that contains other objects, the App Connect Dashboard will ignore those objects because they have no association with the content server.

  Note: If different instances of the App Connect Dashboard are configured to use the same S3 bucket with the same credentials and endpoint, BAR files that are uploaded or imported to the content server from either Dashboard will be visible on the "BAR files" page in both Dashboards and can be deployed from these Dashboards.
• An S3 endpoint to which the S3 REST API sends requests for reading and writing objects

  You should be able to locate the available endpoints from your S3 instance. For example, on IBM Cloud Object Storage S3, you can locate the endpoints from the Endpoints page.

  To minimize latency, it is recommended that you use an S3 bucket that is in the same geographic area as your App Connect Dashboard instance. Also use an endpoint with a location or region that is similar to where the Dashboard is deployed. For more information, see Endpoints and storage locations in the IBM Cloud Object Storage S3 documentation and Amazon Simple Storage Service endpoints and quotas in the Amazon Web Services documentation.

• S3 credentials for connecting to the bucket

  You will need to supply these credentials by creating a configuration of type S3Credentials. For more information, see Creating a configuration of type S3Credentials for use with the App Connect Dashboard.

No attached storage

You can deploy an App Connect Dashboard instance with no storage attached by setting the storage type to none in the Dashboard CR. This option is useful if you intend to only deploy BAR files that are stored in external repositories or in baked container images, and do not need a Dashboard with a running content server for storing BAR files.

A Dashboard with no attached storage does not include a content server and therefore does not need to claim storage on the cluster. Because a content-server container does not run in the Dashboard deployment, any spec.pod.containers.content-server.* settings in the Dashboard CR are ignored.

Note: The ability to deploy a Dashboard instance with no storage attached is available for Dashboard instances at version 13.0.1.0-r1 or later only.

To define the storage type when creating an App Connect Dashboard instance, you must specify your preferred type in the custom resource settings by setting the spec.storage.type parameter and then complete the other spec.storage.* parameters as appropriate for the selected storage type. If you want to create an S3-compatible Dashboard, your must first create a configuration object of type S3Credentials to store the credentials for accessing the bucket.

Creating an instance from the IBM Cloud Pak Platform UI

To create an App Connect Dashboard instance from the IBM Cloud Pak Platform UI, complete the following steps:

1. From a browser window, log in to the Platform UI.
   Tip: You can use the generated URL for a deployed IBM Cloud Pak for Integration Platform UI instance to access the Platform UI.
   • Applicable to IBM App Connect Operator 11.0.0 or later: The Platform UI Instances page opens as the home page. The welcome banner includes a theme switcher that you can use to choose a light theme, a dark theme, or a custom theme that matches your existing system UI.
   • Applicable to IBM App Connect Operator 10.1.1 or earlier: The Platform UI home page opens with cards and navigation menu options that provide access to the instances and other resources that you are authorized to create, manage, or use. For information about completing administration tasks (such as user management or platform customization) from this page, see Platform UI in the IBM Cloud Pak foundational services documentation.

     
     From the navigation menu , expand Administration and click Integration instances.

2. From the Instances (or Integration instances) page, click Create an instance.
3. To create an App Connect Dashboard instance from the Create an instance page, click the Integration dashboard tile and click Next.
4. From the Create an integration dashboard page, click a tile to select which type of instance you want to create:
   • Quick start: Deploy a development dashboard with one replica pod.
   • Production: Deploy a production dashboard with multiple replica pods for resilience and high availability.
   • Select a template from Automation assets: (Applicable to IBM App Connect Operator 11.0.0 or later) Create a Dashboard instance by selecting an existing template from Automation assets. For more information, see Deploying an instance from a template in the IBM Cloud Pak for Integration documentation.
5. Click Next. A UI form view opens with the minimum configuration that is required to create the instance.
6. Complete either of the following steps:
   • To quickly get going, complete the standard set of configuration fields. You can display advanced settings in the UI form view by setting Advanced settings to on. Note that some fields might not be represented in the form.
     Note:

     Identity and access management (IAM) by using Keycloak is enabled by default although the authentication and authorization fields (which are used to enable or disable IAM) are not displayed in UI form view. For more information about using IAM with the instance that you are creating, see Implementing identity and access management for App Connect Designer and App Connect Dashboard instances.

     The parameters for these fields (spec.authentication.integrationKeycloak.enabled and spec.authorization.integrationKeycloak.enabled) are exposed when you switch to the YAML view.

     • Name: Enter a short distinctive name that uniquely identifies this Dashboard.
     • Namespace: Enter the name of the namespace (project) where you want to create the Dashboard instance. If the Platform UI is deployed in a single namespace (namespace-scoped), this namespace is displayed and cannot be changed.
     • Labels: (Applicable to IBM App Connect Operator 11.0.0 or later) Add one or more labels as key/value pairs, which can be used to organize and categorize (scope and select) instances. For more information, see Labels and Selectors.

       By default, a label is provided with a key of backup.appconnect.ibm.com/component and a value of dashboard. This label is used if you need to run backup and restore operations by using OpenShift API for Data Protection (OADP) and is ignored otherwise.

     • Channel or version: Select an App Connect product (fix pack) version that the Dashboard is based on. You can select a channel that will resolve to the latest fully qualified version on that channel, or select a specific fully qualified version. If you are using IBM App Connect Operator 7.1.0 or later, the supported channels or versions will depend on the Red Hat OpenShift version that is installed in your cluster. For more information about these values, see spec.version values.
     • Accept: Review the license that is accessible from the supplied link and then click this check box to accept the terms and conditions.
     • License LI: Select a license identifier that aligns with the channel or the fully qualified version that you selected. For more information, see Licensing reference for IBM App Connect Operator.
     • License use: Select an appropriate CloudPakForIntegration or AppConnectEnterprise license type that you are entitled to use.
       IAM entitlements:

       • If you purchased Cloud Pak for Integration, you are entitled to use either CloudPakForIntegration* or AppConnectEnterprise* style licenses. However, to use a CloudPakForIntegration* license, a Platform UI instance must be deployed.
       • If you purchased the IBM App Connect Operator for an independent deployment, you are restricted to AppConnectEnterprise* style licenses regardless of whether IAM is enabled or disabled. (Although installation of the Cloud Pak for Integration and other Operators is permitted if you want to use a managed Keycloak deployment to configure IAM, you are not allowed to deploy the Platform UI.)
     • Replicas: Specify the number of replica pods to run for this deployment.
     • Display Mode: Select the type of resources that you want to view in, or deploy and manage from, the Dashboard.
       • IntegrationRuntimes: Select this option if you want to use the Dashboard to display, deploy, and manage integration runtimes only. This option is the default for Dashboard instances at version 12.0.9.0-r3 or later.
       • IntegrationServers: Select this option if you want to use the Dashboard to display, deploy, and manage integration servers only.

       For more information, see Dashboard display modes.

     • API/Enabled: Set this switch to on (the default) to enable the API for IBM App Connect in containers (abbreviated to IBM App Connect API). You can use this API to administer BAR files, configuration objects, integration runtimes, and trace objects within an App Connect Dashboard instance. For more information, see API for IBM App Connect in containers.

       This field is not displayed in UI form view in App Connect Dashboard instances at version 12.0.12.2-r1. Instead, the parameter for this field (spec.api.enabled) is exposed with a default value of true when you switch to the YAML view.

     • Audit log/Disabled: Set this switch to false (the default) to enable audit logging for the App Connect Dashboard instance. Set this switch to true to disable audit logging.

       The ability to enable audit logging is available only for Dashboard instances at version 13.0.1.1-r1 or later. For more information, see Viewing audit information for the App Connect Dashboard.

     • Ingress/Enabled: Indicate whether to automatically create ingress resources for your deployed App Connect Dashboard instance and for the IBM App Connect API. In Kubernetes environments, ingress resources are required to expose your Dashboard UI and the IBM App Connect API to external traffic. The creation of ingress resources for the Dashboard and API is disabled by default.

       This field is applicable only for an IBM Cloud Kubernetes Service environment, and for a channel or version that resolves to 13.0.2.1-r1 or later.

     • Ingress/Domain: If you do not want the ingress routes to be constructed with the IBM-provided ingress subdomain of your IBM Cloud Kubernetes Service cluster, specify a preferred custom subdomain that is created in the cluster.

       This field is displayed only when Ingress/Enabled is set to true. The field is applicable only for an IBM Cloud Kubernetes Service environment, and for a channel or version that resolves to 13.0.2.1-r1 or later.

     • Storage type: Select the type of storage to use for storing BAR files that are uploaded or imported to the Dashboard.
       • persistent-claim: Choose this option for storage in a persistent volume in the container’s file system.
       • ephemeral: Choose this option for storage in an ephemeral volume that exists only for the lifetime of the pod.
       • s3: Choose this option for storage in a bucket in a Simple Storage Service (S3) instance.
       • none: Choose this option if you do not want to upload or import BAR files to a content server in the Dashboard, but instead intend to deploy BAR files that are stored in external repositories or in baked container images. This option deploys the Dashboard with no storage attached so you do not need to configure any storage class, claim, size, or S3 settings.
         Note: The ability to deploy a Dashboard instance with no storage attached is available for Dashboard instances at version 13.0.1.0-r1 or later only.

       For more information, see Supported storage types.

     • Storage class: If preferred for a persistent volume, select a supported storage class for your cluster, which should be used to dynamically provision a persistent volume that belongs to that class.

       When Storage type is set to persistent-claim, either Storage class or Claim Name is required.

       IAM requirement: Keycloak requires block storage and a storage class that is set as the default class. For more information, see Storage options for Keycloak in the IBM Cloud Pak for Integration documentation.
     • Claim Name: If preferred for a persistent volume, specify the name of an existing claim that should be used to request a persistent volume for BAR file storage. This claim must exist in the same namespace as the Dashboard. (Depending on the version of the Operator, you might see the Claim Name field only after you set Advanced settings to on to specify advanced settings from the UI form view.)

       When Storage type is set to persistent-claim, either Storage class or Claim Name is required.

     • Size: Specify the maximum amount of storage that is required for a persistent volume in decimal or binary format; that is, Gi or G. This value is required if Storage type is set to persistent-claim.
     • s3 bucket: Specify the name of an existing bucket that is used for object storage in a Simple Storage Service (S3) instance. You must have read/write access to this bucket, which will be used to store BAR files that are uploaded or imported to the Dashboard. This value is required if Storage type is set to s3.

       For a list of supported S3 providers and considerations for choosing a bucket, see Supported storage types.

     • s3 host: Specify an endpoint that is associated with your Simple Storage Service (S3) system, to which the S3 REST API sends requests for reading and writing objects to the bucket specified in s3 bucket. This value is required if Storage type is set to s3.
     • s3 configuration: Specify the name of an existing configuration object of type S3Credentials, which stores credentials for accessing the bucket specified in s3 bucket. Set this parameter to the Name (or metadata.name) value that was specified while creating the configuration. This value is required if Storage type is set to s3.

     Set Advanced settings to on if you want to specify any advanced settings from the UI form view.

     • Advanced: Log Format: Select a format for the container logs that are output to the container's console. Valid values are basic (the default) and json.
     • Advanced: Log Level: Select the level of information to display in the container logs. Valid values are info (the default) and debug.
     • Advanced: Labels: Specify one or more custom labels (as classification metadata) to apply to each pod that is created during deployment. Specify each label as a key/value pair. The custom labels that you specify are merged with the default (generated) labels. If duplicate label keys are detected, the custom value overwrites the default value.
     • Advanced: Annotations: Specify one or more custom annotations (as arbitrary metadata) to apply to each pod that is created during deployment. Specify each annotation as a key/value pair. The custom annotations that you specify are merged with the default (generated) annotations. If duplicate annotation keys are detected, the custom value overwrites the default value.
     • Advanced: Disable Routes: Clear this checkbox (the default) to enable the automatic creation of Red Hat OpenShift routes, which expose the Dashboard UI and the IBM App Connect API (if enabled) to external traffic. Select this checkbox to disable the automatic creation of routes. This option is not applicable in a Kubernetes environment.
       Tip:

       For Dashboard instances at version 13.0.4.0-r1 or later, switch to the YAML view and use the spec.routes.* parameters, which provide enhanced support for routes. The spec.routes.ui.disabled and spec.routes.api.disabled parameters (in conjunction with the Advanced: Disable Routes checkbox) allow you to enable (or disable) the automatic creation of routes for the Dashboard UI and the API (if enabled). You can also optionally use the spec.routes.ui.host and spec.routes.api.host parameters to specify custom hostnames for the routes that are created.

       For Dashboard instances at version 13.0.3.1-r1 or earlier, you can continue to use the Advanced: Disable Routes checkbox to enable (or disable) the automatic creation of Red Hat OpenShift routes for the Dashboard UI and the API (if enabled).

     • Dashboard UI container (Resource requirements): Specify CPU and memory resource requirements for running the Dashboard UI container. For information about the values that you can specify, see the spec.pod.containers.control-ui.* parameters in Custom resource values.
     • Content server container (Resource requirements): Specify CPU and memory resource requirements for running the content server container that stores BAR files. For information about the values that you can specify, see the spec.pod.containers.content-server.* parameters in Custom resource values.
       Note: If you are deploying a Dashboard instance with no storage attached (by setting Storage type to none), the deployed Dashboard does not run a content server container. Therefore, any values that you set in the Content server container (Resource requirements) fields are ignored.
     • Advanced: Name: Specify the name of an existing switch server that enables secure connectivity when running callable flows in the Dashboard instance, or when running flows that interact with applications in a private network. The switch server name is the metadata.name value in the switch server custom resource. For information about how to create a switch server, see App Connect Switch Server reference.
   • For a more advanced configuration, click YAML to switch to the YAML view and then update the editor with your required parameters.
     • For information about the available parameters and their values, see Custom resource values.
     • For information about the supported storage types for storing BAR files that can be deployed to integrations, see Storage. You can use the spec.storage.* parameters to allocate this storage. Note that you cannot change the storage type of your App Connect Dashboard instance after it's created.
7. Click Create. You are redirected to the Instances (or Integration instances) page. An entry for the instance is shown in the table with an initial status of Pending, which you can click to check the progress of the deployment. When the deployment completes, the status changes to Ready.
   

What to do next

1. If IAM with Keycloak is enabled for this instance, use the Keycloak Admin Console to manage user access to the instance by setting up users with assigned roles. For more information, see Implementing identity and access management for App Connect Designer and App Connect Dashboard instances.
2. Share the URL of the Platform UI with the configured users and supply the authentication credentials that they can use to log in to the Platform UI and Dashboard instance.

   The authorized users can access the Dashboard (Integration dashboard) instance by clicking the name in the Platform UI, and then use the instance to deploy Designer and Toolkit integrations to integration servers or integration runtimes.

Creating an instance from the Red Hat OpenShift web console

To create an App Connect Dashboard instance by using the Red Hat OpenShift web console, complete the following steps:

1. From a browser window, log in to the Red Hat OpenShift Container Platform web console. Ensure that you are in the Administrator perspective .
2. From the navigation, click Operators > Installed Operators.
3. If required, select the namespace (project) in which you installed the IBM App Connect Operator.
4. From the Installed Operators page, click IBM App Connect.
5. From the Operator details page for the App Connect Operator, click the Dashboard tab.
6. Click Create Dashboard.

   From the Details tab on the Operator details page, you can also locate the Dashboard tile and click Create instance to specify installation settings for the instance.

7. To use the Form view, ensure that Form view is selected and then complete the fields. Note that some fields might not be represented in the form.
   • Name: Enter a short distinctive name that uniquely identifies this Dashboard.
   • Labels: (Applicable to IBM App Connect Operator 11.0.0 or later)

     By default, a label is provided with a key of backup.appconnect.ibm.com/component and a value of dashboard. This label is used if you need to run backup and restore operations by using OpenShift API for Data Protection (OADP) and is ignored otherwise. For more information, see Backing up and restoring your IBM App Connect resources and persistent volumes on Red Hat OpenShift.

   • License/Accept: Select this checkbox to accept the terms and conditions of the license.
   • License/License LI: Select a license identifier that aligns with the channel or the fully qualified version that you want to select. For more information, see Licensing reference for IBM App Connect Operator.
   • License/License use: Select an appropriate CloudPakForIntegration or AppConnectEnterprise license type that you are entitled to use.
     IAM entitlements:

     • If you purchased Cloud Pak for Integration, you are entitled to use either CloudPakForIntegration* or AppConnectEnterprise* style licenses. However, to use a CloudPakForIntegration* license, a Platform UI instance must be deployed.
     • If you purchased the IBM App Connect Operator for an independent deployment, you are restricted to AppConnectEnterprise* style licenses regardless of whether IAM is enabled or disabled. (Although installation of the Cloud Pak for Integration and other Operators is permitted if you want to use a managed Keycloak deployment to configure IAM, you are not allowed to deploy the Platform UI.)
   • Channel or version: Select an App Connect product (fix pack) version that the Dashboard is based on. You can select a channel that will resolve to the latest fully qualified version on that channel, or select a specific fully qualified version. If you are using IBM App Connect Operator 7.1.0 or later, the supported channels or versions will depend on the Red Hat OpenShift version that is installed in your cluster. For more information about these values, see spec.version values.
   • Storage/Storage type: Select the type of storage to use for storing BAR files that are uploaded or imported to the Dashboard.
     • persistent-claim: Choose this option for storage in a persistent volume in the container’s file system.
     • ephemeral: Choose this option for storage in an ephemeral volume that exists only for the lifetime of the pod.
     • s3: Choose this option for storage in a bucket in a Simple Storage Service (S3) instance.
     • none: Choose this option if you do not want to upload or import BAR files to a content server in the Dashboard, but instead intend to deploy BAR files that are stored in external repositories or in baked container images. This option deploys the Dashboard with no storage attached so you do not need to configure any storage class, claim, size, or S3 settings.
       Note: The ability to deploy a Dashboard instance with no storage attached is available for Dashboard instances at version 13.0.1.0-r1 or later only.

     Note that you cannot change the storage type of your App Connect Dashboard instance after it's created. For more information, see Supported storage types.

   • Storage/Claim Name: If preferred for a persistent volume, specify the name of an existing claim that should be used to request a persistent volume for BAR file storage. This claim must exist in the same namespace as the Dashboard.

     When Storage type is set to persistent-claim, either Storage class or Claim Name is required.

   • Storage/Storage class: If preferred for a persistent volume, select a supported storage class for your cluster, which should be used to dynamically provision a persistent volume that belongs to that class.

     When Storage type is set to persistent-claim, either Storage class or Claim Name is required.

     IAM requirement: Keycloak requires block storage and a storage class that is set as the default class. For more information, see Storage options for Keycloak in the IBM Cloud Pak for Integration documentation.
   • Storage/s3 bucket: Specify the name of an existing bucket that is used for object storage in a Simple Storage Service (S3) instance. You must have read/write access to this bucket, which will be used to store BAR files that are uploaded or imported to the Dashboard. This value is required if Storage type is set to s3.

     For a list of supported S3 providers and considerations for choosing a bucket, see Supported storage types.

   • Storage/s3 host: Specify an endpoint that is associated with your Simple Storage Service (S3) system, to which the S3 REST API sends requests for reading and writing objects to the bucket specified in s3 bucket. This value is required if Storage type is set to s3.
   • Storage/s3 configuration: Specify the name of an existing configuration object of type S3Credentials, which stores credentials for accessing the bucket specified in s3 bucket. Set this parameter to the Name (or metadata.name) value that was specified while creating the configuration. This value is required if Storage type is set to s3.
   • Storage/Selector: Specify a label query that a specified claim can use to filter for volumes that can be bound to the claim. This setting is applicable only when Storage type is set to persistent-claim. For more information, see the spec.storage.selector parameter in Custom resource values.
   • Replicas: Specify the number of replica pods to run for this deployment.
   • Display Mode: Select the type of resources that you want to view in, or deploy from, the Dashboard.
     • IntegrationRuntimes: Select this option if you want to use the Dashboard to display or deploy integration runtimes only. This option is the default for Dashboard instances at version 12.0.9.0-r3 or later.
     • IntegrationServers: Select this option if you want to use the Dashboard to display or deploy integration servers only.

     For more information, see Dashboard display modes.

   • switchServer/Name: Specify the name of an existing switch server that enables secure connectivity when running callable flows in the Dashboard instance, or when running flows that interact with applications in a private network. The switch server name is the metadata.name value in the switch server custom resource. For information about how to create a switch server, see App Connect Switch Server reference.
     Note: If you want to deploy integrations that run callable flows or that interact with applications in a private network, the Dashboard instance must be configured to use a switch server.

     • For callable flows, the Dashboard configuration is automatic if a switch server also exists in the same namespace. When you create a switch server, it is automatically associated with the Dashboard instance, and default Agentx and AgentA configuration objects are created for configuring connectivity. This Agentx configuration object must be selected when creating an integration server or integration runtime that includes a callable flow. The default configuration objects are named in the format metadata.name-agentx and metadata.name-agenta, where metadata.name is the switch server name. For more information about configuration objects, see Configuration types.
     • To deploy integrations that interact with applications in a private network, you need to manually configure the Dashboard instance to use a switch server.
       • If a switch server is already deployed in the namespace, complete the switchServer/Name field (in Form view), or add the spec.switchServer.name parameter to the Dashboard YAML, where switchServerName is the metadata.name value in the switch server custom resource.

         spec:
           switchServer:
             name: switchServerName

       • If a switch server is not yet deployed in the namespace, you can create a switch server after you create the Dashboard instance. Then, update the Dashboard custom resource to add the spec.switchServer.name setting as described in Updating the custom resource settings for an instance.

       For information about how to create a switch server, see App Connect Switch Server reference. When you create a switch server, a default Private Network Agent configuration object is also created, which you can use to set up private network connectivity. The default configuration object is named in the format metadata.name-privatenetworkagent, where metadata.name is the switch server name.

     A Dashboard instance that is configured to use a switch server includes a Private network connections page that you can use to configure connectivity to applications in a private network.

   • API/Enabled: Set this switch to true (the default) to enable the API for IBM App Connect in containers (abbreviated to IBM App Connect API). Set this switch to false to disable the API. You can use this API to administer BAR files, configuration objects, integration runtimes, and trace objects within an App Connect Dashboard instance. For more information, see API for IBM App Connect in containers.
   • Audit log/Disabled: Set this switch to false (the default) to enable audit logging for the App Connect Dashboard instance. Set this switch to true to disable audit logging.

     The ability to enable audit logging is available only for Dashboard instances at version 13.0.1.1-r1 or later. For more information, see Viewing audit information for the App Connect Dashboard.

   Expand the Advanced configuration section if you want to specify any advanced settings in Form view.

   • Authentication and Authorization: Expand these sections in turn to complete the fields that enable you to control access to the Dashboard instance by using Keycloak to implement identity and access management (IAM). Although the same set of fields are displayed in both sections, the Authentication fields relate to user validation whereas the Authorization fields relate to access permissions.
     • To control access to the instance by using the managed Keycloak solution that IBM Cloud Pak for Integration provides on Red Hat OpenShift, select both of the integrationKeycloak/Enabled checkboxes to enable Keycloak. Then, leave all of the remaining fields blank. Keycloak is enabled by default. For more information about using IAM with the instance that you are creating, see Implementing identity and access management in IBM App Connect by using a managed Keycloak solution on Red Hat OpenShift.
       Restriction: You cannot use the managed Keycloak deployment in a Kubernetes environment, so ensure that both of the integrationKeycloak/Enabled checkboxes are clear (to disable Keycloak) and leave all of the remaining fields blank.
     • To control access to the instance by using a self-managed Keycloak solution with an independent deployment of the IBM App Connect Operator on Red Hat OpenShift, select both of the integrationKeycloak/Enabled checkboxes to enable Keycloak. Then, complete all of the remaining fields except integrationKeycloak/Tls/Ingress Host.

       Also ensure that you are using an AppConnectEnterprise* style license. For more information about using IAM with the instance that you are creating, see Implementing identity and access management in IBM App Connect by using a self-managed Keycloak solution on Red Hat OpenShift or Kubernetes.

     • To control access to the instance by using a self-managed Keycloak solution with an independent deployment of the IBM App Connect Operator on Kubernetes, select both of the integrationKeycloak/Enabled checkboxes to enable Keycloak. Then, complete all of the remaining fields.

       Also ensure that you are using an AppConnectEnterprise* style license. For more information about using IAM with the instance that you are creating, see Implementing identity and access management in IBM App Connect by using a self-managed Keycloak solution on Red Hat OpenShift or Kubernetes.

     • If you do not want to restrict access to the instance, clear both of the integrationKeycloak/Enabled checkboxes and ensure that all of the remaining fields are blank. Also ensure that you are using an AppConnectEnterprise* style license.

     Complete the relevant fields to enable IAM in a managed Keycloak deployment or in a self-managed Keycloak deployment:

     • integrationKeycloak/Auth/Client Secret Name: Specify the name of a Kubernetes secret that stores the credentials for the Keycloak client that you set up to represent your secured Dashboard instance in your self-managed Keycloak deployment. These credentials were specified as a user-supplied client ID and a generated client secret when you created the Keycloak client in the Keycloak Admin Console. For information about how to create this secret, see Creating App Connect Designer or App Connect Dashboard instances with IAM enabled (step 3).

       This value is required if the integrationKeycloak/Enabled checkboxes are selected and integrationKeycloak/Endpoint values are defined.

     • integrationKeycloak/Enabled: Select the checkbox in the Authentication section to control access to the Dashboard instance by using IAM to validate user identities. Select the checkbox in the Authorization section to control access to the Dashboard instance by using IAM to grant access permissions.

       Leave both checkboxes blank if you do not want to restrict access to the instance.

       For more information, see Implementing identity and access management in IBM App Connect by using a managed Keycloak solution on Red Hat OpenShift or Implementing identity and access management in IBM App Connect by using a self-managed Keycloak solution on Red Hat OpenShift or Kubernetes.

     • integrationKeycloak/Endpoint: Specify the URL that you use to access your Keycloak instance in your self-managed Keycloak deployment. For more information, see Locating the URL for your Keycloak instance. This value is required if the integrationKeycloak/Enabled checkboxes are selected.
     • integrationKeycloak/Realm: Specify the Keycloak realm, which you created in your self-managed Keycloak deployment to manage users and their access to the Dashboard instance. For more information, see Setting up a self-managed deployment of Keycloak.

       This value is required if the integrationKeycloak/Enabled checkboxes are selected and integrationKeycloak/Endpoint values are defined.

     • integrationKeycloak/Tls/Ca Certificate: Specify the name of the key in a key/value pair that defines the certificate authority (CA) certificate from your self-managed Keycloak deployment. This key and the certificate are stored in the secret that is specified in integrationKeycloak/Tls/Secret Name.

       The name of the key can be ca.crt (the default) or another name of your choice. For more information, see Creating App Connect Designer or App Connect Dashboard instances with IAM enabled.

       This value is required if the integrationKeycloak/Enabled checkboxes are selected and integrationKeycloak/Endpoint values are defined.

     • integrationKeycloak/Tls/Ingress Host: If you are working in a Kubernetes environment with a self-managed Keycloak deployment, complete one of these actions:
       • Applicable to IBM App Connect Operator 12.8.0 or later on IBM Cloud Kubernetes Service only: If you are creating a Dashboard instance at version 13.0.2.1-r1 or later, the integrationKeycloak/Tls/Ingress Host value is optional when the integrationKeycloak/Enabled checkboxes are selected and integrationKeycloak/Endpoint values are defined.

         If you set Ingress/Enabled to true to automatically create ingress resources for the Dashboard UI and for the IBM App Connect API (if enabled), you can leave the integrationKeycloak/Tls/Ingress Host field blank because host names or ingress routes for the Dashboard UI and the API are generated by default.

         If you set Ingress/Enabled to true and then manually specify an ingress host prefix and subdomain (in the format <hostPrefix>.<ingress_subdomain>) within the integrationKeycloak/Tls/Ingress Host field, you must populate the Ingress/Domain field with a matching <ingress_subdomain> value.

         For more information, see Automatically creating ingress definitions for external access to your IBM App Connect instances on IBM Cloud Kubernetes Service.

       • Applicable to IBM App Connect Operator 12.7.0 or earlier on IBM Cloud Kubernetes Service only: If you are creating a Dashboard instance at version 13.0.2.0-r1 or earlier, specify the ingress host prefix and subdomain that are combined to form a host name or ingress route for the Dashboard UI. (You need to manually create an ingress route for the deployed Dashboard instance to define an externally-reachable URL, which is used to access the running service in the cluster.)

         An ingress route is typically created after the Dashboard instance is created, but you can decide which ingress host prefix and subdomain you want to use beforehand and then specify the value in the following format:

         <dashboardHostPrefix>.<ingress_subdomain>

         For more information, see Manually creating ingress definitions for external access to your IBM App Connect instances in Kubernetes environments.

         The integrationKeycloak/Tls/Ingress Host value is required if the integrationKeycloak/Enabled checkboxes are selected and integrationKeycloak/Endpoint values are defined.

       • If you are creating a Dashboard instance within a Kubernetes environment other than IBM Cloud Kubernetes Service, specify the ingress host prefix and subdomain that are combined to form a host name or ingress route for the Dashboard UI. (You need to manually create an ingress route for the deployed Dashboard instance to define an externally-reachable URL, which is used to access the running service in the cluster.)

         An ingress route is typically created after the Dashboard instance is created, but you can decide which ingress host prefix and subdomain you want to use beforehand and then specify the value in the following format:

         <dashboardHostPrefix>.<ingress_subdomain>

         For more information, see Manually creating ingress definitions for external access to your IBM App Connect instances in Kubernetes environments.

         The integrationKeycloak/Tls/Ingress Host value is required if the integrationKeycloak/Enabled checkboxes are selected and integrationKeycloak/Endpoint values are defined.

     • integrationKeycloak/Tls/Secret Name: Specify the name of a secret that stores the CA certificate from your self-managed Keycloak deployment, which is used to establish secure communication between the Dashboard instance and the Keycloak instance. When you create the secret, define a key/value pair, where:
       • The key has a default of name of ca.crt or another name. (You also need to specify this key as the value for integrationKeycloak/Tls/Ca Certificate.)
       • The value is the Base64-encoded CA certificate from Keycloak.

       For more information, see Creating App Connect Designer or App Connect Dashboard instances with IAM enabled (step 2).

       This value is required if the integrationKeycloak/Enabled checkboxes are selected and integrationKeycloak/Endpoint values are defined.

   • Ingress/Enabled: Indicate whether to automatically create ingress resources for your deployed App Connect Dashboard instance and for the IBM App Connect API. In Kubernetes environments, ingress resources are required to expose your Dashboard UI and the IBM App Connect API to external traffic. The creation of ingress resources for the Dashboard and API is disabled by default.

     This field is applicable only for an IBM Cloud Kubernetes Service environment, and for a channel or version that resolves to 13.0.2.1-r1 or later.

   • Ingress/Domain: If you do not want the ingress routes to be constructed with the IBM-provided ingress subdomain of your IBM Cloud Kubernetes Service cluster, specify a preferred custom subdomain that is created in the cluster.

     This field is displayed only when Ingress/Enabled is set to true. The field is applicable only for an IBM Cloud Kubernetes Service environment, and for a channel or version that resolves to 13.0.2.1-r1 or later.

   • Disable Routes: Clear this checkbox (the default) to enable the automatic creation of Red Hat OpenShift routes, which expose the Dashboard UI and the IBM App Connect API to external traffic. Select this checkbox to disable the automatic creation of routes. This option is not applicable in a Kubernetes environment.
     Tip:

     For Dashboard instances at version 13.0.4.0-r1 or later, use the Routes/API and Routes/UI fields, which provide enhanced support for routes. The Routes/UI/Disabled and Routes/API/Disabled switches (in conjunction with the Disable Routes checkbox) allow you to enable (or disable) the automatic creation of routes for the Dashboard UI and the API (if enabled). You can also optionally use the Routes/UI/Hostname and Routes/API/Hostname fields to specify custom hostnames for the routes that are created.

     For Dashboard instances at version 13.0.3.1-r1 or earlier, you can continue to use the Disable Routes checkbox to enable (or disable) the automatic creation of Red Hat OpenShift routes for the Dashboard UI and the API (if enabled).

   • Log Format: Select a format for the container logs that are output to the container's console. Valid values are basic (the default) and json.
   • Log Level: Select the level of information to display in the container logs. Valid values are info (the default) and debug.
   • Pod/containers/control-ui: Specify resource requirements for running the Dashboard UI container. For information about the values that you can specify, see the spec.pod.containers.control-ui.* parameters in Custom resource values.
   • Pod/containers/content-server: Specify resource requirements for running the content server container that stores BAR files. For information about the values that you can specify, see the spec.pod.containers.content-server.* parameters in Custom resource values.
     Note: If you are deploying a Dashboard instance with no storage attached (by setting Storage type to none), the deployed Dashboard does not run a content server container. Therefore, any values that you set in the Pod/containers/content-server fields are ignored.
   • Pod/imagePullSecrets: Use the Add ImagePullSecrets link to add one or more secrets for pulling images.
   • Pod/tolerations: Specify one or more pod tolerations (together with taints) to prevent pods from being scheduled on inappropriate nodes.

     First, apply one or more taints to a node (by running oc taint or kubectl taint with a key, value, and taint effect) to indicate that the node should repel any pods that do not tolerate the taints. Then, use the Pod/tolerations fields to apply toleration settings (effect, key, operator, toleration period, and value) to a pod to allow it to be scheduled on the node if the pod's toleration matches the node's taint. For information about the values that you can specify, see the spec.pod.tolerations.effect, spec.pod.tolerations.key, spec.pod.tolerations.operator, spec.pod.tolerations.tolerationSeconds, and spec.pod.tolerations.value parameters in Custom resource values. See also Taints and Tolerations in the Kubernetes documentation.

   • Pod/volumes: Specify details of one or more named volumes that can be provided to the pod, to use for persisting data. For information about the values that you can specify, see the spec.pod.volumes parameter in Custom resource values.
   • Pod/Advanced configuration/Topology Spread Constraints: Use the Add Topology Spread Constraints link to add one or more topology spread constraints that control how to distribute or spread pods across topological domains such as zones, nodes, or regions in a multi-zone or multi-node cluster. You can use these settings to configure high availability and fault tolerance by spreading workloads evenly across domains. These fields are applicable only for a channel or version that resolves to 13.0.4.1-r1 or later. For information about the values that you can specify, see the spec.pod.topologySpreadConstraint[].* parameters in Custom resource values.
   • Routes/API/Disabled: Set this switch to false (the default) to enable the automatic creation of a Red Hat OpenShift route for the IBM App Connect API, to route external traffic to the API. Set this switch to true to disable the automatic creation of a route.

     This field is applicable only when the API/Enabled switch is set to true to enable the API for the Dashboard instance, and when the channel or version resolves to 13.0.4.0-r1 or later. For more information, see the spec.routes.api.disabled parameter in Custom resource values.

     Note: The Routes fields provide enhanced support (over the Disable Routes checkbox) for Red Hat OpenShift routes.
   • Routes/API/Hostname to set on the route: Specify a unique custom hostname that should be used to define the base URL (minus the https:// prefix) for the API server that is reserved for the Dashboard instance; for example, myapiserver.mydomain.com.

     This field is applicable only when the Routes/API/Disabled switch is set to false and the API/Enabled switch is set to true. The channel or version must also resolve to 13.0.4.0-r1 or later. For more information, see the spec.routes.api.host parameter in Custom resource values.

   • Routes/UI/Disabled: Set this switch to false (the default) to enable the automatic creation of a Red Hat OpenShift route, which externally exposes a service that identifies the set of App Connect Dashboard pods. Set this switch to true to disable the automatic creation of a route.

     This field is applicable only for a channel or version that resolves to 13.0.4.0-r1 or later. For more information, see the spec.routes.ui.disabled parameter in Custom resource values.

   • Routes/UI/Hostname to set on the route: Specify a unique custom hostname that should be used to define the URL (minus the https:// prefix) for accessing the Dashboard UI from a browser address bar; for example, mydashboard.mydomain.com.

     This field is applicable only for a channel or version that resolves to 13.0.4.0-r1 or later. For more information, see the spec.routes.ui.host parameter in Custom resource values.

   • Pod affinity: Specify custom affinity settings that will control the placement of pods on nodes. For more information, see the spec.affinity parameter in Custom resource values.
8. Optional: For a finer level of control over your installation settings, click YAML view to switch to the YAML view. Update the content of the YAML editor with the parameters and values that you require for this Dashboard instance.

   To view the full set of parameters and values available, see Custom resource values.

9. Click Create to start the deployment. An entry for the Dashboard instance is shown in the Dashboards table, initially with a Pending status.
10. Click the Dashboard name to view information about its definition and current status.

    On the Details tab of the page, you can view the following information:

    • The Conditions section reveals the progress of the deployment.
    • If you created the Dashboard by using IBM App Connect Operator 11.2.0 or later, you also see the following details:
      • API: (12.0.12.2-r1 or later Dashboard versions) If the API for IBM App Connect in containers is enabled for the Dashboard instance, this value displays the base URL for the API server that is reserved for the instance.
      • Dashboard UI: This value displays the URL that you can use to access the Dashboard instance.
      • Keycloak UI: If Keycloak is enabled, this value displays the URL of the Keycloak instance that you can use to access the Keycloak Admin Console.

      These URLs are displayed after the deployment completes. You can also locate these URLs under Networking > Routes in the console navigation.

      
    • If you created the Dashboard by using IBM App Connect Operator 11.1.0 or earlier, the Admin UI field provides the URL for accessing the Dashboard instance. (This URL is displayed after the deployment completes.) You can also locate this URL under Networking > Routes in the console navigation.
      

    You can use the breadcrumb trail to return to the (previous) Operator details page for the App Connect Operator. When the deployment is complete, the status is shown as Ready in the Dashboards table.

What to do next

1. If IAM with Keycloak is enabled for this instance, use the Keycloak Admin Console to manage user access to the instance by setting up users with assigned roles. For more information, see Implementing identity and access management for App Connect Designer and App Connect Dashboard instances.
2. Share the Dashboard UI (or Admin UI) URL with the users who need to access the Dashboard. If IAM is enabled, also supply the authentication credentials that users can use to log in to the Dashboard instance.

   Users can then access and use the Dashboard instance to deploy Designer and Toolkit integrations to integration servers or integration runtimes.

Creating an instance from the Red Hat OpenShift or Kubernetes CLI

To create an App Connect Dashboard instance from the Red Hat OpenShift or Kubernetes CLI, complete the following steps.

1. From your local computer, create a YAML file that contains the configuration for the App Connect Dashboard instance that you want to create. Include the metadata.namespace parameter to identify the namespace in which you want to create the instance; this should be the same namespace where the other App Connect instances or resources are created.
   • To view the full set of parameters and values that you can specify, see Custom resource values.
     
     For information about the supported storage types for storing BAR files that can be deployed to integrations, see Storage. You can use the spec.storage.* parameters to allocate this storage. Note that you cannot change the storage type of your App Connect Dashboard instance after it's created.

     IAM requirement: Keycloak requires block storage and a storage class that is set as the default class. For more information, see Storage options for Keycloak in the IBM Cloud Pak for Integration documentation.
     Note: If you want to deploy integrations that run callable flows or that interact with applications in a private network, the Dashboard instance must be configured to use a switch server.

     • For callable flows, the Dashboard configuration is automatic if a switch server also exists in the same namespace. When you create a switch server, it is automatically associated with the Dashboard instance, and default Agentx and AgentA configuration objects are created for configuring connectivity. This Agentx configuration object must be selected when creating an integration server or integration runtime that includes a callable flow. The default configuration objects are named in the format metadata.name-agentx and metadata.name-agenta, where metadata.name is the switch server name. For more information about configuration objects, see Configuration types.
     • To deploy integrations that interact with applications in a private network, you need to manually configure the Dashboard instance to use a switch server.
       • If a switch server is already deployed in the namespace, complete the switchServer/Name field (in Form view), or add the spec.switchServer.name parameter to the Dashboard YAML, where switchServerName is the metadata.name value in the switch server custom resource.

         spec:
           switchServer:
             name: switchServerName

       • If a switch server is not yet deployed in the namespace, you can create a switch server after you create the Dashboard instance. Then, update the Dashboard custom resource to add the spec.switchServer.name setting as described in Updating the custom resource settings for an instance.

       For information about how to create a switch server, see App Connect Switch Server reference. When you create a switch server, a default Private Network Agent configuration object is also created, which you can use to set up private network connectivity. The default configuration object is named in the format metadata.name-privatenetworkagent, where metadata.name is the switch server name.

     A Dashboard instance that is configured to use a switch server includes a Private network connections page that you can use to configure connectivity to applications in a private network.

   • Use the spec.displayMode parameter to indicate whether you want to use the Dashboard to display or deploy integration servers only or integration runtimes only.
   • To control access to the instance by using identity and access management (IAM), specify values for the spec.authentication.integrationKeycloak.* and spec.authorization.integrationKeycloak.* parameters, which are provided for configuring Keycloak. The authentication parameters enable user identities to be validated whereas the authorization parameters enable access permissions to be granted.

     The parameters that you specify depend on the type of Keycloak solution that you are using.

     • To control access to the instance by using the managed Keycloak solution that IBM Cloud Pak for Integration provides on Red Hat OpenShift, set spec.authentication.integrationKeycloak.enabled and spec.authorization.integrationKeycloak.enabled to true to enable Keycloak. Omit all of the remaining parameters or leave them blank. Keycloak is enabled by default. For more information about using IAM with the instance that you are creating, see Implementing identity and access management in IBM App Connect by using a managed Keycloak solution on Red Hat OpenShift.
       Restriction: You cannot use the managed Keycloak solution in a Kubernetes environment, so ensure that both spec.authentication.integrationKeycloak.enabled and spec.authorization.integrationKeycloak.enabled are set to false to disable Keycloak.
     • To control access to the instance by using a self-managed Keycloak solution with an independent deployment of the IBM App Connect Operator on Red Hat OpenShift, set spec.authentication.integrationKeycloak.enabled and spec.authorization.integrationKeycloak.enabled to true to enable Keycloak. Then, complete all of the remaining parameters except spec.authentication.integrationKeycloak.tls.ingressHost and spec.authorization.integrationKeycloak.tls.ingressHost.

       Also ensure that you are using an AppConnectEnterprise* style license. For more information about using IAM with the instance that you are creating, see Implementing identity and access management in IBM App Connect by using a self-managed Keycloak solution on Red Hat OpenShift or Kubernetes.

     • To control access to the instance by using a self-managed Keycloak solution with an independent deployment of the IBM App Connect Operator on Kubernetes, set spec.authentication.integrationKeycloak.enabled and spec.authorization.integrationKeycloak.enabled to true to enable Keycloak. Then, complete all of the remaining parameters.

       Also ensure that you are using an AppConnectEnterprise* style license. For more information about using IAM with the instance that you are creating, see Implementing identity and access management in IBM App Connect by using a self-managed Keycloak solution on Red Hat OpenShift or Kubernetes.

     • If you do not want to restrict access to the instance, set spec.authentication.integrationKeycloak.enabled and spec.authorization.integrationKeycloak.enabled to false (to disable Keycloak). Omit all of the remaining parameters or leave them blank. Also ensure that you are using an AppConnectEnterprise* style license.
     Note: You cannot disable IAM by omitting spec.authentication.integrationKeycloak.enabled and spec.authorization.integrationKeycloak.enabled from the CR. If omitted, IAM is enabled by default.
   • Use the spec.api.enabled parameter to indicate whether you want to enable the API for IBM App Connect in containers (abbreviated to IBM App Connect API). You can use this API to administer BAR files, configuration objects, integration runtimes, and trace objects within an App Connect Dashboard instance. For more information, see API for IBM App Connect in containers.
   • Use the spec.auditLog.disabled parameter to indicate whether you want to enable audit logging for the App Connect Dashboard instance. For more information, see Viewing audit information for the App Connect Dashboard.
   • Use the spec.ingress.enabled parameter to indicate whether to automatically create ingress resources for your deployed App Connect Dashboard instance and for the IBM App Connect API. Use the spec.ingress.domain parameter to specify a custom subdomain to include in the ingress routes that are generated to expose your IBM App Connect instances to external traffic. These parameters are applicable only for an IBM Cloud Kubernetes Service environment.
   • Use the spec.pod.topologySpreadConstraint[].* parameters to add one or more topology spread constraints that control how to distribute or spread pods across topological domains such as zones, nodes, or regions in a multi-zone or multi-node cluster. You can use these settings to configure high availability and fault tolerance by spreading workloads evenly across domains.
   • Use the spec.routes.ui.disabled and spec.routes.api.disabled parameters to enable or disable the automatic creation of Red Hat OpenShift routes for the App Connect Dashboard and the IBM App Connect API (if enabled for the Dashboard instance). When the automatic creation of routes is enabled, you can also optionally use the spec.routes.ui.host and spec.routes.api.host parameters to specify custom hostnames to use in the generated URL for accessing the Dashboard UI and the generated base URL for the API server.
   • For licensing information, see Licensing reference for IBM App Connect Operator.
     IAM entitlements:

     • If you purchased Cloud Pak for Integration, you are entitled to use either CloudPakForIntegration* or AppConnectEnterprise* style licenses. However, to use a CloudPakForIntegration* license, a Platform UI instance must be deployed.
     • If you purchased the IBM App Connect Operator for an independent deployment, you are restricted to AppConnectEnterprise* style licenses regardless of whether IAM is enabled or disabled. (Although installation of the Cloud Pak for Integration and other Operators is permitted if you want to use a managed Keycloak deployment to configure IAM, you are not allowed to deploy the Platform UI.)

   The following examples (Example 1 and Example 2) show a Dashboard CR with settings for a persistent-claim storage type and a display mode that provides a view of integration runtimes only. The spec.switchServer.name setting references an existing switch server that is used for callable flow and private network connectivity, and spec.api.enabled is set to true to enable the API for IBM App Connect in containers.

   Example 1: Keycloak enabled for IAM by default for a managed Keycloak deployment that IBM Cloud Pak for Integration provides

   apiVersion: appconnect.ibm.com/v1beta1
   kind: Dashboard
   metadata:
     name: db-prod
     labels:
       backup.appconnect.ibm.com/component: dashboard
     namespace: mynamespace
   spec:
     license:
       accept: true
       license: L-CKFT-S6CHZW
       use: CloudPakForIntegrationNonProduction
     pod:
       containers:
         content-server:
           resources:
             limits:
               memory: 512Mi
             requests:
               cpu: 50m
               memory: 50Mi
         control-ui:
           resources:
             limits:
               memory: 512Mi
             requests:
               cpu: 50m
               memory: 125Mi
     switchServer:
       name: default
     authentication:
       integrationKeycloak:
         enabled: true
     authorization:
       integrationKeycloak:
         enabled: true
     api:
       enabled: true
     storage:
       size: 5Gi
       type: persistent-claim
       class: ocs-storagecluster-cephfs
     displayMode: IntegrationRuntimes
     replicas: 3
     version: '13.0'

   Example 2: Keycloak disabled for a managed Keycloak deployment that IBM Cloud Pak for Integration provides (not supported on Kubernetes)

   apiVersion: appconnect.ibm.com/v1beta1
   kind: Dashboard
   metadata:
     name: db-prod
     labels:
       backup.appconnect.ibm.com/component: dashboard
     namespace: mynamespace
   spec:
     license:
       accept: true
       license: L-CKFT-S6CHZW
       use: AppConnectEnterpriseProduction
     pod:
       containers:
         content-server:
           resources:
             limits:
               memory: 512Mi
             requests:
               cpu: 50m
               memory: 50Mi
         control-ui:
           resources:
             limits:
               memory: 512Mi
             requests:
               cpu: 50m
               memory: 125Mi
     switchServer:
       name: default
     authentication:
       integrationKeycloak:
         enabled: false
     authorization:
       integrationKeycloak:
         enabled: false
     api:
       enabled: true
     storage:
       size: 5Gi
       type: persistent-claim
       class: valid-storage-class
     displayMode: IntegrationRuntimes
     replicas: 3
     version: '13.0'

   The following examples (Example 3 and Example 4) show a Dashboard CR with settings for an s3 storage type and a display mode that provides a view of integration servers only. The spec.switchServer.name setting also references an existing switch server that is used for callable flow and private network connectivity.

   Example 3: Keycloak enabled for IAM by default for a managed Keycloak deployment that IBM Cloud Pak for Integration provides

   apiVersion: appconnect.ibm.com/v1beta1
   kind: Dashboard
   metadata:
     name: db-prod
     labels:
       backup.appconnect.ibm.com/component: dashboard
     namespace: mynamespace
   spec:
     license:
       accept: true
       license: L-CKFT-S6CHZW
       use: CloudPakForIntegrationNonProduction
     pod:
       containers:
         content-server:
           resources:
             limits:
               memory: 512Mi
             requests:
               cpu: 50m
               memory: 50Mi
         control-ui:
           resources:
             limits:
               memory: 512Mi
             requests:
               cpu: 50m
               memory: 125Mi
     switchServer:
       name: default
     authentication:
       integrationKeycloak:
         enabled: true
     authorization:
       integrationKeycloak:
         enabled: true
     storage:
       size: 5Gi
       type: s3
       bucket: appc-operator-e2e
       host: s3.eu-gb.cloud-object-storage.appdomain.cloud
       s3Configuration: s3credentials-ibmcosiam
     displayMode: IntegrationServers
     replicas: 3
     version: '13.0'

   Example 4: Keycloak disabled for a managed Keycloak deployment that IBM Cloud Pak for Integration provides (not supported on Kubernetes)

   apiVersion: appconnect.ibm.com/v1beta1
   kind: Dashboard
   metadata:
     name: db-prod
     labels:
       backup.appconnect.ibm.com/component: dashboard
     namespace: mynamespace
   spec:
     license:
       accept: true
       license: L-CKFT-S6CHZW
       use: AppConnectEnterpriseProduction
     pod:
       containers:
         content-server:
           resources:
             limits:
               memory: 512Mi
             requests:
               cpu: 50m
               memory: 50Mi
         control-ui:
           resources:
             limits:
               memory: 512Mi
             requests:
               cpu: 50m
               memory: 125Mi
     switchServer:
       name: default
     authentication:
       integrationKeycloak:
         enabled: false
     authorization:
       integrationKeycloak:
         enabled: false
     storage:
       size: 5Gi
       type: s3
       bucket: appc-operator-e2e
       host: s3.eu-gb.cloud-object-storage.appdomain.cloud
       s3Configuration: s3credentials-ibmcosiam
     displayMode: IntegrationServers
     replicas: 3
     version: '13.0'

   To see examples of a Dashboard CR with settings to enable Keycloak for a self-managed Keycloak deployment on Red Hat OpenShift or Kubernetes, see Implementing identity and access management in IBM App Connect by using a self-managed Keycloak solution on Red Hat OpenShift or Kubernetes.

   To see an example of a Dashboard CR with settings to enable ingress for a Dashboard and API in an IBM Cloud Kubernetes Service cluster, see Automatically creating ingress definitions for IBM App Connect instances in an IBM Cloud Kubernetes Service cluster.

2. Save this file with a .yaml extension; for example, dashboard_cr.yaml.
3. From the command line, log in to your cluster by using the oc login command or the relevant command for your Kubernetes environment.
4. Run the following command to create the App Connect Dashboard instance. (Use the name of the .yaml file that you created.)
   

   oc apply -f dashboard_cr.yaml

   

   kubectl apply -f dashboard_cr.yaml

5. Run the following command to check the status of the App Connect Dashboard instance and verify that it is ready:
   

   oc get dashboards -n namespace

   

   kubectl get dashboards -n namespace

   On IBM App Connect Operator 11.2.0 or later, the output also provides the following details, as shown in the following example:

   • UI URL: This value displays the URL that you can use to access the Dashboard instance.
   • API URL: (12.0.12-r1 or later Dashboard versions only) If the API for IBM App Connect in containers is enabled for the Dashboard instance, this value displays the base URL for the API server that is reserved for the instance.
   • KEYCLOAK URL: If Keycloak is enabled, this value displays the URL of the Keycloak instance, which you can use to access the Keycloak Admin Console.

   NAME             RESOLVEDVERSION   REPLICAS   CUSTOMIMAGES   STATUS   UI URL                                                             API URL                                                             KEYCLOAK URL                                                        AGE
   db-fd-cp4i-rc2   13.0.6.0-r1        1          false          Ready    https://db-fd-cp4i-rc2-ui-ace-fiona.apps.acecc-414-amd64.abc.com   https://db-fd-cp4i-rc2-api-ace-fiona.apps.acecc-414-amd64.abc.com   https://keycloak-ibm-common-services.apps.acecc-414-amd64.abc.com   75m
   

   On IBM App Connect Operator 11.1.0 or earlier, the output also provides the URL of the Dashboard instance; for example:

   NAME       RESOLVEDVERSION   REPLICAS   CUSTOMIMAGES   STATUS    URL                                                          AGE
   db-prod    12.0.10.0-r3      3          false          Ready     https://db-prod-ui-mynamespace.apps.acecc-abcde.icp4i.com    9m12s

What to do next

1. If IAM with Keycloak is enabled for this instance on Red Hat OpenShift, use the Keycloak Admin Console to manage user access to the instance by setting up users with assigned roles. For more information, see Implementing identity and access management for App Connect Designer and App Connect Dashboard instances.
2. Share the UI URL value in the output with the users who need to access the Dashboard. If IAM is enabled, also supply the authentication credentials that users can use to log in to the Dashboard instance.

   Users can then access and use the Dashboard instance to deploy Designer and Toolkit integrations to integration servers or integration runtimes.

Updating an instance from the IBM Cloud Pak Platform UI

To update an App Connect Dashboard instance from the IBM Cloud Pak Platform UI, complete the following steps:

1. From a browser window, log in to the Platform UI.
   Tip: You can use the generated URL for a deployed IBM Cloud Pak for Integration Platform UI instance to access the Platform UI.
   • Applicable to IBM App Connect Operator 11.0.0 or later: The Platform UI Instances page opens as the home page. The welcome banner includes a theme switcher that you can use to choose a light theme, a dark theme, or a custom theme that matches your existing system UI.
   • Applicable to IBM App Connect Operator 10.1.1 or earlier: The Platform UI home page opens with cards and navigation menu options that provide access to the instances and other resources that you are authorized to create, manage, or use. For information about completing administration tasks (such as user management or platform customization) from this page, see Platform UI in the IBM Cloud Pak foundational services documentation.

     
     From the navigation menu , expand Administration and click Integration instances.

2. From the Instances (or Integration instances) page, locate the App Connect Dashboard (Integration dashboard) instance that you want to update.
3. Click the options icon to open the options menu, and then click Edit. The "Edit" page opens for that instance.
4. Either use the fields in the "UI form" view or switch to the YAML view to update the required settings. You can update existing values, add new entries, or delete entries. For information about the available parameters and their values, see Custom resource values.
5. Click Update to save your changes.

Updating an instance from the Red Hat OpenShift web console

To update an App Connect Dashboard instance by using the Red Hat OpenShift web console, complete the following steps:

1. From a browser window, log in to the Red Hat OpenShift Container Platform web console. Ensure that you are in the Administrator perspective .
2. From the navigation, click Operators > Installed Operators.
3. If required, select the namespace (project) in which you installed the IBM App Connect Operator.
4. From the Installed Operators page, click IBM App Connect.
5. From the Operator details page for the App Connect Operator, click the Dashboard tab.
6. Locate and click the name of the instance that you want to update.
7. Click the YAML tab.
8. Update the content of the YAML editor as required. You can update existing values, add new entries, or delete entries. For information about the available parameters and their values, see Custom resource values.
9. Click Save to save your changes.

Updating an instance from the Red Hat OpenShift or Kubernetes CLI

To update an App Connect Dashboard instance from the Red Hat OpenShift or Kubernetes CLI, complete the following steps.

1. From the command line, log in to your cluster by using the oc login command or the relevant command for your Kubernetes environment.
2. From the namespace where the Dashboard instance is deployed, run the oc edit or kubectl edit command to partially update the instance, where instanceName is the name (metadata.name value) of the instance.
   

   oc edit dashboard instanceName

   

   kubectl edit dashboard instanceName

   The Dashboard CR automatically opens in the default text editor for your operating system.

3. Update the contents of the file as required. You can update existing values, add new entries, or delete entries. For information about the available parameters and their values, see Custom resource values.
4. Save the YAML definition and close the text editor to apply the changes.

Tip:

If preferred, you can also use the oc patch or kubectl patch command to apply a patch with some bash shell features, or use oc apply or kubectl apply with the appropriate YAML settings.

For example, you can save the YAML settings to a file with a .yaml extension (for example, updatesettings.yaml), and then run oc patch or kubectl patch as follows to update the settings for an instance:

oc patch dashboard instanceName --type='merge' --patch "$(cat updatesettings.yaml)"

kubectl patch dashboard instanceName --type='merge' --patch "$(cat updatesettings.yaml)"

Deleting an instance from the IBM Cloud Pak Platform UI

To delete an App Connect Dashboard instance from the IBM Cloud Pak Platform UI, complete the following steps:

1. From a browser window, log in to the Platform UI.
   Tip: You can use the generated URL for a deployed IBM Cloud Pak for Integration Platform UI instance to access the Platform UI.
   • Applicable to IBM App Connect Operator 11.0.0 or later: The Platform UI Instances page opens as the home page. The welcome banner includes a theme switcher that you can use to choose a light theme, a dark theme, or a custom theme that matches your existing system UI.
   • Applicable to IBM App Connect Operator 10.1.1 or earlier: The Platform UI home page opens with cards and navigation menu options that provide access to the instances and other resources that you are authorized to create, manage, or use. For information about completing administration tasks (such as user management or platform customization) from this page, see Platform UI in the IBM Cloud Pak foundational services documentation.

     
     From the navigation menu , expand Administration and click Integration instances.

2. From the Instances (or Integration instances) page, locate the App Connect Dashboard (Integration dashboard) instance that you want to delete.
3. Click the options icon () to open the options menu, and then click Delete.
4. Confirm the deletion.

Deleting an instance from the Red Hat OpenShift web console

To delete an App Connect Dashboard instance by using the Red Hat OpenShift web console, complete the following steps:

1. From a browser window, log in to the Red Hat OpenShift Container Platform web console. Ensure that you are in the Administrator perspective .
2. From the navigation, click Operators > Installed Operators.
3. If required, select the namespace (project) in which you installed the IBM App Connect Operator.
4. From the Installed Operators page, click IBM App Connect.
5. From the Operator details page for the App Connect Operator, click the Dashboard tab.
6. Locate the instance that you want to delete.
7. Click the options icon () to open the options menu, and then click the Delete option.
8. Confirm the deletion.

Deleting an instance from the Red Hat OpenShift or Kubernetes CLI

To delete an App Connect Dashboard instance from the Red Hat OpenShift or Kubernetes CLI, complete the following steps.

1. From the command line, log in to your cluster by using the oc login command or the relevant command for your Kubernetes environment.
2. From the namespace where the Dashboard instance is deployed, run the following command to delete the instance, where instanceName is the value of the metadata.name parameter.
   

   oc delete dashboard instanceName

   

   kubectl delete dashboard instanceName