Skip to main content

Configure a Custom Connector

Custom connectors require various configurations to function correctly within a Kubernetes environment. These configurations define how the connector interacts with external services, manages security-sensitive data, and optimizes runtime behavior.

Key Configuration Areas

Secrets Management

Securely store sensitive data using SOPS encryption

Connector Properties

Define external service details and feature toggles

Traits

Control deployment-specific parameters

Resources

Specify transformation files and custom logic

Prerequisites

Before configuring a custom connector, ensure you have:
  • Built a connector successfully
  • Access to the gc-applications-live repository
  • Understanding of your target deployment environment

Secrets Management with SOPS

To securely store sensitive data in Kubernetes secrets, use SOPS for encryption. ArgoCD automatically applies encrypted secrets placed in the secrets folder as part of the secrets-app application.

Managing Secrets

  1. Follow the guide in your installation for the specific runtime at:
    baas-devops-<installation>/gc-applications-live/blob/main/runtimes/<runtime>/secrets/README.md
    
  2. Configure a secret in the connector by adding the secret name in values.yaml:
connector:
  existingSecretName: servicebus-credentials

Connector Properties

Define connector configuration values in the Helm values.yaml file in the gc-applications-live repository.

Example Properties Configuration

connector:
  existingSecretName: uat-secret
  properties:
    connector.baseUrl: https://base-url/
    connector.id: vendor-specific-id
    connector.security-token-type: Oauth2
    enableValidation: false
    isEncryptionRequired: false

Common Properties

PropertyDescriptionExample
connector.baseUrlBase URL for external servicehttps://api.example.com
connector.idVendor-specific identifiervendor-123
connector.security-token-typeAuthentication typeOauth2, Bearer
enableValidationEnable request validationtrue, false
isEncryptionRequiredRequire encryptiontrue, false

Traits Configuration

Traits control deployment-specific parameters such as auto-scaling, logging, health monitoring, and telemetry.

Supported Traits

Grand Central supports the following Camel traits:
  • affinity - Pod scheduling preferences
  • container - Container resource limits
  • health - Health check configuration
  • knativeservice - Knative-specific settings
  • logging - Logging configuration
  • prometheus - Metrics collection
  • telemetry - Distributed tracing

Example Traits Configuration

connector:
  traits:
    knativeservice:
      minScale: 1
      enabled: true
    logging:
      color: false
      enabled: true
      level: INFO
    addons:
      telemetry:
        auto: true
        enabled: true
    health:
      enabled: true
      livenessProbeEnabled: true
      livenessInitialDelay: 30
      livenessTimeout: 30
      livenessPeriod: 5
      livenessSuccessThreshold: 1
      livenessFailureThreshold: 3
      readinessProbeEnabled: true
      readinessInitialDelay: 5
      readinessTimeout: 30
      readinessPeriod: 5
      readinessSuccessThreshold: 1
      readinessFailureThreshold: 3
      startupProbeEnabled: false
      startupInitialDelay: 5
      startupTimeout: 30
      startupPeriod: 5
      startupSuccessThreshold: 1
      startupFailureThreshold: 3
    prometheus:
      enabled: false

Health Check Configuration

Configure health, liveness, and readiness probes:
  • Liveness Probe: Detects if the connector is alive
  • Readiness Probe: Determines if the connector can accept traffic
  • Startup Probe: Checks if the application has started successfully

Resource Configurations

Specify additional resources such as transformation files, validation rules, and custom processing logic.

Supported Transformation Libraries

Grand Central supports the following transformation libraries for processing request and response payloads:
  • Jolt - JSON-to-JSON transformation
  • XSLT - XML transformation

Example: Jolt Transformation

Map a user’s first and last name into a single fullName field:
{
  "operation": "shift",
  "spec": {
    "user": {
      "firstName": "fullName.first",
      "lastName": "fullName.last"
    }
  }
}

Example: XSLT Transformation

Convert an XML <user> element into a <customer> element:
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/user">
        <customer>
            <name>
                <xsl:value-of select="firstName"/> <xsl:value-of select="lastName"/>
            </name>
        </customer>
    </xsl:template>
</xsl:transform>

Configuration Best Practices

  • Always use SOPS for sensitive data
  • Never commit secrets to version control
  • Rotate credentials regularly
  • Set appropriate resource limits
  • Configure auto-scaling based on load
  • Monitor resource utilization
  • Enable all probe types
  • Set realistic timeout values
  • Test probe configurations thoroughly
  • Use appropriate log levels
  • Enable structured logging
  • Configure log retention policies

Next Steps

Once you have completed your connectors configuration, you are ready to:
  • Test and validate your connector
  • Deploy the connector to your environment
  • Verify logs to ensure it’s running correctly