Vom Server gesendete Ereignisse streamen

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Apigee unterstützt das kontinuierliche Streaming von Antworten von SSE-Endpunkten (Server-Sent Events) an Clients in Echtzeit. Die Apigee-SSE-Funktion ist nützlich für die Verarbeitung von LLM-APIs (Large Language Model), die am effektivsten funktionieren, wenn ihre Antworten an den Client gestreamt werden. Durch SSE-Streaming wird die Latenz reduziert und Clients können Antwortdaten empfangen, sobald sie von einem LLM generiert werden. Diese Funktion unterstützt die Verwendung von KI-Agents, die in Echtzeitumgebungen arbeiten, z. B. Kundenservice-Bots oder Workflow-Orchestratoren.

Wenn Sie SSE mit Apigee verwenden möchten, verweisen Sie einfach einen API-Proxy auf einen SSE-fähigen Zielendpunkt. Für eine detailliertere Steuerung der SSE-Antwort bietet Apigee einen speziellen Zielendpunkt-Flow namens EventFlow. Im Kontext eines EventFlow können Sie eine begrenzte Anzahl von Richtlinien hinzufügen, um Vorgänge für die SSE-Antwort auszuführen, z. B. Filtern, Ändern oder Behandeln von Fehlern. Weitere Informationen zu Proxy-Abläufen finden Sie unter API-Proxys mit Abläufen steuern.

API-Proxy für SSE erstellen

Die Apigee-Benutzeroberfläche bietet eine Vorlage zum Erstellen eines neuen Proxys, der eine EventFlow enthält.

So erstellen Sie einen API-Proxy mit der Vorlage EventFlow über die Apigee-UI:

  1. Öffnen Sie die Apigee-UI in der Cloud Console in einem Browser.
  2. Klicken Sie im linken Navigationsbereich auf Proxy-Entwicklung > API-Proxys.
  3. Klicken Sie im Bereich API-Proxys auf + Erstellen.
  4. Wählen Sie im Bereich Proxy erstellen unter Proxy-Vorlage die Option Proxy mit Server-Sent Events (SSE) aus.
  5. Geben Sie unter Proxydetails Folgendes ein:
    • Proxyname: Geben Sie einen Namen für den Proxy ein, z. B. myproxy.
    • Basispfad: Wird automatisch auf den Wert festgelegt, den Sie für Proxy name eingeben. Der Basispfad ist Teil der URL, die zum Senden von Anfragen an Ihre API verwendet wird. Apigee verwendet die URL, um eingehende Anfragen zuzuordnen und an den richtigen API-Proxy weiterzuleiten.
    • Beschreibung (Optional): Geben Sie eine Beschreibung für den neuen API-Proxy ein, z. B. „Apigee mit einem einfachen Proxy testen“.
    • Ziel (vorhandene API): Geben Sie die SSE-Ziel-URL für den API-Proxy ein. Beispiel: https://mocktarget.apigee.net/sse-events/5
    • Klicken Sie auf Weiter.
  6. Bereitstellen (optional):
    • Bereitstellungsumgebungen: Optional. Wählen Sie durch die Kästchen eine oder mehrere Umgebungen aus, in denen Sie Ihren Proxy bereitstellen möchten. Wenn Sie den Proxy zu diesem Zeitpunkt nicht bereitstellen möchten, lassen Sie das Feld Bereitstellungsumgebungen leer. Sie können den Proxy später jederzeit bereitstellen.
    • Dienstkonto: (optional) Ein Dienstkonto für den Proxy. Das Dienstkonto stellt die Identität des bereitgestellten Proxys dar und bestimmt, welche Berechtigungen er hat. Dies ist eine erweiterte Funktion, die Sie für diese Anleitung ignorieren können.

    API-Proxys, die mit einer EventFlow-Konfiguration bereitgestellt werden, werden als erweiterbar abgerechnet.

  7. Klicken Sie auf Erstellen.
Siehe auch Einfachen API-Proxy erstellen.

EventFlow konfigurieren

Für eine detailliertere Steuerung der SSE-Antwort bietet Apigee einen speziellen Zielendpunkt-Flow namens EventFlow. Im Kontext eines EventFlow können Sie eine begrenzte Anzahl von Richtlinien hinzufügen, die unten aufgeführt sind, um die SSE-Antwort zu ändern, bevor sie an den Client zurückgestreamt wird. Weitere Informationen zu Proxy-Abläufen finden Sie unter API-Proxys mit Abläufen steuern.

