Mise en conformité du wsdl avec la spec interop #21

aminvielledebat · 2018-06-04T09:23:43Z

Ajout de contraintes
Mise en conformité des contraintes
Respect des séquences
Suppression du CodeRetour dans la requête de mise à jour (erreur de la spec selon moi)
Gestion du choice sur les éléments d'adresse (à valider)

aminvielledebat · 2018-06-04T22:46:06Z

@jlsaxione j'ai du modifier le binding pour être en non wrapped avec cette définition du wsdl.
Est-ce que tu penses que cela pose problème ? Perso je ne vois rien de choquant avec le fait de bosser avec l'objet défini dans le wsdl, et non ses attributs directement, mais je ne suis connaisseur java 😄

- Ajout de contraintes - Mise en conformité des contraintes - Respect des séquences

aminvielledebat · 2018-06-04T23:10:27Z

@jlsaxione @dlevasseuraltitude j'ai ajouté deux modifs en plus des restrictions et séquences :

la suppression de l'élément CodeRetour dans la requête de maj qui est une typo je pense.
deux séquences en choice d'après la spec pour les types d'adresses.
De ce que j'ai compris, un seul élément est autorisé, et je pense qu'il vaut mieux interdire les choix multiples pour limiter les erreurs (que faire si on nous donne plusieurs infos d'adresse qui ne sont pas cohérentes ?).

Cf la spec :

jlsaxione · 2018-06-07T15:16:25Z

voulez vous merger ?

aminvielledebat · 2018-06-07T15:20:34Z

Merci @jlsaxione ! Par contre je pense que la gestion des champs d'adresse a un vrai impact pour SFR.
Il faudrait qu'ils valident... sinon ça peut les piquer.

On passe quand même d'un container où tu mets ce que tu veux (mais bonjour les RGs), à quelque chose où il n'y a qu'un seul champ d'adresse.

olaissac-bt · 2018-06-12T15:20:08Z

C'est la première fois que je poste donc je me présente: Olivier Laissac. Je m'occupe du sujet emutation pour Bouygues Telecom (en lien avec Manuel Rogier).

Si on veut que ne soit rempli qu'une seule référence d'adresse pour éviter d'éventuelles incohérences (ce qui est louable), il faut garantir que chacun saura interpréter correctement cette référence. Replaçons ce sujet dans son contexte fonctionnel.

L'objet AdressePBOReponseType est utile lors de la récupération des pbo voisins. Si dans l'ihm on décide de ne pas afficher l'adresse du pbo, la question posée dans ce topic est sans objet. Si on décide de l'afficher, au delà de l'unicité de la référence, la complexité va être de traduire cette unique référence d'adresse en adresse lisible par un humain. Si c'est une référenceGeo, on peut passer par une carte, mais si c'est une hexaclé ou un code rivoli comment va-t-on faire ? Doit-on utiliser les correspondances issues des IPE OI qui normalement ne concernent pas les pbo ? Est-ce réellement à chaque OC de faire cette traduction qui pourrait simplement être fournie par l'OI dans l'objet ? Donc au délà de la question technique c'est l'utilisation même de cette donnée et son format qui m'interrogent. Au passage, on aura le même problème sur le service de récupération des bases arrière d’un pbo (sur la partie OAPC) mais en plus embêtant car il s’agira là de faire corriger l’adresse par un humain donc là on sera obligé de mettre en place cette traduction. Mais comme ce n’est pas lié à ce wsdl je ne m'étends pas plus.

L'autre objet AdresseType est utilisé lors de la mise à jour de la route optique dans le sens OC vers OI. Là utiliser une unique référence me semble pertinent et sans débat car l'OC peut choisir celle qui lui convient le mieux et l'OI les connait toutes.

Dans tous le cas, si on décide d'aller dans cette direction il faudra faire mettre à jour la spec interop en cohérence.

aminvielledebat · 2018-06-12T17:19:29Z

Hello et bienvenue @olaissac-bt 😄 !

C'est super que vous fassiez des retours également, c'est comme cela que l'on avance.

AdressePBOReponseType

Complètement en phase sur l'usage de l'objet AdressePBOReponseType !
Il est clair qu'en fonction du type remonté, il sera très difficile pour le technicien d'en faire quelque chose, si un travail de traduction n'est pas fait en amont par l'OC, et qu'un seul type est remonté... Sauf à mettre en place une première étape de récupération de l'adresse (et des différents types) via l'outil d'aide à la prise de commande comme c'est proposé dans la spec... Sauf qu'ici, cela veut dire que l'appel à l'outil d'aide à la prise de commande est obligatoire et non plus une possibilité.

Donc en phase sur l'utilisation 😃
Problème, comment comprends-tu la spécification intérop' ? Personnellement, quand je la lis, on est bien sur un "Ou Exclusif". 😢
Cf :

Du coup pour moi, il faudrait effectivement faire remonter le point et acter :

soit on identifie quel(s) est(sont) le(s) type(s) approprié(s) pour les humains et ceux-ci deviennent obligatoires (niveau impacts chez tous les opérateurs, on est bien)
soit on permet de mettre ce que l'on veut, et dans ce cas :
- aucune chance que l'on arrive à afficher quelque chose d'exploitable par le technicien
- une bonne chance d'avoir des données pas forcément cohérentes les unes avec les autres.
soit on supprime ce champ (mais au départ je pense qu'il y a un besoin quand même 😄)
Bref, pas simple.

AdresseType

Quand tu dis "l'OI connait toutes les références", ce n'est pas forcément gagné pour tout le monde je pense.

Et puis pas si simple en fait car même si la spécification dit :

Charge à l’OI de prendre en compte ces remontées terrain pour la mise à jour de son référentiel

... Rien ne dit dans la spécification si un OI ne peut pas simplement refuser la maj d'adresse au motif qu'il ne supporte pas le type d'objet envoyé par l'OI avec le code d'erreur C01:

C01	Adresse inexistante dans le référentiel de l’OI

Ou ne pas prendre en compte cette adresse (alors que l'OC a quand même fait l'effort de la fournir) avec un code d'info I04 (à valider si ce code existe toujours dans la spec finale, j'ai retrouvé ça dans une vieille version).

I04	Coordonnées géographiques introuvable ou incomplètes

Du coup, est-ce à l'OI d'imposer son type, ou à l'OC ? Si l'OC fournit n'importe quoi, doit-on faire remonter quelque chose ? Pour moi, cela doit également remonter.

Note : Accessoirement, je pense qu'il y a une erreur dans la spécification sur le caractère obligatoire de AdresseType. @jlsaxione, @dlevasseuraltitude @olaissac-bt en phase ?

olaissac-bt · 2018-06-13T10:38:51Z

Sur l’interprétation de la spec interop, "Obligatoire si les autres sont vides" ne vaut pas pour "Interdit si une est remplie", ça doit être plus explicite que cela.

Dans l'autre sens effectivement je suis d'accord avec toi que si l'OC choisit de manière complètement arbitraire le format ça pourrait poser problème à l'OI, mais l'OC est censé utiliser les services d'aide à la commande exposés par l'OI pour corriger l'adresse, donc à moins d'un gros pb de QOD côté OI, l'adresse corrigée provient de l'OI. Les principes définis en interop limitent donc ce risque.

Enfin sur l'objet AdresseType j'ai regardé trop vite et en fait ce type est défini dans la spec interop mais, sauf erreur ma part, n'est utilisé nulle part (d’ailleurs il n’est pas dans le wsdl). Le service de MAJ de RO utilise un autre type ReferenceAdresseDemandeType. Mais la question reste la même sur ce dernier objet. De manière globale coté interop, je trouve qu’ils ont multiplié les types d’objets adresse sans que j’en comprenne l’intérêt réel. Dans Emut on a 3 objets : AdressePBOReponseType, AdresseType, ReferenceAdresseDemandeType. Dans l’aide à la commande 4 : ReferenceAdresseDemandeType (même nom que pour emut mais avec un contenu !=, sinon c’est pas drôle 😊), ReferenceAdresseReponseType, ReferenceAdresseDemandeSimpleType, ListeImmeubleType. Doit-on demander l'homogénéisation et la correction des incohérences coté interop ? Et là on parle que des adresses…j'en ai vu quelques autres.

dlevasseuraltitude · 2018-06-27T14:49:04Z

@aminvielledebat Peut-on merger cette branche sur le master afin de valider cette version?

jlsaxione · 2018-06-27T15:33:12Z

pour moi ok, on merge ? on attend la validation de bytel et de sfr ?

dlevasseuraltitude · 2018-06-28T08:44:22Z

Pour moi il faut merger, car on a eu une consigne en GroupeInetrop de valider une version très rapidement

olaissac-bt · 2018-06-28T08:56:55Z

Valider une version me parait avoir du sens pour que l'on puisse tous travailller sur quelque chose de concret. Pour autant, sur le côté exclusif des références d'adresse, ce n'est pas ce qui est demandé en interop et à raison, car ça risque justement de limiter l'interopérabilité. L'OC va être contraint par le format d'adresse choisi par l'OI et il est possible que ce format ne soit pas supporté par l'OC, alors qu'ils auraient pu se comprendre sur un autre format. Je ne vois pas pourquoi on imposerait cela sans validation préalable de l'interop.

aminvielledebat · 2018-06-28T21:56:31Z

Hello et désolé pour le temps de réponse.

`AdressePBOReponseType`

En phase avec toi @olaissac-bt pour le type AdressePBOReponseType (on reprend tout l'échange sur AdresseType et on transpose sur celui-là, ça marche aussi). Après tout, c'est l'OI qui possède la référence des adresses, donc il n'y a pas de raison à être exclusif sur le type retourné par l'OI.
Je fais la modif en ce sens.

`ReferenceAdresseDemandeType`

Pour le type ReferenceAdresseDemandeType, présent dans la maj de route, je suis d'accord avec toi @olaissac-bt sur le fait que l'OC doit "normalement" prendre les valeurs remontées par l'OI dans l'outil d'aide à la prise de commande.
Sauf que par définition, dans un flux interop', j'aurai plutôt tendance à dire qu'il ne faut faire confiance à personne 🤡

Deux solutions pour moi du coup :

On laisse l'OC choisir un seul type de champ d'adresse (mais de ce que je comprends, ça n'a pas l'air de te convenir @olaissac-bt)
On permet à l'OC de choisir plusieurs types de champs d'adresses (comme proposé par @dlevasseuraltitude au départ), mais on demande à définir les cas de gestion en GT si plusieurs champs sont renseignés, et si ils sont cohérents ou non (avec une gestion des priorités de type).

Dans le cas contraire, au mieux, on aura quelque chose que personne n'implémentera, au pire, quelque chose qui ne marche pas et qui perturbe nos SI.

`ReferenceAdresse` à passer en facultatif dans `MiseAJourRouteOptique`

En phase là dessus ? Je trouve ça étrange que cela soit obligatoire si on part du principe que le ws doit être simple à utiliser. Ne serait-ce pas une erreur ?

Normalisation des types adresse

Pour ce qui est de la normalisation des types en fonction des ws, je serai tenté d'aller dans ton sens, mais l'inertie des différents produits risque plus de nous causer plus de problèmes qu'autre chose (par exmple, la maj d'un xsd, entrainera la montée de version de N ws... difficile à accepter le temps que tout le monde soit d'accord)

Si vous êtes d'accord, je boucle tout ça demain.

aminvielledebat · 2018-06-28T21:57:12Z

Vote

Pour voter, on peut aussi faire ça là facilement :

Editer ce post, vous avez les droits, et mettez votre vote

	olaissac-bt	dlevasseuraltitude	aminvielledebat
`AdressePBOReponseType` à repasser en multi type	👍	👍	👍
`ReferenceAdresseDemandeType` à conserver en mono type	👎	👍	👍
`ReferenceAdresseDemandeType` à repasser en multi type mais avec RGs définies en GT	👍	👎	👍
`ReferenceAdresse` à passer en facultatif dans requête de maj	👍	👍	👍
Normalisation des champs d'adrsse	👎	👎	👎

olaissac-bt · 2018-06-29T08:05:10Z

@aminvielledebat . Merci pour la réponse. On est globalement en phase. Ça ne me dérange pas particulièrement que ReferenceAdresseDemandeType soit exclusif (d'ailleurs je pense mettre qu'une référence). Maintenant pour être homogène et maximiser l'interop je laisserai tout ouvert plutôt que tout contraint. En laissant ouvert on n’empêche personne de ne mettre qu'une seule référence alors qu'une fois fermé, ça l'est définitivement. Et si la contrainte devait être choisie, je trouve ça quand même très étonnant qu'on s'autorise à changer de notre propre chef cette règle qui a mon avis a été laissé ouverte volontairement en interop pour maximiser les cas d'usage. En mettant une contrainte on risque de rendre caduque l'utilisation de ce services dans un certain nombre de cas de figures.

Sur l'homogénéité des objets d'adresse je suis d'accord avec toi @aminvielledebat qu'homogénéiser maintenant c'est probablement trop tard. Il faut juste remonter en interop d'être plus vigilants sur les services à venir.

olaissac-bt · 2018-06-29T08:20:29Z

@aminvielledebat je n'ai pas les droits d'édition de ton post. Pour moi ce sera 👍 👎 👍 👍 👎
Quels que soient nos choix il faudra mettre à jour la doc d'interop en conséquence sinon ça promet des divergences d'interprétation entre ceux qui lisent les STI et ceux qui utilisent le wsdl (chez nous typiquement ce ne sont pas les mêmes personnes).

aminvielledebat · 2018-06-29T08:26:46Z

@olaissac-bt, je t'ai mis les droits

aminvielledebat · 2018-06-29T08:35:41Z

@dlevasseuraltitude, une petite explication sur le pourquoi tu es contre le fait de repasser les champs d'adresse en multi-type ? 😄

@olaissac-bt, en ouvrant tout, certes on facilite l'interop' d'un point de vue technique, mais on complexifie les RGs à mettre en place pour la gestion de ces données côté OI (sachant qu'elles ne sont pas encore déclarées dans la spec, et qu'il faudra qu'elles le soient).
Pour ce qui est de changer les éléments, je pense que les référents techniques peuvent être force de proposition, surtout si la question de la maintenance est mise sur la table. C'est un peu le rôle que l'on nous donne jusqu'à présent d'ailleurs.

Au final, avec la réponse d'altitude, et le fait que l'on ne comprenne pas tous de la même manière cette partie de la spec :

je vais faire un mail à Corinne pour qu'elle fasse un tour de table avec les fonctionnels.

olaissac-bt · 2018-06-29T10:04:56Z

Pour aider au consensus, ça ne me dérangerait pas de contraindre ReferenceAdresseDemandeType. Comme @aminvielledebat j'aurai pu mettre 👍 aux deux choix. Sur AdressePBOReponseType, c'est plus compliqué, car à partir de la référence fournie il faut retrouver l'adresse à afficher et avec certains types de référence, je ne saurai pas le faire facilement. Comme je l'ai déjà demandé, si cette traduction, que l'OI sait faire puisque c'est sa référence, était aussi fournie par le service, ça éviterait à tous les OC de traduire une référence d'adresse de l'OI en adresse explicite de l'OI, à ce moment-là, pourquoi pas.

dlevasseuraltitude · 2018-06-29T12:17:49Z

@aminvielledebat effectivement en relisant ce que tu avais dit sur le sujet, je me suis rendu compte que j'avais mal compris. Je pensais que tu voulais remplacer le type AdressePBOReponseType par le AdresseType, ce qui poserait problème dans les cas de ZMD. Mais si c'est juste le fait de pouvoir retourner ce que l'on veux sans le caractère exclusif je suis OK.

aminvielledebat · 2018-06-29T12:36:40Z

Merci pour le retour @dlevasseuraltitude . Non non, c'est déjà assez compliqué comme ça 🤡

Sinon j'ai envoyé un mail à Corinne, qui a forwardé au GT. J'ai repris nos différents points, et ajouté une question sur les bâtiment/escalier/étage envoyé par l'OC lors de la mise à jour.

Wait & see. Dès que j'ai une réponse, je mets à jour asap.

Note : Je peux aussi mettre la PR à dispo sur une branche du repo before-interop plutôt que sur mon fork si vous voulez faire une autre PR dessus (ou la modifier) et/ou si je suis trop long à répondre.

aminvielledebat · 2018-07-10T10:27:17Z

J'ai pris en compte les retours de notre point d'hier avec un nouveau commit.

aminvielledebat · 2018-07-10T10:28:18Z

J'ai pris en compte les retours de notre point d'hier avec un nouveau commit.

En résumé :

MiseAJourRouteOptiqueDemande :

Les champs bâtiment, escalier et étage deviennent conditionnés (en fonction du motif). Ils passent en facultatifs dans le wsdl
Ajout d'un motif de mutation "Commande HOTLINE"
Correction de deux types sur les motifs de mutation "PTO existante alors que PTO à construire dans la commande OC" et "PTO à construire alors que PTO existante dans la commande OC"
Le champ "ReferenceAdresseDemandeType" devient conditionnés (en fonction du motif). Il passe en facultatif dans le wsdl

RecherchePBOResponse :

Le type complexe "AdressePBOReponseType" est remplacé par "LocalisationPBO" (chaine de 256 caractères max)

WMaraux · 2018-07-11T09:11:13Z

emutation.wsdl

-                    <xsd:enumeration value="PTO existante alors que PTO à construire à la commande OC"/>
-                    <xsd:enumeration value="PTO à construire alors que PTO existante à la commande OC"/>
+                    <xsd:enumeration value="PTO existante alors que PTO à construire dans la commande OC"/>
+                    <xsd:enumeration value="PTO à construire alors que PTO existante dans la commande OC"/>


Dans la spec, je vois bien "à la commande OC". Je suis d'accord que "dans" est mieux mais il faut faire évoluer la SPEC. Je préviens Nicolas.

WMaraux · 2018-07-11T09:11:59Z

emutation.wsdl

                    <xsd:enumeration value="Référence PTO erronée"/>
+                    <xsd:enumeration value="commande HOTLINE"/>


Salut Alexis, peut on mettre une majuscule a commande ? "Commande HOTLINE"

Je fais ça

WMaraux · 2018-07-11T09:13:06Z

emutation.wsdl

+                    <xsd:minLength value="0"/>
+                    <xsd:maxLength value="256"/>
+                </xsd:restriction>
+            </xsd:simpleType>


RAS sur la modification du Type. Je pense que ce sera plus simple de procéder avec un string. Je pense néanmoins qu'il serait judicieux de le grossir ca risque d'être léger sinon.

en phase aussi... je trouve que le 1.3 est un peu léger avec 256 caractères.

Je suis monté à 2048, car au dernier GT Accès avec l'APNF sur la plateforme de tests, il avait été acté que le champ LocalisationPBO du 1.3 devait passer à 2048 caractères.

WMaraux · 2018-07-11T09:14:20Z

emutation.wsdl

@@ -222,7 +223,7 @@
                        <xsd:element name="Entete" type="tns:EnteteReponseType"/>
                        <xsd:element name="CodeRetour" type="tns:CodeRetourType"/>
                        <xsd:element name="PboType" type="tns:PboType"/>
-                        <xsd:element name="Fibre" type="tns:ListeFibreType"/>
+                        <xsd:element name="Fibres" type="tns:ListeFibresType"/>


Modif logique mais a ne pas oublier de reporter chez nous.

Oui c'est une typo que j'ai vu dans le wsdl existant. Cela donnait quelque chose de bizarre de type

<Fibre><Fibres></Fibres><Fibre>

WMaraux · 2018-07-11T09:16:23Z

emutation.wsdl

+                        <xsd:element minOccurs="0" name="ReferenceAdresse" type="tns:ReferenceAdresseDemandeType"/>
+                        <xsd:element minOccurs="0" name="Batiment" type="tns:BatimentType"/>
+                        <xsd:element minOccurs="0" name="Escalier" type="tns:EscalierType"/>
+                        <xsd:element minOccurs="0" name="Etage" type="tns:EtageType"/>


OK pour la mise en facultatif de ces champs.

WMaraux · 2018-07-11T09:16:31Z

emutation.wsdl

@@ -299,21 +300,12 @@
                <xsd:sequence>
                    <xsd:element name="ReferencePM"  type="tns:ReferencePMType"/>
                    <xsd:element name="ReferencePBO" type="tns:ReferencePBOType"/>
-                    <xsd:element name="AdressePBO" type="tns:AdressePBOReponseType"/>
+                    <xsd:element name="LocalisationPBO" type="tns:LocalisationPBOType"/>


WMaraux · 2018-07-11T09:19:39Z

emutation.wsdl

                    <xsd:element minOccurs="0" name="ReferenceHexacle" type="tns:ReferenceHexacleType"/>
                    <xsd:element minOccurs="0" name="ReferenceRivoli" type="tns:ReferenceRivoliType"/>
                    <xsd:element minOccurs="0" name="ReferenceGeographique" type="tns:CoordonneesGeographiquesType"/>
                    <xsd:element minOccurs="0" name="ReferenceHexacleVoie" type="tns:ReferenceHexacleVoieType"/>
                    <xsd:element minOccurs="0" name="IdentifiantImmeuble" type="tns:IdentifiantImmeubleType"/>
-                </xsd:choice>
+                </xsd:sequence>


Le passage de "choice" à "séquence" permet de faire les contrôles en entonnoir c'est bien ca ? Il faut donc surement revoir l'ordre pour moi ca fait : Immeuble => Hexaclé / Rivoli => coordonnées.

Je serai bien resté sur le "choice", car pour moi, même si entonnoir il y a, la première valeur renseignée sur le haut de l'entonnoir et OK est prise en compte, les autres sont ignorées (et si une valeur avant est KO on rejette tout), mais je n'ai pas réussi à faire passer l'idée 😢

On est donc resté sur le fait de pouvoir renseigner plusieurs champs, même si je ne vois pas le cas d'usage.... Peut être que Nicolas y verra plus clair.

Sinon pour l'histoire d'ordre dans l'entonnoir, pour moi c'est de l'applicatif pure, mais rien n'empêche effectivement de changer l'ordre de description pour être plus clair.

MiseAJourRouteOptiqueDemande : - Les champs bâtiment, escalier et étage deviennent conditionnés (en fonction du motif). Ils passent en facultatifs dans le wsdl - Ajout d'un motif de mutation "Commande HOTLINE" - Correction de deux types sur les motifs de mutation "PTO existante alors que PTO à construire dans la commande OC" et "PTO à construire alors que PTO existante dans la commande OC" - Le champ "ReferenceAdresseDemandeType" devient conditionnés (en fonction du motif). Il passe en facultatif dans le wsdl RecherchePBOResponse : - Le type complexe "AdressePBOReponseType" est remplacé par "LocalisationPBO" (chaine de 256 caractères max)

olaissac-bt · 2018-07-12T07:49:59Z

On merge ?

aminvielledebat · 2018-07-12T07:55:00Z

@olaissac-bt, donne ton accord dans l'outil :-)

A faire via :

Après, ça pourrait être bien que @dlevasseuraltitude aussi :-)

