Diese Seite gilt für Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen
Übersicht
Die DataCapture-Richtlinie erfasst Daten (z. B. Nutzlast, HTTP-Header und Pfad- oder Suchparameter) von einem API-Proxy zur Verwendung in Analytics. Sie können die erfassten Daten in benutzerdefinierten Analytics-Berichten sowie zur Implementierung von Monetarisierungs- und Monitoring-Regeln nutzen.
Diese Richtlinie ist eine erweiterbare Richtlinie, deren Verwendung je nach Apigee-Lizenz Auswirkungen auf die Kosten oder die Nutzung haben kann. Informationen zu Richtlinientypen und Auswirkungen auf die Nutzung finden Sie unter Richtlinientypen.
.Data Collector-Ressource
Sie müssen zuerst eine Ressource vom Typ
Data Collector erstellen, um die Richtlinie DataCapture
verwenden zu können. Schritte zum Erstellen einer Daten-Collector-Ressource mit der Apigee-Benutzeroberfläche und der Apigee API finden Sie unter Daten-Collector erstellen.
<DataCapture>
Mit dem <DataCapture>
-Element wird eine DataCapture
-Richtlinie definiert.
<DataCapture async="true" continueOnError="true" enabled="true" name="DC">
Hier ein Beispiel für eine DataCapture
-Richtlinie:
<DataCapture name="DC-1"> <Capture> <DataCollector>dc_data_collector</DataCollector> <Collect ref="my_data_variable" /> </Capture> </DataCapture>
Das Hauptelement der Richtlinie DataCapture
ist das Element <Capture>
, das die Mittel zur Erfassung der Daten angibt. Es hat zwei erforderliche untergeordnete Elemente:
- Das Element
<DataCollector>
, das eine Data Collector REST-Ressource angibt. In diesem Fall lautet der Name der Ressourcedc_data_collector
. - Das Element
<Collect>
, das die Mittel zur Erfassung der Daten angibt.
In diesem einfachen Beispiel werden die Daten aus einer Variablen namens my_data_variable
extrahiert, die an anderer Stelle im Proxy erstellt wurde.
Die Variable wird durch das Attribut ref
angegeben.
Das <Collect>
-Element bietet auch mehrere andere Möglichkeiten, Daten aus verschiedenen Quellen über ihre untergeordneten Elemente zu erfassen.
Unter Beispiele finden Sie weitere Beispiele zur Erfassung von Daten mit der Richtlinie DataCapture
.
Das DataCapture
-Element hat die folgende Syntax.
<DataCapture name="capturepayment" continueOnError="false" enabled="true"> <DisplayName>Data-Capture-Policy-1</DisplayName> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <ThrowExceptionOnLimit>false</ThrowExceptionOnLimit> <!-- Existing Variable --> <Capture> <Collect ref="existing-variable" default="0"></Collect> <DataCollector>dc_1</DataCollector> </Capture> <!-- JSONPayload --> <Capture> <DataCollector>dc_2</DataCollector> <Collect default="0"> <Source>request</Source> <JSONPayload> <JSONPath>result.var</JSONPath> </JSONPayload> </Collect> </Capture> <!-- URIPath --> <Capture> <DataCollector>dc_3</DataCollector> <Collect default="0"> <URIPath> <!-- All patterns must specify a single variable to extract named $ --> <Pattern ignoreCase="false">/foo/{$}</Pattern> <Pattern ignoreCase="false">/foo/bar/{$}</Pattern> </URIPath> </Collect> </Capture> </DataCapture>
Dieses Element hat folgende Attribute, die allen Richtlinien gemeinsam sind:
Attribut | Standard | Erforderlich? | Beschreibung |
---|---|---|---|
name |
- | Erforderlich |
Der interne Name der Richtlinie. Der Wert des Attributs Optional können Sie das Element |
continueOnError |
false | Optional | Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten. Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird. Weitere Informationen:
|
enabled |
wahr | Optional | Setzen Sie den Wert auf true , um die Richtlinie zu erzwingen. Legen Sie false fest, um die Richtlinie zu deaktivieren. Die Richtlinie wird nicht durchgesetzt, selbst wenn sie mit einem Ablauf verknüpft ist. |
async |
false | Verworfen | Dieses Attribut wurde verworfen. |
Die folgende Tabelle enthält eine allgemeine Beschreibung der untergeordneten Elemente von <DataCapture>
.
Untergeordnetes Element | Erforderlich | Beschreibung |
---|---|---|
<Capture> |
Erforderlich | Erfasst die Daten für eine bestimmte Variable. |
Beispiele
Die folgenden Beispiele zeigen verschiedene Möglichkeiten, die Richtlinie DataCapture
zu verwenden.
Daten für eine eingebundene Variable erfassen
Das Codebeispiel unten zeigt, wie Sie Daten für eine eingebundene Variable message.content
erfassen, die den Inhalt der Anfrage, Antwort oder Fehlermeldung enthält. Weitere Informationen zu eingebundenen Variablen finden Sie unter Ablaufvariablen.
<DataCapture name="DC-FullMessage"> <Capture> <DataCollector>dc_data_collector</DataCollector> <Collect ref="message.content" /> </Capture> </DataCapture>
Im obigen Code gibt das Attribut ref
des Elements </Collect>
die zu erfassende Variable an, in diesem Beispiel "message.content"
.
Im Beispiel werden die Daten mit einem <Capture>
-Element erfasst, das auch ein <DataCollector>
-Element enthält, das den Namen der Data Collector-Ressource angibt.
Daten inline erfassen
Im nächsten Beispiel wird gezeigt, wie Sie Daten mit <JSONPayload>
, einem untergeordneten Element des <Collect>
-Elements, inline erfassen.
<DataCapture name="DC-Currency"> <Capture> <DataCollector>dc_data_collector<DataCollector> <Collect> <JSONPayload> <JSONPath>$.results[0].currency</JSONPath> </JSONPayload> </Collect> </Capture> </DataCapture>
Im obigen Code gilt Folgendes:
- Das Element
<JSONPayload>
gibt die JSON-formatierte Nachricht an, aus der der Wert der Variablen extrahiert wird. - Das
<JSONPath>
-Element gibt den JSON-Pfad an, der zum Extrahieren des Werts aus der Nachricht verwendet wird, in diesem Fall$.results[0].currency
.
Angenommen, der Wert, der beim Empfang der Nachricht extrahiert wird, lautet 1120
. Der an Analytics gesendete Eintrag lautet dann
{ "dc_data_collector": "1120" }
<Capture>
Das <Capture>
-Element gibt die Mittel zur Erfassung der Daten an.
<Capture />
Die folgende Tabelle enthält eine allgemeine Beschreibung der untergeordneten Elemente von <Capture>
.
Untergeordnetes Element | Erforderlich? | Beschreibung |
---|---|---|
<DataCollector> |
Erforderlich | Gibt die Data Collector-Ressource an. |
<Collect> |
Erforderlich | Gibt die Mittel zur Datenerfassung an. |
<DataCollector>
Das Element <DataCollector>
gibt die Data Collector-Ressource an.
<DataCollector>dc_data_collector</DataCollector>
<DataCollector>
-Elements beschrieben.
Attribut | Beschreibung | Standard | Erforderlich? | Typ |
---|---|---|---|---|
Bereich |
Geben Sie dieses Attribut an und setzen Sie den Wert auf |
– | Optional | String |
Der Text des Elements <DataCollector>
enthält den Namen der Data Collector-Ressource.
<Collect>
Das <Collect>
-Element gibt die Mittel zur Datenerfassung an.
<Collect ref="existing-variable" default="0"/>
In der folgenden Tabelle werden die Attribute des <Collect>
-Elements beschrieben.
Attribut | Beschreibung | Standard | Erforderlich? | Typ |
---|---|---|---|---|
ref |
Die Variable, für die Sie Daten erfassen. |
– | Optional – Wenn ref weggelassen wird, muss genau einer der folgenden Werte angegeben werden: QueryParam , Header , FormParam , URIPath , JSONPayload oder XMLPayload .
|
String |
Standard | Gibt den Wert an, der an Analytics gesendet wird, wenn der Wert der Variablen zur Laufzeit nicht ausgefüllt wird. Wenn Sie beispielsweise default="0" festlegen, beträgt der an Analytics gesendete Wert 0.
|
Wenn Sie den Wert von default nicht angeben ist und der Wert der Variablen zur Laufzeit nicht ausgefüllt wird, lautet der an Analytics gesendete Wert null für eine numerische Variable oder "Not set" für eine Stringvariable.
|
Erforderlich | String |
Die Daten können mit dem Attribut ref
oder durch untergeordnete <Collect>
-Elemente aus einer vorhandenen Variablen erfasst werden.
Untergeordnete Elemente von <Collect>
Die folgende Tabelle enthält eine allgemeine Beschreibung der untergeordneten Elemente von <Collect>
:
Untergeordnetes Element | Erforderlich? | Beschreibung |
---|---|---|
<Source> |
Optional | Gibt die zu parsende Variable an. |
<URIPath> |
Optional | Extrahiert einen Wert aus dem proxy.pathsuffix einer Anfragequellnachricht. |
<QueryParam> |
Optional | Extrahiert einen Wert aus dem angegebenen Suchparameter einer Anfragequellnachricht. |
<Header> |
Optional | Extrahiert einen Wert aus dem angegebenen HTTP-Header der angegebenen Anfrage- oder Antwortnachricht. |
<FormParam> |
Optional | Extrahiert einen Wert aus dem angegebenen Formularparameter der angegebenen Anfrage- oder Antwortnachricht. |
<JSONPayload> |
Optional | Gibt die JSON-formatierte Nachricht an, aus der der Wert der Variablen extrahiert wird. |
<XMLPayload> |
Optional | Gibt die XML-formatierte Nachricht an, aus der der Wert der Variablen extrahiert wird. |
<Source>
Gibt die zu parsende Variable an. Der Wert von <Source>
ist standardmäßig message
. Der Wert message
ist kontextabhängig. In einem Anfragefluss löst message
die Anfragenachricht auf. In einem Antwortfluss löst message
die Antwortnachricht auf.
Obwohl Sie diese Richtlinie häufig zum Extrahieren von Informationen aus einer Anfrage- oder Antwortnachricht verwenden, können Sie sie zum Extrahieren von Informationen aus einer beliebigen Variable verwenden. Sie können sie beispielsweise verwenden, um Informationen aus einer Entität zu extrahieren, die durch die AccessEntity-Richtlinie erstellt wurde, durch Daten, die von der ServiceCallout-Richtlinie zurückgegeben wurden, oder um Daten aus einem XML- oder JSON-Objekt zu extrahieren.
Wenn <Source>
nicht aufgelöst werden kann oder in einen Nicht-Nachrichtentyp aufgelöst wird, reagiert die Richtlinie nicht.
Standardwert | – |
Erforderlich? | Optional |
Typ | String |
Übergeordnetes Element |
<Collect> |
Untergeordnete Elemente | – |
Attribute
Attribut | Beschreibung | Standard | Erforderlich? | Typ |
---|---|---|---|---|
clearPayload |
Setzen Sie den Wert auf wahr, wenn Sie die in Verwenden Sie die Option |
false |
Optional | Boolesch |
<Source clearPayload="true|false">request</Source>
<URIPath>
Extrahiert einen Wert aus dem proxy.pathsuffix
einer request
-Quellnachricht. Der für das Muster angewendete Pfad ist das proxy.pathsuffix
, das nicht den Basispfad für den API-Proxy enthält. Wenn die Quellnachricht in den Nachrichtentyp response
aufgelöst wird, führt das Element nichts aus.
Standardwert | – |
Erforderlich? | Optional |
Typ | Komplex |
Übergeordnetes Element |
<Collect> |
Untergeordnete Elemente | <Pattern> |
Attribute
Attribut | Beschreibung | Standard | Erforderlich? | Typ |
---|---|---|---|---|
ignoreCase | Gibt an, dass die Groß-/Kleinschreibung beim Abgleich mit dem Muster ignoriert wird. |
false |
Optional | Boolesch |
<Collect> <URIPath> <Pattern ignoreCase="false">/foo/{$}</Pattern> </URIPath> </Collect>
Sie können mehrere <Pattern>
-Elemente verwenden:
<URIPath> <Pattern ignoreCase="false">/foo/{$}</Pattern> <Pattern ignoreCase="false">/foo/bar/{$}</Pattern> </URIPath>
<QueryParam>
Extrahiert einen Wert aus dem angegebenen Suchparameter einer request
-Quellnachricht. Wenn die Quellnachricht in einen Nachrichtentyp von response
aufgelöst wird, führt das Element nichts aus.
Standardwert | – |
Erforderlich? | Optional |
Typ | Komplex |
Übergeordnetes Element |
<Collect> |
Untergeordnete Elemente | <Pattern> |
Attribute
Attribut | Beschreibung | Standard | Erforderlich? | Typ |
---|---|---|---|---|
Name | Gibt den Namen des Suchparameters an. Wenn mehrere Suchparameter denselben Namen haben, verwenden Sie indexierte Verweise, bei denen die erste Instanz des Suchparameters keinen Index hat, die zweite an Index 2 verwiesen wird, die dritte an Index 3 usw. |
– |
Erforderlich | String |
<Collect> <QueryParam name="code"> <Pattern ignoreCase="true">{$}</Pattern> </QueryParam> </Collect>
Wenn mehrere Suchparameter denselben Namen haben, verweisen Sie mit Indexen auf die Parameter:
<Collect> <QueryParam name="code.2"> <Pattern ignoreCase="true">{$}</Pattern> </QueryParam> </Collect>
Hinweis: Sie müssen eine einzelne Variable namens {$}
angeben.
Es können mehrere eindeutige Pattern
-Elemente vorhanden sein, aber das erste übereinstimmende Muster wird für eine bestimmte Anfrage aufgelöst.
<Header>
Extrahiert einen Wert aus dem angegebenen HTTP-Header der angegebenen request
- oder response
-Nachricht. Wenn mehrere Header denselben Namen haben, werden ihre Werte in einem Array gespeichert.
Standardwert | – |
Erforderlich? | Optional |
Typ | Komplex |
Übergeordnetes Element |
<Collect> |
Untergeordnete Elemente | <Pattern> |
Attribute
Attribut | Beschreibung | Standard | Erforderlich? | Typ |
---|---|---|---|---|
Name | Gibt den Namen des Headers an, aus dem der Wert extrahiert wird. Wenn mehrere Header denselben Namen haben, verwenden Sie indexierte Verweise, bei denen die erste Instanz des Headers keinen Index hat, die zweite sich bei Index 2, die dritte bei Index 3 usw. befindet. Verwenden Sie .values , um alle Header im Array abzurufen. |
– |
Erforderlich | String |
<Collect> <Header name="my_header"> <Pattern ignoreCase="false">Bearer {$}</Pattern> </Header> </Collect>
Wenn mehrere Header denselben Namen haben, verweisen Sie mit Indexen auf einzelne Header im Array:
<Collect> <Header name="my_header.2"> <Pattern ignoreCase="true">{$}</Pattern> </Header> </Collect>
Alternativ können Sie auch alle Header im Array auflisten:
<Collect> <Header name="my_header.values"> <Pattern ignoreCase="true">{$}</Pattern> </Header> </Collect>
<FormParam>
Extrahiert einen Wert aus dem angegebenen Formularparameter der angegebenen request
- oder response
-Nachricht. Formularparameter können nur dann extrahiert werden, wenn der Content-Type
-Header der angegebenen Nachricht application/x-www-form-urlencoded
lautet.
Standardwert | – |
Erforderlich? | Optional |
Typ | Komplex |
Übergeordnetes Element |
<Collect> |
Untergeordnete Elemente | <Pattern> |
Attribute
Attribut | Beschreibung | Standard | Erforderlich? | Typ |
---|---|---|---|---|
Name | Der Name des Formularparameters, aus dem der Wert extrahiert wird. |
– |
Optional | String |
<Collect> <FormParam name="greeting"> <Pattern>hello {$}</Pattern> </FormParam> </Collect>
<JSONPayload>
Gibt die XML-formatierte Nachricht an, aus der der Wert der Variablen extrahiert wird. Die JSON-Extraktion wird nur durchgeführt, wenn der Content-Type
-Header der Nachricht application/json
ist.
Standardwert | – |
Erforderlich? | Optional |
Typ | Komplex |
Übergeordnetes Element |
<Collect> |
Untergeordnete Elemente | <JSONPath> |
<Collect> <JSONPayload> <JSONPath>$.results[0].currency</JSONPath> </JSONPayload> </Collect>
<JSONPath>
Erforderliches untergeordnetes Element des Elements <JSONPayload>
. Gibt den JSON-Pfad an, der zum Extrahieren eines Werts aus einer JSON-formatierten Nachricht verwendet wird.
Standardwert | – |
Erforderlich? | Erforderlich |
Typ | String |
Übergeordnetes Element |
<JSONPayload> |
Untergeordnete Elemente | – |
<JSONPath>$.rss.channel.title</JSONPath>
<XMLPayload>
Gibt die XML-formatierte Nachricht an, aus der der Wert der Variablen extrahiert wird. XML-Nutzlasten werden nur extrahiert, wenn der Content-Type
-Header der Nachricht text/xml
, application/xml
oder application/*+xml
ist.
Standardwert | – |
Erforderlich? | Optional |
Typ | Komplex |
Übergeordnetes Element |
<Collect> |
Untergeordnete Elemente |
<Namespaces> <XPath> |
Die folgende Tabelle enthält eine allgemeine Beschreibung der untergeordneten Elemente von <XMLPayload>
.
Untergeordnetes Element | Erforderlich? | Beschreibung |
---|---|---|
<Namespaces> |
Optional | Gibt null oder mehr Namespaces für die XPath-bewertung an: |
<XPath> |
Erforderlich | Gibt den für die Variable definierten XPath an. |
<Collect> <XMLPayload> <Namespaces> <Namespace prefix="soap">http://schemas.xmlsoap.org/soap/envelope/</Namespace> <Namespace prefix="ns1">http://ns1.example.com/operations</Namespace> </Namespaces> <!-- get the local name of the SOAP operation --> <XPath>local-name(/soap:Envelope/soap:Body/ns1:*[1])</XPath> </XMLPayload> </Collect>
<Namespaces>
Gibt die Gruppe an Namespaces an, die im XPath-Ausdruck verwendet werden können. Beispiel:
<Collect> <XMLPayload> <Namespaces> <Namespace prefix="maps">http://maps.example.com</Namespace> <Namespace prefix="places">http://places.example.com</Namespace> </Namespaces> <XPath>/maps:Directions/maps:route/maps:leg/maps:endpoint/places:name</XPath> </XMLPayload> </Collect>
Wenn Sie in Ihren XPath-Ausdrücken keine Namespaces verwenden, können Sie das Element <Namespaces>
auslassen oder kommentieren, wie im folgenden Beispiel gezeigt:
<Collect> <XMLPayload> <!-- <Namespaces/> --> <XPath>/Directions/route/leg/name</XPath> </XMLPayload> </Collect>
<Namespace>
Gibt einen Namespace und ein entsprechendes Präfix für die Verwendung im XPath-Ausdruck an. Beispiel:
Standardwert | – |
Erforderlich? | Optional |
Typ | String |
Übergeordnetes Element |
<Namespaces> |
Untergeordnete Elemente | – |
Attribute
Attribut | Beschreibung | Standard | Erforderlich? | Typ |
---|---|---|---|---|
prefix |
Das Präfix mit dem Sie im xpath-Ausdruck auf den Namespace verweisen. Dies muss nicht das gleiche Präfix wie im ursprünglichen XML-Dokument sein. |
– |
Erforderlich | String |
<Collect> <XMLPayload> <Namespaces> <Namespace prefix="maps">http://maps.example.com</Namespace> </Namespaces> <XPath>/maps:Directions/maps:route/maps:leg/maps:endpoint</XPath> </XMLPayload> </Collect>
<XPath>
Erforderliches untergeordnetes Element des XMLPayload-Elements. Gibt den für die Variable definierten XPath an. Es werden nur XPath 1.0-Ausdrücke unterstützt.
Standardwert | – |
Erforderlich? | Erforderlich |
Typ | String |
Übergeordnetes Element |
<XMLPayload> |
Untergeordnete Elemente | – |
<XPath>/test/example</XPath>
Hinweis: Wenn Sie in Ihren XPath-Ausdrücken Namespaces verwenden, müssen Sie die Namespaces im Abschnitt <XMLPayload><Namespaces>
der Richtlinie angeben.
<ThrowExceptionOnLimit>
Das <ThrowExceptionOnLimit>
-Element gibt an, was geschieht, wenn die Erfassungslimits für die Anzahl der Variablen erreicht werden oder die maximale Größe einer Variablen erreicht wird. Weitere Informationen finden Sie unter Erfassungslimits erzwingen.
Für <ThrowExceptionOnLimit>
kann einer der folgenden Werte angegeben werden:
false
: Die Daten für die Variablen werden an Analytics gesendet.true
: Eine Fehlermeldung wird zurückgegeben und die Daten werden nicht an Analytics gesendet.
Fehlerreferenz
Laufzeitfehler
In der folgenden Tabelle werden Laufzeitfehler beschrieben, die beim Ausführen der Richtlinie auftreten können.
Fehlercode | Ursache |
---|---|
DataCollectorTypeMismatch |
Der zu erfassende Wert entspricht nicht dem Typ |
ExtractionFailure |
Fehler bei der Datenextraktion. |
UnresolvedVariable |
Die Variable existiert nicht. |
VariableCountLimitExceeded |
Die Anzahl der erfassten Variablen überschreitet die Obergrenze von 100 Variablen. |
VariableValueLimitExceeded |
Die Größe eines erfassten Werts überschreitet die Beschränkung der einzelnen Variablen von 400 Byte. |
MsgContentParsingFailed |
Der Nachrichteninhalt konnte nicht in XML oder JSON geparst werden. |
InvalidMsgContentType |
Der Nachrichteninhaltstyp stimmt nicht mit dem erwarteten Nachrichteninhaltstyp in der Klausel zur Erfassung von Richtlinien überein. |
NonMsgVariable |
Der Wert des Elements <Source> verweist nicht auf eine Nachrichtenvariable. |
JSONPathQueryFailed |
Die JSONPath -Abfrage konnte nicht in einen Wert aufgelöst werden. |
PrivateVariableAccess |
Fehler beim Versuch, auf eine private Variable zuzugreifen. |
XPathEvaluationFailed |
XPath konnte nicht in einen Wert aufgelöst werden. |
Laufzeitfehler werden auf zwei Arten zurückgegeben:
- Fehlerantwort zurück zum Client (
continueOnError=false
)Wenn das
continueOnError
-Attribut der Richtlinie auffalse
gesetzt ist, werden bei während der Richtlinienausführung auftretenden Fehlern die Nachrichtenverarbeitung abgebrochen und eine beschreibende Fehlermeldung zurückgegeben. Die Richtlinie versucht, alle relevanten Fehler in der Datenerfassungsrichtlinie zu erfassen, bevor die Nachricht zurückgegeben wird. DataCapture
FehleranalysefeldDas Feld
dataCapturePolicyErrors
enthält eine Liste aller aufgetretenen Fehler. Im Folgenden sehen Sie ein Beispiel dafür, wie das im Analaysedatenabgleich angezeigt wird:# Example payload [ { errorType: TypeMismatch, policyName: MyDataCapturePolicy-1, dataCollector: purchaseValue }, { errorType: MaxValueSizeLimitReached, policyName: MyDataCapturePolicy-1, dataCollector: purchasedItems }, ]
Für dieses Feld gilt die Größenbeschränkung von 400 Byte.
Bereitstellungsfehler
Fehlercode | Ursache |
---|---|
DeploymentAssertionError |
Der in der Richtlinie referenzierte DataCollector konnte während der Bereitstellung nicht in der Organisation gefunden werden. |
JsonPathCompilationFailed |
Fehler beim Kompilieren mit dem angegebenen JSONPath . |
XPathCompilationFailed |
Wenn das Präfix oder der Wert, der im Element XPath verwendet wird, zu keinem der angegebenen Namespaces in der Richtlinie gehört, schlägt die Bereitstellung des API-Proxys fehl. |
PatternCompilationFailed |
Musterkompilierung fehlgeschlagen. |
DataCapture
-Fehler im Debug-Tool finden
Die Variable dataCapturePolicyErrors
ist im Debug-Tool verfügbar.
Mit diesem zusätzlichen Tool können Sie Fehler erkennen, ohne Analytics aufrufen zu müssen.
Sie können beispielsweise einen Fehler feststellen, der auftritt, wenn Sie Ihre Version der Hybridlaufzeit aktualisieren und dabei die Analyse in einem bereits bereitgestellten Proxy versehentlich unterbrechen.
Erfassungslimits erzwingen
Apigee erzwingt die folgenden Limits für Variablen in den erfassten Daten:
- Es sind maximal 100 Variablen zulässig.
- Die maximale Größe einer Variablen (einschließlich Listenwerte) beträgt 400 Byte.
Wenn die Datenerfassungsrichtlinie ausgeführt wird, bevor ein Wert zur Datenerfassungszuordnung im Nachrichtenkontext hinzugefügt wird:
- Wenn das Limit für die Anzahl der Variablen erreicht wurde, wird die neue Variable gelöscht.
- Wenn das Limit für die Größe der Variablen erreicht wurde, wird der Wert gekürzt, um die gewünschten Limits einzuhalten.
In beiden Fällen gilt:
- Eine Debug-Nachricht wird im Message Processor-Log erfasst.
- Eine
limit reached
-Fehlermeldung wird andataCapturePolicyErrors
angehängt, das sowohl in Analytics als auch im Debugging verfügbar ist. Hinweis: Es wird nur eine Fehlermeldung angehängt, um die maximal zulässige Anzahl von Variablen zu erreichen. - Wenn <ThrowExceptionOnLimit>
true
ist, werden die Daten nicht an Analytics gesendet und stattdessen wird ein Fehler an den Client zurückgegeben.