Conduktor Gateway

Routen. Schützen. Transformieren.

Ein Kafka-Proxy, der Platform-Teams die Kontrolle gibt, die sie sich schon immer gewünscht haben – ohne dass Entwickler eine einzige Zeile Code ändern müssen.

Conduktor Gateway

Erweitern Sie Ihre Infrastruktur.

Kafka ist leistungsstark, wurde aber nicht für Governance, Sicherheit oder Policy-Durchsetzung entwickelt. Ein Kafka Gateway schließt diese Lücke, damit Platform-Teams Kafka an ihre Anforderungen anpassen können – und nicht umgekehrt.

Für Platform-Teams Skalieren Sie Kafka teamübergreifend, ohne Infrastruktur oder Komplexität zu vervielfachen.

Für Sicherheit & Compliance Setzen Sie Verschlüsselung und Datenrichtlinien auf Infrastrukturebene durch – nicht im Anwendungscode.

Was ist Conduktor Gateway?

Conduktor Gateway ist ein Kafka-Proxy, der zwischen Ihren Client-Anwendungen und Ihren Kafka-Brokern sitzt. Er bietet Platform-Teams einen zentralen Kontrollpunkt für Sicherheit, Routing, Datenqualität und Multi-Tenancy – ohne Änderungen am Anwendungscode.

Natives Kafka-Protokoll

Gateway spricht das Kafka-Wire-Protokoll. Clients verbinden sich damit genau wie mit einem Broker. Aktualisieren Sie einfach bootstrap.servers und der Proxy übernimmt Authentifizierung, Verschlüsselung, Routing und Observability transparent.

Kontrolle auf Infrastrukturebene

Fügen Sie Funktionen hinzu, die nativ nicht verfügbar sind – wie feldbasierte Verschlüsselung, virtuelle Cluster, SQL-basierte Topic-Views und Chaos-Testing –, ohne jedes Anwendungsteam um eine individuelle Implementierung zu bitten.

Keine Anwendungsänderungen

Jede Produce- und Consume-Anfrage läuft durch den Proxy. Richtlinien werden auf Infrastrukturebene angewendet, sodass Platform-Teams Standards für alle Teams von einem Ort aus durchsetzen können.

Benötigen Sie nur netzwerkübergreifenden Zugriff auf Kafka? Probieren Sie Gateway Community Edition, unseren kostenlosen Kafka-Proxy. Er verbindet Clients mit Clustern in anderen VPCs, Clouds oder privaten Netzwerken – ohne Änderungen an Ihren Brokern oder Anmeldedaten.

Routing, Multi-Tenancy & Performance

Beseitigen Sie Netzwerkbarrieren, stellen Sie isolierte Kafka-Umgebungen ohne separate Cluster bereit und optimieren Sie den Durchsatz auf Proxy-Ebene.

Client-Zugangskontrolle & Routing

Verbinden ohne Code-Änderungen

Beseitigen Sie Netzwerkbarrieren für die Kafka-Konnektivität mit Kafka-Proxy-Routing, zentralisieren Sie die Authentifizierung über OIDC-Integration und setzen Sie feingranulare Zugriffskontrollen durch, die über native ACLs hinausgehen.

  • Netzwerkübergreifende Konnektivität – Client-Verbindungen werden über Gateway geroutet, ohne Client-Konfigurationsänderungen
  • Zentralisierte Authentifizierung – Integration mit externen OIDC-Systemen für einheitliche Zugangskontrolle in hybriden Deployments
  • Anwendungs-Audit-Trails – Verfolgung jeder Aktion über Kafka-Ressourcen hinweg zur Erfüllung von SOC2-, ISO 27001- und GDPR-Anforderungen

Mehr erfahren →

Clients routen
# Gateway Configuration
gateway:
  environment:
    GATEWAY_SECURITY_MODE: GATEWAY_MANAGED
    GATEWAY_SECURITY_PROTOCOL: SASL_PLAINTEXT

    # OIDC Provider Settings
    GATEWAY_OAUTH_JWKS_URL: "https://your-idp.com/.well-known/jwks.json"
    GATEWAY_OAUTH_EXPECTED_ISSUER: "https://your-idp.com"
    GATEWAY_OAUTH_EXPECTED_AUDIENCES: "kafka-gateway"
    GATEWAY_OAUTH_SUB_CLAIM_NAME: "sub"