…hamp LocalisationPBO

aminvielledebat · 2018-07-12T14:34:54Z

@olaissac-bt. Ton GO avait sauté suite à la suppression de la StructureVerticalePBO. J'ai tout de même mergé comme nous étions d'accord.

jlsaxione · 2018-07-12T14:38:13Z

merci ;)

olaissac-bt · 2018-07-12T14:40:41Z

Pas de soucis

aminvielledebat force-pushed the spec_compliance branch from 344704b to 63a4b2e Compare June 4, 2018 09:25

aminvielledebat mentioned this pull request Jun 4, 2018

Proposition de mise à jour du wsdl #12

Merged

aminvielledebat force-pushed the spec_compliance branch 8 times, most recently from 441ad74 to ce706d8 Compare June 4, 2018 22:41

aminvielledebat force-pushed the spec_compliance branch from ce706d8 to 09f747d Compare June 4, 2018 22:59

Mise en conformité du wsdl avec la spec interop :

55e61cb

- Ajout de contraintes - Mise en conformité des contraintes - Respect des séquences

aminvielledebat force-pushed the spec_compliance branch from 09f747d to 55e61cb Compare June 4, 2018 23:05

aminvielledebat changed the title ~~WIP : Mise en conformité du wsdl avec la spec interop~~ Mise en conformité du wsdl avec la spec interop Jun 5, 2018

