|
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 möglicherweise anschließend von der Anwendung selbst generiert werden. 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 Endziel akzeptiert und noch nicht geprüft. Sie erhalten Aktualisierungen zum Status der Anforderung, wenn ein Mechanismus zur Zustellung 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 Response-Daten des angeforderten Typs. In einer PunchOutOrderMessage gibt dieser Status an, dass die PunchOut-Sitzung ohne Änderung des Einkaufswagens (oder der Clientanforderung) 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 wissen müssen, z. B. Feiertagszeitpläne, Schließung der Produktionsstätte oder Abschluss bestimmter Aktivitäten wie Abschluss des Planungslaufs. |
280 | Die Anforderung 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 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, liegt nicht unbedingt ein Problem vor. | |
400 | Ungültige Anforderung | Anforderung für den Server nicht akzeptabel, obwohl er korrekt geparst wurde. |
401 | Nicht autorisiert | Die in der Anfrage (dem Senderelement) angegebenen Anmeldeinformationen 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 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 der (Aktualisierungs-)Operation. Es ist unwahrscheinlich, dass ein identischer Request in der Zukunft erfolgreich ist, aber erst, wenn überhaupt, nachdem ein anderer Vorgang 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 | Request impliziert eine Ressourcenbedingung, die nicht erfüllt wurde. Ein Beispiel könnte eine SupplierDataRequest sein, die nach Informationen über einen Lieferanten fragt, 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 bedeutet 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 in der Signatur verwendete Algorithmen nicht unterstützt. |
477 | Unterschrift nicht akzeptabel | Die Signatur ist technisch gültig, aber aus einem anderen Grund für den Empfänger nicht akzeptabel. Die Signaturrichtlinien oder Zertifikatsrichtlinien sind möglicherweise nicht akzeptabel, die Art des verwendeten Zertifikats ist möglicherweise nicht akzeptabel, oder es kann ein anderes Problem auftreten. |
500 | Interner Serverfehler | Der Server konnte die Anforderung nicht abschließen. |
550 | cXML-Server kann nicht erreicht werden | Der nächste cXML-Server kann nicht erreicht werden, um eine Transaktion abzuschließen, die vorgelagerte Verbindungen erfordert. 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 | Zurücknehmen, um Anforderung weiterzuleiten | Anforderung kann aufgrund fehlender Lieferantenkonfiguration nicht weitergeleitet werden. Beispiel: Ein Zwischen-Hub konnte sich bei einem Lieferanten nicht authentifizieren. Clients können diesen Fehler nicht beheben, aber dieser Fehler kann vor den Client-Wiederholungsversuchen behoben werden. |
560 | Temporärer Serverfehler |
Ein Server kann z. B. 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/ zum Download zur Verfügung steht.
SAP Business Network for Procurement und Supply Chain