# Map OIDC identities to Gateway Service Accounts
apiVersion: gateway/v2
kind: GatewayServiceAccount
metadata:
  name: my-application
spec:
  type: EXTERNAL
  externalNames:
    - "oauth-subject-id-from-token"  # Value from 'sub' claim in JWT
// Audit log event
{
  "id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "type": "APIKEYS_REQUEST",
  "time": "2024-10-15T14:30:45.123Z",
  "source": "//kafka/cluster/production",
  "authenticationPrincipal": "tenant-acme",
  "userName": "order-service",
  "connection": {
    "localAddress": "172.17.0.2:6969",
    "remoteAddress": "192.168.1.42:52341"
  },
  "eventData": {
    "apiKeys": "PRODUCE",
    "topics": [
      { "name": "orders", "partition": 0 },
      { "name": "orders", "partition": 1 }
    ]
  },
  "specVersion": "0.1.0"
}

Multi-Tenancy & Virtualisierung

Mandanten von Clustern entkoppeln

Stellen Sie mehreren Teams isolierte Kafka-Umgebungen bereit, ohne die Kosten separater Cluster, beseitigen Sie das Chaos bei Topic-Namen und reduzieren Sie die Anzahl der Partitionen erheblich.

  • Virtuelle Cluster – Bereitstellung mehrerer logischer Kafka-Cluster auf einem einzelnen physischen Cluster mit isolierten Namespaces und ACL-Grenzen
  • Topic-Konzentration – Zusammenführung von Topics mit geringem Volumen in gemeinsam genutzte physische Topics, wodurch die Partitionsanzahl um mehr als 90 % reduziert wird
  • Topic-Aliase – Zugriff auf Topics über Alias-Namen, um sie ohne Client-Änderungen umzubenennen oder interne Bezeichnungen zu verbergen

Mehr erfahren →

apiVersion: gateway/v2
kind: VirtualCluster
metadata:
  name: payments-team
spec:
  type: Standard
  aclEnabled: true
  superUsers:
    - payments-admin

apiVersion: gateway/v2
kind: VirtualCluster
metadata:
  name: orders-team
spec:
  type: Standard
  aclEnabled: true
  superUsers:
    - orders-admin
Topics konzentrieren
apiVersion: gateway/v2
kind: AliasTopic
metadata:
  name: customers
  vCluster: partner-team
spec:
  physicalName: internal-crm-customers

apiVersion: gateway/v2
kind: AliasTopic
metadata:
  name: orders
  vCluster: partner-team
spec:
  physicalName: internal-billing-orders

Performance & Effizienz

Last effizient bewältigen

Reduzieren Sie die Broker-Last durch wiederholte Lesevorgänge, verarbeiten Sie überdimensionierte Payloads ohne Auswirkungen auf die Cluster-Performance und stellen Sie gefilterte Topic-Views ohne die Komplexität von Stream-Processing bereit.

  • SQL-Topics – Erstellung schreibgeschützter virtueller Topics mit SQL-basierter Filterung und Projektionen auf Gateway-Ebene
  • Caching – Bereitstellung häufig abgerufener Nachrichten aus dem Gateway-Cache, um die Broker-Last bei hochfrequenten Lesezugriffen zu reduzieren
  • Auslagerung großer Nachrichten – Automatische Auslagerung von Nachrichten, die Größenschwellenwerte überschreiten, nach S3 oder Azure Blob Storage

Mehr erfahren →

apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: sql-filter-adults
spec:
  pluginClass: io.conduktor.gateway.interceptor.VirtualSqlTopicPlugin
  priority: 100
  config:
    virtualTopic: customers-adult
    statement: |
      SELECT firstName, lastName, email, country
      FROM customers
      WHERE age >= 18 AND country = 'US'
    schemaRegistryConfig:
      host: http://schema-registry:8081
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: cache-high-traffic-topics
spec:
  pluginClass: io.conduktor.gateway.interceptor.CacheInterceptorPlugin
  priority: 100
  config:
    topic: "events.*"
    cacheConfig:
      type: IN_MEMORY
      inMemConfig:
        cacheSize: 1000
        expireTimeMs: 60000
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: offload-large-messages-s3
spec:
  pluginClass: io.conduktor.gateway.interceptor.LargeMessageHandlingPlugin
  priority: 100
  config:
    topic: "media.*"
    minimumSizeInBytes: 1048576
    localDiskDirectory: /tmp/kafka-offload
    s3Config:
      bucketName: kafka-large-messages
      region: us-east-1

Schema Registry Governance

Ihre Schema Registry steuern

Fügen Sie Ihrer Schema Registry Authentifizierung, Zugangskontrolle und Observability mit einem Drop-in-Kafka-Proxy hinzu, der Governance bei jeder Operation durchsetzt.

  • JWT/OIDC-Authentifizierung – Validierung von Tokens Ihres bestehenden Identity-Providers, bevor eine Anfrage die Registry erreicht
  • Subjektbezogene Zugriffskontrollen – Durchsetzung von Lese- und Schreibberechtigungen mit exakter Übereinstimmung, Platzhalter- und Präfix-Matching
  • Vollständige Observability – Nachverfolgung jeder Operation mit OpenTelemetry, Messung mit Prometheus und Logging in strukturiertem JSON

Mehr erfahren →

# docker-compose.yml
schema-registry-proxy:
  ports:
    - "8080:8080"
    - "9464:9464"  # Prometheus metrics
  environment:
    # Schema Registry backend
    CONFLUENT_SCHEMA_REGISTRY_URL: http://schema-registry:8081

    # JWT authentication via OIDC provider
    AUTH_PROVIDER: jwt
    JWT_JWKS_URL: http://keycloak:8080/realms/kafka/protocol/openid-connect/certs
    JWT_SUBJECT_CLAIM_NAME: sub

    # Dynamic permissions via Kafka
    AUTH_USE_REACTIVE_CONFIG: true
    KAFKA_BOOTSTRAP_SERVERS: kafka:9092

    # OpenTelemetry tracing
    OTEL_EXPORTER_OTLP_ENDPOINT: http://otel-collector:4317
# Permission format (Kafka topic: _conduktor_srp_commands)
# Key: service account name
# Value: permission entries

# Admin — full access to all subjects
{ "permissions": [
    { "subject": "*",
      "permissionType": "WRITE" }
]}

# Payments team — prefix matching
{ "permissions": [
    { "subject": "payments-*",
      "permissionType": "WRITE" },
    { "subject": "orders-*",
      "permissionType": "READ" }
]}

# Analytics — read-only, all subjects
{ "permissions": [
    { "subject": "*",
      "permissionType": "READ" }
]}
# Get a JWT token (client credentials flow)
TOKEN=$(curl -s -X POST \
  http://keycloak:8080/realms/kafka/protocol/openid-connect/token \
  -d "grant_type=client_credentials" \
  -d "client_id=payments-service" \
  -d "client_secret=secret" | jq -r '.access_token')

# Register a schema through the proxy
curl -X POST http://localhost:8080/subjects/payments-value/versions \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"schema": "{\"type\":\"record\",\"name\":\"Payment\",\"fields\":[{\"name\":\"id\",\"type\":\"string\"}]}"}'

# Response: {"id": 1}
# Metrics: schema_registry_requests_total +1
# Trace: full span in Jaeger/OTLP

Resilienz & Disaster Recovery

Verhindern Sie, dass Entwickler-Fehlkonfigurationen Ihre Plattform destabilisieren, gewährleisten Sie Betriebskontinuität bei Ausfällen und validieren Sie die Fehlertoleranz durch kontrollierte Tests.

Anwendungsresilienz

Fehlkonfigurationen verhindern