jlsaxione previously approved these changes Jun 7, 2018

View reviewed changes

aminvielledebat dismissed jlsaxione’s stale review via 0a1a99e July 10, 2018 10:26

WMaraux reviewed Jul 11, 2018

View reviewed changes

aminvielledebat force-pushed the spec_compliance branch from 0a1a99e to 9fae456 Compare July 11, 2018 15:53

olaissac-bt previously approved these changes Jul 12, 2018

View reviewed changes

Suppression du champ StructurePBO qui n'est plus nécessaire avec le c…

28e9b49

…hamp LocalisationPBO

aminvielledebat dismissed olaissac-bt’s stale review via 28e9b49 July 12, 2018 13:39

aminvielledebat force-pushed the spec_compliance branch from 6a3c699 to 28e9b49 Compare July 12, 2018 13:39

WMaraux approved these changes Jul 12, 2018

View reviewed changes

aminvielledebat merged commit 822e5da into before-interop:master Jul 12, 2018

		<xsd:enumeration value="Référence PTO erronée"/>
		<xsd:enumeration value="commande HOTLINE"/>

Mise en conformité du wsdl avec la spec interop #21

Mise en conformité du wsdl avec la spec interop #21

Conversation

aminvielledebat commented Jun 4, 2018 • edited Loading

