| |||||||||
Liste der cXML-Statuscodes, die als Antwort gesendet werden.
| Status | Text | Bedeutung |
| 200 | OK | Der Server konnte den Request ausführen oder an den Letztempfä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 später von der Anwendung selbst generiert werden könnten. Sie erhalten keine weiteren Statusaktualisierungen, es sei denn, bei der späteren Verarbeitung tritt ein Fehler auf. |
|
201 | Angenommen | Die Anfrage wurde von einem Zwischen-Hub zur Weiterleitung angenommen oder von seinem endgültigen Ziel akzeptiert und noch nicht geprüft. Sie erhalten Aktualisierungen zum Status der Anforderung, wenn ein Mechanismus verfügbar ist, um sie zu liefern. Der Client sollte spätere StatusUpdate-Transaktionen erwarten. |
| 204 | Kein Inhalt | Alle Anforderungsinformationen 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 Kundenbestellanforderung) 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 dem Abschluss eines Planungslaufs. |
| 280 | Die Anfrage wurde von einem Zwischen-Hub weitergeleitet. Sie erhalten mindestens eine weitere Statusaktualisierung. Dieser Status kann bedeuten, dass die Anforderung an einen anderen Vermittler oder an den Letztempfänger mit dem Status 201 gesendet wurde oder dass sie über einen zuverlässigen Nicht-cXML-Transport weitergeleitet wurde. | |
| 281 | Die Anfrage wurde von einem Zwischen-Hub mit einem unzuverlässigen Transport (z.B. E-Mail) weitergeleitet. Möglicherweise erhalten Sie Statusaktualisierungen. Wenn Sie jedoch keine Statusaktualisierungen erhalten, gibt es nicht unbedingt ein Problem. | |
| 400 | Ungültige Anforderung | Anforderung ist für den Server nicht akzeptabel, obwohl sie 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 nicht über ausreichende Berechtigungen zum Ausführen dieser Anforderung. |
| 406 | Nicht akzeptabel | Anforderung ist für den Server nicht akzeptabel, wahrscheinlich aufgrund eines Parsing-Fehlers. |
| 409 | Konflikt | Der aktuelle Zustand des Servers oder seiner internen Daten verhinderte die (Aktualisierungs-)Operationsanforderung. Ein identischer Request kann in Zukunft wahrscheinlich nicht erfolgreich sein, jedoch erst, nachdem eine andere Operation ausgeführt wurde, wenn überhaupt. |
| 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 eine SupplierDataRequest sein, in der nach Informationen über einen dem Server unbekannten Lieferanten gefragt wird. Dieser Status kann zu verlorenen 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 Profil des Servers ignoriert hat. |
| 475 | Signatur erforderlich | Der Empfänger ist nicht bereit, das Dokument zu akzeptieren, 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 Algorithmen, die in der Signatur verwendet werden, nicht unterstützt. |
| 477 | Unterschrift 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 ist möglicherweise inakzeptabel, oder es gibt ein anderes Problem. |
| 500 | Interner Serverfehler | Server konnte die Anforderung nicht abschließen. |
| 550 | cXML-Server kann nicht erreicht werden | Der nächste 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 | Unale zum Weiterleiten der Anforderung | Anforderung kann aufgrund einer falschen Lieferantenkonfiguration nicht weitergeleitet werden. Beispielsweise konnte sich ein Zwischen-Hub nicht bei einem Lieferanten authentifizieren. Clients können diesen Fehler nicht beheben, aber dieser Fehler kann behoben werden, bevor der Client erneut versucht wird. |
| 560 | Temporärer Serverfehler |
Beispielsweise kann 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, der unter http://cxml.org/ heruntergeladen werden kann.
SAP Business Network for Procurement und Supply Chain