Présentation du problème

Dans cet article, Julien nous montre un moyen de gérer les codes retours HTTP.
Cette méthode est intéressante quand on passe directement par les connecteurs HTTP (et pas par la palette REST d’OSB).
Pour compléter, voici une autre méthode qui s’appuie directement sur les outils REST d’Oracle.

Création du projet

L’exemple sera un projet qui, pour un code postal, renvoie la commune associée.
Les erreurs seront :
– 404 Not Found : aucune commune ne correspond au code postal
– 406 Not Acceptable : le code postal n’est pas valide
– 500 Internal Server Error : plantage technique durant le traitement

Définition des erreurs

On commence par créer une XSD qui associera un élément spécifique par erreur.

Il est important de bien avoir un type différent par erreur. En effet, au moment de renvoyer la réponse, OSB regardera l’élément fourni et fera correspondre le code retour en conséquence.
Il faut éviter les élément vides. Cela provoque (parfois) des erreurs « unmarshalling » qui sont pénibles à traiter. Donc, penser à mettre du contenu, même minimaliste, pour être tranquille.

Création du pipeline et du WSDL

Dans une autre XSD, on déclare les formats d’entrée/sortie nominaux de type texte.
Ici, en entrée le code postal, en sortie le nom de la ville.
Ensuite on crée un pipeline de type WSDL :


Attention : On ne place pas les erreurs dans le WSDL à ce stade. Sinon OSB risque d’avoir du mal à gérer les retours.

Exposition en tant que REST

Une fois le contrat défini, on expose le service en tant que REST.
Dans le partie réponse, on rajoute la gestion les erreurs en référant le type et le code d’erreur associés.


Si l’on ouvre le WADL généré, on retrouve nos erreurs avec pour chaque code retour le type d’erreur associé et la référence vers le WSDL.

(OSB remonte des avertissements sur les éléments en réponse. Pour une raison inconnue, JDeveloper n’arrive pas à retrouver les objets même correctement définis. Cela n’empêche pas le déploiement et l’exécution correcte du flux.)
Si on ouvre le WSDL, on voit qu’il a été mis à jour avec l’ajout des erreurs.

Gestion des codes retours

Maintenant, il reste à définir dans le process les conditions qui déclenchent les exceptions.

Création de l’erreur

Par exemple, dans cas où le code n’est pas valide, on remplit un body au format correspondant à l’erreur 406.

Il est important de garder le format du bloc « Fault » comme cela pour éviter qu’OSB le traite correctement.
A l’intérieur du bloc « detail », on ajoute notre erreur.
Pour les autres erreurs, on applique la même logique en adaptant l’erreur.

Application du code retour

Il reste à indiquer à OSB que le retour est en erreur.
Pour cela, il suffit de mettre un « Reply failure ».

Sachant qu’il s’agit d’une erreur, OSB va automatiquement assigner le code retour en fonction du type d’erreur défini juste au-dessus.

Tests

On peut maintenant tester les cas et voir les erreurs attendues

Pas d’erreur

Code postal incohérent : 406

Code postal inconnu : 404

Erreur technique : 500

Références

Maîtriser le code de réponse HTTP renvoyé par l’OSB : Article de Julien sur les codes retours HTTP
List of HTTP status codes : Liste des codes retours HTTP
SBTestRestHttpCode : Projet Oracle de retour HTTP en REST