← Back to list

TIBCO Platform and capability deployments with Istio Ingress Gateway

1. Summary

Kulbhushan Bhalerao · 2026-01-15 09:52 · 0 claps · 3.5 min read
#tibco-platform #istio-ingress-gateway #kubernetes #tibco-businessworks #tibco-flogo
Open on Medium ↗
Wiki topics: EVAL · Evaluation & Benchmarks ☁️ · DevOps & Cloud 🥊 · Combat Sports

TIBCO Platform and capability deployments with Istio Ingress Gateway

1. Summary

This document outlines testing conducted for using the Istio Ingress Gateway with TIBCO Dataplane. This document is created as the Istio Ingress Gateway is not supported as of TIBCO Platform Control Plane version 1.13 version.

This guide is intended for users who wish to deploy TIBCO Platform and its capabilities (e.g., BW6/BWCE and Flogo), along with their applications, using the Istio Ingress Gateway. It provides the necessary configuration steps.

Important Note: Users must manually create the required Istio Gateway and VirtualService objects to enable this functionality. When TIBCO officially supports an ingress solution, the TIBCO Platform automatically handles the creation of the necessary ingress objects; however, this automatic object creation does not occur with the Istio Ingress Gateway setup described here.

2. Prerequisites & Naming Conventions

Infrastructure used to create this document

  • TIBCO Platform 1.13
  • Kubernetes Cluster: v1.33+ (I have used GKE for testing, however this should work for AKS, EKS, minikube also)
  • Istio: v1.28.0+ (Ingress Gateway in istio-system) Istio / Ingress Gateways
  • Cert-Manager: (Optional) for TLS/HTTPS needed for secret holding tls crt and key
  • Domain: bwcegke.example.com which you can register in the dns zone. Note that, same domain will be used by all the BWCE Applications. If you have Flogo, it is better to have another flogogke.example.com domain pointing to the LB of the istio ingress gateway. And there also you can use the same pattern described in this document.

Component Identifiers

Use these values as references. Replace specific IDs with your actual environment data.

3. Architecture Overview

We use a Shared Gateway pattern. A single Istio Gateway listener handles traffic for the domain bwcegke.example.com. VirtualServices are then used to “split” traffic based on the URL path. It is recommended to have a separate Gateway listener per capability which then should be shared by application types (BWCE or Flogo) using Virtual Services per application.

  • Shared Gateway: Terminates TLS (HTTPS) for bwcegke.example.com.
  • Provisioner VirtualService: Routes management traffic (/tibco/bw/…) to the Provisioner.
  • Application VirtualService: Routes app traffic (/tibco/apps/…) to specific BWCE services.

4. Step 1: Infrastructure Setup (Deploy Once)

This section sets up the shared entry point and the management console routing. You generally apply this once per cluster/environment.

File: 01-infrastructure-setup.yaml

YAML

# ---------------------------------------------------------
# 1. SHARED GATEWAY (The Entry Point)
# Do NOT create other Gateways for this host/port or for BWCE Apps
# ---------------------------------------------------------
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: bwprovisioner-gateway
  namespace: dp-gke
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "bwcegke.example.com"
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: bwcegke-tls # Must exist in istio-system
    hosts:
    - "bwcegke.example.com"

---
# ---------------------------------------------------------
# 2. PROVISIONER VIRTUAL SERVICE (Management Console)
# Routes traffic to the TIBCO Provisioner Service
# ---------------------------------------------------------
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: bwprovisioner-vs
  namespace: dp-gke
spec:
  hosts:
  - "bwcegke.example.com"
  gateways:
  - bwprovisioner-gateway # ATTACH TO SHARED GATEWAY
  http:
  - match:
    - uri:
        prefix: "/tibco/bw/d4o61daal6jc73d7ubmg/"
    rewrite:
      uriRegexRewrite:
        match: "/tibco/bw/d4o61daal6jc73d7ubmg(/|$)(.*)"
        rewrite: "/\\2"
    headers:
      request:
        set:
          # Headers required for the Provisioner to know its public URL
          X-Forwarded-Prefix: "/tibco/bw/d4o61daal6jc73d7ubmg"
          X-Forwarded-Proto: "https"
          X-Forwarded-Host: "bwcegke.example.com"
          X-Forwarded-Port: "443"
          X-Forwarded-For: "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
    route:
    - destination:
        host: bwprovisioner
        port:
          number: 7816

Apply it:

kubectl apply -f 01-infrastructure-setup.yaml

5. Step 2: Application Deployment (Per App)

For every new application you deploy, create a dedicated VirtualService using this template.

File: 02-app-template.yaml

Replace:

  1. {APP_NAME_VS} -> e.g., order-processing-vs
  2. {APP_ID} -> e.g., abc123def456
  3. {SERVICE_NAME} -> e.g., com-tibco-tp-order-processing

YAML

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: {APP_NAME_VS}
  namespace: dp-gke
spec:
  hosts:
  - "bwcegke.example.com"
  gateways:
  - bwprovisioner-gateway # ALWAYS use the shared gateway
  http:
  - match:
    - uri:
        prefix: "/tibco/apps/{APP_ID}/Resource"
    rewrite:
      uriRegexRewrite:
        match: "/tibco/apps/{APP_ID}/Resource(/|$)(.*)"
        rewrite: "/\\2"
    headers:
      request:
        set:
          # Critical for Swagger UI and internal links
          X-Forwarded-Prefix: "/tibco/apps/{APP_ID}/Resource"
          X-Forwarded-Proto: "https"
          X-Forwarded-Host: "bwcegke.example.com"
          X-Forwarded-Port: "443"
          X-Forwarded-For: "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
    route:
    - destination:
        host: {SERVICE_NAME}
        port:
          number: 8080

Appendix I: Verification & Testing

1. Verify Provisioner (Management)

Check if the management console is reachable via the rewritten path.

curl -I -k https://bwcegke.example.com/tibco/bw/d4o61daal6jc73d7ubmg/health

Expected: HTTP 200 OK

2. Verify Application (Workload)

Check if your specific application is reachable and if the Swagger UI loads.

curl -I -k https://bwcegke.example.com/tibco/apps/{APP_ID}/Resource/swagger/swagger.json

Expected: HTTP 200 OK

Appendix II: Troubleshooting Common Issues

Issue 1: 404 Not Found (External)

  • Cause: You likely created a duplicate gateway (e.g., my-app-gateway) listening on the same host (bwcegke.example.com).
  • Fix:
  • kubectl get gateway -n dp-gke
  • Delete any gateway other than bwprovisioner-gateway.
  • Update your App’s VirtualService to reference bwprovisioner-gateway.

Issue 2: Swagger UI Links are Broken

  • Cause: The application doesn’t know it is behind a reverse proxy (Istio) and is generating links using http://internal-ip:8080.
  • Fix: Ensure the headers section (X-Forwarded-Prefix, X-Forwarded-Host, X-Forwarded-Proto) is present in your VirtualService configuration as shown in Step 4.

메타데이터
post_id
2dd17fbabbb3
slug
tibco-platform-and-capability-deployments-with-istio-ingress-gateway-2dd17fbabbb3
url
https://medium.com/@kulbhushan.bhalerao/tibco-platform-and-capability-deployments-with-istio-ingress-gateway-2dd17fbabbb3
canonical_url
https://medium.com/@kulbhushan.bhalerao/tibco-platform-and-capability-deployments-with-istio-ingress-gateway-2dd17fbabbb3
author_url
https://medium.com/@kulbhushan.bhalerao
status
ok
fetched_at
2026-08-08 03:53:51