Beseitigen Sie Noisy-Neighbor-Probleme und Konfigurationsdrift mit Kafka Gateway-Schutzmaßnahmen, die Namenskonventionen, Aufbewahrungslimits, Quotas und Replikationsregeln durchsetzen, bevor Probleme die Produktion erreichen.

  • Konfigurationsrichtlinien – Durchsetzung von Topic-Namenskonventionen, Aufbewahrungslimits, Replikationsregeln und Schema-Anforderungen bei Bereitstellung und Laufzeit
  • Traffic-Steuerung & Quotas – Durchsetzung von Bandbreiten- und Ratenbegrenzungen pro Mandant oder Cluster zur Vermeidung von Noisy-Neighbor-Problemen
  • Producer- & Consumer-Richtlinien – Sicherstellung von Acks-, Komprimierungs- und Idempotenzanforderungen für alle Producer sowie Steuerung des Fetch-Verhaltens von Consumern

Mehr erfahren →

apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: topic-governance-policy
spec:
  pluginClass: io.conduktor.gateway.interceptor.safeguard.CreateTopicPolicyPlugin
  priority: 100
  config:
    namingConvention:
      value: "^[a-z]+-[a-z]+-[a-z]+$"
      action: BLOCK
    numPartition:
      min: 3
      max: 12
      action: OVERRIDE
      overrideValue: 6
    replicationFactor:
      min: 3
      max: 3
      action: BLOCK
    retentionMs:
      min: 86400000
      max: 604800000
      action: OVERRIDE
      overrideValue: 259200000
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: producer-rate-limit
  scope:
    vCluster: payments-team
spec:
  pluginClass: io.conduktor.gateway.interceptor.safeguard.ProducerRateLimitingPolicyPlugin
  priority: 100
  config:
    maximumBytesPerSecond: 10485760
    action: BLOCK

apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: consumer-rate-limit
  scope:
    vCluster: payments-team
spec:
  pluginClass: io.conduktor.gateway.interceptor.safeguard.ConsumerRateLimitingPolicyPlugin
  priority: 100
  config:
    maximumBytesPerSecond: 52428800

Disaster Recovery & Failover

Sicher migrieren und wiederherstellen

Gewährleisten Sie Betriebskontinuität bei Cluster-Migrationen und Failover durch transparente Kafka-Proxy-Umleitung und validieren Sie die Fehlertoleranz durch kontrolliertes Chaos-Testing.

  • Cluster-Wechsel & Failover – Migration von Anwendungen zwischen Clustern oder Wechsel zu Failover-Infrastruktur ohne Änderungen an der Anwendungskonfiguration oder teamübergreifende Koordination
  • Chaos Engineering – Einschleusung von Latenz, Protokollfehlern und Nachrichtenkorruption über Gateway-Interceptors, um Resilienz zu testen, ohne die Produktion zu stören

Mehr erfahren →

# Gateway cluster configuration
config:
  main:
    bootstrap.servers: kafka-primary:9092
    security.protocol: SASL_SSL
    sasl.mechanism: PLAIN

  failover:
    bootstrap.servers: kafka-secondary:9092
    gateway.roles: failover

# Switch from main → failover
curl -X POST 'http://localhost:8888/gateway/v2/cluster-switching' \
  -H 'Content-Type: application/json' \
  -d '{"fromPhysicalCluster": "main", "toPhysicalCluster": "failover"}'
Traffic auf Failover umleiten
# Chaos testing interceptor
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: chaos-broken-broker
spec:
  pluginClass: io.conduktor.gateway.interceptor.chaos.SimulateBrokenBrokersPlugin
  priority: 100
  config:
    rateInPercent: 100
    errorMap:
      FETCH: UNKNOWN_SERVER_ERROR
      PRODUCE: CORRUPT_MESSAGE

Datenschutz

Steuern Sie Nachrichten-Metadaten, setzen Sie Datenqualität durch, schützen Sie sensible Felder und verifizieren Sie die Nachrichtenintegrität auf Proxy-Ebene.

Datenqualität

Schlechte Daten an der Quelle stoppen

Stoppen Sie fehlerhafte und nicht konforme Daten an der Quelle, anstatt Qualitätsprobleme erst zu entdecken, nachdem sie nachgelagerte Systeme beeinträchtigt haben.

  • Datenqualitätserkennung – Bewertung der durch Gateway fließenden Daten auf Einhaltung von Validierungsregeln und Qualitätsstandards
  • Datenqualitätsdurchsetzung – Blockierung, Umleitung oder Markierung von Nachrichten, die Qualitätsregeln verletzen, bevor sie Kafka erreichen