Ein EventFlow muss in der TargetEndpoint-Definition platziert werden, wie im folgenden Codebeispiel gezeigt:

<TargetEndpoint name="default">
  <Description/>
  <FaultRules/>
  <PreFlow name="PreFlow">
    <Request/>
    <Response/>
  </PreFlow>
  <PostFlow name="PostFlow">
    <Request/>
    <Response/>
  </PostFlow>
  <Flows/>
  <EventFlow name="EventFlow" content-type="text/event-stream">
    <Response/>
  </EventFlow>
  <HTTPTargetConnection>
    <Properties/>
    <URL>https://httpbun.org/sse</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

EventFlow hat zwei Attribute:

  • name: Ein Name zur Identifizierung des Ablaufs.
  • content-type: Der Wert dieses Attributs muss text/event-stream sein.

Weitere Informationen finden Sie unter Ablaufkonfigurationsreferenz.

Sie können dem Response-Element der EventFlow bis zu vier Richtlinien hinzufügen. Wie bei allen Abläufen werden Richtlinien in der Reihenfolge ausgeführt, in der sie hinzugefügt werden. Sie können bedingte Schritte hinzufügen, um die Ausführung zu steuern. Die Richtlinientypen, die Sie einem EventFlow hinzufügen können, sind auf die folgenden beschränkt. In einem EventFlow sind keine anderen Richtlinientypen zulässig:

Weitere Informationen finden Sie unter Richtlinien in der Benutzeroberfläche anhängen und konfigurieren und Richtlinien in XML-Dateien anhängen und konfigurieren.

Das folgende Beispiel zeigt ein EventFlow mit einem bedingten RaiseFault-Richtlinienschritt:

<TargetEndpoint name="default">
  <EventFlow content-type="text/event-stream">
    <Response>
      <Step>
        <Name>Raise-Fault-Cred-Invalid</Name>
        <Condition>fault.name equals "invalid_access_token"</Condition>
      </Step>
    </Response>
  </EventFlow>
  <HTTPTargetConnection>
</TargetEndpoint></pre>

Weitere EventFlow-Codebeispiele finden Sie im Abschnitt EventFlow-Anwendungsfälle und -Beispiele.

Ablaufvariablen

Durch EventFlow werden zwei Ablaufvariablen für Antworten ausgefüllt. Diese Variablen können nur im Rahmen des aktuellen Ereignisses verwendet werden, das in EventFlow verarbeitet wird. Der Zugriff auf diese Variablen oder das Festlegen dieser Variablen außerhalb des EventFlow-Bereichs hat keine Auswirkungen. Sie sind nur im Kontext der EventFlow sinnvoll.

  • response.event.current.content: Ein String mit der vollständigen Antwort des aktuellen Ereignisses. Apigee parst den String nicht. Sie enthält die gesamte Antwort unverändert, einschließlich aller Datenfelder.
  • response.event.current.count: Zählt die Anzahl der gesendeten Antwort-Ereignisse inkrementell. Dieser Wert wird für jedes empfangene Ereignis aktualisiert. Die Anzahl ist 1 für das erste Ereignis und wird für nachfolgende Ereignisse erhöht.

Weitere Informationen finden Sie unter Referenz zu Ablaufvariablen.

EventFlow-Anwendungsfälle und ‑Beispiele

Die folgenden Beispiele zeigen, wie Sie gängige Anwendungsfälle für SSE-Proxys implementieren:

SSE-Antwort ändern

