Se connecter à un flux de données et utiliser les données

Pour vous connecter à un flux de données et utiliser des données, procédez comme suit :

Etape 1 : création de l'URL WebSocket

Lisez les valeurs suivantes à partir du YAML AsyncAPI généré :

wss://<server-host><channel-address>?begin=<percent-encoded-begin-value>

Ne codez pas en dur le chemin : OCI GoldenGate, un déploiement sur site et un proxy inverse peuvent exposer différents préfixes de routage. Copiez l'adresse de l'hôte et du canal à partir du YAML généré ou des liens canoniques renvoyés par l'API REST.

Etape 2 : sélectionnez la valeur de début

Indiquez la valeur BEGIN en fonction des instructions fournies dans le tableau suivant :

Valeur Utiliser Lignes directrices
now Commencer par une nouvelle activité Converti en horodatage en cours et résolu par rapport à la trace disponible. Les modifications avant le point résolu ne sont pas fournies.
earliest Remplissage initial à partir de la trace disponible Converti en horodatage zéro. La livraison commence au premier enregistrement encore disponible dans la trace configurée, pas nécessairement au début de l'historique source.
Horodatage ISO 8601 Commencer près d'une limite d'heure d'affaires Le service effectue une recherche basée sur l'horodatage. Utilisez un fuseau horaire explicite, par exemple 2026-07-13T04:00:00Z.
pos enregistré Récupération après une précédente exécution réussie Le service effectue une recherche basée sur les postes. Le résultat lorsque le profil n'est pas disponible dépend de la qualité du service.

Codage en pourcentage de la valeur de début

Un jeton pos peut contenir des caractères tels que +, / et = qui ont une signification spéciale dans une URL. Codez en pourcentage le jeton complet avant de l'ajouter à la chaîne de requête. Ne modifiez ni ne décodez le jeton dans la logique de l'application.

Etape 3 : authentification et authentification TLS

Sélectionnez la méthode d'authentification. Utilisez le tableau suivant pour déterminer la méthode la plus appropriée :

Mode Cas d'utilisation Réponse du client
L'authentification de base Commun avec un service directement exposé ou un proxy inverse Envoyez un en-tête Authorization: Basic .... Conservez les informations d'identification dans une banque de clés secrètes ou une injection d'environnement, et non dans l'URL ou le code source.
Authentification de la synthèse Lorsque requis par le proxy inverse Utilisez un client ou un modèle généré qui implémente la question de vérification de synthèse HTTP lors de l'établissement de liaison WebSocket.
Certificat client Authentification TLS mutuelle ou de service basé sur un certificat Chargez le certificat client et la clé privée dans le contexte TLS et validez le serveur par rapport à l'autorité de certification configurée.
Proxy inverse sécurisé La passerelle met fin au protocole TLS ou le transmet Suivez le mode d'authentification proxy. Un proxy sécurisé peut nécessiter à la fois des informations d'identification de base/numérique et un certificat client.

Etape 4 : générer un client à partir de AsyncAPI

Oracle fournit un modèle client WebSocket pour le générateur AsyncAPI. Il peut générer JavaScript, Python, Java, Go ou tous les clients pris en charge. Le générateur nécessite Node.js 18.12 ou version ultérieure et npm 8.19 ou version ultérieure.

npm install -g @asyncapi/generator

git clone https://github.com/oracle-samples/websocket-client-template.git
cd websocket-client-template

ag /path/to/sales-orders.yaml .
  -o output
  -p server=production
  -p language=python
  -p authorization=basic

cd output
python -m pip install -r requirements.txt
export ASYNCAPI_WS_CLIENT_USERNAME="$OGG_USER"
export ASYNCAPI_WS_CLIENT_PASSWORD="$OGG_PASSWORD"
python client.py

Le modèle prend également en charge les variables de certificat ASYNCAPI_WS_CLIENT_CERT, ASYNCAPI_WS_CLIENT_KEY et ASYNCAPI_WS_CA_CERT. Passez en revue le code généré et les versions de dépendance dans le cadre du processus de développement logiciel sécurisé habituel de votre organisation.

Etape 5 : Comprendre les messages WebSocket

La charge utile de message habituelle est un tableau JSON. Un cadre peut contenir un ou plusieurs enregistrements de schéma, de métadonnées, LMD ou LDD. Le client doit itérer le tableau et classer chaque objet indépendamment.

Pression arrière : le service transmet les enregistrements sans accusé de réception client par enregistrement. Gardez la boucle de réception légère. Placez les processus métier lents derrière une file d'attente interne limitée ou une couche intermédiaire durable, surveillez la profondeur de la file d'attente et arrêtez ou redimensionnez le consommateur avant que la mémoire ne soit épuisée.

Etape 6 : Boucle de traitement consommateur

  1. Recevez un message WebSocket complet.

  2. Analysez le tableau JSON. Lorsque CloudEvents est activé, déroulez le membre data.

  3. Classez les enregistrements de schéma, de flux de données, de métadonnées d'objet, LMD et LDD.

  4. Valider les enregistrements par rapport au dernier schéma mis en cache lorsque la validation est requise.

  5. Appliquez l'opération métier ou publiez-la sur un système durable en aval.

  6. Une fois l'opération terminée, enregistrez l'enregistrement pos à l'aide de la conception de point de reprise atomique ou idempotent sélectionnée.

  7. En cas de perte de connexion, reconnectez-vous au dernier élément durable pos et au dernier arrêt exponentiel.