Produits Entr'ouvert » Passerelle

Note préliminaire : je serai d'avis de permettre les "patchs" i.e pourvoir envoyer des données incomplètes (d'après le schéma) qui seront réintroduites dans la donnée complète qui sera lue, en espérant les schémas compatibles en entrée et en sortie.

Ça permettra du côté de w.c.s. de découper la mise à jour en autant de formulaires qu'on le souhaite (ou pas mais on ne sera pas bloqué).

Il faudrait ajouter UPDATE_FAMILY_SCHEMA['unflatten'] = True et faire tes tests avec la syntaxe qu'utilisera w.c.s. i.e.

{
  "ADRESSE/CODEINSEEVILLE": null,
  "ADRESSE/CODEPOSTAL": "31400" 
}

Pour transformer ton fichier de donnée actuel tu as passerelle.utils.json.flatten().

Sur 0002

Sur flat_update_family_info.json on peut laisser quelques null par ci par là, mais il faudrait essentiellement avoir des chaines vides. En effet dans les appels wcs on va surtout remplir les données avec du gabarit Django (genre {{form_var_truc| default:""}}) et donc ça sera jamais None/null.

Ensuite, lors du retour de update_family_info, je serais partant pour renvoyer aussi post_data, pour savoir ce qui a été mis dans QUIACTUALISEDUI, mais surtout avoir un "echo" général de ce qui a été envoyé vers Axel (bon c'est pas le xml mais c'est super proche). Donc je dirais qqchose comme : return {'updated': True, 'dui': link.dui, 'post_data': post_data}

Pour le reste de 0002 ça me semble ok. Me reste 0001 où je patauge encore bien bien bien à comprendre.

Lauréline Guerin a écrit :

remarques prises en compte :)

hannn zut je suis bête, oublié de voir que le raise APIError('Axel error: %s' % e, err='error') lors du try/except sur form_maj_famille_dui() pourrait lui aussi renvoyer le post_data ; à vrai dire c'est là que ça sera utile de comparer l'erreur renvoyée par Axel aux données poussées. Bon, pour APIError on peut seulement renvoyer un "data", donc je propose :

except:
    APIError('Axel error: %s' % e, err='error', data={'error_post_data': post_data})

Un truc chouette serait qu'on puisse renvoyer aussi le XML généré, afin de pouvoir l'afficher à l'écran (action "Alerte" dans le workflow en cas d'erreur) aux personnes qui feront l'exploitation de l'affaire (admins fonctionnels, support, etc). Ca demanderait sans doute une petite adaptation sur AxelError pour qu'on puisse y ajouter des attributs genre xml_request et xml_response... Je vais faire un ticket séparé.

(et, aussi, je pense que le err='error' n'est pas pris en charge sur APIError, je sais plus pourquoi on est parti sur ça ; je vais faire un autre ticket sur ça, si besoin)