In diesem Beispiel wird gezeigt, wie Daten aus einer SSE-EventFlow-Antwort entfernt werden, bevor sie an den Client zurückgegeben werden. Der Inhalt der SSE-Antwort wird in einer Ablaufvariablen namens response.event.current.content gespeichert. In diesem Fall verwenden wir eine JavaScript-Richtlinie, um den Wert der Ablaufvariablen abzurufen, zu parsen und zu ändern. Siehe auch Ablaufvariablen.

  1. Erstellen Sie einen neuen Proxy mit der SSE-Proxyvorlage. Weitere Informationen finden Sie unter API-Proxy mit vom Server gesendeten Ereignissen (SSE) erstellen.
  2. Öffnen Sie den Proxy im Apigee-Proxy-Editor und klicken Sie auf den Tab Entwickeln.
  3. Erstellen Sie eine neue JavaScript-Richtlinie mit der folgenden Definition. In diesem Beispiel ist der JavaScript-Code direkt in der Richtlinie enthalten. Eine weitere Möglichkeit zum Konfigurieren der Richtlinie besteht darin, den JavaScript-Code in eine Ressourcendatei einzufügen. 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Javascript continueOnError="false" enabled="true" timeLimit="200" name="js-update-resp">
  <DisplayName>js-update-resp</DisplayName>
  <Properties/>
  <Source>
    var event = JSON.parse(context.getVariable("response.event.current.content"));
    event.modelVersion = null;
    context.setVariable("response.event.current.content",JSON.stringify(event));
  </Source>
</Javascript>
  4. Fügen Sie die JavaScript-Richtlinie dem EventFlow des Proxys hinzu. Die EventFlow ist an die Standard-TargetEndpoint angehängt. In diesem Beispiel wird die Gemini API in Vertex AI verwendet, um Inhalte zu generieren. 
    <TargetEndpoint name="default">
  <EventFlow content-type="text/event-stream">
    <Response>
      <Step>
        <Name>js-update-resp</Name>
      </Step>
    </Response>
  </EventFlow>
  <HTTPTargetConnection>
    <URL>https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:streamGenerateContent?key=GEMINI_API_KEY&alt=sse</URL>
  </HTTPTargetConnection>
</TargetEndpoint>
  5. Speichern Sie den Proxy und stellen Sie ihn bereit.
  6. Bereitgestellten Proxy aufrufen: 
    curl -X POST -H 'Content-Type: application/json'  \
  "https://YOUR_APIGEE_ENVIRONMENT_GROUP_HOSTNAME/YOUR_API_PATH" \
  -d '{ "contents":[{"parts":[{"text": "Write a story about a magic pen."}]}]}'

    Beispielantwort anzeigen

    Dies ist eine Beispielantwort ohne Filterung. Beachten Sie, dass die Antwort ein modelVersion": "gemini-2.5-flash"-Attribut enthält.

    data: {
    "candidates": [
      {
        "content": {
          "parts": [
            {
              "text": "ara found the pen tucked away in a dusty antique shop, nestled amongst chipped tea"
            }
          ],
          "role": "model"
        }
      }
    ],
    "usageMetadata": {
      "promptTokenCount": 8,
      "totalTokenCount": 8
    },
    "modelVersion": "gemini-2.5-flash"
  }

    Dies ist eine weitere Beispielantwort, in der die JavaScript-Richtlinie angewendet wurde. Das Attribut „modelVersion“ wurde entfernt.

    data: {
    "candidates": [
      {
        "content": {
          "parts": [
            {
              "text": " the fantastical creatures of her imagination.  The quiet beauty of a simple life was a magic all its own.\n"
            }
          ],
          "role": "model"
        },
        "finishReason": "STOP"
      }
    ],
    "usageMetadata": {
      "promptTokenCount": 8,
      "candidatesTokenCount": 601,
      "totalTokenCount": 609,
      "promptTokensDetails": [
        {
          "modality": "TEXT",
          "tokenCount": 8
        }
      ],
      "candidatesTokensDetails": [
        {
          "modality": "TEXT",
          "tokenCount": 601
        }
      ]
    }
  }

SSE-Antwort filtern

In diesem Beispiel wird gezeigt, wie Sie Daten aus einer SSE-Antwort filtern, bevor Sie sie an den Client zurückgeben. In diesem Fall filtern wir Ereignisdaten aus der Antwort mithilfe einer JavaScript-Richtlinie. Die Richtlinie parst die Ereignisantwort in JSON, ändert das JSON, um die Ereignisdaten zu entfernen, und sendet die geänderten Antwortdaten dann zurück an den Client.