aminvielledebat commented Jun 4, 2018 • edited Loading

aminvielledebat commented Jun 4, 2018

jlsaxione commented Jun 7, 2018

aminvielledebat commented Jun 7, 2018

olaissac-bt commented Jun 12, 2018

aminvielledebat commented Jun 12, 2018

AdressePBOReponseType

AdresseType

olaissac-bt commented Jun 13, 2018 • edited Loading

dlevasseuraltitude commented Jun 27, 2018

jlsaxione commented Jun 27, 2018

dlevasseuraltitude commented Jun 28, 2018

olaissac-bt commented Jun 28, 2018

aminvielledebat commented Jun 28, 2018

AdressePBOReponseType

ReferenceAdresseDemandeType

ReferenceAdresse à passer en facultatif dans MiseAJourRouteOptique

Normalisation des types adresse

aminvielledebat commented Jun 28, 2018 • edited by dlevasseuraltitude Loading

Vote

olaissac-bt commented Jun 29, 2018

olaissac-bt commented Jun 29, 2018 • edited Loading

aminvielledebat commented Jun 29, 2018

aminvielledebat commented Jun 29, 2018

olaissac-bt commented Jun 29, 2018

dlevasseuraltitude commented Jun 29, 2018

aminvielledebat commented Jun 29, 2018

aminvielledebat commented Jul 10, 2018

aminvielledebat commented Jul 10, 2018

MiseAJourRouteOptiqueDemande :

RecherchePBOResponse :

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aminvielledebat Jul 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

olaissac-bt commented Jul 12, 2018

aminvielledebat commented Jul 12, 2018

aminvielledebat commented Jul 12, 2018

jlsaxione commented Jul 12, 2018

olaissac-bt commented Jul 12, 2018

aminvielledebat commented Jun 4, 2018 •

edited

Loading

aminvielledebat commented Jun 4, 2018 •

edited

Loading

olaissac-bt commented Jun 13, 2018 •

edited

Loading

`AdressePBOReponseType`

`ReferenceAdresseDemandeType`

`ReferenceAdresse` à passer en facultatif dans `MiseAJourRouteOptique`

aminvielledebat commented Jun 28, 2018 •

edited by dlevasseuraltitude

Loading

olaissac-bt commented Jun 29, 2018 •

edited

Loading

aminvielledebat Jul 11, 2018 •

edited

Loading