| |||||||||
Liste der cXML-Statuscodes, die als Antwort gesendet werden.
| Status | Text | Bedeutung |
| 200 | OK | Der Server konnte den Request ausführen oder an den Endempfänger liefern. Die zurückgegebene Antwort kann Anwendungswarnungen oder -fehler enthalten: Die cXML-Anforderung selbst hat keine Fehler oder Warnungen generiert. Dieser Status spiegelt jedoch keine Fehler oder Warnungen wider, die anschließend von der Anwendung selbst generiert werden können. Sie erhalten keine weiteren Statusaktualisierungen, es sei denn, bei der späteren Verarbeitung tritt ein Fehler auf. |
|
201 |
Angenommen | Der Antrag wurde von einem Zwischen-Hub zur Weiterleitung angenommen oder von seinem endgültigen Bestimmungsort angenommen und noch nicht geprüft. Sie erhalten Aktualisierungen zum Status der Anforderung, wenn ein Mechanismus zur Bereitstellung der Anforderung verfügbar ist. Der Client sollte spätere StatusUpdate-Transaktionen erwarten. |
| 204 | Kein Inhalt | Alle Request-Informationen waren gültig und wurden erkannt. Der Server hat keine Antwortdaten des angeforderten Typs. In einer PunchOutOrderMessage gibt dieser Status an, dass die PunchOut-Sitzung ohne Änderung des Einkaufswagens (oder der Client-Bestellanforderung) beendet wurde. |
| 211 | OK | Käufer können diesen Statuscode verwenden, um eine Broadcast-Nachricht an Lieferanten zu senden, um sie über alle Ereignisse zu informieren, die sie kennen müssen, z. B. Feiertagszeitpläne, Schließung der Produktionsstätte oder Abschluss bestimmter Aktivitäten wie Abschluss des Planungslaufs. |
| 280 | Die Anfrage wurde von einem Zwischen-Hub weitergeleitet. Sie erhalten mindestens eine weitere Statusaktualisierung. Dieser Status könnte bedeuten, dass die Anforderung an einen anderen Vermittler oder an den Endempfänger mit dem Status 201 gesendet wurde oder dass sie über einen zuverlässigen Nicht-cXML-Transport weitergeleitet wurde. | |
| 281 | Die Anforderung wurde von einem Zwischen-Hub über einen unzuverlässigen Transport (z.B. E-Mail) weitergeleitet. Sie erhalten möglicherweise Statusaktualisierungen. Wenn Sie jedoch keine Statusaktualisierungen erhalten haben, besteht nicht unbedingt ein Problem. | |
| 400 | Ungültige Anforderung | Anforderung für den Server nicht akzeptabel, obwohl er korrekt geparst wurde. |
| 401 | Nicht berechtigt | Die in der Anforderung angegebenen Anmeldeinformationen (das Senderelement) wurden vom Server nicht erkannt. |
| 402 | Zahlung erforderlich | Diese Anforderung muss ein vollständiges Zahlungselement enthalten. |
| 403 | Verboten | Der Benutzer verfügt über unzureichende Berechtigungen zum Ausführen dieser Anforderung. |
| 406 | Nicht akzeptabel | Anforderung für den Server nicht akzeptabel, wahrscheinlich aufgrund eines Parsing-Fehlers. |
| 409 | Konflikt | Der aktuelle Status des Servers oder seiner internen Daten verhinderte die Anforderung des (Aktualisierungs-)Vorgangs. Ein identischer Request ist in Zukunft wahrscheinlich nicht erfolgreich, aber nur, wenn überhaupt, nachdem eine andere Operation ausgeführt wurde. |
| 412 | Vorbedingung fehlgeschlagen | Eine Vorbedingung der Anforderung (z. B. eine PunchOut-Sitzung, die für eine PunchOutSetupRequest-Bearbeitung geeignet ist) wurde nicht erfüllt. Dieser Status impliziert normalerweise, dass der Client einen Teil einer vorherigen Übertragung von einem Server ignoriert hat (z.B. das Attribut operationAllowed eines PunchOutOrderMessageHeader). |
| 417 | Erwartung fehlgeschlagen | Anfrage implizierte eine Ressourcenbedingung, die nicht erfüllt wurde. Ein Beispiel könnte ein SupplierDataRequest sein, in dem nach Informationen über einen Lieferanten gefragt wird, der dem Server unbekannt ist. Dieser Status kann zum Verlust von Informationen auf dem Client oder Server führen. |
| 450 | Nicht implementiert | Der Server implementiert den jeweiligen Request nicht. Beispielsweise wird PunchOutSetupRequest oder der angeforderte Vorgang möglicherweise nicht unterstützt. Dieser Status impliziert normalerweise, dass der Client das Serverprofil ignoriert hat. |
| 475 | Unterschrift erforderlich | Der Empfänger ist nicht bereit, das Dokument anzunehmen, da es keine digitale Signatur hat. |
| 476 | Signaturverifizierung fehlgeschlagen | Der Empfänger kann die Signatur nicht validieren, möglicherweise weil das Dokument während des Transports geändert wurde oder der Empfänger einen oder mehrere in der Signatur verwendete Algorithmen nicht unterstützt. |
| 477 | Signatur nicht akzeptabel | Die Signatur ist technisch gültig, aber für den Empfänger aus einem anderen Grund nicht akzeptabel. Die Signaturrichtlinien oder Zertifikatsrichtlinien können inakzeptabel sein, die Art des verwendeten Zertifikats kann inakzeptabel sein, oder es kann ein anderes Problem vorliegen. |
| 500 | Interner Serverfehler | Server konnte die Anforderung nicht abschließen. |
| 550 | cXML-Server kann nicht erreicht werden | Nächster cXML-Server zum Abschließen einer Transaktion, die vorgelagerte Verbindungen erfordert, kann nicht erreicht werden. Ein Zwischen-Hub kann diesen Code zurückgeben, wenn eine Lieferanten-Site nicht erreichbar ist. Wenn vorgelagerte Verbindungen abgeschlossen sind, sollten Zwischen-Hubs Fehler direkt an den Client zurückgeben. |
| 551 | Anforderung kann nicht weitergeleitet werden | Anforderung kann aufgrund einer falschen Konfiguration des Lieferanten nicht weitergeleitet werden. Beispiel: Ein Zwischen-Hub konnte sich nicht bei einem Lieferanten authentifizieren. Clients können diesen Fehler nicht beheben, aber dieser Fehler kann vor den Client-Wiederholungsversuchen behoben werden. |
| 560 | Temporärer Serverfehler |
Beispielsweise könnte ein Server wegen Wartungsarbeiten ausgefallen sein. Der Client sollte es später erneut versuchen. |
Sie finden diese Liste und die Liste der Statuscodes für Katalog-Upload-Anforderungen auch im cXML Reference Guide, Abschnitt 3.1.9.1, das Sie unter http://cxml.org/ herunterladen können.
SAP Business Network