Wie im vorherigen Beispiel wird in diesem Beispiel der Wert der Ablaufvariablen response.event.current.content abgerufen und in JSON geparst. Anschließend wird die Logik angewendet, um die gewünschte Filterung zu implementieren.

  1. Erstellen Sie einen neuen Proxy mit der SSE-Proxyvorlage. Weitere Informationen finden Sie unter API-Proxy mit vom Server gesendeten Ereignissen (SSE) erstellen.
  2. Öffnen Sie den Proxy im Apigee-Proxy-Editor und klicken Sie auf den Tab Entwickeln.
  3. Erstellen Sie eine neue JavaScript-Richtlinie mit der folgenden Definition. In diesem Beispiel ist der JavaScript-Code direkt in der Richtlinie enthalten. Eine weitere Möglichkeit zum Konfigurieren der Richtlinie besteht darin, den JavaScript-Code in eine Ressourcendatei einzufügen. 
    <Javascript continueOnError="false" enabled="true" timeLimit="200" name="js-filter-resp">
  <DisplayName>js-filter-resp</DisplayName>
  <Properties/>
  <Source>
    var event = JSON.parse(context.getVariable("response.event.current.content"));
    if("error" in event){
      // Do not send event to customer
      context.setVariable("response.event.current.content", "");
    }
  </Source>
</Javascript>
  4. Fügen Sie die JavaScript-Richtlinie dem EventFlow des Proxys hinzu. Die EventFlow ist an die Standard-TargetEndpoint angehängt. In diesem Beispiel wird die Gemini API in Vertex AI verwendet, um Inhalte zu generieren. 
    <TargetEndpoint name="default">
  <EventFlow content-type="text/event-stream">
    <Response>
      <Step>
        <Name>js-filter-resp</Name>
      </Step>
    </Response>
  </EventFlow>
  <HTTPTargetConnection>
	  <URL>https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:streamGenerateContent?key=GEMINI_API_KEY&alt=sse	</URL>
  </HTTPTargetConnection>
</TargetEndpoint>
  5. Speichern Sie den Proxy und stellen Sie ihn bereit.
  6. Bereitgestellten Proxy aufrufen: 
    curl -X POST -H 'Content-Type: application/json'  \
    "https://YOUR_APIGEE_ENVIRONMENT_GROUP_HOSTNAME/YOUR_API_PATH" \
    -d '{ "contents":[{"parts":[{"text": "Write a story about a magic pen."}]}]}'

    Beispielantwort anzeigen

    Hier sehen Sie ein Beispiel dafür, wie die Antwort ohne Filterung aussehen könnte. Beachten Sie, dass sie Fehlerdaten enthält:

    data: {
    "candidates": [
      {
        "content": {
          "parts": [
            {
              "text": "El"
            }
          ],
          "role": "model"
        }
      }
    ],
    "usageMetadata": {
      "promptTokenCount": 8,
      "totalTokenCount": 8
    },
    "modelVersion": "gemini-2.5-flash"
  }
    data: {
    "error": "Service temporarily unavailable. We are experiencing high traffic.",
    "modelVersion": "gemini-2.5-flash"
    }

    Hier sehen Sie ein weiteres Beispiel für eine Antwort nach der Filterung, wobei die Fehlermeldung entfernt wurde.

    data: {
  "candidates": [
    {
      "content": {
        "parts": [
          {
            "text": "El"
          }
        ],
        "role": "model"
      }
    }
  ],
  "usageMetadata": {
    "promptTokenCount": 8,
    "totalTokenCount": 8
  },
  "modelVersion": "gemini-2.5-flash"
}
data: {
  "candidates": [
    {
      "content": {
        "parts": [
          {
            "text": "ara found the pen tucked away in a dusty antique shop, nestled amongst chipped tea"
          }
        ],
        "role": "model"
      }
    }
  ],
  "usageMetadata": {
    "promptTokenCount": 8,
    "totalTokenCount": 8
  },
  "modelVersion": "gemini-2.5-flash"
}

SSE-Ereignis an ein externes System senden