Mehr erfahren →

{
  "name": "myDataQualityProducerPlugin",
  "pluginClass": "io.conduktor.gateway.interceptor.safeguard.DataQualityProducerPlugin",
  "priority": 100,
  "config": {
    "statement": "SELECT x FROM orders WHERE amount_cents > 0 AND amount_cents < 1000000",
    "schemaRegistryConfig": {
       "host": "http://schema-registry:8081"
    },
    "action": "BLOCK_WHOLE_BATCH",
    "deadLetterTopic": "dead-letter-topic",
    "addErrorHeader": false
  }
}
Qualität durchsetzen

Datenvertraulichkeit

Konsistent über alle Apps verschlüsseln

Gewährleisten Sie konsistente Verschlüsselung über alle Anwendungen hinweg mit zentralisierter KMS-Durchsetzung auf Kafka Gateway-Ebene und ermöglichen Sie Analysen sensibler Daten durch feldbasierte Tokenisierung.

  • Zentralisierte Verschlüsselung – Durchsetzung der Verschlüsselung mit einer standardisierten KMS-Verbindung zur Vermeidung von Konfigurationsdrift und Ermöglichung von Crypto-Shredding für GDPR-Compliance
  • Multi-Cloud-KMS-Integration – Verbindung mit Vault, AWS KMS, Azure Key Vault, GCP KMS oder Fortanix für PCI-DSS-, HIPAA- und GDPR-Compliance
  • Feldbasierte Verschlüsselung – Verschlüsselung sensibler Felder mit schemabasierter Zielsetzung, während nicht sensible Daten lesbar bleiben
  • Tokenisierung – Ersetzen sensibler Werte durch Tokens unter Beibehaltung des Formats für Analysen

Mehr erfahren → · Kafka-Verschlüsselung →

apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: encrypt-pii-fields
spec:
  pluginClass: io.conduktor.gateway.interceptor.EncryptPlugin
  priority: 100
  config:
    topic: "customers.*"
    recordValue:
      fields:
        - fieldName: ssn
          keySecretId: "vault-kms://vault:8200/transit/keys/pii-key"
          algorithm: AES256_GCM
        - fieldName: creditCard.number
          keySecretId: "vault-kms://vault:8200/transit/keys/payment-key"
          algorithm: AES256_GCM
        - fieldName: email
          keySecretId: "in-memory-kms://email-key"
          algorithm: AES128_GCM
    kmsConfig:
      vault:
        uri: http://vault:8200
        type: TOKEN
        token: ${VAULT_TOKEN}
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: encrypt-with-kms
spec:
  pluginClass: io.conduktor.gateway.interceptor.EncryptPlugin
  priority: 100
  config:
    topic: ".*"
    recordValue:
      fields:
        - fieldName: ssn
          keySecretId: "vault-kms://..."
        - fieldName: payment.cardNumber
          keySecretId: "aws-kms://..."
        - fieldName: healthRecord
          keySecretId: "azure-kms://..."
    kmsConfig:
      vault:
        uri: http://vault:8200
        type: APP_ROLE
      aws:
        basicCredentials:
          accessKey: ${AWS_ACCESS_KEY}
      azure:
        tokenCredential:
          tenantId: ${AZURE_TENANT_ID}

Datenintegrität

Nachrichtenintegrität verifizieren

Verifizieren Sie die Authentizität von Nachrichten und erkennen Sie Manipulationen, um Audit- und Custody-Chain-Anforderungen zu erfüllen.

  • Kryptografische Signierung – Signierung von Nachrichten am Gateway zur Erkennung von Manipulationen und Verifizierung des Nachrichtenursprungs für Compliance-Anforderungen

Mehr erfahren →

apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: sign-messages
spec:
  pluginClass: io.conduktor.gateway.interceptor.integrity.ProduceIntegrityPolicyPlugin
  priority: 100
  config:
    topic: "transactions.*"
    secretKeyUri: "secret/data/signing-key#key"
    keyProviderConfig:
      vault:
        uri: https://vault:8200
        type: TOKEN
        token: ${VAULT_TOKEN}

