HCL Commerce Information d'erreur de services

Lorsqu'une exception se produit pendant le traitement d'un message, la convention OAGIS doit renvoyer un message de réponse bien formulé, avec les données d'erreur incorporées. L'élément ChangeStatus est utilisé pour stocker des données sur l'exception ; si la demande s'est terminée correctement, cette zone n'est pas renseignée. Étant donné qu'une seule action par message est prise en charge, il ne peut y avoir qu'une seule erreur par message. Pour cette raison, la limitation d'une zone ChangeStatus par message est raisonnable.

Dans les critères de réponse, ResponseExpression indique l'actionCode de la demande et l'élément ChangeStatus contient des informations sur l'exception en cas d'échec de la demande. Ce qui suit est un mappage d'exception et le ChangeStatus.

Code: Toujours ERROR pour indiquer qu'il s'agit d'une réponse d'erreur à l'expression d'action
Description: Texte détaillé de l'exception spécifique à l'environnement local
EffectiveDateTime: Heure de l'échec du traitement
ReasonCode: Il s'agit d'une clé unique qui représente l'erreur. Ce code correspond généralement à la clé de message d'une exception HCL Commerce qui identifie le problème de manière unique. Toutefois, il existe des cas où la clé de message n'est pas suffisante pour identifier l'erreur de manière unique et il existe un code d'erreur qui classe davantage l'erreur. Pour ces cas, le code raison est la clé de message + code d'erreur pour identifier l'erreur de manière unique.
Motif: Informations supplémentaires pouvant être utilisées pour comprendre les conditions à l'origine de l'erreur. Il peut y avoir plusieurs raisons et cela correspond généralement aux paramètres de message utilisés pour remplir le texte détaillé du message, où le classement de la raison correspond au classement des paramètres du message.

L'exemple suivant illustre un message d'erreur de réponse :


<?xml version="1.0" encoding="UTF-8"?>
<_mbr:AcknowledgePerson releaseID="9.0"
	xmlns:_mbr="http://www.ibm.com/xmlns/prod/commerce/9/member"
	xmlns:_wcf="http://www.ibm.com/xmlns/prod/commerce/9/foundation"
	xmlns:oa="http://www.openapplications.org/oagis/9" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<oa:ApplicationArea xsi:type="_wcf:ApplicationAreaType">
		<oa:CreationDateTime>2009-07-20T15:28:12.968Z
		</oa:CreationDateTime>
		<oa:BODID>efcd3260-7541-11de-a99e-83c74a648a93
		</oa:BODID>
	</oa:ApplicationArea>
	<_mbr:DataArea>
		<oa:Acknowledge>
			<oa:OriginalApplicationArea>
				<oa:CreationDateTime>2009-07-20Z</oa:CreationDateTime>
				<oa:BODID>ef9188f0-7541-11de-a590-83c74a648cf4
				</oa:BODID>
			</oa:OriginalApplicationArea>
			<oa:ResponseCriteria>
				<oa:ChangeStatus>
					<oa:Code>ERROR</oa:Code>
					<oa:Description>The Logon ID user123 already exists. Specify a
						different Logon ID and try again.</oa:Description>
					<oa:ReasonCode>_ERR_LOGONID_ALREDY_EXIST+2030
					</oa:ReasonCode>
					<oa:Reason>user123</oa:Reason>
				</oa:ChangeStatus>
			</oa:ResponseCriteria>
		</oa:Acknowledge>
	</_mbr:DataArea>
</_mbr:AcknowledgePerson>

La zone ChangeStatus est utilisée uniquement pour signaler les erreurs. Si cette zone n'est pas présente dans la BOD, alors vous savez que le traitement a été effectué avec succès.

Si la demande échoue avec une erreur, le nom dans DataArea ne doit pas être présent (null). Ceci est dû au fait qu'un nom défini pourrait avoir des champs obligatoires, et le code de traitement des exceptions peut ne pas avoir suffisamment d'informations pour renseigner ces champs correctement. Il est donc plus logique de transmettre la réponse avec un champ Nom vierge.

La gestion des erreurs qui fait partie de la base du traitement des documents BOD se chargera de renseigner l'état de modification de la réponse.