In diesem Beispiel hängen wir die Apigee PublishMessage-Richtlinie an EventFlow an, um ein SSE-Ereignis an ein Pub/Sub-Thema zu senden.

  1. Erstellen Sie einen neuen Proxy mit der SSE-Proxyvorlage. Weitere Informationen finden Sie unter API-Proxy mit vom Server gesendeten Ereignissen (SSE) erstellen.
  2. Öffnen Sie den Proxy im Apigee-Proxy-Editor und klicken Sie auf den Tab Entwickeln.
  3. Erstellen Sie eine neue PublishMessage-Richtlinie mit der folgenden Definition: 
    <PublishMessage continueOnError="false" enabled="true" name="PM-record-event">
  <DisplayName>PM-record-event</DisplayName>
  <Source>{response.event.current.content}</Source>
  <CloudPubSub>
    <Topic>projects/<customer_project>/topics/<topic_name></Topic>
  </CloudPubSub>
</PublishMessage>
  4. Fügen Sie die PublishMessage-Richtlinie als Schritt in den EventFlow des API-Proxy ein. 
    <TargetEndpoint name="default">
  <EventFlow content-type="text/event-stream">
    <Response>
      <Step>
        <Name>PM-record-event</Name>
      </Step>
    </Response>
  </EventFlow>
  <HTTPTargetConnection>
</TargetEndpoint>
  5. Stellen Sie den API-Proxy bereit und testen Sie ihn.
  6. Nachdem Sie dem Pub/Sub-Thema generierte Inhalte hinzugefügt haben, können Sie beispielsweise eine Cloud Run-Funktion erstellen, um Nachrichten aus dem Thema zu verarbeiten.

Apigee Model Armor-Richtlinie in einem EventFlow verwenden

Mit der SanitizeModelResponse-Richtlinie können Sie eingehende Server-Sent Events in einem EventFlow bereinigen. Diese Richtlinie schützt Ihre KI-Anwendungen, indem Antworten von Large Language Models (LLMs) bereinigt werden. Informationen zu Model Armor finden Sie in der Übersicht zu Model Armor. Informationen zu den Apigee Model Armor-Richtlinien finden Sie unter Erste Schritte mit Apigee Model Armor-Richtlinien.

  1. Erstellen Sie einen neuen Proxy mit der SSE-Proxyvorlage. Weitere Informationen finden Sie unter API-Proxy mit vom Server gesendeten Ereignissen (SSE) erstellen.
  2. Öffnen Sie den Proxy im Apigee-Proxy-Editor und klicken Sie auf den Tab Entwickeln.
  3. Erstellen Sie eine neue SanitizeModelResponse-Richtlinie mit der folgenden Definition: 
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <SanitizeModelResponse async="false" continueOnError="false" enabled="true" name="SMR-modelresponse">
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <DisplayName>SMR-modelresponse</DisplayName>
    <ModelArmor>
      <TemplateName>projects/{project}/locations/{location}/templates/{template-name}</TemplateName>
    </ModelArmor>
    <LLMResponseSource>{response_partial}</LLMResponseSource>
    <!-- Use the below settings if you want to call a Model Armor policy on every event -->
    <LLMResponseSource>{response.event.current.content}</LLMResponseSource>
  </SanitizeModelResponse>
  4. Optional: Fügen Sie eine JavaScript-Richtlinie hinzu, um Ereignisse zu gruppieren, bevor sie an die Apigee Model Armor-Richtlinie gesendet werden. 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Javascript continueOnError="false" enabled="true" timeLimit="200" name="JS-combine-resp">
  <DisplayName>JS-combine-events</DisplayName>
  <Properties/>
  <Source>
    var eventText = JSON.parse(context.getVariable("response.event.current.content").substring(5)).candidates[0].content.parts[0].text;
    var finishReason = JSON.parse(context.getVariable("response.event.current.content").substring(5)).candidates[0].finishReason;
    var idx = context.getVariable("response.event.current.count");
    if(idx%5==0 || finishReason=="STOP") {
      context.setVariable("response_partial", context.getVariable("tmp_buffer_pre"));
      context.setVariable("buff_ready", true);
      context.setVariable("tmp_buffer_pre", "");
    } else {
      context.setVariable("buff_ready", false);
      context.setVariable("response_partial", "");
      var previousBufferVal = context.getVariable("tmp_buffer_pre");
      if(previousBufferVal) {
        context.setVariable("tmp_buffer_pre", previousBufferVal+eventText);
      } else {
        context.setVariable("tmp_buffer_pre", eventText);
      }
    }
  </Source>
