When deploying IBM API Connect's CMS Portal v12.1.0 on OpenShift Container Platform (OCP), you might need to serve different portal sites with unique domain names and host configurations. This guide walks you through setting up multiple public-facing endpoints for the portal-www service, enabling you to create distinct portal experiences for different audiences or business units. 

Note: Multiple endpoint support has been available for Kubernetes environments since API Connect v10. Starting with API Connect v12, this capability has been extended to OpenShift Container Platform, where each endpoint configuration creates a separate route for the CMS Portal, allowing each endpoint to be accessed through its own dedicated route with independent TLS certificates and hostnames.

Why Multiple Endpoints?

Traditional CMS portal deployments often distinguish different sites using subpaths:

• https://www.example.com/banking/loans
• https://www.example.com/insurance/vehicle

With multiple endpoint configuration, you can instead use unique hostnames and domains:

• https://banking.example.com/loans
• https://insurance.example.com/vehicle

This approach provides cleaner URLs, better branding opportunities, and more flexible site organization.

OpenShift Routes

On OpenShift Container Platform, each endpoint configuration automatically creates a separate route. This means:

• Each hostname gets its own OCP route object
• Routes can be managed independently through the OpenShift console or CLI

Configuration Steps

To configure multiple endpoints, you'll need to edit your portal Custom Resource (CR) template. The configuration is straightforward and uses the portalUIEndpoint specification.

Basic Configuration Structure

Here's how to add multiple endpoints to your portal CR:
Edit your portal_cr template's portalUIEndpoint specification.

spec:
  portalUIEndpoint:
    annotations:
      cert-manager.io/issuer: ingress-issuer
    hosts:
      - name: ptl.host1.example.com
        secretName: portal-web-host1
      - name: ptl.host2.example.com
        secretName: portal-web-host2
      - name: ptl.host3.example.com
        secretName: portal-web-host3

Configuration Breakdown

Let's examine each component:

portalUIEndpoint: The main configuration section for portal UI endpoints.

annotations: Metadata for the ingress resource. In this example, we're using cert-manager to automatically provision TLS certificates with the ingress-issuer.

hosts: An array of endpoint definitions, where each entry includes:

• name: The fully qualified domain name (FQDN) for the portal endpoint
• secretName: The Kubernetes secret containing the TLS certificate for this specific endpoint
  
  

Real-World Example

Imagine you're managing API Connect for a financial services company with separate banking and insurance divisions. You could configure:

spec:
  portalUIEndpoint:
    annotations:
      cert-manager.io/issuer: ingress-issuer
    hosts:
      - name: banking.example.com
        secretName: banking-portal-tls
      - name: insurance.example.com
        secretName: insurance-portal-tls

This configuration creates two distinct portal experiences:

• Banking developers access their portal at https://banking.example.com/loans
• Insurance developers access theirs at https://insurance.example.com/vehicle

Each portal can be customized independently while being served by the same underlying CMS Portal service.

Key Benefits

1. Better Branding: Each business unit or product line can have its own branded domain
2. Improved Organization: Clearer separation between different portal sites
3. Flexible Security: Individual TLS certificates for each endpoint
4. Simplified URLs: No need for complex subpath routing

Prerequisites

Before implementing multiple endpoints, ensure you have:

• IBM API Connect v12.1.x deployed on OpenShift Container Platform
• The CMS Portal subsystem installed and running
• Access to your portal CR template
• TLS certificates (or cert-manager configured) for each endpoint
• DNS records pointing to your OpenShift cluster's router
• Appropriate permissions to create and manage routes in your OCP namespace

Additional Resources

For more information about CMS Portal endpoints,  refer to the https://www.ibm.com/docs/en/api-connect/software/12.1.0?topic=subsystem-defining-multiple-portal-endpoints-kubernetes-openshift-environments documentation.

Conclusion

Configuring multiple public endpoints for your CMS Portal on OpenShift Container Platform is a powerful way to create distinct, branded experiences for different developer audiences. By leveraging unique hostnames and domains with OCP's native routing capabilities, you can provide a more professional and organized portal infrastructure that scales with your organization's needs. Configuring multiple public endpoints for your CMS Portal on Kubernetes environment is already supported on IBM API Connect v10.0.8