Metadaten-Steuerung

Nachrichten-Metadaten steuern

Stellen Sie sicher, dass Nachrichten-Metadaten ohne Anwendungsänderungen den Unternehmensstandards entsprechen.

  • Header- & Nachrichtenverarbeitung – Einfügen, Ändern oder Entfernen von Nachrichten-Headern zur zentralen Transformation und Steuerung von Metadaten

Mehr erfahren →

apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: inject-tracking-headers
spec:
  pluginClass: io.conduktor.gateway.interceptor.DynamicHeaderInjectionPlugin
  priority: 100
  config:
    topic: "orders.*"
    headers:
      X-Source-Region: "${GATEWAY_REGION}"
      X-Gateway-Timestamp: "${timestamp}"
    overrideIfExists: true
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: remove-internal-headers
spec:
  pluginClass: io.conduktor.gateway.interceptor.safeguard.MessageHeaderRemovalPlugin
  priority: 100
  config:
    topic: ".*"
    headerKeyRegex: "^X-Internal-.*"

Externer Datenaustausch

Teilen Sie Kafka-Daten mit externen Partnern, ohne Ihre Infrastruktur übermäßig offenzulegen, passen Sie Datenformate für den Partner-Einsatz an und verfolgen Sie die Nutzung für die Kostenzuordnung.

Partnerzugang & Datenaustausch

Daten sicher teilen

Teilen Sie Kafka-Daten mit externen Partnern, ohne Ihre Infrastruktur übermäßig offenzulegen, passen Sie Datenformate ohne Dual-Write-Muster an und verfolgen Sie die Nutzung für die Abrechnung.

  • Virtuelle Partner-Cluster – Bereitstellung isolierter virtueller Cluster mit Topic-Mappings, Ratenbegrenzungen und Service-Accounts für Dritte
  • Partner-Topic-Views – Erstellung logischer Topic-Views mit Aliasing für partnerspezifischen Zugriff ohne Infrastrukturduplizierung
  • Datenformattransformationen – Transformation von Nachrichtenformaten mithilfe von SQL-Ausdrücken für partnerspezifische Schemas
  • Partner-Chargeback – Verfolgung von Verbrauchsmetriken nach Partner zur Nutzungszuordnung und Kostenzuteilung

Mehr erfahren →

Nutzung verfolgen
apiVersion: gateway/v2
kind: VirtualCluster
metadata:
  name: partner-a
spec:
  type: Partner
  aclEnabled: true
  superUsers:
    - partner-admin

apiVersion: gateway/v2
kind: GatewayServiceAccount
metadata:
  name: partner-admin
  vCluster: partner-a
spec:
  type: LOCAL

apiVersion: gateway/v2
kind: AliasTopic
metadata:
  name: orders
  vCluster: partner-a
spec:
  physicalName: internal-orders

Kafka-Proxy-Vergleich

Wie schneidet Conduktor Gateway ab?

Vergleichen Sie Conduktor Gateway mit dem Wettbewerb – Funktion für Funktion.

Confluent Gateway Kong Gravitee Aklivity Zilla Kroxylicious

Kafka-Proxies vergleichen →

Messbarer Nutzen

Echte Ergebnisse von Platform-Teams, die Gateway einsetzen.

Eine europäische Fluggesellschaft wechselte in 9 Monaten zu Confluent Cloud – ohne Ausfallzeit.

Ein Zahlungsdienstleister erhielt die MasterCard- und VISA-Zertifizierung mit Gateway-Verschlüsselung.

FlixBus skalierte Multi-Tenancy ohne Infrastrukturvervielfachung.

Verschlüsselung, Routing und Richtlinien werden auf Proxy-Ebene angewendet – nicht in Anwendungen.

Weitere Kundenberichte lesen

Bereit, Gateway auszuprobieren?

Erfahren Sie, wie Platform-Teams unseren Kafka-Proxy nutzen, um Verschlüsselung, Multi-Tenancy und Traffic-Steuerung hinzuzufügen – ohne den Anwendungscode zu ändern.

Sprechen Sie mit uns