</Javascript>
  5. Fügen Sie die JavaScript- und ModelArmor-Richtlinien einem Schritt im EventFlow des Proxys hinzu: 
    <EventFlow name="EventFlow" content-type="text/event-stream">
  <Request/>
  <Response>
    <Step>
      <Name>JS-combine-resp</Name>
    </Step>
    <Step>
      <!-- Remove below Condition if you want to call model armor policy on every event -->
      <Condition> buff_ready = true </Condition>
      <Name>SMR-modelresponse</Name>
    </Step>
  </Response>
</EventFlow>
  6. Stellen Sie den API-Proxy bereit und testen Sie ihn.

Fehlerbehandlung im EventFlow

Standardmäßig wird der Ereignisstream beendet, wenn ein Fehler auftritt. Wenn Sie jedoch zusätzliche Fehlerbehebung durchführen möchten, können Sie Fehlerinformationen wie in diesem Beispiel an Cloud Logging senden.

  1. Erstellen Sie einen neuen Proxy mit der SSE-Proxyvorlage. Weitere Informationen finden Sie unter API-Proxy mit vom Server gesendeten Ereignissen (SSE) erstellen.
  2. Öffnen Sie den Proxy im Apigee-Proxy-Editor und klicken Sie auf den Tab Entwickeln.
  3. Erstellen Sie eine neue RaiseFault-Richtlinie mit der folgenden Definition: 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault continueOnError="false" enabled="true" name="RF-Empty-Event">
  <DisplayName>RF-Empty-Event</DisplayName>
  <Properties/>
  <FaultResponse>
    <AssignVariable>
      <Name>faultReason</Name>
      <Value>empty-event</Value>
    </AssignVariable>
  </FaultResponse>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>
  4. Hängen Sie die RaiseFault-Richtlinie an EventFlow des SSE-Proxys an: 
    <EventFlow content-type="text/event-stream">
  <Response>
    <Step>
      <Name>RF-Empty-Event</Name>
      <Condition>response.event.current.content ~ "data: "</Condition>
    </Step>
  </Response>
</EventFlow>
  5. Erstellen Sie eine MessageLogging-Richtlinie, um Fehler zu protokollieren. Beispiel: 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging continueOnError="false" enabled="true" name="ML-log-error">
  <DisplayName>ML-log-error</DisplayName>
  <CloudLogging>
    <LogName>projects/{organization.name}/logs/apigee_errors</LogName>
    <Message contentType="text/plain">Request failed due to {faultReason}.</Message>
    <ResourceType>api</ResourceType>
  </CloudLogging>
  <logLevel>ALERT</logLevel>
</MessageLogging>
  6. Fügen Sie die MessageLogging-Richtlinie den FaultRules des Zielendpunkts hinzu: 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="TargetEndpoint-1">
  <Description/>
  <FaultRules>
    <FaultRule name="default-fault">
      <Step>
        <Name>ML-log-error</Name>
      </Step>
    </FaultRule>
  </FaultRules>
  ...
</TargetEndpoint>
  7. Stellen Sie den API-Proxy bereit und testen Sie ihn.

Fehler in einem EventFlow weiterleiten

In diesem Beispiel wird gezeigt, wie Sie mit einem EventFlow Fehler an den Client weitergeben. Der Prozess benachrichtigt den Client sofort während der Richtlinienausführung über Fehler.

  1. Erstellen Sie einen neuen Proxy mit der SSE-Proxyvorlage. Weitere Informationen finden Sie unter API-Proxy mit vom Server gesendeten Ereignissen (SSE) erstellen.
  2. Öffnen Sie den Proxy im Apigee-Proxy-Editor und klicken Sie auf den Tab Entwickeln.
  3. Erstellen Sie eine neue JavaScript-Richtlinie mit der folgenden Definition: 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <Javascript continueOnError="false" enabled="true" timeLimit="200" name="js-error">
    <DisplayName>js-error</DisplayName>
    <Properties/>
    <Source>
      if(context.getVariable("response.event.current.count")=="2") {
        throw new Error("Internal Error");
      }
      context.setVariable("response.event.current.content", context.getVariable("response.event.current.content"));
    </Source>
  </Javascript>

    Diese Richtlinie ist so konzipiert, dass ein Fehler ausgegeben wird, wenn eine bestimmte Bedingung erfüllt ist.

  4. Hängen Sie die JavaScript-Richtlinie an EventFlow des SSE-Proxys in der TargetEndpoint-Konfiguration an. Mit diesem Schritt wird sichergestellt, dass der EventFlow die Richtlinie während der Antwortverarbeitung verarbeitet: 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
  <EventFlow content-type="text/event-stream">
    <Response>
      <Step>
        <Name>js-error</Name>
      </Step>
    </Response>
  </EventFlow>
  <HTTPTargetConnection>
    <URL>https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:streamGenerateContent</URL>
  </HTTPTargetConnection>
</TargetEndpoint>
  5. Stellen Sie den API-Proxy bereit.
  6. Testen Sie das Proxyverhalten mit dem folgenden curl-Befehl: 
    curl -X POST -H 'Content-Type: application/json'  "https://ENVIRONMENT_GROUP_NAME/llm-api" -d '{ "contents":[{"parts":[{"text": "Write a story about a magic pen."}]}]}'

    Ersetzen Sie ENVIRONMENT_GROUP_NAME durch den Namen Ihrer Umgebungsgruppe.

    Die Ausgabe sollte in etwa so aussehen:

    data: {"candidates": [{"content": {"parts": [{"text": "El"}],"role": "model"}}],"usageMetadata": {"promptTokenCount": 8,"totalTokenCount": 8},"modelVersion": "gemini-2.5-flash"}
data: {"fault":{"faultstring":"Execution of JS-error failed with error: Exception thrown from JavaScript : Error: Internal Error (Resource_1_js#2)","detail":{"errorcode":"steps.javascript.ScriptExecutionFailed"}}}

    In der Ausgabe wird der ursprüngliche Datenstream gefolgt von der Meldung fault angezeigt. Im Fehlerfall erfasst Apigee die Fehlerinformationen und sendet sie als Ereignis an den Client.

Weitere Informationen zur Fehlerbehandlung in Apigee finden Sie unter Umgang mit Fehlern.

SSE-Daten in Apigee Analytics ansehen

Daten für SSE-Proxys werden wie für jeden API-Proxy in Apigee Analytics angezeigt. Rufen Sie in der Cloud Console Analysen > API-Messwerte auf.

SSE-Proxys debuggen

Verwenden Sie das Apigee-Debugging-Tool, um SSE-Proxys zu debuggen. Debug-Daten werden für EventFlow genauso erfasst wie für die anderen Ablaufarten.

Fehlerbehebung

Bei Problemen mit Echtzeitverkehrsdaten können Sie die Ursache in den Apigee-Zugriffsprotokollen ermitteln.

Beschränkungen

Für SSE-Proxys gelten die folgenden Einschränkungen:

  • Da Analysedaten erst nach dem Schließen der SSE-Sitzung erfasst werden, kann es zu einer gewissen Verzögerung bei der Berichterstellung kommen.
  • Fehler in einem EventFlow führen dazu, dass der Stream sofort beendet wird und ein Fehler ausgegeben wird. Informationen zum manuellen Protokollieren dieser Arten von Fehlern oder zum Senden an den Client finden Sie unter EventFlow-Anwendungsfälle und -Beispiele.
  • Ein Client, der gestreamte SSE-Antworten empfängt, erhält die HTTP-Header, einschließlich aller Statuscodes, am Anfang des Ereignisstreams. Wenn der Ereignisstream in einen Fehlerstatus wechselt, spiegelt der ursprünglich empfangene Statuscode den Fehlerstatus nicht wider.

    Diese Einschränkung ist beim Aufrufen einer Fehlerbehebungssitzung zu sehen. In der Sitzung sehen Sie möglicherweise, dass sich der Statuscode HTTP für Streams, die in den Fehlerstatus wechseln, von den Statuscodes unterscheidet, die an den Client gesendet werden. Das kann passieren, weil der Debug-Sitzungseintrag erst generiert wird, nachdem die gesamte Anfrage verarbeitet wurde, und nicht am Anfang des Ereignisstreams. In der Debugging-Sitzung wird möglicherweise der vom Fehler generierte Fehlercode angezeigt, während der Client anfangs nur den in den Headern empfangenen 2xx-Status sieht.