OVH Community, votre nouvel espace communautaire.

Fermeture prochaine de SoAPI


esolution
09/09/2016, 03h59
D'accord, mais comment fait-on lorsque l'on a des applications développées en C# qui utilise SoAPI pour l'envoi de SMS et pour faire du Click2Call ? Quand aura-t-on un wrapper C# ?

s.berry
26/08/2016, 16h57
J'ai eu des réponses par mail (domains@ml.ovh.net) !

je les mets ici pour ceux que ça intéresserait

Actuellement, l'API OVH ne vous permet pas d'effectuer un changement de propriétaire. Mais ce sera bientôt disponible.

Pour effectuer une mise à jour des informations du propriétaire, c'est comme vous l'avez sans doute fait:
- On récupère l'id du contact owner via la requête GET /domain/{serviceName}
- On modifie le contact via PUT /me/contact/{contactId}

L'api POST /domain/{serviceName}/changeContact vous permet de changer le nicadmin/nictech/nicbilling de votre service OVH.
Suivant le TLD de votre domain, alors cela entraîne alors un changement dans le whois.
- - - Mise à jour - - -

Pour information j'attends toujours des informations sur les mxPlan :

https://forum.ovh.com/showthread.php...l=1#post669070
- Commander tout court, des impossibilités de commander un mxplan supérieur ou de retrouver l'offre actuelle. C'est dans la TODO des 8 semaines et c'est une des priorités de cette période. Je pense que c'est ton problème s.berry. Je pensais pouvoir faire un simple patch la dernière fois mais le problème est plus profond.
ça ne semble pas fonctionnel même si c'était "dans la TODO des 8 semaines" en avril...
Est-ce vraiment le cas?

Merci

s.berry
26/08/2016, 15h16
C'est encore moi

Je vois bien que vous ne répondez pas mai je persévère, j'aimerais bien que l'on me réponde

D'ailleurs je viens de trouver une fonction "POST /domain/{serviceName}/changeContact" est-ce que ça permet de changer les contacts au niveau du whois?

Sinon j'ai une autre question !
En attendant d'avoir une réponse je suis partie sur le fait qu'il y a un id de contact créé à la création du domaine et que je mets à jour celui-ci (whoisOwner GET /domain/{serviceName}).
Mon traitement fonctionne bien, quand je fais un whois de mon domaine le "registrant" contient bien les données que j'ai renseigné via l'API.
MAIS les contacts "Admin" et "Tech" sont ceux du compte OVH... Comment puis-je les modifier avec les données du contact (comme le "registrant" aujourd'hui)?

Merci de prendre le temps de me répondre

s.berry
24/08/2016, 10h13
Citation Envoyé par s.berry
Autre question !

d'après ce que j'ai compris, quand on crée un domaine, un contact est automatiquement créé avec un identifiant de contact récupérable via la donnée whoisOwner du GET /domain/{serviceName}. Mais peut-on changer cet identifiant ? Pour mettre l'identifiant d'un contact existant à la place?

Merci
Allez, s'il-vous plaît, j'ai besoin de l'info pour faire mon dev...

Soit je fais un POST pour le nouveau contact, soit je fais un PUT pour mettre à jour l'existant... Et si un contact est mis à jour dans mon interface il faut que je le répercute sur tous les ids créés ou un seul selon votre réponse. L'impact est aussi sur la structure de ma base de données...

J'ai envoyé un mail à domains@ml.ovh.net mais pas de réponse non plus...

s.berry
22/08/2016, 16h44
Autre question !

d'après ce que j'ai compris, quand on crée un domaine, un contact est automatiquement créé avec un identifiant de contact récupérable via la donnée whoisOwner du GET /domain/{serviceName}. Mais peut-on changer cet identifiant ? Pour mettre l'identifiant d'un contact existant à la place?

Merci

s.berry
22/08/2016, 10h56
Bonjour,

J'ai une question sur la gestion des contacts (/me/contact) : il y a bien GET, POST et PUT mais pas de DELETE, pourquoi ?
Est-ce amené à changer?

Sinon je suis encore et toujours en attente d'informations sur ce qui a été réalisé de ce post : https://forum.ovh.com/showthread.php...l=1#post669070

- Commander tout court, des impossibilités de commander un mxplan supérieur ou de retrouver l'offre actuelle. C'est dans la TODO des 8 semaines et c'est une des priorités de cette période. Je pense que c'est ton problème s.berry. Je pensais pouvoir faire un simple patch la dernière fois mais le problème est plus profond.
c'était "dans la TO-DO des 8 semaines" en avril quand même...

frame
10/08/2016, 16h31
Bonjour,
est-ce que vous avez touche la funcion resellerDomainRenew de l'interface SOAP?

L'appelle marche mais votre system ne fait par le renouvement du domain.

Merci
Frame

Krenos
08/08/2016, 14h58
Bonjour,

votre service d'assistance m'a redirigé vers le forum.
Nous utilisons quotidiennement votre ancienne API (SoAPI) afin d'automatiser l'achat et la configuration de nos domaines. Je travaille actuellement à la migration de nos scripts vers votre nouvelle API v6.

En cela la page https://www.ovh.com/fr/soapi-to-apiv6-migration/ m'a été utile.

Auparavant la méthode method=resellerDomainCreate (https://www.ovh.com/soapi/fr/?method...erDomainCreate) permettait de définir les DNS primaires et secondaires. Désormais il ne me semble plus que ce soit possible via la configuration de l'item. Est-ce une fois que le domaine est commandé que nous devons le configurer ou pouvons nous le faire avant de faire le checkout ?

Il me semble en effet est possible de configurer un DNS de cette manière lors de la commande mais il n'est pas possible d'en indiquer deux :
$config = $this->api_ovh->post('/order/cart/'.$id_cart.'/item/'.$item["itemId"].'/configuration', array(
'label' => 'DNS',
'value' => $dns_primary
));

Merci par avance,

marc.audefroy
29/07/2016, 09h00
Pas de date de prévision pour l'instant mais c'est dans le backlog.
On vous tiens au courant dès qu'on en a une.

Un moyen de contourner le problème en attendant l'api : activer l'autorenew via PUT /domain/{serviceName}/serviceInfos.
Par contre il faudra faire attention à avoir un moyen de paiement par défault valide via le manager.

lea69
29/07/2016, 08h40
Merci pour ces informations.

A-t-on une prévision pour la sortie de l'API de renew ?

s.berry
27/07/2016, 16h00
Merci ksio

Je suis en vacances mais je relance quand même OVH car si on se relâche un peu ils en profitent pour nous oublier !

Bon courage / bonnes vacances également !

marc.audefroy
27/07/2016, 10h57
Bonjour,

Quelques news concernant l'API domains ;

Create, Transfert, Alldom

L'ApiV6 est en cours de finalisation, n'hésitez pas à nous transmettre votre feedback. Vous trouverez tout ça ici : https://api.ovh.com/console/
Un rapide "Getting Starting" pour faire une commande de create/transfert/alldom

  1. On créé un panier via POST /order/cart
  2. On récupére la liste des tlds disponibles via GET /domain/data/extension

  3. [CREATE] On récupère les infos du domain voulu via GET /order/cart/{cartId}/domain
    [TRANSFERT] On récupère les infos du domain voulu via GET /order/cart/{cartId}/domainTransfer
    [ALLDOM] On récupère les infos du domain voulu via GET /order/cart/{cartId}/domainpacks
  4. On ajoute les produits voulu dans le panier via les méthodes POST de ces mêmes URL.
  5. On récupère les configurations requises pour ces produits via /order/cart/{cartId}/item/{itemId}/requiredConfiguration et /domain/rules
  6. On renseigne ces configurations via /order/cart/{cartId}/item/{itemId}/configuration
  7. Différentes possibilités :
    a. GET /order/cart/{cartId}/summary => Pas de vérification, on a juste le prix de la commande
    b. GET /order/cart/{cartId}/checkout => On procède à toute les vérifications sans créer le bon de commande, cela permet de s'assurer qu'on a bien remplis toutes les configurations requises.
    c. POST /order/cart/{cartId}/checkout => On procède à toutes les véritications et on créé le bon de commande


Vous trouverez ici également des examples ici https://github.com/ovh/order-cart-examples.
N'hésitez pas à utiliser les ML domains@ml.ovh.net et api@ml.ovh.net pour plus d'informations/aide.

Trade
Concernant le changement de propriétaire d'un nom de domaine (trade), l'api est en cours de développement et devrait arriver durant le mois de Août.

Renew

Concernant le renouvellement d'un nom de domaine, celui-ci va bientôt devenir automatique. Ce sera activable/desactivable via une API.
On prépare également une api de renew.


Marc - OVH
Team Domains

ksio
26/07/2016, 11h31
Je me permet de relancer, dans ce cas, moi aussi...

- Renouvellement de domaines
- Transfert de domaine

Et je confirme moi aussi, s'il en était besoin, le désarroi dans lequel vous laissez vos clients, sur des sujets comme l'API, comme le Manager, etc.

(Bon courage Léa et Sarah, et bonnes vacances, peut-être)

lea69
22/07/2016, 15h11
Merci s.berry pour le soutient, c’est vraiment appréciable de voir qu'on est pas la seule à être mis en galère par OVH. C’est déprimant on a vraiment l'impression d’être laisser pour compte.

OVH que faîtes-vous pour le développement de votre API, est-ce un projet toujours en cours ? Quelle est la roadmap actuelle ? informez-nous au minimum. À défaut d'avoir des appels API fonctionnel on pourrait avoir un minimum de retour d’information. Vous bloquez des projets R&D complet !

Merci.

s.berry
22/07/2016, 15h01
Bonjour Vincent,

Est-ce qu'il y a du nouveau ? Je sais que je n'ai pas été aussi assidue ces derniers jours... Mais je tiens quand même à ma réponse, n'en doutez pas!

@Léa : Il va falloir les relancer si vous voulez une réponse, sinon vous passerez entre les mailles du filet! (bon, je sais que c'est un peu moi qui vous ai piqué le tour de parole, je m'en excuse... c'est déjà arrivé par le passé à d'autres alors j'ai essayé d'attirer l'attention sur votre post mais ça ne semble pas fonctionner...)

s.berry
19/07/2016, 10h14
Bonjour Vincent

Je parle de ce post-ci : https://forum.ovh.com/showthread.php...l=1#post669070

Des réponses en juillet, c'est la folie !

P.S. : N'oubliez pas Léa aussi : https://forum.ovh.com/showthread.php...l=1#post674402

Merciiii

vcasse
19/07/2016, 10h07
Citation Envoyé par s.berry
Bonjour OVH!

Comment ça va depuis hier?
J'espère que tout le monde n'est pas en vacances et qu'il y aura des réponses...
Moi je vais continuer à venir en tout cas

A demain !
Salut s.berry,

Peux tu m'indiquer de quel post tu parles quand tu cites la todo des 8 semaines ?
Je vais essayer de relancer les bonnes personnes pour que tu aies des réponses, même en juillet

Cordialement,
Vincent

s.berry
19/07/2016, 08h42
Bonjour OVH!

Comment ça va depuis hier?
J'espère que tout le monde n'est pas en vacances et qu'il y aura des réponses...
Moi je vais continuer à venir en tout cas

A demain !

s.berry
18/07/2016, 09h08
Bonjour OVH

Je me demandais si ce qui était dans "la TODO des 8 semaines" en avril a été réalisé?
Vous pouvez nous faire un petit compte-rendu?

N'oubliez pas de répondre à Léa aussi !

En tout cas, c'est bien si au moins ce sujet empêche au moins à d'autres de se retrouver avec les mêmes problèmes...

Merci!

angelius720
15/07/2016, 12h31
Et dire que ma société était sur le point d’implémenter l'api d'ovh pour un gros projet !

Ouf, je suis bien content d'avoir decouvert ce sujet ... je vois qu'il manque une tonnes de call api indispensables a notre projet ... et le "serieux" de l'equipe ovh ....

Pas de gestion des renouvellement de domaine, pas de transfert, pas de liste des prix des extensions .... LA BLAGUE !!!

lea69
06/07/2016, 15h06
Bonjour à tous,

Aux dernières nouvelles sur ce fil j’ai trouvé ceci :

* Commande .FR: c'est disponible
* Renouvellement de domaine: toujours en scheduling, pas d'ETA pour le moment :/
* Transfert de domaine: en cours de développement, on parle en semaine, pas en mois
(probablement une BETA sur une portion réduite de TLD dans un premier temps, si vous êtes intéressé pour nous envoyer des feedbacks en direct, contactez-moi ! )
Avez-vous des nouvelle concernant le renouvellement de nom de domaine, j’ai un développement en attente.
Pourriez-vous m'informer ?

s.berry
12/05/2016, 09h35
Bonjour,

Oups, effectivement je n'avais pas vu cela... excusez-moi
Et merci

MaxV
03/05/2016, 15h50
Citation Envoyé par MaxV
Plus précisément sur la commande, nous avons eu plusieurs problèmes:
- Commander avec un domaine externe à OVH : Nous voulions faire la même procédure que dans le manager V3 mais nous nous sommes rendu compte que la sécurité n'était pas assez élevé et donc nous avons du repensé le système. La solution est en cours de développement et devrait sortir dans quelques semaines.
- Commander tout court, des impossibilités de commander un mxplan supérieur ou de retrouver l'offre actuelle. C'est dans la TODO des 8 semaines et c'est une des priorités de cette période. Je pense que c'est ton problème s.berry. Je pensais pouvoir faire un simple patch la dernière fois mais le problème est plus profond.
ça réponds pas a tes question ça ? ^^

s.berry
02/05/2016, 15h04
Merci pour ces infos sur votre travail mais ça ne change rien au fait que personne ne répond à mes questions...

Elles sont ici.
Merci de prendre un peu de votre temps pour ça

MaxV
28/04/2016, 18h41
Citation Envoyé par ksio
J'admire la ténacité avec laquelle vous tentez d'avoir une réponse du support OVH.

Moi je me dit que le plus probable c'est qu'ils doivent avoir une panne d'Internet depuis 1 mois, et qu'ils n'ont du coup pas vu nos questions. Parce que sinon, on va finir par prendre cela pour du dédain d'un hébergeur pour ses clients, et ça ne peut pas être cela, hein... Si ?
En effet ce n'est pas cela

Je suis désolé d'arriver aussi tard :/ J'ai déserté un peu le forum ces dernières semaines et ce n'était pas pour des vacances
Cela fait 4-5 semaines (j'ai perdu la notion du temps au bout d'un moment ) que nous travaillons comme des fous et c'est avec les touches du clavier collé sur le front que je vous réponds

Je vous explique ce que l'on a fait/se que l'on fait, en ce moment, nous l'avons exposé sur la mailinglist email@ml.ovh.net:

Nous avions une gros urgence, étant donné la croissance de l’infra et le nombre de comptes hébergés, il fallait rendre disponible le service multi datacenter.


Première phase : rendre le service modulaire :

Le projet baptisé « MailProxy » nous a paru évident:

- Le but étant d’avoir une infrastructure devant n’importe quel service email d’OVH (Exchange, HostedEmail, Mxplan ou email avec hébergement) permettant d’avoir un seul point de réception des emails (champs MX de votre zone DNS) et un seul point de prétraitement des emails. Grâce a cela, nous pouvons détecter, tagguer et/ou supprimer des virus, spams ou emails commerciaux, vérifier et gérer le DKIM ou le SPF, tout ceci étant parametrable par adresse email individuelle. Le point de réception unique apporte aussi la possibilité d’avoir des comptes emails d’un même domaine sur plusieurs services emails OVH. Hormis ces gains de fonctionnalités, MailProxy est la aussi afin d'assurer une haute disponibilité du service, permettant ainsi de garantir la réception des emails vers nos infrastructures même si le service final est perturbé. La question est quand ? Pour Exchange et HostedEmail la 1ère version est déjà en place, il reste un peu de travail pour rendre le DKIM et SPF totalement opérationnels et pour les MXPlan et les emails avec hébergement c’est pour bientôt, la masse de donnée est impressionnante et nous sommes en train de la synchroniser.

« Lemmy » c’est quoi ça ?:

- « Lemmy » c’est encore une nouvelle infrastructure mais cette fois pour l’envoi et la consultation des emails. Comme « MailProxy », elle se place devant des services. Elle gère les connexions SMTP et IMAP dont vous avez besoin pour consulter et envoyer des emails (ce qui est demandé au paramétrage de vos comptes emails). Son but est d’apporter un point d’entrée commun pour ces types de connexions, elle va notamment bénéficier aux Mxplan, emails avec hébergement et au webmail. Par la suite, elle sera étendue à d’autres services ayant ce besoin. Le gain en tant qu’utilisateur ne sera pas visible dans l'immédiat mais cela évitera d’avoir différents webmails en fonction des services et d’apporter une gestion des paramètres d’envoi par adresse email. La première version de Lemmy est en production actuellement.


Deuxième phase, place aux jeunes :

L’ACE c’est fini, IPLB est là:

- La conséquence de ces deux nouvelles infrastructures est que l’ACE en frontend du service email (Mxplan, email avec hébergement) devient obsolète. L’ACE sert actuellement au LoadBalancing sur nos serveurs pour la réception et la soumission des emails, ce matériel est en fin de vie. Le frontend sera assuré par MailProxy et Lemmy, utilisant le nouveau système de LoadBalancing OVH, IPLB.


Pour résumé, on doit avoir reinstallé ~50% de nos serveurs

Dès que le service est multi-datacentre, l'urgence est passé et nous avons prévu de ~8 semaines de bugfix /petites améliorations.

Plus précisément sur la commande, nous avons eu plusieurs problèmes:
- Commander avec un domaine externe à OVH : Nous voulions faire la même procédure que dans le manager V3 mais nous nous sommes rendu compte que la sécurité n'était pas assez élevé et donc nous avons du repensé le système. La solution est en cours de développement et devrait sortir dans quelques semaines.
- Commander tout court, des impossibilités de commander un mxplan supérieur ou de retrouver l'offre actuelle. C'est dans la TODO des 8 semaines et c'est une des priorités de cette période. Je pense que c'est ton problème s.berry. Je pensais pouvoir faire un simple patch la dernière fois mais le problème est plus profond.


J'espère que ça vous rassure un peu et je suis désolé encore pour ce silence, je suis plus assidu à la mailinglist (email@ml.ovh.net) et nous avons des discussions qui peuvent vous intéresser comme le changement/amélioration du webmail

Je laisse la page du forum ouvert sur mon navigateur pour penser venir tous les jours

Bonne soirée,

ksio
28/04/2016, 12h11
J'admire la ténacité avec laquelle vous tentez d'avoir une réponse du support OVH.

Moi je me dit que le plus probable c'est qu'ils doivent avoir une panne d'Internet depuis 1 mois, et qu'ils n'ont du coup pas vu nos questions. Parce que sinon, on va finir par prendre cela pour du dédain d'un hébergeur pour ses clients, et ça ne peut pas être cela, hein... Si ?

s.berry
28/04/2016, 08h36
Oui?
Non?
Peut-être ?
Jamais?

s.berry
27/04/2016, 08h36
Bonjour

des nouvelles pour mes questions ? (https://forum.ovh.com/showthread.php...l=1#post667543)

ksio
21/04/2016, 16h02
Moi je revient a peu près tous jours pour voir si il y a une réponse, mais il faut être plus assidu qu'un jeune homme essayant de séduire une jolie fille pour avoir une chance d'avoir ladite interaction.

Quand à avoir une réponse, je crois qu'on a été friendzonés, pour le coup. On espère toujours, mais en vain.

s.berry
21/04/2016, 15h43
Il faut flooder pour avoir une interaction! Harceler, jour après jour et promettre de venir le lendemain ;p

Mais ça c'est juste pour une interaction, pas pour une réponse...
Je n'ai pas encore trouvé pour avoir une réponse

pizzapp
21/04/2016, 15h17
Sarah, au moins vous avez une interaction...

Moi à priori je suis transparent !!!
C'est n'importe quoi.

s.berry
21/04/2016, 08h47
Diiiiiiiites ?

Elles en sont où mes questions?
y'a quelqu'un qui bosse dessus au moins?

s.berry
19/04/2016, 15h23
Okay...

Pour info, il y a 2 questions..
Se référer à ce poste : https://forum.ovh.com/showthread.php...l=1#post667543

Merci

vcasse
19/04/2016, 15h01
Bonjour Sarah,

Je ne peux pas te répondre sur cette partie là, mais j'ai transmis ta question à l'équipe concernée !

Cordialement,
Vincent

s.berry
19/04/2016, 14h29
Je réessaye plus tôt dans la journée au cas où

Bonjour,

pouvez-vous répondre à mes questions posées ici depuis le 30/03 ?

Merci...
(demain je poste avant 9h!)
ça va peut-être être considéré comme du flood à force?
Mais bon, j'ai besoin de réponses...

s.berry
18/04/2016, 17h33
Bonjour,

pouvez-vous répondre à mes questions posées ici depuis le 30/03 ?

Merci...

s.berry
15/04/2016, 15h09
Nan mais ça doit pas être le même service...
Entre ceux qui produisent le code et ceux qui nous répondent je veux dire... Pour mes questions c'est souvent transmis à d'autres services apparemment..
C'est la dernière réponse que j'ai eu le 30 mars d'ailleurs...

Depuis rien. Alors que j'ai posé une nouvelle question depuis! (et 3 messages de relance aussi)

ksio
15/04/2016, 14h53
Lundi y'avait bien encore quelqu'un qui nous rappelait les services qui allait fermer.

Donc à moins que c'était la femme de ménage qui passait par la et voyant un ordinateur allumé s'est amusée avec nos nerfs, je pense que y'a surement encore une personne ou deux qui bossent dans les bureaux, mais (peut être que) nous ne sommes pas la priorité.

s.berry
15/04/2016, 14h44
Oui ;(

Avec un peu de chance, en postant ici on flood la boîte mail d'un mec en vacances..

ksio
15/04/2016, 14h12
Les dernières réponses datent c'est vrai...

Ne restent plus que nous, pauvres utilisateurs d'une solution technique inaboutie chez un hébergeur sourd à nos suppliques.

s.berry
15/04/2016, 14h01
Hello Hello Hello...

Est-ce qu'il y a encore des gens qui répondent à ce topic ?

Ceci est mon 42ème message sur le forum d'ovh, 42ème message sur ce sujet en fait, c'est un peu triste... et c'est dommage qu'il soit dédié à une relance u_u...

répondez-moi s'il-vous-plaîiiiiiiiiit...

pizzapp
15/04/2016, 13h10
Bonjour Romain,

Je suis toujours sans nouvelle. De plus maintenant, je suis bloqué. Les appels soapi ne marchent plus sur VoicemailMessagesRemoteUpload…

@romain.beuque

s.berry
13/04/2016, 17h03
Y'a quelqu'uuuuun ?

Non?

pizzapp
12/04/2016, 19h00
Bonjour,

Aujourd'hui j'ai des erreurs sur mes appels soapi sur telephony VoicemailMessagesRemoteUpload.
Depuis plus de 3 MOIS j'attends une réponse de votre part pour savoir ce qui va se passer sur cet élément qu’on utilise tous les jours? (informations contradictoires entre ce post du forum et la page du site qui a évolué ) On en est où ? On fait quoi ?

UNE RÉPONSE SVP !!!

(voir mes posts depuis 3 mois pour plus de détails).

s.berry
12/04/2016, 14h34
Bonjour...

Vous pouvez me répondre s'il vous plaiiiiiit ...?

Citation Envoyé par s.berry
Je tente une relance (la 3ème si je me souviens bien!)

Bonjour

J'aimerais savoir où vous en êtes concernant le webservice de création de mxPlan ?
J'ai une réunion de planification dans quelques jours et j'aimerais savoir si je peux y placer quelques tâches là-dessus?

Merci!
Citation Envoyé par s.berry
Bonjour,

j'avais posté cette question en janvier, je me trouve de nouveau confrontée au même besoin ;
Est-ce qu'il y a un moyen de savoir de quelle offre MxPlan (5, 25, 100, ...) un domaine dispose afin d'afficher un quota et proposer de passer à l'offre supérieure ?
Merci.

J'avais eu cette réponse à l'époque mais je n'ai pas eu d'infos par la suite et je ne trouve pas dans la doc...
"Citation Envoyé par MaxV
Bonjour,

Je suis en train de bosser dessus. Je fais ça au plus vite.
Si besoin, le support (1007) peut le faire à la main en attendant.
"

(c'est pour un check auto donc je ne peux pas passer par le support bien évidemment)

Est-ce que quelqu'un en sait plus?

Par ailleurs la création de MxPlan semble ne toujours pas fonctionner... Est-ce que vous avez une idée de la progression du sujet?

Merci..
J'espère que vous pourrez me répondre rapidement...

ksio
12/04/2016, 13h43
A noter qu'aujourd'hui la fonction resellerDomainRenew en SoAPI ne semble pas fonctionner.

J'espere que rien n'a été coupé chez vous !

frame
11/04/2016, 16h45
Sans le resellerDomainRenew, je continuera a utilizer le functionalite Account.

S'est pas un bonne idee de quitter le service "interdipendentes" ou qu'on utilize dans notre workflow, en maniere graduelle.

Pour moi, tout ou rien. J'ai besoin de resellerDomaiRenew pout completer mon workflow, et je suis contre des solution hibride (SOAP+REST)/

ksio
11/04/2016, 16h30
Bonjour,

Peut-on avoir des nouvelles de resellerDomainRenew ?

Merci

Edouard
11/04/2016, 16h16
Bonjour, comme annoncé, cloturons les sections de SOAPi.

voici le récapitulatif:

Account En cours de fermeture
Billing À définir
Dedicated À définir
Domains À définir
Emails En cours de fermeture
Hosting En cours de fermeture
Infrastructure En cours de fermeture
ManagedServices En cours de fermeture
Misc À définir
NIC En cours de fermeture
Notepad Fermé
Order En cours de fermeture
Prepaid En cours de fermeture
Reseller À définir
RPS Fermé
Service À définir
Session À définir
Sqlprive En cours de fermeture
Support Fermé
Telephony À définir
Ticket Fermé
http://www.ovh.com/soapi/fr/

Edouard
11/04/2016, 16h16
Bonjour, comme annoncé, cloturons les sections de SOAPi.

voici le récapitulatif:

Account En cours de fermeture
Billing À définir
Dedicated À définir
Domains À définir
Emails En cours de fermeture
Hosting En cours de fermeture
Infrastructure En cours de fermeture
ManagedServices En cours de fermeture
Misc À définir
NIC En cours de fermeture
Notepad Fermé
Order En cours de fermeture
Prepaid En cours de fermeture
Reseller À définir
RPS Fermé
Service À définir
Session À définir
Sqlprive En cours de fermeture
Support Fermé
Telephony À définir
Ticket Fermé
http://www.ovh.com/soapi/fr/

s.berry
06/04/2016, 15h43
Bonjour,

j'avais posté cette question en janvier, je me trouve de nouveau confrontée au même besoin ;
Est-ce qu'il y a un moyen de savoir de quelle offre MxPlan (5, 25, 100, ...) un domaine dispose afin d'afficher un quota et proposer de passer à l'offre supérieure ?
Merci.

J'avais eu cette réponse à l'époque mais je n'ai pas eu d'infos par la suite et je ne trouve pas dans la doc...

Citation Envoyé par MaxV
Bonjour,

Je suis en train de bosser dessus. Je fais ça au plus vite.
Si besoin, le support (1007) peut le faire à la main en attendant.
(c'est pour un check auto donc je ne peux pas passer par le support bien évidemment)

Est-ce que quelqu'un en sait plus?

Par ailleurs la création de MxPlan semble ne toujours pas fonctionner... Est-ce que vous avez une idée de la progression du sujet?

Merci..

romain.beuque
05/04/2016, 14h45
Citation Envoyé par frame
Pourquoi il y a une différence entre la liste de configurations que je recoi de "POST /order/cart/{cartId}/domainTransfer" et "GET /order/cart/{cartId}/domainTransfer"?
Le retour de POST /order/cart/{cartId}/domainTransfer est un order.cart.Item (c'est à dire une représentation de l'objet dans le panier)
Le champs configurations est dans la liste des configurations associées à cet item. Pour le moment, aucune configuration n'est ajoutée donc c'est un tableau vide.

GET /order/cart/{cartId}/domainTransfer renvoie un objet order.cart.ProductInformation[] qui représente les informations d'un produit. On a rajouté une propriété configurations, mais qui a ce moment là correspond aux configurations que l'on pourra poster par la suite.

C'est peut-être un peu subtil l'affichages des configurations disponible dans le GET, sachant qu'à ce moment là, c'est un appel non connecté, et donc les informations renvoyés ne sont donné qu'à titre indicatives. Il vaut mieux utiliser /requiredConfiguration pour avoir des informations bien à jour

Romain

frame
05/04/2016, 14h34
Merci Romain,
juste un petite question.

Pourquoi il y a une différence entre la liste de configurations que je recoi de "POST /order/cart/{cartId}/domainTransfer" et "GET /order/cart/{cartId}/domainTransfer"?

Merci

romain.beuque
05/04/2016, 14h14
Citation Envoyé par frame
Bonne Nouvelle Roumain,
merci!

J'ai une question, je ne sais pas si s'est un bug.

Quand j'appelle POST /order/cart/{cartId}/domainTransfer je recoi un liste di "configurations" vide
Code:
configurations: [ ]
Mais quand j'appelle GET /order/cart/{cartId}/domainTransfer je recoi la configuration AUTH_INFO
Quand j'appelle /order/cart/{cartId}/item/{itemId}/requiredConfiguration je recoi touts sauf le AUTH_INFO.

Je pensais de reveivoire une liste cohérente entre GET et POST de domaineTransfert et de recevoir le AUTH_INFO dans le requiredConfiguration aussi.
Bonjour frame,
Effectivement, c'était un bug. Je viens de passer le correctif en production, c'est corrigé, tu trouveras bien le AUTH_INFO dans le requiredConfiguration

Bonne journée
Romain

frame
05/04/2016, 13h55
Bonne Nouvelle Roumain,
merci!

J'ai une question, je ne sais pas si s'est un bug.

Quand j'appelle POST /order/cart/{cartId}/domainTransfer je recoi un liste di "configurations" vide
Code:
configurations: [ ]
Mais quand j'appelle GET /order/cart/{cartId}/domainTransfer je recoi la configuration AUTH_INFO

Code:
configurations: [
    {
        required: true
        fields: null
        label: "AUTH_INFO"
        type: "String"
    }
]
Quand j'appelle /order/cart/{cartId}/item/{itemId}/requiredConfiguration je recoi touts sauf le AUTH_INFO.

Code:
[
    {
        fields: null
        required: false
        label: "DNS"
        type: "String"
    }
    {
        fields: [ ]
        required: false
        label: "OWNER_CONTACT"
        type: "/me/contact"
    }
    {
        fields: [ ]
        required: false
        label: "ADMIN_ACCOUNT"
        type: "Nichandle"
    }
    {
        fields: [ ]
        required: false
        label: "TECH_ACCOUNT"
        type: "Nichandle"
    }
]
Je pensais de reveivoire une liste cohérente entre GET et POST de domaineTransfert et de recevoir le AUTH_INFO dans le requiredConfiguration aussi.

romain.beuque
30/03/2016, 18h08
Bonjour à tous,
(english below)

L'API de commande de transfert de domaine est désormais disponible au
public, sous l'URL:

GET/POST /order/cart/{cartId}/domainTransfer

https://api.ovh.com/console/#/order/...inTransfer#GET

Son fonctionnement est similaire à la commande de nom de domaine en
création.
N'hésitez pas à nous faire des retours en cas de problèmes lors de
l'utilisation de cette API ou demande de fonctionnalité supplémentaire.

Bonne journée,
Romain Beuque, OVH

--

Hello everyone,

The DomainTransfer order API is now available for the public, under the
endpoint:

GET/POST /order/cart/{cartId}/domainTransfer

https://api.ovh.com/console/#/order/...inTransfer#GET

This new API works as the DomainCreation order API.
Don't hesitate to come at us with any questions or feedback for
improvements.

Have a good day,
Romain Beuque, OVH

romain.beuque
30/03/2016, 18h00
Citation Envoyé par s.berry
Je tente une relance (la 3ème si je me souviens bien!)

Bonjour

J'aimerais savoir où vous en êtes concernant le webservice de création de mxPlan ?
J'ai une réunion de planification dans quelques jours et j'aimerais savoir si je peux y placer quelques tâches là-dessus?

Merci!
Bonjour,
Je vais transférer à l'équipe concernée !

@titiscan @pizzapp
Idemm pour telephonyOfferInfo & VoicemailMessagesRemoteUpload

Romain

s.berry
25/03/2016, 16h34
Je tente une relance (la 3ème si je me souviens bien!)

Bonjour

J'aimerais savoir où vous en êtes concernant le webservice de création de mxPlan ?
J'ai une réunion de planification dans quelques jours et j'aimerais savoir si je peux y placer quelques tâches là-dessus?

Merci!

ksio
25/03/2016, 14h23
Je me pose la même question...

titiscan
25/03/2016, 12h29
ce fil est encore suivi ?

pizzapp
11/03/2016, 17h54
Bonjour,

Je repost mon message du 17 Fevrier, car a priori il est passé entre les mailles du filet :

Bonjour,

Suivant régulièrement l'avancée de la migration de l'API, j’ai découvert avec surprise (mauvaise) que VoicemailMessagesRemoteUpload qui était en TODO (voir votre 1 post de ce thread) vient de passer en DEPRECATED sur https://www.ovh.com/fr/soapi-to-apiv6-migration/ .

POURQUOI ?
On l'utilise tous les jours (minimum 2 fois jours).
J’espère que c’est juste une erreur sur le site de migration
.Merci par avance pour votre reponse.

titiscan
10/03/2016, 10h18
Bonjour,

je n'ai pas trouvé dans l'api l'équivalent de la fonction isEngage()
dans : telephonyOfferInfo(session, number, country.getHardware().isEngage()

j'en ai besoin pour le développement d'une fonction de supervision et j'aimerai savoir s'il est possible de l'intégrer ou faut il que je la code avec SoApi

Merci

romain.beuque
08/03/2016, 12h14
Citation Envoyé par ksio
Personnellement moi je code en PHP, mais un simple pseudo code me suffirait, avec simplement les actions sous une forme (que je trouve) facile à lire et à adapter au langage utilisé.

Mais je comprendrais que vous préfèreriez faire un code utilisant votre bibliothèque maison.
Hello
Bon, je vais voir pour sortir la version PHP en même temps que l'API, et je donnerais l’enchaînement des calls pour que ça soit simple aux personnes parlant pas le PHP

Romain

ksio
07/03/2016, 15h28
Citation Envoyé par romain.beuque
Tu verrais ça plutôt sous la forme d'une documentation écrite, ou un petit exemple dans le code qui donne la succession des appels ?
(si tu le veux en code, dans quel language) ?
Personnellement moi je code en PHP, mais un simple pseudo code me suffirait, avec simplement les actions sous une forme (que je trouve) facile à lire et à adapter au langage utilisé.

// Recuperation d'un ID de commande

$infos_commande = POST '/order/cart' [ 'ovhSubsidiary' : 'FR' ]

// Ajout du domaine au panier

$infos_domaine = POST '/order/cart/' . $infos_commande->cartId . '/domain' [ 'domain' : 'truc.fr' ]

etc.

Mais je comprendrais que vous préfèreriez faire un code utilisant votre bibliothèque maison.

romain.beuque
07/03/2016, 15h12
Tu verrais ça plutôt sous la forme d'une documentation écrite, ou un petit exemple dans le code qui donne la succession des appels ?
(si tu le veux en code, dans quel language) ?

ksio
07/03/2016, 14h56
Citation Envoyé par romain.beuque
Pour la commande on a:
Python : https://github.com/ovh/order-cart-ex.../master/python
PHP : https://github.com/ovh/order-cart-ex...ree/master/php

C'est plus des exemples de code interactifs que des petits scripts: on peut adapter à ce que vous préférez
Non, c'est pas vraiment ce que j'ai en tete.

Appeler une fonction c'est facile, mais ce qui est très compliqué, c'est de trouver la succession de fonctions pour parvenir à faire ce que l'on a besoin.

Avant pour déposer un domaine je devais faire
$nick = $soap->nicCreate(...);
$soap->resellerDomainCreate( ... $nick...);
-> 2 appels

Maintenant je dois :
- Créer une commande
- Ajout du domaine au panier
- Assigner ce domaine à mon compte
- Set du DNS 1
- Set du DNS 2
- Set de L'admin account
- Set de Tech account
- création du propriétaire
- Set du propriétaire
- Validation des CGV du panier
- Checkout
- Paiement
-> 12 appels à l'API REST

C'est trouver cette succession qui est vraiment complexe.

romain.beuque
07/03/2016, 14h30
Pour la commande on a:
Python : https://github.com/ovh/order-cart-ex.../master/python
PHP : https://github.com/ovh/order-cart-ex...ree/master/php

C'est plus des exemples de code interactifs que des petits scripts: on peut adapter à ce que vous préférez

ksio
07/03/2016, 14h20
Citation Envoyé par romain.beuque
Les guides sur GitHub, c'était suffisant ?
Je ne les ai jamais trouvés pour le dépot de domaines (on parle bien de ca : https://github.com/ovh/php-ovh/tree/master/examples ? )

je suis parti d'un code posté par un autre contributeur de ce fil (je ne retrouve pas le code d'origine par contre) que j'ai adapté à mes propres bibliothèques CuRL et que j'ai complété pour les Zones DNS.

romain.beuque
07/03/2016, 14h08
Citation Envoyé par ksio
Volontier. Et SVP, si on pouvait avoir le moment venu la suite d'opération à faire pour mener à bien le transfert, ca serait top, car sans aide, je n'aurai jamais réussi à déposer un domaine, vu le nombre d'opérations successives à mener pour gérer le panier, etc.
OK, je note
Les guides sur GitHub, c'était suffisant ?

ksio
07/03/2016, 13h26
Citation Envoyé par romain.beuque
* Commande .FR: c'est disponible
Ok, on va procéder au test dès que l'on en aura un à réserver.

Citation Envoyé par romain.beuque
* Renouvellement de domaine: toujours en scheduling, pas d'ETA pour le moment :/
Ok.

Citation Envoyé par romain.beuque

* Transfert de domaine: en cours de développement, on parle en semaine, pas en mois

(probablement une BETA sur une portion réduite de TLD dans un premier temps, si vous êtes intéressé pour nous envoyer des feedbacks en direct, contactez-moi ! )
Volontier. Et SVP, si on pouvait avoir le moment venu la suite d'opération à faire pour mener à bien le transfert, ca serait top, car sans aide, je n'aurai jamais réussi à déposer un domaine, vu le nombre d'opérations successives à mener pour gérer le panier, etc.

Citation Envoyé par romain.beuque
* Pour vérifier si le domaine est actuellement chez OVH, je vais me renseigner
Merci

romain.beuque
07/03/2016, 12h25
Citation Envoyé par RyanEMS
La commande checkout (/order/cart/{cartId}/checkout) me retourne l'objet suivant (via CURL sou PHP) :

"setting labeled PROTECTED_DOMAIN is missing for this item"

Il manquerait donc un paramètre dans "requierdConfiguation" ? Ou alors il s'agit d'autre chose ?
Bonjour RyanEMS,
Il s'agit d'un cas très particulier....! Tu as essayé de commander "ems-ovh-api-domain-command-test.fr", si tu essaies de le faire sur le site commercial, on te demandera également une clé d'activation. Pour information, tous les domaines en *ovh*.* sont bloqués par une clé d'activation. Si tu essaies avec autre chose que *ovh*, cela fonctionnera

Citation Envoyé par ksio
Bonjour,

- Pourrait-on avoir des nouvelles concernant le dépôt de domaines en FR ?

- Pourrait-on avoir des nouvelles concernant le renouvellement de domaines (une date approximative ?) ?

- Pourrait-on avoir des nouvelles concernant le transfert de domaine (une date approximative ?) ?

- Pourrait-on savoir si une amélioration des API remplacant domainCheck pour savoir si un domaine est chez OVH actuellement et si il est transférable, et pas seulement si il est disponible comme actuellement dans la nouvelle API ?

Merci.
Hello ksio,
* Commande .FR: c'est disponible
* Renouvellement de domaine: toujours en scheduling, pas d'ETA pour le moment :/
* Transfert de domaine: en cours de développement, on parle en semaine, pas en mois
(probablement une BETA sur une portion réduite de TLD dans un premier temps, si vous êtes intéressé pour nous envoyer des feedbacks en direct, contactez-moi ! )

* Pour vérifier si le domaine est actuellement chez OVH, je vais me renseigner

Bonne journée
Romain

ksio
07/03/2016, 08h30
Bonjour,

- Pourrait-on avoir des nouvelles concernant le dépôt de domaines en FR ?

- Pourrait-on avoir des nouvelles concernant le renouvellement de domaines (une date approximative ?) ?

- Pourrait-on avoir des nouvelles concernant le transfert de domaine (une date approximative ?) ?

- Pourrait-on savoir si une amélioration des API remplacant domainCheck pour savoir si un domaine est chez OVH actuellement et si il est transférable, et pas seulement si il est disponible comme actuellement dans la nouvelle API ?

Merci.

llfister
04/03/2016, 15h37
Citation Envoyé par LouisM
Il manque effectivement les appels entrant avec cette fonction actuellement.
J'ai remonté le défaut en interne.

Tout comme bertranddcs, je t'invite a créer un ticket support et a me donner le numéro de ticket. Je l'attacherais à la tache interne pour que tu sois prévenu de la résolution.
Bonjour,

Suite à votre réponse ci-dessus, j'ai créé le ticket comme vous me l'aviez proposé. Je n'ai pas jugé utile de vous transmettre le numéro de ticket, pensant que j'aurais une réponse rapidement. Cela a été le cas, malheureusement, une réponse qui ne m'a pas été grandement utile. En effet, la personne qui m'a répondu m'a expliqué que la fonction /telephony/{billingAccount}/historyConsumption/{date}/document répondait à mon besoin alors que ce n'est toujours pas le cas.

Cette fonction retourne un fichier avec les consommations téléphoniques. Soit. Cela ne répond qu'à moitié à mon problème. J'ai besoin d'avoir le relevé des appels reçus et pas seulement des appels passés...

RyanEMS
04/03/2016, 10h18
Bonjour,

Concernant la commande de nom de domaine :
Après avoir suivi le use case de création de panier (https://github.com/ovh/order-cart-examples) : Assignation au compte, ajout du domaine, récupération de la configuration requise, etc, je reste bloqué sur le "checkout".

J'ai testé avec un compte "corporation" pour commander un .fr et après avoir créé une fiche contact (/me/contact) et avoir bien renseigné les informations demandés lors de l'appel suivant à "/order/cart/{cartId}/item/{ItemId}/requierdConfiguation" (INPI, Afnic, etc).

Dernier retour de requierdConfiguration :

Array
(
[0] => stdClass Object
(
[required] =>
[fields] => Array
(
)

[label] => INPI
[type] => /domain/data/afnicCorporationTrademarkInformation
)

[1] => stdClass Object
(
[required] =>
[fields] => Array
(
[0] => companyNationalIdentificationNumber
[1] => vat
[2] => organisation
)

[label] => INFORMATION
[type] => /me
)

[2] => stdClass Object
(
[required] =>
[fields] => Array
(
[0] => companyNationalIdentificationNumber
[1] => vat
[2] => organisation
)

[label] => OWNER_CONTACT
[type] => /me/contact
)

[3] => stdClass Object
(
[required] =>
[fields] =>
[label] => DNS
[type] => String
)

[4] => stdClass Object
(
[required] =>
[fields] => Array
(
)

[label] => ADMIN_ACCOUNT
[type] => Nichandle
)

[5] => stdClass Object
(
[required] =>
[fields] => Array
(
)

[label] => TECH_ACCOUNT
[type] => Nichandle
)

)
Comme il s'agit d'un compte de test, les données (optionnelles d'après l'api) dans /me ne sont pas renseignées (INFORMATION).
Les "configuration" suivantes sont bien renseignées par contre : OWNER_CONTACT, DNS, ADMIN_ACCOUNT et TECH_ACCOUNT

La commande checkout (/order/cart/{cartId}/checkout) me retourne l'objet suivant (via CURL sou PHP) :

stdClass Object
(
[message] => setting labeled PROTECTED_DOMAIN is missing for this item
)
Il manquerait donc un paramètre dans "requierdConfiguation" ? Ou alors il s'agit d'autre chose ?

Merci d'avance pour votre retour.

Cordialement, Ryan.

RyanEMS
04/03/2016, 10h15
Bonjour,

Concernant la commande de nom de domaine (création) :
Après avoir suivi le use case de création de panier (https://github.com/ovh/order-cart-examples) : Assignation au compte, ajout du domaine, récupération de la configuration requise, etc, je reste bloqué sur le "checkout".

J'ai testé avec un compte "corporation" pour commander un .fr et après avoir créé une fiche contact (/me/contact) et avoir bien renseigné les informations demandés lors de l'appel suivant à "/order/cart/{cartId}/item/{ItemId}/requierdConfiguation" (INPI, Afnic, etc).

Dernier retour de requierdConfiguration :

Code:
Array
(
    [0] => stdClass Object
        (
            [required] => 
            [fields] => Array
                (
                )

            [label] => INPI
            [type] => /domain/data/afnicCorporationTrademarkInformation
        )

    [1] => stdClass Object
        (
            [required] => 
            [fields] => Array
                (
                    [0] => companyNationalIdentificationNumber
                    [1] => vat
                    [2] => organisation
                )

            [label] => INFORMATION
            [type] => /me
        )

    [2] => stdClass Object
        (
            [required] => 
            [fields] => Array
                (
                    [0] => companyNationalIdentificationNumber
                    [1] => vat
                    [2] => organisation
                )

            [label] => OWNER_CONTACT
            [type] => /me/contact
        )

    [3] => stdClass Object
        (
            [required] => 
            [fields] => 
            [label] => DNS
            [type] => String
        )

    [4] => stdClass Object
        (
            [required] => 
            [fields] => Array
                (
                )

            [label] => ADMIN_ACCOUNT
            [type] => Nichandle
        )

    [5] => stdClass Object
        (
            [required] => 
            [fields] => Array
                (
                )

            [label] => TECH_ACCOUNT
            [type] => Nichandle
        )

)
Comme il s'agit d'un compte de test, les données (optionnelles d'après l'api) dans /me ne sont pas renseignées (INFORMATION).
Les "configuration" suivantes sont bien renseignées par contre : OWNER_CONTACT, DNS, ADMIN_ACCOUNT et TECH_ACCOUNT

La commande checkout (/order/cart/{cartId}/checkout) me retourne l'objet suivant (via CURL sou PHP) :

Code:
stdClass Object
(
    [message] => setting labeled PROTECTED_DOMAIN is missing for this item
)
Il manquerait donc un paramètre dans "requierdConfiguation" ? Ou alors il s'agit d'autre chose ?

Merci d'avance pour votre retour.

Je pense que ce serait une bonne chose d'avoir un use case complet de création de domaine .fr / .com avec un contact corporation/individual
Ça permettrai d'y voir plus claire. L'API est très complète mais il manque de la documentation sur l'utilisation de l'ensemble et le chaînage des appels.

Cordialement, Ryan.

romain.beuque
03/03/2016, 10h06
Citation Envoyé par ZeDvD
Est-ce possible d'avoir une réponse ????

Vous annoncez une fermeture de prepaid en mars et je ne sais pas si cette fonction est implémentée donc ce serait bien de nous tenir au courant ! Reprogrammer un logiciel prend du temps, donc il faut nous laisser ce temps...
Merci
Bonjour à tous,

Effectivement, il y a eu une confusion ici: prepaidDomainRenew, prepaidDomainTransfer n'ayant toujours pas d'équivalents APIv6, il n'est
pas possible dans l'état de fermer la partie prepaid aussi rapidemment.

L'implémentation de domainRenew a été remonté au sein de l'équipe, on devrait y voir plus clair prochainement (en terme d'ETA)

Je vois pour faire modifier la communication officielle sur ce point.


Merci à tous pour votre vigilance !
Bien cordialement,
Romain

s.berry
03/03/2016, 09h56
Bonjour

Comme le topic semble de nouveau actif, je réitère : où en êtes-vous concernant le webservice de création de mxPlan ?

Merci

vcasse
03/03/2016, 09h45
Salut ZeDvD,

Effectivement, ton message est passé entre les mailles du filet..

Donc non, le tuto actuel ne créé pas la zone DNS correspondante et il s'agit d'une bonne idée !
On ajoute ca dans la semaine.

Merci pour le feedback (et pour le reveil du topic )
Cordialement,
Vincent

ZeDvD
02/03/2016, 23h26
Là encore je poste la réponse, c'est à croire que les admins OVH ont complètement abandonné ce topic.
Donc oui, il y a un bug dans le tuto OVH - youhou.... y'a quelqu'un ???...
C'est bien beau d'attacher un domaine, mais si y'a pas de zone DNS associée, ça marche moins bien.
C'est la même chose avec les multi-domaines...

Donc je me permet de réveiller un peu le sujet (et ceux qui le surveillent, ou pas...) : Monsieur OVH, pouvez-vous corriger le tuto d'attachement de domaine qui est buggé, afin que tout le monde puisse bien comprendre et ne pas perdre autant de temps que moi ?... Merci ;-)

ZeDvD
26/02/2016, 22h31
Bon, ben en attendant ma réponse je poste une autre question. Je suis en train de tester la création de sous-domaine. Je me base sur ce tuto : https://github.com/ovh/php-ovh/blob/...chedDomain.php

Mon problème est le suivant : quand je vais dans le manager OVH, je vois bien le sous-domaine créé. Mais je n'ai aucune zone DNS associée. Et donc sans zone DNS le sous-domaine n'est pas accessible. Est-ce normal ? Y a-t-il un bug dans le tuto ?

ZeDvD
25/02/2016, 18h14
Citation Envoyé par ZeDvD
Bonjour

Est-ce que prepaidDomainRenew a finalement été implémentée dans la nouvelle API ? Si oui, est-ce qu'il existe un tuto pour la mettre en oeuvre ?

Merci pour votre réponse
Est-ce possible d'avoir une réponse ????

Vous annoncez une fermeture de prepaid en mars et je ne sais pas si cette fonction est implémentée donc ce serait bien de nous tenir au courant ! Reprogrammer un logiciel prend du temps, donc il faut nous laisser ce temps...
Merci

ZeDvD
24/02/2016, 23h22
Bonjour

Est-ce que prepaidDomainRenew a finalement été implémentée dans la nouvelle API ? Si oui, est-ce qu'il existe un tuto pour la mettre en oeuvre ?

Merci pour votre réponse

vcasse
24/02/2016, 15h51
Bonjour WebArtMedia,

Nous avons conscience que la documentation n'est pas la meilleure et nous tentons de l'améliorer à partir de vos feedbacks
Pour ce qui est de la consumer Key, toute la documentation est ici (mais en anglais) : https://api.ovh.com/g934.first_step_with_api

Les slides de l'une de mes présentation des APIs en World tour est disponible en Français : http://fr.slideshare.net/ovhcom/fr-cest-quoi-une-api Ca peut surement t'aider à comprendre ce qui est demandé.

Le path correspond aux droits d'accés que tu fournis à ta consumer key. Tu peux dire qu'elle a accés à tout (GET /*), ou alors, uniquement aux serveurs dédiés (GET /dedicated/server/*)

N'hésites pas si tu as d'autres questions. J'essaies souvent de répercuter les questions que je reçois en réalisant des exemples ou en mettant à jour la documentation.
https://github.com/ovh/php-ovh/tree/master/examples
https://github.com/ovh/python-ovh/tree/master/examples

Cordialement,
Vincent

s.berry
24/02/2016, 11h40
Bonjour

J'aimerais savoir où vous en êtes concernant le webservice de création de mxPlan ?
J'ai une réunion de planification dans quelques jours et j'aimerais savoir si je peux y placer quelques tâches là-dessus?

Merci!

WebArtMedia
24/02/2016, 10h30
Ah oui, autre chose !
Je vois qu'il y a une page pour la création de clé pour un script (https://eu.api.ovh.com/createToken/). Formidable ! Mais :
— On ne précise pas si le nom du script doit être un vrai nom de fichier (genre "mon_script.php") ou s'il s'agit d'un simple nom (genre "Mon Script") ;
— On ne précise rien quant au "path" ???
Encore une fois, je comprends les changements de technologies, de normes, et les évolutions (surtout en informatique). Mais j'ai quand-même le sentiment que vous avez mis la charrue avant les bœufs sur ce coup-là ! On se sent au pied du mur avec peu d'informations claires.
Pour exemple, lorsque j'ai voulu me servir de l'ancienne API (soAPI), je ne vous ai jamais écrit, j'ai lu la doc, fait deux trois tests et hop, l'affaire était dans le sac. Alors, peut-être suis-je devenu carrément débile en quelques années (possible), mais il faudra vous remettre en question sur cette histoire...
Allez, je ne veux pas vous accabler non plus, simplement envie de rester un client content d'avoir choisi OVH depuis plus de 10 ans !
(et puis au fait, OVH c'était un truc français, pourquoi tout est en anglais dans vos docs ?)
A très vite pour vos réponses...

WebArtMedia
24/02/2016, 10h13
Bonjour Vincent,

Le problème n'est pas la compréhension des nouvelles syntaxes relativement simples... Le problème pour ma part est l'obtention de la consumer key ! Les exemples donnés ne sont pas clairs (en plus uniquement en anglais). Et il est difficile à comprendre quels sont les éléments propres à mon script et ceux qui sont propres à la requête... Bref ! le flou artistique... ^^
Si vous connaissez une méthode claire et précise quant à l'obtention de cette consumer key, je prends, et plutôt deux fois qu'une.
Merci d'avance pour votre attention.
Vincent

titiscan
18/02/2016, 15h01
bonjour,

est il possible d'avoir le nombre de sms envoyées sur un mois par utilisateur ?

-la fonction /sms/{serviceName}/outgoing à les champs creationDatetime.from et creationDatetime.to mais pas d'information sur l'utilisateur qui l'a envoyée
-la fonction /sms/{serviceName}/users/{login}/outgoing permet de trier par utilisateur mais pas par date...

serait'il possible d'ajouter les champs creationDatetime.from et creationDatetime.to a la méthode /sms/{serviceName}/users/{login}/outgoing ?

et/ou d'ajouter le champ de l'utilisateur qui a envoyé le message dans la réponse /sms/{serviceName}/outgoing/{id}

merci

pizzapp
17/02/2016, 15h04
Bonjour,

Suivant régulièrement l'avancée de la migration de l'API, j’ai découvert avec surprise (mauvaise) que VoicemailMessagesRemoteUpload qui était en TODO (voir votre 1 post de ce thread) vient de passer en DEPRECATED sur https://www.ovh.com/fr/soapi-to-apiv6-migration/ .

POURQUOI ?
On l'utilise tous les jours (minimum 2 fois jours).
J’espère que c’est juste une erreur sur le site de migration
.Merci par avance pour votre reponse.

yas75
15/02/2016, 16h57
Bonjour,

Je souhaite accéder aux informations du nic d'un domaine avec APIv6, j'y arrivais sans problème dans SoAPI avec nicInfo
La table des correspondances SoAPI vs APIv6 me propose GET /me , or on ne peut pas passer en paramètre le nic comme dans soapi->nicInfo(session, nic )
Y a t-il une solution ?

Merci

romain.beuque
12/02/2016, 10h37
Citation Envoyé par ksio
Pour info la création de .COM fonctionne, elle.
Bonjour,
Oui effectivement, j'ai pu identifié les cas problématiques, il s'agit notamment des extensions avec restrictions ou configurations obligatoires.

Citation Envoyé par ksio
- Nous constatons que le propriétaire du .com nouvellement créé est éditable dans le Manager, mais pas les domaines créés auparavant, cela va t'il changer pour l'historique de nos dépôts ?
Tous les domaines vont être migrés au fur et à mesure vers le nouveau système de contact, et seront à termes tous éditables dans le Manager.

Citation Envoyé par ksio
- Nous créons principalement des domaines pour des associations et nous devons renseigner le SIREN du contact propriétaire. Actuellement je le place dans le champ companyNationalIdentificationNumber mais j'ai hésité avec le nationalIdentificationNumber. Pouvez vous me confirmer que je fais bien ?
Pour les associations, effectivement, il faut l'indiquer en tant que companyNationalIdentificationNumber.

Citation Envoyé par ksio
- Peut-on avoir des nouvelles des fonctions resellerDomainTransfer et resellerDomainRenew qui sont toujours en "To do" et dont nous avons besoin quotidiennement ?
resellerDomainTransfer est en planification côté équipe domaine. Pas d'ETA pour le moment.
Idem pour le renouvellement, qui devrait être planifier rapidement.

Tous ces développements sont bloquants pour la fermeture de SoAPI et seront donc effectués rapidement afin de permettre votre migration, et ensuite la fermeture de cette plateforme.

Romain

ksio
12/02/2016, 09h08
Merci Romain,

Pour info la création de .COM fonctionne, elle.

Trois questions :

- Nous constatons que le propriétaire du .com nouvellement créé est éditable dans le Manager, mais pas les domaines créés auparavant, cela va t'il changer pour l'historique de nos dépôts ?

- Nous créons principalement des domaines pour des associations et nous devons renseigner le SIREN du contact propriétaire. Actuellement je le place dans le champ companyNationalIdentificationNumber mais j'ai hésité avec le nationalIdentificationNumber. Pouvez vous me confirmer que je fais bien ?

- Peut-on avoir des nouvelles des fonctions resellerDomainTransfer et resellerDomainRenew qui sont toujours en "To do" et dont nous avons besoin quotidiennement ?

Merci

romain.beuque
11/02/2016, 17h34
Citation Envoyé par ksio
Merci Romain,

Je voudrais bien envoyer un MP mais pas trouvé comment le faire.
Effectivement, je vois pas de fonctionnalité MP sur le forum.
Citation Envoyé par ksio
je ne peux pas reproduire le problème avec le même domaine, car depuis on l'a déposé via le manager, néanmoins le problème se pose pour tout dépot de domaine en ".fr" à priori.

Je viens de le reproduire en déposant ssdfsdf.fr
CartID : 92f17972-333e-4bd4-b3ba-f15631c43549
en créant le owner : /me/contact/532873

Je donnerait un nickhandle en privé si nécessaire.
J'ai pu récupérer ton nichandle via les informations fournies.
En effet, je vois le cas qui pose problème, je vais faire en sorte de régler ce problème là rapidement. Le message d'erreur vient du fait que le contact propriétaire n'appartient pas au compte connecté à l'API, ce qui est normal, puisqu'il a été cloné pour être disponible depuis le compte admin (ADMIN_ACCOUNT).

Je reposterais sur ce thread lorsque le fix sera publié
Merci du feedback!

ksio
11/02/2016, 16h28
Merci Romain,

Je voudrais bien envoyer un MP mais pas trouvé comment le faire.

je ne peux pas reproduire le problème avec le même domaine, car depuis on l'a déposé via le manager, néanmoins le problème se pose pour tout dépot de domaine en ".fr" à priori.

Je viens de le reproduire en déposant ssdfsdf.fr
CartID : 92f17972-333e-4bd4-b3ba-f15631c43549
en créant le owner : /me/contact/532873

Je donnerait un nickhandle en privé si nécessaire.

Seb

romain.beuque
11/02/2016, 12h25
Citation Envoyé par ksio
Bonjour,

j'essaye de mettre en oeuvre le dépot d'un domaine et j'ai une erreur que je ne comprend pas.

Voici mon code qui, même si il est incomplet, permet de suivre la liste des opérations que je fais :



La ou j'ai un probleme c'est que l'opération Checkout (l'avant dernière) me répond en message d'erreur


Je ne sais pas quel contact ne m'appartient pas : le contact propriétaire est créé et je pense m'appartient, quand aux autres, ils sont ceux que je met manuellement sur les domaines via l'interface Manager.

Pouvez vous m'aider à y voir plus clair ?
Bonjour,
Ce message d'erreur est affiché quand tu essaies d'accéder à un contact qui n'appartient pas au compte connecté dans l'API.
Avec les modifications des ADMIN_ACCOUNT, c'est possible qu'il y ai un effet de bord que nous n'avons pas calculé.

Serait-il possible de m'envoyer l'identifiant du panier utilisé, le nom de domaine choisi, ainsi qu'un nichandle s'il te plait (possible de faire ça en privé si tu ne souhaites pas le donner en clair ici)

Merci d'avance,
Romain

ksio
11/02/2016, 09h46
Bonjour,

j'essaye de mettre en oeuvre le dépot d'un domaine et j'ai une erreur que je ne comprend pas.

Voici mon code qui, même si il est incomplet, permet de suivre la liste des opérations que je fais :

$extensions = 'FR';

// Recuperation d'un ID de commande

$infos_commande = $this->docall( 'POST', '/order/cart', array( 'ovhSubsidiary' => $extensions ) );

// Ajout du domaine au panier

$params = array(
'domain' => $domaine
);

$infos_domaine = $this->docall( 'POST', '/order/cart/' . $infos_commande->cartId . '/domain', $params );

// Assigne ce domaine à mon compte

$infos_assign = $this->docall( 'POST', '/order/cart/' . $infos_commande->cartId . '/assign', $params, true );

// Configure le domaine----------------------------------------------------

$t = array(
'label' => 'ADMIN_ACCOUNT',
'value' => '***-OVH'
);

$r = $this->docall( 'POST', '/order/cart/' . $infos_commande->cartId . '/item/' . $infos_domaine->itemId . '/configuration', $t, true );

$t = array(
'label' => 'TECH_ACCOUNT',
'value' => '***-OVH'
);

$r = $this->docall( 'POST', '/order/cart/' . $infos_commande->cartId . '/item/' . $infos_domaine->itemId . '/configuration', $t, true );

// Création du contact

$id_contact = $this->nicCreate( $nom_association, $nom_president, $prenom_president, $adresse, $code_postal, $ville, $telephone, $siren );

$t = array(
"label" => "OWNER_CONTACT",
"value" => "/me/contact/" . $id_contact
);

$r = $this->docall( 'POST', '/order/cart/' . $infos_commande->cartId . '/item/' . $infos_domaine->itemId . '/configuration', $t, true );

// Validation du panier : respect des CGV

$r = $this->docall( 'GET', '/order/cart/' . $infos_commande->cartId . '/checkout', array(), true );

// Checkout

$infos_order = $this->docall( 'POST', '/order/cart/' . $infos_commande->cartId . '/checkout', array(), true );

// Paiement final avec le compte prepaid

$t = Array (
"paymentMean" => "fidelityAccount"
);

$r = $this->docall( 'POST', '/me/order/' . $infos_order->orderId . '/payWithRegisteredPaymentMean', $t, true );
La ou j'ai un probleme c'est que l'opération Checkout (l'avant dernière) me répond en message d'erreur
This contact doesn't belongs to you
Je ne sais pas quel contact ne m'appartient pas : le contact propriétaire est créé et je pense m'appartient, quand aux autres, ils sont ceux que je met manuellement sur les domaines via l'interface Manager.

Pouvez vous m'aider à y voir plus clair ?

s.berry
10/02/2016, 08h49
okay, merci
Je verrais avec la personne qui gère le compte alors.

romain.beuque
09/02/2016, 19h00
Citation Envoyé par s.berry
Il ne me reste que la question concernant la consumerKey du coup mais qui sera peut-être pour un autre de vos collègues ?
Hello,
Pour la consumer key, le champs "Unlimited" permet de générer des consumer key à durée de vie non limitée. (cf screen shot => http://demo.ovh.eu/fr/2cab56b5c0a50b75e66d50dd1d04df6e/ )

s.berry
09/02/2016, 17h28
Citation Envoyé par MaxV
Bonjour,

alors alors, il y a plusieurs points :
- Le message d'erreur "Account of copy is not available with account", en faite si tu as un compte email et que tu ajouts un répondeur, tu peux 'cocher' copy, pour avoir une copie sur ce même compte, si tu 'coche' copy et ajoute une adresse en copie tu as le message d'erreur. Donc si tu veux, mettre un répondeur et faire une copie vers un autre compte, il suffit de créer un répondeur sans copie et d'ajouter une redirection du compte où tu as le répondeur vers le compte où tu veux recevoir les messages.
- Pour allowedAccountSize, en faite c'est peut être pas clair mais dans la fonction GET /email/domain/{domain} il y a un argument allowedAccountSize.

Sinon merci beaucoup pour tes remarques, c'est vrai que certaines chose ne sont pas très clair :/, on va essayer de remèdier à ça et je te rassure tout de suite sans changer le comportement des fonctions actuelle ^^.
Pour les Mxplan, on avance on avance j'espère sincèrement régler les problèmes la semaine et apporter des réponses la semaines prochaines.

Merci !
Et hésite pas si tu as d'autres questions, remarques ou autre ^^
Ah okay, je n'avais pas compris ça comme ça ! Donc en gros quand on met en place un répondeur sur un compte, il y a 3 choix possibles :
- "copy" à true, "copyTo" vide et on a les mails sur le compte où l'on met en place le répondeur (à ce moment là si on veut recevoir les mails sur un autre compte en plus il faut créer une redirection)
- "copy" à false, "copyTo" avec un autre compte et seul le compte renseigné reçoit les mails
- "copy" à false et "copyTo" vide et il n'y a aucune trace des mails reçus (sauf si on a mis en place une redirection à côté)

Si c'est bien ça je vais réécrire le docblock de ma fonction et valider mes tests alors.

Je comprends maintenant pour allowedAccountSize mais effectivement, de la façon dont c'est présenté je n'avais pas compris...
J'espère que mes retours seront utiles (même s'il y a peut-être des trucs qui sont plus évident quand on a accès au manage à côté ?)

Okay, je resterais en surveillance pour le MxPlan la semaine prochaine alors.

Il ne me reste que la question concernant la consumerKey du coup mais qui sera peut-être pour un autre de vos collègues ?
Citation Envoyé par s.berry
Bonjour,

Je me demandais...
Concernant la consumerKey que l'on peut générer avec la fonction requestCredentials où il faut se connecter au compte pour valider les droits d'accès à l'API, la personne qui gère le compte OVH de mon entreprise m'a dit n'avoir pu valider l'accès que pour 1mois. Est-ce qu'il y a un moyen d'étendre la durée de validité de la consumerKey via l'API ?
Ou il faut absolument faire cette opération de validation manuelle et changement de la consumerKey ?
Merci.

MaxV
09/02/2016, 16h39
Citation Envoyé par s.berry
Bonjour

Le problème du POST que j'avais à la création du ticket venait bien de là, ça posait problème pour le DELETE également.
J'ai fini mes tests sur les fonctions de gestion de compte mail et globalement ça s'est bien passé.

Concernant la création de répondeur (POST /email/domain/{domain}/responder), lorsque je veux mettre en place la copie, j'ai le message d'erreur suivant : "Account of copy is not available with account" et je ne sais pas trop quoi faire pour ne pas l'avoir. J'ai créé 2 comptes et ai essayé de mettre l'un en copie lors de la mise en place du répondeur sur l'autre. J'ai bien mis un compte existant, et non l'adresse mail complète de ce compte sinon j'ai de messages d'erreur différents de celui énoncé précédemment.
Par ailleurs, la documentation sur les dateTime pourrait être plus complète pour permettre une mise en place plus rapide.

J'aurais également quelques remarques sur la documentation :
  • POST /email/domain/{domain}/account : pour le paramètre 'size', il y a la fonction /email/domain/{domain}/allowedAccountSize qui est évoquée pour connaître les tailles de compte dispo mais elle n'existe pas. Un oubli ? On peut quand même obtenir la liste en passant une taille aberrante, la liste est alors retournée en message d'erreur (2500000, 5000000, 25000000, 50000000, 100000000, 250000000, 500000000, 1000000000, 1500000000, 2000000000, 5000000000)
  • PUT /email/domain/{domain}/account/{accountName} & PUT /email/domain/{domain}/responder/{account} : la documentation ne me semble pas claire. Bien-sûr on peut arriver à se débrouiller mais en tant qu'utilisatrice, la façon dont est présentée la doc m'a laissé penser que je devais passer en paramètre un tableau (Account dans le 1er cas, Responder dans le 2nd) contenant mes autres paramètres cette fois-ci optionnels. Alors que du coup il faut juste passer les 'sous-paramètres' en paramètre directement.


Voilà
J'espère que vous pourrez m'aider sur la mise en place du répondeur.
Sinon, des nouvelles sur la mise en place de MxPlan?

Merci
Bonjour,

alors alors, il y a plusieurs points :
- Le message d'erreur "Account of copy is not available with account", en faite si tu as un compte email et que tu ajouts un répondeur, tu peux 'cocher' copy, pour avoir une copie sur ce même compte, si tu 'coche' copy et ajoute une adresse en copie tu as le message d'erreur. Donc si tu veux, mettre un répondeur et faire une copie vers un autre compte, il suffit de créer un répondeur sans copie et d'ajouter une redirection du compte où tu as le répondeur vers le compte où tu veux recevoir les messages.
- Pour allowedAccountSize, en faite c'est peut être pas clair mais dans la fonction GET /email/domain/{domain} il y a un argument allowedAccountSize.

Sinon merci beaucoup pour tes remarques, c'est vrai que certaines chose ne sont pas très clair :/, on va essayer de remèdier à ça et je te rassure tout de suite sans changer le comportement des fonctions actuelle ^^.
Pour les Mxplan, on avance on avance j'espère sincèrement régler les problèmes la semaine et apporter des réponses la semaines prochaines.

Merci !
Et hésite pas si tu as d'autres questions, remarques ou autre ^^

s.berry
09/02/2016, 16h00
Bonjour,

Je me demandais...
Concernant la consumerKey que l'on peut générer avec la fonction requestCredentials où il faut se connecter au compte pour valider les droits d'accès à l'API, la personne qui gère le compte OVH de mon entreprise m'a dit n'avoir pu valider l'accès que pour 1mois. Est-ce qu'il y a un moyen d'étendre la durée de validité de la consumerKey via l'API ?
Ou il faut absolument faire cette opération de validation manuelle et changement de la consumerKey ?
Merci.

titiscan
09/02/2016, 14h40
Bonjour,

mes autres questions restant sans réponse, je vais en faire une nouvelle...

Serait-il possible d'avoir (dans le manager par exemple) un log des accès soapi avec le referrer ?

merci

s.berry
09/02/2016, 12h13
Oki, merci

romain.beuque
09/02/2016, 11h57
Citation Envoyé par s.berry
Et moi, et moi ?
Hello s.berry,
je n'ai pas la réponse pour cette partie de l'API, ce n'est pas moi qui suis en charge du développement de cette partie.
Je transfère à l'équipe concernée

s.berry
09/02/2016, 10h58
Et moi, et moi ?

Citation Envoyé par s.berry
Bonjour

Le problème du POST que j'avais à la création du ticket venait bien de là, ça posait problème pour le DELETE également.
J'ai fini mes tests sur les fonctions de gestion de compte mail et globalement ça s'est bien passé.

Concernant la création de répondeur (POST /email/domain/{domain}/responder), lorsque je veux mettre en place la copie, j'ai le message d'erreur suivant : "Account of copy is not available with account" et je ne sais pas trop quoi faire pour ne pas l'avoir. J'ai créé 2 comptes et ai essayé de mettre l'un en copie lors de la mise en place du répondeur sur l'autre. J'ai bien mis un compte existant, et non l'adresse mail complète de ce compte sinon j'ai de messages d'erreur différents de celui énoncé précédemment.
Par ailleurs, la documentation sur les dateTime pourrait être plus complète pour permettre une mise en place plus rapide.

J'aurais également quelques remarques sur la documentation :
  • POST /email/domain/{domain}/account : pour le paramètre 'size', il y a la fonction /email/domain/{domain}/allowedAccountSize qui est évoquée pour connaître les tailles de compte dispo mais elle n'existe pas. Un oubli ? On peut quand même obtenir la liste en passant une taille aberrante, la liste est alors retournée en message d'erreur (2500000, 5000000, 25000000, 50000000, 100000000, 250000000, 500000000, 1000000000, 1500000000, 2000000000, 5000000000)
  • PUT /email/domain/{domain}/account/{accountName} & PUT /email/domain/{domain}/responder/{account} : la documentation ne me semble pas claire. Bien-sûr on peut arriver à se débrouiller mais en tant qu'utilisatrice, la façon dont est présentée la doc m'a laissé penser que je devais passer en paramètre un tableau (Account dans le 1er cas, Responder dans le 2nd) contenant mes autres paramètres cette fois-ci optionnels. Alors que du coup il faut juste passer les 'sous-paramètres' en paramètre directement.


Voilà
J'espère que vous pourrez m'aider sur la mise en place du répondeur.
Sinon, des nouvelles sur la mise en place de MxPlan?

Merci

romain.beuque
08/02/2016, 17h17
Citation Envoyé par yannickn
Bonjour,


je ne vois pas de remplacant pour le dépôt de nom de domaine :

Prepaid prepaidDomainCreate Create a domain DEPRECATED

Quels seront la/les fonctions remplacantes ?

Merci
Yannick
Hello,
D'après la page https://www.ovh.com/soapi/fr/?group=prepaid,
This group is DEPRECATED and will be replaced by Loyalty/Reseller account as soon as the switch between the old and the new account will be done.
L'équivalent de prepaidDomainCreate est donc resellerDomainCreate (méthode SoAPI).
Il faut donc utiliser la méthode correspondante en APIv6, à savoir : GET-POST /order/cart/{cartId}/domain.
Pour auto-payer le bon de commande suite à la génération de la commande, il faut utiliser POST /me/order/{orderId}/payWithRegisteredPaymentMean.

Si tu as d'autres questions, n'hésites pas

s.berry
08/02/2016, 16h36
Bonjour

Le problème du POST que j'avais à la création du ticket venait bien de là, ça posait problème pour le DELETE également.
J'ai fini mes tests sur les fonctions de gestion de compte mail et globalement ça s'est bien passé.

Concernant la création de répondeur (POST /email/domain/{domain}/responder), lorsque je veux mettre en place la copie, j'ai le message d'erreur suivant : "Account of copy is not available with account" et je ne sais pas trop quoi faire pour ne pas l'avoir. J'ai créé 2 comptes et ai essayé de mettre l'un en copie lors de la mise en place du répondeur sur l'autre. J'ai bien mis un compte existant, et non l'adresse mail complète de ce compte sinon j'ai de messages d'erreur différents de celui énoncé précédemment.
Par ailleurs, la documentation sur les dateTime pourrait être plus complète pour permettre une mise en place plus rapide.

J'aurais également quelques remarques sur la documentation :
  • POST /email/domain/{domain}/account : pour le paramètre 'size', il y a la fonction /email/domain/{domain}/allowedAccountSize qui est évoquée pour connaître les tailles de compte dispo mais elle n'existe pas. Un oubli ? On peut quand même obtenir la liste en passant une taille aberrante, la liste est alors retournée en message d'erreur (2500000, 5000000, 25000000, 50000000, 100000000, 250000000, 500000000, 1000000000, 1500000000, 2000000000, 5000000000)
  • PUT /email/domain/{domain}/account/{accountName} & PUT /email/domain/{domain}/responder/{account} : la documentation ne me semble pas claire. Bien-sûr on peut arriver à se débrouiller mais en tant qu'utilisatrice, la façon dont est présentée la doc m'a laissé penser que je devais passer en paramètre un tableau (Account dans le 1er cas, Responder dans le 2nd) contenant mes autres paramètres cette fois-ci optionnels. Alors que du coup il faut juste passer les 'sous-paramètres' en paramètre directement.


Voilà
J'espère que vous pourrez m'aider sur la mise en place du répondeur.
Sinon, des nouvelles sur la mise en place de MxPlan?

Merci

yannickn
08/02/2016, 15h49
Bonjour,


je ne vois pas de remplacant pour le dépôt de nom de domaine :

Prepaid prepaidDomainCreate Create a domain DEPRECATED

Quels seront la/les fonctions remplacantes ?

Merci
Yannick

s.berry
05/02/2016, 17h17
Citation Envoyé par romain.beuque
Visiblement, y'a 0 payload à fournir, je viens de tester chez moi. Normalement, si le body est complètement vide, ca devrait passer.
Vérifies que tu n'envoies pas de body du coup, même si c'est juste
Code:
{}
Ah c'est pas faux! Il est vrai que tous mes autres POST ont au moins un paramètre, c'est le premier dans ce cas. Je vais vérifier ma classe d'appel du coup. De toute façon je dois y faire un tour car je viens de repérer un problème sur mon DELETE...

Il n'y a pas quelqu'un d'autre qui avait bossé sur un appel curl en PHP ?

Merci

romain.beuque
05/02/2016, 16h58
Citation Envoyé par s.berry
En fait j'ai une fonction pour l'installation de mxPlan qui comprend la création de la zone, la création du mxPlan et qui, en cas de problème, crée un ticket.
Du coup quand je l'ai lancée pour créer ma zone ce matin avec ovhAccount la première fois cela m'a créé un ticket (je n'avais pas commenté puisque lors de mon dernier test la création de ticket échouait...) C'était le ticket 2016020519031256.
Ah ok good !
Citation Envoyé par s.berry
Par contre comme il s'agit d'un POST sur /support/tickets/{ticketId}/close et qu'il n'y a pas d'autres paramètres je ne comprends pas trop le message d'erreur reçu...
Visiblement, y'a 0 payload à fournir, je viens de tester chez moi. Normalement, si le body est complètement vide, ca devrait passer.
Vérifies que tu n'envoies pas de body du coup, même si c'est juste
Code:
{}

Romain

s.berry
05/02/2016, 16h25
Citation Envoyé par romain.beuque
Ce ticket a été crée suite au paiement automatique ?
Serait-il possible d'avoir le numéro du ticket histoire que je vérifie que chaque paiement automatique ne génère pas un ticket
Bonjour Romain

Je n'ai pas été très claire dans mon message, désolée
En fait j'ai une fonction pour l'installation de mxPlan qui comprend la création de la zone, la création du mxPlan et qui, en cas de problème, crée un ticket.
Du coup quand je l'ai lancée pour créer ma zone ce matin avec ovhAccount la première fois cela m'a créé un ticket (je n'avais pas commenté puisque lors de mon dernier test la création de ticket échouait...) C'était le ticket 2016020519031256.

Si j'ai un peu de temps après les tests de fonction de gestion de compte mail je prendrais un peu de temps pour voir ce qui pouvait poser problème pour la clôture du ticket et vous fournir un message d'erreur précis si je ne trouve pas de problème de mon côté. Par contre comme il s'agit d'un POST sur /support/tickets/{ticketId}/close et qu'il n'y a pas d'autres paramètres je ne comprends pas trop le message d'erreur reçu...

Merci
Bon week-end également!

titiscan
05/02/2016, 16h06
Bonjour,

j'aimerai avoir quelques précisions quant à l'utilisation de l'api :

Il est courant avec soapi de faire une requête pour obtenir un ensemble de données (par exemple telephonySmsHistory renvoi un tableau avec l'ensemble des données composant chaque message)

Pour faire la même chose avec l'api, il faut donc utiliser la fonction correspondante (/sms/{serviceName}/outgoing) qui renvoi un tableau d'id puis faire une boucle de requêtes "GET" (/sms/{serviceName}/outgoing/{id}) pour avoir l'ensemble des données.

Est-ce bien la bonne méthode ?

Merci

romain.beuque
05/02/2016, 15h52
Citation Envoyé par s.berry
Bonjour,

J'ai enfin eu le temps de tester la création de la zone!
-> J'ai toujours l'erreur "This order can't be paid with ovhAccount".
-> MAIS l'appel à '/me/order/{orderId}/availableRegisteredPaymentMean' me retourne "fidelityAccount" comme moyen de paiement possible. Après comme c'est une commande à 0€ j'ai pu utiliser fidelityAccount pour créer la zone mais je tenais à vous le signaler par rapport à nos échanges.
Hello
Oui, ça doit être la pratique pour le paiement de bon de commande à 0€: utilisation du compte en point et non pas le ovhAccount.
Je préciserais ça pour les prochaines personnes qui poseront la question !

Citation Envoyé par s.berry
La bonne surprise fut qu'un ticket a été créé automatiquement... Je ne sais pas trop comment mais c'est arrivé Par contre quand j'ai essayé de clore le ticket via l'api j'ai eu une erreur "INVALID JSON" Bad request... Mais je n'ai pas trop insisté et ai demandé à la personne en charge du compte OVH de le faire via l'interface. Encore une fois, je tenais juste à vous le signaler.
Ce ticket a été crée suite au paiement automatique ?
Serait-il possible d'avoir le numéro du ticket histoire que je vérifie que chaque paiement automatique ne génère pas un ticket

Merci, et bon week-end
Romain

s.berry
05/02/2016, 15h31
Bonjour,

J'ai enfin eu le temps de tester la création de la zone!
-> J'ai toujours l'erreur "This order can't be paid with ovhAccount".
-> MAIS l'appel à '/me/order/{orderId}/availableRegisteredPaymentMean' me retourne "fidelityAccount" comme moyen de paiement possible. Après comme c'est une commande à 0€ j'ai pu utiliser fidelityAccount pour créer la zone mais je tenais à vous le signaler par rapport à nos échanges.

La bonne surprise fut qu'un ticket a été créé automatiquement... Je ne sais pas trop comment mais c'est arrivé Par contre quand j'ai essayé de clore le ticket via l'api j'ai eu une erreur "INVALID JSON" Bad request... Mais je n'ai pas trop insisté et ai demandé à la personne en charge du compte OVH de le faire via l'interface. Encore une fois, je tenais juste à vous le signaler.

Je vais tester un certain nombre d'autres fonctions d'ici lundi concernant la création / gestion de comptes mails, je vous ferais un retour global si nécessaire

LaurentLep
03/02/2016, 14h52
Bonjour à tous,

La section "Service" de SoAPI fermera le 3 Mai 2016.
Vous retrouverez le tableau d'équivalence des méthodes SoAPI vs APIv6 suivant ce lien.

Cordialement,
Laurent

romain.beuque
03/02/2016, 10h10
Citation Envoyé par s.berry
Jsuis pas sûre d'avoir tout compris faute de frappe ?
La correction de la commande de mxPlan est en cours chez vous il me semble. J'avais fait des tests de création de mxPlan sur des noms de domaines pour lesquels les zones avaient été créées manuellement via l'interface. On ne peut plus créer de mxPlan depuis l'interface non plus d'après ce que j'ai compris donc il avait déjà été convenu que l'on passerait par les tickets apparemment.

J'ai une erreur sur le serviceName quand je veux créer un ticket de category "incident" ou "assistance".
Après c'est pour la qualif des tickets chez vous je voudrais que ça corresponde...

je passe ça en param :
"body" : 'Test de l'api en cours, ne pas prendre en compte, merci.'
"subject" : '[TEST API] - NE PAS PRENDRE EN COMPTE',
"type" : 'genericRequest',
"category" : 'incident',
"product " :'mail'
Bonjour,
Oui pardon, faute de frappe.
De plus, je pensais que le seul élément bloquant était la non-validation automatique d'un bon de commande à 0€.

J'ai refais l'appel depuis le Manager, en sélectionnant un ticket incident, et un service, j'ai obtenu:
Code:
{"body": "interne test body",
"category": "incident",
"serviceName": "nomdedomaine.fr",
"subject": "interne test subject",
"type": "genericRequest"}
J'ai un nom de domaine associé au service zone, donc il est possible que si le nom de domaine n'est pas chez OVH, ça ne produit pas le même comportement.
Peut-tu essayer de voir avec un corps de requête comme je viens d'indiquer ci-dessus, si ça ne marche pas, je demanderais à l'équipe concerné de regarder ton problème

bonne journée
Romain

s.berry
02/02/2016, 17h52
Citation Envoyé par romain.beuque
Toujours la même
Le paiement sera autorisé via ovhAccount ou fidelityAccount, c'est juste que y'aura un débit de 0 !
Okidoki ! Je testerais ça demain.

Citation Envoyé par romain.beuque
Je viens de faire un test avec le Manager. J'ai pu récupérer un body du style:
Code:
{"body": "romain corps du sujet test",
"category": "billing",
"serviceName": null,
"subject": "romain test",
"type": "genericRequest"}
Peut-tu essayé de voir si ça marche de ton côté?

La livraison d'un MxPlan ne devrait pas fonctionner d'ailleurs maintenant que les zones DNS peuvent être payé automatiquement avec le bon de commande à 0€ ? (donc sans passer par un ticket support)
Jsuis pas sûre d'avoir tout compris faute de frappe ?
La correction de la commande de mxPlan est en cours chez vous il me semble. J'avais fait des tests de création de mxPlan sur des noms de domaines pour lesquels les zones avaient été créées manuellement via l'interface. On ne peut plus créer de mxPlan depuis l'interface non plus d'après ce que j'ai compris donc il avait déjà été convenu que l'on passerait par les tickets apparemment.

J'ai une erreur sur le serviceName quand je veux créer un ticket de category "incident" ou "assistance".
Après c'est pour la qualif des tickets chez vous je voudrais que ça corresponde...

je passe ça en param :
"body" : 'Test de l'api en cours, ne pas prendre en compte, merci.'
"subject" : '[TEST API] - NE PAS PRENDRE EN COMPTE',
"type" : 'genericRequest',
"category" : 'incident',
"product " :'mail'

romain.beuque
02/02/2016, 17h24
Citation Envoyé par s.berry
La méthode API correspondante est /me/order/{orderId}/payWithRegisteredPaymentMean ou c'est une nouvelle méthode ?
Toujours la même
Le paiement sera autorisé via ovhAccount ou fidelityAccount, c'est juste que y'aura un débit de 0 !

Citation Envoyé par s.berry
Est-ce que quelqu'un a des renseignements sur mon problème de paramétrage du serviceName du POST "/support/tickets/create"?
Je viens de faire un test avec le Manager. J'ai pu récupérer un body du style:
Code:
{"body": "romain corps du sujet test",
"category": "billing",
"serviceName": null,
"subject": "romain test",
"type": "genericRequest"}
Peut-tu essayé de voir si ça marche de ton côté?

La livraison d'un MxPlan ne devrait pas fonctionner d'ailleurs maintenant que les zones DNS peuvent être payé automatiquement avec le bon de commande à 0€ ? (donc sans passer par un ticket support)

s.berry
02/02/2016, 16h00
Merci Romain Beuque

La méthode API correspondante est /me/order/{orderId}/payWithRegisteredPaymentMean ou c'est une nouvelle méthode ?

Est-ce que quelqu'un a des renseignements sur mon problème de paramétrage du serviceName du POST "/support/tickets/create"?

romain.beuque
02/02/2016, 15h34
Citation Envoyé par s.berry
Ensuite je crée la commande (POST /order/domain/zone/new) et veux la valider avec un POST sur /me/order/{$orderId}/payWithRegisteredPaymentMean (avec comme payment mean mon 'ovhAccount') mais j'ai le message d'erreur suivant : "This order can't be paid with ovhAccount"

Du coup je suis passée par un GET sur /me/order/{$orderId}/availableRegisteredPaymentMean mais ça ne me retourne rien...

Mais bon, vu que la création de zone est gratuite il faut peut-être passer par une autre fonction pour valider la commande ?
Bonjour s.berry,
Pour information, la fonctionnalité de paiement de bon de commande gratuit a été implémentée, tu peux désormais valider ces bons de commandes via la méthode API correspondante.

Bonne journée,
Romain

romain.beuque
01/02/2016, 14h15
Citation Envoyé par frame
Bonjour Romain,
alors je ne sais pas qui a fait ce guide / tutorial, mais il est clairement incorrecte:

https://github.com/ovh/order-cart-ex...guration.fr.md

Tout d'abord, vous mentionnez requiredConfigurations (avec S à la fin), apres c'est claire que s'est pas possible de recuperer la configuration OWNER_CONTACT de cette méthode.

F.
Bonjour frame,
C'est notre équipe qui a fait le guide. Effectivement requiredConfiguration n'est pas correct sur l'image (et dans mon ancien post), je vais le faire modifier pour la prochaine release.

Concernant le renvoi des paramètres personnalisables non-obligatoires pour un item, on va le faire rajouter dans /order/cart/{cartId}/item/{itemId}/requiredConfiguration.

Si tu as d'autres questions/remarques

vcasse
01/02/2016, 12h09
Bonjour Yoram,

Le wrapper d'api php est testé continuellement avec les version 5.5, 5.6, 7.0 et hhvm.
https://travis-ci.org/ovh/php-ovh/builds/103878855

J'ai ajouté les anciennes versions de PHP afin de savoir jusqu'où le wrapper peut aller.
La version courante du wrapper (2.x) nécessite au minimum la version 5.5
https://travis-ci.org/ovh/php-ovh/builds/106181606

La version 1.x du wrapper, toujours maintenue, nécessite au minimum la version 5.4
https://travis-ci.org/ovh/php-ovh/builds/106183283
Cette version peut être trouvée ici https://github.com/ovh/php-ovh/releases/tag/v1.1.2

/!\ Seules les versions 5.5 et 5.6 sont encore maintenues par PHP
http://php.net/supported-versions.php

Cordialement,
Vincent

yoram
01/02/2016, 11h09
Bonjour,

Quelle est la version minimale de PHP pour utiliser le wrapper d'API pour php (https://github.com/ovh/php-ovh) ?
5.3, 5.4, 5.5 ?

Cordialement,

Yoram.

frame
01/02/2016, 10h49
Bonjour Romain,
alors je ne sais pas qui a fait ce guide / tutorial, mais il est clairement incorrecte:

https://github.com/ovh/order-cart-ex...guration.fr.md

Tout d'abord, vous mentionnez requiredConfigurations (avec S à la fin), apres c'est claire que s'est pas possible de recuperer la configuration OWNER_CONTACT de cette méthode.

F.

Citation Envoyé par romain.beuque
Bonjour frame,
Effectivement, requiredConfigurations renvoie uniquement les configurations nécessaires pour la commande d'un domaine mais pas celle qui permettent de "personnaliser" ce dernier (notamment personnalisation du contact propriétaire). Je vais voir si ca ne serait pas intéressant de renvoyer les configurations de personnalisation également dans ce endpoint (histoire d'avoir tout au même endroit).
Globalement, la liste des personnalisations non requises est: DNS / OWNER_CONTACT
Nous allons en rajouter la semaine prochaine, je reposterais ici pour vous avertir

A noter également que via GET /order/cart/{cid}/domain, on obtient la liste des configurations

Bien cordialement,
Romain

s.berry
01/02/2016, 10h15
Merci Vincent.
Julien GU avait commencé à me répondre mais j'ai besoin de plus d'infos.

vcasse
01/02/2016, 10h07
Bonjour Sarah Berry,

Je n'ai pas la réponse sur cette partie de l'API mais je demande à des collégues de te répondre.

Cordialement,
Vincent

s.berry
01/02/2016, 08h41
Quelqu'un peut répondre à ma question sur le ServiceName à fournir à la création d'un ticket via l'API?
Suivant ce qu'a pu me dire une personne en interne, j'ai essayé "Autre service", "otrs_service_other_services" des noms de domaine nous appartenant ou leur id mais rien ne semble fonctionner... j'ai toujours le message "This service does not exist"...
J'ai déjà dépassé le délai de livraison mais moins j'aurais de retard mieux ce sera...
Merci...

romain.beuque
29/01/2016, 18h41
Citation Envoyé par frame
Bonjour Julien,
j'ai en effet appelle la methode GET /order/cart/{cartId}/item/{itemId}/requiredConfiguration pour recuperer la liste de labels mais je reçois une liste vide.

F.
Bonjour frame,
Effectivement, requiredConfigurations renvoie uniquement les configurations nécessaires pour la commande d'un domaine mais pas celle qui permettent de "personnaliser" ce dernier (notamment personnalisation du contact propriétaire). Je vais voir si ca ne serait pas intéressant de renvoyer les configurations de personnalisation également dans ce endpoint (histoire d'avoir tout au même endroit).
Globalement, la liste des personnalisations non requises est: DNS / OWNER_CONTACT
Nous allons en rajouter la semaine prochaine, je reposterais ici pour vous avertir

A noter également que via GET /order/cart/{cid}/domain, on obtient la liste des configurations

Bien cordialement,
Romain

s.berry
29/01/2016, 14h57
Bonjour,

Je n'ai pas accès à l'interface de gestion du compte OVH, pouvez-vous m'indiquer où trouver cette information pour que je la demande à la personne en charge du compte?
Sinon, notre compte client est celui lié au ticket 2015122219066894 (si ça peut vous aider à nous retrouver...) Je vais demander en interne quand même...

J'ai essayé avec des noms de domaine existant et ai toujours le même message d'erreur...

Citation Envoyé par JuGU
Et si tu renseignes le nom d'un service que tu possèdes déjà dans ton nic handle, est-ce que le ticket est bien créé ?

Peux-tu me communiquer ton nic pour que je puisse consulter ton dossier s'il te plaît ?

Merci.

JuGU
29/01/2016, 14h10
Citation Envoyé par s.berry
Où est-ce que je peux voir la configuration des nic handle? Pouvez-vous m'indiquer ce que je dois rechercher ? Est-ce qu'il y en a un global ? ou comment je fais pour en configurer un global?

Merci d'avance
Et si tu renseignes le nom d'un service que tu possèdes déjà dans ton nic handle, est-ce que le ticket est bien créé ?

Peux-tu me communiquer ton nic pour que je puisse consulter ton dossier s'il te plaît ?

Merci.

s.berry
29/01/2016, 11h34
Bonjour Julien,

J'ai besoin de créer des mxPlan pour des domaines qui ne sont pas encore rattachés au compte de mon entreprise... Donc je suppose, qui ne sont pas dans mon nic handle?
Pour donner un aperçu de l'historique, mon code doit créer une zone pour un domaine puis créer le mxPlan sur ce même domaine. Le problème est que l'API ne nous permet pas de le faire aujourd'hui, même l'interface semble poser problème. Donc il a été convenu que nous ferions un ticket au support pour ces créations jusqu'à ce que la correction soit effectuée.
Je mets donc en place ce système de création de ticket dans mon code en attendant pour limiter les interventions humaines et rendre le traitement plus efficace.

Où est-ce que je peux voir la configuration des nic handle? Pouvez-vous m'indiquer ce que je dois rechercher ? Est-ce qu'il y en a un global ? ou comment je fais pour en configurer un global?

Merci d'avance

frame
29/01/2016, 11h28
Bonjour Julien,
j'ai en effet appelle la methode GET /order/cart/{cartId}/item/{itemId}/requiredConfiguration pour recuperer la liste de labels mais je reçois une liste vide.

F.

JuGU
29/01/2016, 10h49
Bonjour Sarah,

Il s'agit d'un des services présents dans votre nic handle, donc un domaine par exemple.

Pour quels services as-tu besoin de mxplan ?

@frame Je t'invite à jeter un oeil à ce lien qui te donnera quelques astuces : https://github.com/ovh/order-cart-examples

s.berry
29/01/2016, 10h19
Bonjour,

Est-ce que quelqu'un peut répondre à ma question?
Je dois livrer ce dev pour ce soir... Déjà que ce sera un mode complètement dégradé à cause des problèmes avec l'API, j'aimerais au moins pouvoir respecter les délais...

Merci...
Citation Envoyé par s.berry
Bonjour,

J'ai une nouvelle question !

Puisque l'on a besoin que le support crée pour nous les MxPlan en attendant que le développement soit fait, nous allons automatiser la création du ticket afin de limiter les interventions humaines.
Le problème est que la documentation du POST "/support/tickets/create" n'est pas suffisante. Lorsque j'essaie de créer un ticket de type "assistance" ou "incident" il me retourne : "Invalid parameter : Request of type assistance requires serviceName".
Je remplis donc ce paramètre avec quelque chose qui me semble approprié n'ayant que peu de renseignements : "MxPlan"
Il m'est alors retourné : "This service does not exist"...
Comme c'est un champs libre et qu'il n'y a pas de doc dessus je ne sais pas quoi mettre...

Qu'est ce que je peux passer en paramètre serviceName du POST "/support/tickets/create" dans mon cas ?

Merci !

frame
28/01/2016, 15h12
Où puis-je obtenir la liste des «labels» pour configurer un domaine au cours du processus de commande?

Je parle des labels qui on utilize pour le "POST /order/cart/{cardId}/item/{itemId}/configuration"

Je ai trouvé seulement le OWNER_CONTACT.

Quels sont les autres?

s.berry
28/01/2016, 10h39
Bonjour,

J'ai une nouvelle question !

Puisque l'on a besoin que le support crée pour nous les MxPlan en attendant que le développement soit fait, nous allons automatiser la création du ticket afin de limiter les interventions humaines.
Le problème est que la documentation du POST "/support/tickets/create" n'est pas suffisante. Lorsque j'essaie de créer un ticket de type "assistance" ou "incident" il me retourne : "Invalid parameter : Request of type assistance requires serviceName".
Je remplis donc ce paramètre avec quelque chose qui me semble approprié n'ayant que peu de renseignements : "MxPlan"
Il m'est alors retourné : "This service does not exist"...
Comme c'est un champs libre et qu'il n'y a pas de doc dessus je ne sais pas quoi mettre...

Qu'est ce que je peux passer en paramètre serviceName du POST "/support/tickets/create" dans mon cas ?

Merci !

LaurentLep
27/01/2016, 16h53
Bonjour,

Voici le lien du guide pour la fonction billingGetReferencesToExpired
https://github.com/ovh/python-ovh/bl...xpired_soon.md

Cordialement,
Laurent

s.berry
26/01/2016, 16h38
Ah... D'accord...
J'attendrais votre retour là-dessus également alors...

LaurentLep
26/01/2016, 16h33
Bonjour,

Voici la liste des dernières fonctions mises à jour :

billingGetAccessByNic
=> GET /{typeOfProduct}

dedicatedCapabilitiesGet
=> GET /dedicated/server/{serviceName}/orderable/ip
=> GET /dedicated/server/{serviceName}/specifications/ip

domainOperationCancel
=> POST /domain/zone/{zoneName}/task/{id}/cancel
=> POST /domain/{serviceName}/task/{id}/cancel

globalAccessByNic
=> DEPRECATED

serviceList
=> GET /{typeOfProduct}
=> GET /{typeOfProduct}/{serviceName}/serviceInfos

serviceListPaginated
=> GET /{typeOfProduct}
=> GET /{typeOfProduct}/{serviceName}/serviceInfos

telephonySpareList
=> GET /xdsl/spare
=> GET /telephony/spare

ticketListContact
=> DEPRECATED

Vous trouverez le changelog à jour sur la première page de cette discussion :
https://forum.ovh.com/showthread.php...haine-de-SoAPI

Cordialement,
Laurent

romain.beuque
26/01/2016, 16h21
Citation Envoyé par s.berry
Ensuite je crée la commande (POST /order/domain/zone/new) et veut la valider avec un POST sur /me/order/{$orderId}/payWithRegisteredPaymentMean (avec comme payment mean mon 'ovhAccount') mais j'ai le message d'erreur suivant : "This order can't be paid with ovhAccount"

Du coup je suis passée par un GET sur /me/order/{$orderId}/availableRegisteredPaymentMean mais ça ne me retourne rien...

Mais bon, vu que la création de zone est gratuite il faut peut-être passer par une autre fonction pour valider la commande ?
Bonjour s.berry,
Ce soucis a déjà été remonté en interne, et va être traité prochainement.
Je reposterai ici pour prévenir de la disponibilité de la fonction.

Bonne journée
Romain

s.berry
26/01/2016, 15h52
Bonjour,

On m'a informé qu'il y avait eu une réponse au ticket et qu'un développement sera fait prochainement. J'attendrais donc votre retour à ce sujet dans le ticket.

J'ai une nouvelle question.

Lorsque l'on a besoin de créer un mxPlan pour un de nos client dont le domaine n'est pas chez OVH, la première opération à effectuer est de créer une zone chez OVH pour le domaine.
Je commence donc par vérifier qu'aucune zone n'a déjà été créée pour ce domaine chez OVH (GET /order/domain/zone/new avec mon nom de domaine en paramètre) et je vérifie qu'il ne me retourne pas 'This zone already exists'.
Ensuite je crée la commande (POST /order/domain/zone/new) et veux la valider avec un POST sur /me/order/{$orderId}/payWithRegisteredPaymentMean (avec comme payment mean mon 'ovhAccount') mais j'ai le message d'erreur suivant : "This order can't be paid with ovhAccount"

Du coup je suis passée par un GET sur /me/order/{$orderId}/availableRegisteredPaymentMean mais ça ne me retourne rien...

Mais bon, vu que la création de zone est gratuite il faut peut-être passer par une autre fonction pour valider la commande ?

Ou alors c'est un autre problème ? (Si ça peut être lié au compte, merci de se référer au compte lié au ticket 2015122219066894, mais merci de répondre ici pour que je puisse voir la réponse et avancer dans mon code / mes tests car je n'ai pas accès au compte.)

s.berry
22/01/2016, 11h48
Citation Envoyé par MaxV
Ok je vois ça, merci.
On revoit les règles de commande de MxPlan en ce moment avec l'équipe et on va clarifier un peu ça dans l'API et Manager.
On voit pour décider/coder/proder ça au plus vite.
D'accord, j'attendrais votre retour sur le sujet alors.
Ce sera ici ou dans le ticket ?
Merci

MaxV
22/01/2016, 11h22
Citation Envoyé par s.berry
MaxV,

la personne en charge du compte OVH de l'entreprise dit avoir complété le ticket 2015122219066894 avec le problème de la création de MxPlan via l'API.
N'hésitez pas à revenir vers moi pour tout complément d'informations.
Ok je vois ça, merci.
On revoit les règles de commande de MxPlan en ce moment avec l'équipe et on va clarifier un peu ça dans l'API et Manager.
On voit pour décider/coder/proder ça au plus vite.

s.berry
21/01/2016, 17h11
MaxV,

la personne en charge du compte OVH de l'entreprise dit avoir complété le ticket 2015122219066894 avec le problème de la création de MxPlan via l'API.
N'hésitez pas à revenir vers moi pour tout complément d'informations.

s.berry
21/01/2016, 08h56
Merci MaxV pour ces réponses

Concernant la création de mxPlan, le fait que le domaine doive être rapatrié chez OVH me paraît étrange... Il y a près d'une centaine de mxPlan enregistré avec le compte de mon entreprise et aucun n'a de domaine enregistré chez OVH. Normalement il suffit de créer une zone pour ce domaine chez OVH pour pouvoir créer un mxPlan (/order/domain/zone/new).

A moins que cela n'ai changé ?

MaxV
21/01/2016, 08h27
Citation Envoyé par s.berry
Si j'essaye de créer le MxPlan avec cette même configuration depuis le manage, je n'ai aucun souci, pourquoi l'API me retourne l'erreur "Domain does not exist, unable to create an mx".
Etrange, si le manager a le même comportement que l'API normalement.
Si tu veux qu'on voit ça en privé, fait un ticket au support avec tes problèmes, un email de contact et post le numéro de ticket ici et je te retrouverai ^^

MaxV
21/01/2016, 08h21
Citation Envoyé par s.berry
Merci vcasse,

j'attendrais leur retour alors.

Je résume ici mes questions/problèmes et dans quel post trouver le détail pour faciliter leur intervention :
post #154 : Problème lors de l'utilisation du webservice "/order/email/domain/new/{duration}" en GET qui me retourne une 403 : "Domain does not exist, unable to create an mx" alors que tout semble bon pour passer une commande de MxPlan. [Très bloquant]
post #157 : Est-ce qu'une réelle commande est créée au POST "/order/email/domain/new/{duration}" ou faut-il faire une opération supplémentaire?
post #158 : Est-ce qu'il y a un moyen de savoir de quelle offre MxPlan un domaine dispose afin d'afficher un quota et proposer de passer à l'offre supérieure ?
Bonjour,

Alors pour le problème sur le GET "/order/email/domain/new/{duration}" : Il n'est pas possible de commander un mxplan sur un domaine non OVH. Le seul moyen est de rapatrier ton domaine chez OVH.

Pour le POST, la fonction te crée un Bon de Commande avec une date d'expiration, si tu ne paye pas ce Bon de Commande rien ne se passe.

Pour l'affichage du MxPlan actuel et l'upgrade, je bosse dessus actuellement, Pour le moment le support (1007) peuvent le faire à la main.

Hésite pas si tu as d'autres questions.

s.berry
20/01/2016, 18h10
Est-ce que ma question a été prise en compte et quelqu'un travaille actuellement à me fournir une réponse ou a-t-elle été complètement ignorée?
C'est pour savoir si je pourrais continuer à travailler dessus demain...

Merci

s.berry
20/01/2016, 12h47
Merci romain.beuque pour la réponse à ma 2eme question

Il reste donc le problème avec la création d'un mxPlan dont le détail est dans le post 154 :
[URGENT] Bonjour,

J'ai un problème avec le webservice de création de MxPlan, pouvez-vous m'aider?

Quand j'appelle le webservice "/order/email/domain/new/{duration}" en GET avec les bons paramètres il me retourne une 403 : "Domain does not exist, unable to create an mx".

Je passe par tout un tas de conditions avant d'arriver à ma fonction :
Le domaineName passé en paramètre
- a une zone (GET sur /order/domain/zone/new retourne 'This zone already exists')
- appartient bien à mon compte (il fait partie des résultats renvoyés par un GET sur '/email/domain')
- n'a pas de mxPlan déjà déclaré (la creation_date du GET sur "/email/domain/{domain}" est à NULL

Les problèmes possibles :
Le crédit de compte (GET de "/me/ovhAccount/{ovhAccountId}" : $ovhAccount->balance->value est inférieur à 0)
Le domaine n'est pas enregistré chez OVH

Si j'essaye de créer le MxPlan avec cette même configuration depuis le manage, je n'ai aucun souci, pourquoi l'API me retourne l'erreur "Domain does not exist, unable to create an mx".

Merci d'avance pour votre aide.

romain.beuque
20/01/2016, 12h27
Bonjour,
Je vais répondre à ce que je peux:

Citation Envoyé par s.berry
post #157 : Est-ce qu'une réelle commande est créée au POST "/order/email/domain/new/{duration}" ou faut-il faire une opération supplémentaire?
Cette opération génère un bon de commande.
Tu obtiendras un numéro de bon de commande (orderId) que tu pourras payer via POST /me/order//payWithRegisteredPaymentMean.

Citation Envoyé par ZeDvD
Je veux simplement connaitre le solde de mon compte fidélité.
Solde du compte de fidélité : https://api.ovh.com/console/#/me/fidelityAccount#GET
Solde du OVH account : https://api.ovh.com/console/#/me/ovh...countId%7D#GET

s.berry
20/01/2016, 11h10
Je n'ai peut-être pas été assez claire...
Est-ce que quelqu'un peut répondre à toutes mes questions ? Merci

Citation Envoyé par s.berry
Je résume ici mes questions/problèmes et dans quel post trouver le détail pour faciliter leur intervention :
post #154 : Problème lors de l'utilisation du webservice "/order/email/domain/new/{duration}" en GET qui me retourne une 403 : "Domain does not exist, unable to create an mx" alors que tout semble bon pour passer une commande de MxPlan. [Très bloquant]
post #157 : Est-ce qu'une réelle commande est créée au POST "/order/email/domain/new/{duration}" ou faut-il faire une opération supplémentaire?
post #158 : Est-ce qu'il y a un moyen de savoir de quelle offre MxPlan un domaine dispose afin d'afficher un quota et proposer de passer à l'offre supérieure ?

s.berry
20/01/2016, 10h46
Merci MaxV pour cette réponse à ma dernière question.
Ce n'est donc pas dispo pour le moment.
Le but de cette demande est seulement de récupérer l'offre actuellement souscrite donc si je dois le faire manuellement, il me suffirait d'aller dans le manage je suppose. Mais le but est bien de checker l'offre actuelle en auto pour différents tests avant de souscrire à l'offre au-dessus ou non, ou simplement pour afficher l'information au client pour un quota.

- - - Mise à jour - - -

J'ai vu ça vcasse, mais c'est bien ce que je craignais, seule ma dernière question a été prise en compte et non la totalité d'où mon message qui se voulait préventif. Ce que je demande dans le post 154 est vraiment bloquant pour mon dev.

vcasse
20/01/2016, 10h35
Bonjour S.berry,

Vos réponses se sont croisées

Cordialement,
Vincent

s.berry
20/01/2016, 10h33
Merci vcasse,

j'attendrais leur retour alors.

Je résume ici mes questions/problèmes et dans quel post trouver le détail pour faciliter leur intervention :
post #154 : Problème lors de l'utilisation du webservice "/order/email/domain/new/{duration}" en GET qui me retourne une 403 : "Domain does not exist, unable to create an mx" alors que tout semble bon pour passer une commande de MxPlan. [Très bloquant]
post #157 : Est-ce qu'une réelle commande est créée au POST "/order/email/domain/new/{duration}" ou faut-il faire une opération supplémentaire?
post #158 : Est-ce qu'il y a un moyen de savoir de quelle offre MxPlan un domaine dispose afin d'afficher un quota et proposer de passer à l'offre supérieure ?

MaxV
20/01/2016, 10h28
Citation Envoyé par s.berry
Nouvelle question. Oui, je les enchaîne...
Est-ce qu'il y a un moyen de savoir de quelle offre MxPlan un domaine dispose afin d'afficher un quota et proposer de passer à l'offre supérieure ?
Merci.
Bonjour,

Je suis en train de bosser dessus. Je fais ça au plus vite.
Si besoin, le support (1007) peut le faire à la main en attendant.

titiscan
20/01/2016, 10h15
Bonjour,
compte tenu de l’évolution active de l'api serait il possible avoir un "change log" des modifications afin de pouvoir les tester au mieux

Merci

vcasse
20/01/2016, 10h13
Bonjour ZeDvd,

Merci pour ces remarques, nous les avons remontées aux personnes intéressées, afin de faire autrement la prochaine fois.

Cordialement,
Vincent

- - - Mise à jour - - -

Bonjour S.berry,

J'ai demandé à des collégues, spécialistes des offres mails, de regarder ce soucis. Ils vont revenir vers toi.

Cordialement,
Vincent

s.berry
20/01/2016, 09h21
Nouvelle question. Oui, je les enchaîne...
Est-ce qu'il y a un moyen de savoir de quelle offre MxPlan un domaine dispose afin d'afficher un quota et proposer de passer à l'offre supérieure ?
Merci.

s.berry
20/01/2016, 09h00
Bonjour,

J'ai une question supplémentaire concernant mon précédent poste.
Si je fais un POST "/order/email/domain/new/{duration}", je passe bien la commande d'un MxPlan ? Je n'ai pas besoin d'une seconde opération pour valider la commande ? De ce fait, le solde de mon compte est par défaut celui utilisé ? (ce qui répondrait à une question que j'ai posé la semaine dernière d'ailleurs...) ?
J'espère que vous pourrez rapidement m'apporter une réponse à toute ces question pour que je puisse avancer sur mon dev....

Merci.

ZeDvD
19/01/2016, 22h34
Citation Envoyé par vcasse
C'est exactement ce que nous avons dans notre roadmap. D'autres priorités ont retardées leur sortie.
Si je peux me permettre un conseil pour les évolutions futures : faites d'abord ces fonctions de haut niveau en premier avant d'annoncer la fin des anciennes fonctions.

1 - vous mettez à disposition une API complète et simple d'emploi avec des tutos
2 - vous donnez un délai pour faire les mises à jour
3 - vous annoncez la fin des anciens services.?

Là, vous l'avez fait dans l'ordre inverse, ça a foutu la panique, enervé du monde (moi le premier) vous voyez bien qu'il y a un truc qui cloche.
Si vous le faites dans le bon sens, les clients gagnent du temps, son contents, et tout le monde est satisfait.

Comment se fait-il que quelqu'un chez vous ait pu donner une consigne inverse, ça me semble tellement illogique et inconcevable ? Si je fais ça dans mon job je me fais massacrer par mes clients.

Citation Envoyé par vcasse
Ca t'intéresserait de tester ? Je pense que tes retours pourraient nous aider à aller dans le bon sens !
Disons que si j'avais pas perdu autant de temps à faire les dernières mises à jour, ça aurait été avec plaisir. Mais là il faut que je rattrape le temps perdu et que je me remette à bosser pour moi et pas pour faire de la maintenance, question vitale, donc le temps est limité. Bref, ça sera sans moi, désolé. Je reste dispo pour répondre aux questions du forum sur des scripts que j'ai déjà faits.

ZeDvD
19/01/2016, 22h25
Citation Envoyé par romain.beuque

Prepaid infos => que veux-tu dire par là ?
Je veux simplement connaitre le solde de mon compte fidélité

Citation Envoyé par romain.beuque
Juste une petite remarque: à la fin du script, lorsque tu récupères le orderId
Code:
$l_order_id = $resp ["orderId"];
=> il faut le récupérer après l'appel au POST /order/cart//checkout et non pas après le GET. => le GET n'est qu'une version 'dryRun' permettant de simuler la création du bon de commande, et ne retourne pas de orderId valide
OK, c'est noté, merci. J'ai modifié mon exemple dans le message précédent pour le cas où quelqu'un le réutiliserait.

s.berry
19/01/2016, 18h38
[URGENT] Bonjour,

J'ai un problème avec le webservice de création de MxPlan, pouvez-vous m'aider?

Quand j'appelle le webservice "/order/email/domain/new/{duration}" en GET avec les bons paramètres il me retourne une 403 : "Domain does not exist, unable to create an mx".

Je passe par tout un tas de conditions avant d'arriver à ma fonction :
Le domaineName passé en paramètre
- a une zone (GET sur /order/domain/zone/new retourne 'This zone already exists')
- appartient bien à mon compte (il fait partie des résultats renvoyés par un GET sur '/email/domain')
- n'a pas de mxPlan déjà déclaré (la creation_date du GET sur "/email/domain/{domain}" est à NULL

Les problèmes possibles :
Le crédit de compte (GET de "/me/ovhAccount/{ovhAccountId}" : $ovhAccount->balance->value est inférieur à 0)
Le domaine n'est pas enregistré chez OVH

Si j'essaye de créer le MxPlan avec cette même configuration depuis le manage, je n'ai aucun souci, pourquoi l'API me retourne l'erreur "Domain does not exist, unable to create an mx".

Merci d'avance pour votre aide.

vcasse
19/01/2016, 15h40
Bonjour à tous,

Un nouvel exemple d'utilisation de l'API a été expliqué : comment attacher un domaine à un hébergement mutualisé ?
https://github.com/ovh/php-ovh/blob/...web_hosting.md

Attacher un domaine, pour les anciens, c'est à dire créer un sous domaine ou créer un multidomaines

Tous les tutos concernant le wrapper PHP se trouvent ici :
https://github.com/ovh/php-ovh/tree/master/examples

Bien sur, pour les utilisateurs de Curl directement, ce tuto peut vous servir à connaître les endpoints d'API à utiliser.

Si vous avez encore des questions après la lecture de cette doc, je suis preneur de vos feedbacks !

Cordialement,
Vincent

ksio
19/01/2016, 11h05
Citation Envoyé par ZeDvD
Merci !
Ca va faire un peu rétrograde, mais c'est ça que je reproche à l'informatique actuelle par rapport à celle d'avant (ça fait 25 ans que je bosse dans l'informatique...) : on multiplie des dizaines de frameworks pour rien, "au cas où" un jour on en ait besoin, pour se "simplifier les évolutions futures qu'on n'aura jamais", mais surtout parce que ça nous éclate de faire de la technique et que le nouveau framework est beaucoup plus cool que celui d'avant et qu'on est beaucoup plus efficace... On ne pense pas au temps qu'on fait perdre à tous ceux qui ne connaissent pas ce frameworks. On noie les gens dans une complexité technique souvent inutile, en multipliant les outils, au lieu de penser à simplifier les usages.

Ce petit tuto, ça m'a pris une journée pour le faire, ce n'est que du bon sens. Si je l'avais eu au début, je n'aurais pas perdu un mois à rechercher l'information dans des dizaines de pages de docs souvent incomplètes, voire erronées. J'espère qu'il va en aider d'autres, car au final c'est très simple.

Ce qui aurait été intelligent de la part d'OVH, ça aurait été de faire des fonctions de plus haut niveau pour masquer la complexité technique. Exemples :
- je veux acheter un domaine, j'appelle un service "buyDomaine", et je passe tous les paramètres dans un tableau. Un seul appel, des codes d'erreur en retour si ça ne marche pas, et terminé. Au lieu de ça, on se tape plusieurs séquences de services à enchainer.
- Je veux créer une redirection, j'appelle un service "createRedirection" et non pas la réinit des zones DNS, la suppression des zones AAAA, CNAME..., le refresh...
- etc.

Là, on tape directement dans le très bas niveau, et à nous de trouver la bonne séquence d'opérations jusqu'à ce que ça marche. Je trouve ça incroyable de raisonner ainsi à l'époque ou l'on est ! Pensez à l'utilisateur avant tout quand vous faites des interfaces, simplifiez lui la vie !
Je n'aurais pas mieux parlé.

On change des API pour rien, juste parce que c'est la mode de faire comme ca. Ca n'apportera rien, car ca n'apporte jamais rien.

Les fonctions haut niveaux existent : c'est l'API Soap que l'on supprime, elle faisait exactement cela. L'API telle qu'elle est pensée est mal pensée, et on n'est pas les seuls a le dire, c'est aussi l'avis en interne (déjà c'est pas mal).

vcasse
19/01/2016, 11h03
Citation Envoyé par ZeDvD
Ce qui aurait été intelligent de la part d'OVH, ça aurait été de faire des fonctions de plus haut niveau pour masquer la complexité technique. Exemples :
- je veux acheter un domaine, j'appelle un service "buyDomaine", et je passe tous les paramètres dans un tableau. Un seul appel, des codes d'erreur en retour si ça ne marche pas, et terminé. Au lieu de ça, on se tape plusieurs séquences de services à enchainer.
- Je veux créer une redirection, j'appelle un service "createRedirection" et non pas la réinit des zones DNS, la suppression des zones AAAA, CNAME..., le refresh...
- etc.
C'est exactement ce que nous avons dans notre roadmap. D'autres priorités ont retardées leur sortie.
Ca t'intéresserait de tester ? Je pense que tes retours pourraient nous aider à aller dans le bon sens !

Cordialement,
Vincent

romain.beuque
19/01/2016, 10h19
Bonjour,
Citation Envoyé par vcasse
Ce n'est pas possible actuellement dans l'api. Peux tu nous expliquer quel est ton usage de la "création de nic". Tu fais un nic par client ?
En réalité si, c'est possible, c'est un autre endpoint !
POST /newAccount permet de générer un nouveau nichandle (les fonctions autour de /newAccount permettent de récupérer dynamiquement via l'API les règles de créations d'un nichandle.

Les contacts /me/contact que tu utilises ZeDvD sont parfait pour la création de contacts propriétaires pour les domaines : ils sont rattachés au compte connecté à l'API, sont modifiables via le ManagerV6 (et l'API).

Information domaine
Test si un domaine existe
Prepaid create domain
Prepaid infos
Prepaid renew domain
Prepaid infos => que veux-tu dire par là ?
Prepaid renew domain => les équipes travaillent dessus

@ZeDvD: très bon script, merci de l'avoir partagé !
Nous avons une version interactive en PHP qui est censé sortir bientôt sur Github pour la commande.

Juste une petite remarque: à la fin du script, lorsque tu récupères le orderId
Code:
$l_order_id = $resp ["orderId"];
=> il faut le récupérer après l'appel au POST /order/cart//checkout et non pas après le GET. => le GET n'est qu'une version 'dryRun' permettant de simuler la création du bon de commande, et ne retourne pas de orderId valide

Bien cordialement,
Romain

ZeDvD
18/01/2016, 23h14
Citation Envoyé par Jacques-ch
Un grand merci pour ce tuto ZeDvD ! Ca fonctionne parfaitement. Simple, efficace, compréhensible.
Maintenant il ne me reste plus qu'à modifier toutes les pages sur lesquelles j'ai appelé des commandes SoAPI et remplacer par ces quelques lignes
Merci !
Ca va faire un peu rétrograde, mais c'est ça que je reproche à l'informatique actuelle par rapport à celle d'avant (ça fait 25 ans que je bosse dans l'informatique...) : on multiplie des dizaines de frameworks pour rien, "au cas où" un jour on en ait besoin, pour se "simplifier les évolutions futures qu'on n'aura jamais", mais surtout parce que ça nous éclate de faire de la technique et que le nouveau framework est beaucoup plus cool que celui d'avant et qu'on est beaucoup plus efficace... On ne pense pas au temps qu'on fait perdre à tous ceux qui ne connaissent pas ce frameworks. On noie les gens dans une complexité technique souvent inutile, en multipliant les outils, au lieu de penser à simplifier les usages.

Ce petit tuto, ça m'a pris une journée pour le faire, ce n'est que du bon sens. Si je l'avais eu au début, je n'aurais pas perdu un mois à rechercher l'information dans des dizaines de pages de docs souvent incomplètes, voire erronées. J'espère qu'il va en aider d'autres, car au final c'est très simple.

Ce qui aurait été intelligent de la part d'OVH, ça aurait été de faire des fonctions de plus haut niveau pour masquer la complexité technique. Exemples :
- je veux acheter un domaine, j'appelle un service "buyDomaine", et je passe tous les paramètres dans un tableau. Un seul appel, des codes d'erreur en retour si ça ne marche pas, et terminé. Au lieu de ça, on se tape plusieurs séquences de services à enchainer.
- Je veux créer une redirection, j'appelle un service "createRedirection" et non pas la réinit des zones DNS, la suppression des zones AAAA, CNAME..., le refresh...
- etc.

Là, on tape directement dans le très bas niveau, et à nous de trouver la bonne séquence d'opérations jusqu'à ce que ça marche. Je trouve ça incroyable de raisonner ainsi à l'époque ou l'on est ! Pensez à l'utilisateur avant tout quand vous faites des interfaces, simplifiez lui la vie !

Citation Envoyé par Jacques-ch
Question subsidiaire:
Les 3 clés que l'on a générées, sont-elles reliées à un domaine bien précis ou elle est reliée au nic-handle ? Donc une fois le fichier OvhApi.php mis à jour avec les différentes clés, on peu utiliser ce même fichier pour tous les domaines qu'on gère ou il faut générer des clés différentes pour chacun des domaines? Quel est l'intérêt d'avoir plusieurs clés différentes par rapport à en avoir une seule qu'on utilise partout?
D'après ce que j'ai compris, oui.
Si tu fais plusieurs clefs, c'est que tu veux donner des droits particuliers restreints sur certains services, ou des droits limités. Je vais t'avouer que je ne vois pas trop l'intérêt à première vue...

Jacques-ch
18/01/2016, 20h06
Un grand merci pour ce tuto ZeDvD ! Ca fonctionne parfaitement. Simple, efficace, compréhensible.
Maintenant il ne me reste plus qu'à modifier toutes les pages sur lesquelles j'ai appelé des commandes SoAPI et remplacer par ces quelques lignes

Question subsidiaire:
Les 3 clés que l'on a générées, sont-elles reliées à un domaine bien précis ou elle est reliée au nic-handle ? Donc une fois le fichier OvhApi.php mis à jour avec les différentes clés, on peu utiliser ce même fichier pour tous les domaines qu'on gère ou il faut générer des clés différentes pour chacun des domaines? Quel est l'intérêt d'avoir plusieurs clés différentes par rapport à en avoir une seule qu'on utilise partout?

ZeDvD
18/01/2016, 18h57
Citation Envoyé par vcasse
Bonjour ZeDvd,

J'ai repris ta liste de migrations à effectuer.


J'ai écris des exemples qui utilisent l'api v6. C'est en cours de relecture. Ca se trouve sur github si tu ne veux pas attendre demain !


Bon, c'est pour résumé, car tu m'as déjà indiqué que tu l'as lu. La documentation est ici https://github.com/ovh/php-ovh/blob/...redirection.md



@romain.beuque je pense que tu sais mieux que moi si des exemples existent



C'est toujours dans ma liste de todo. Ca arrive les prochains jours



Ce n'est pas possible actuellement dans l'api. Peux tu nous expliquer quel est ton usage de la "création de nic". Tu fais un nic par client ?

Cordialement,
Vincent
La seule chose qui me manque actuellement c'est le Renew des domaines avec compte fidélité, et le solde du compte fidélité. Tout le reste est OK
La création de nic me sert pour l'achat de noms de domaines, on en a besoin, mais j'ai trouvé comment faire, voir ci-dessous

function f_ovh_nic_create($p_array)
{
$l_result = false;
f_log ("f_ovh_nic_create - creation nic handle");

$l_array = array (
"organisationName" => "",
"firstName" => $p_array['nom'],
"lastName" => $p_array['prenom'],
"legalForm" => "individual",
"address" => Array
(
"country" => $p_array['pays'], // "FR"
"zip" => $p_array['code_postal'],
"city" => $p_array['ville'],
"province" => "",
"line1" => $p_array['adresse'],
"line2" => "",
"line3" => ""
),
"language" => "fr_FR",
"birthCountry" => "FR",
"birthZip" => $p_array['departement'],
"birthCity" => $p_array['lieu_naissance'],
"birthDay" => $p_array['date_naissance'],
"email" => $p_array['mail'],
"phone" => $p_array['telephone'],

"fax" => "",
"vat" => "",
"nationalIdentificationNumber" => "",
"cellPhone" => "",
"companyNationalIdentificationNumber" => "",
"gender" => "male",
"organisationType" => "",
"nationality" => ""
);

$ovh = new OvhApi();
$resp = $ovh->post('/me/contact', $l_array);

if (@$resp["message"] == "")
{
$l_id = $resp["id"];
}
else
{
$l_id = false;
}

return $l_id;
}




Pour l'achat de noms de domaines, je poste ici la séquence de commandes pour ceux qui sont intéressés car ce n'est pas trivial




$ovh = new OvhApi();
$l_domain = "nouveau-domaine-a-acheter-chez-ovh.fr";

// Recuperation d'un ID de commande
$resp = $ovh->post('/order/cart', array(
'ovhSubsidiary' => 'FR'
)
);
$l_cart_id = $resp ["cartId"];


// Ajout du domaine au panier
$resp = $ovh->post('/order/cart/'.$l_cart_id.'/domain', array(
'domain' => $l_domain
)
);
$l_item_id = $resp ["itemId"];


// Assigne ce domaine à mon compte
$resp = $ovh->post('/order/cart/'.$l_cart_id.'/assign', "");


// Creation contact----------------------------------------------------
$l_id_contact = f_ovh_nic_create ($l_array); // retourne l'ID du contact créé ou false sinon (voir fonction plus haut)

// Configure le domaine----------------------------------------------------
// Configuration du domaine : https://github.com/ovh/order-cart-ex...guration.fr.md
$resp = $ovh->post('/order/cart/'.$l_cart_id.'/item/'.$l_item_id.'/configuration', array(
"label" => "OWNER_CONTACT",
"value" => "/me/contact/".$l_id_contact
)
);

// Validation du panier : respect des CGV
$resp = $ovh->get('/order/cart/'.$l_cart_id.'/checkout');


// Checkout
$resp = $ovh->post('/order/cart/'.$l_cart_id.'/checkout', "");
$l_order_id = $resp ["orderId"];


// Paiement final avec le compte prepaid

$resp = $ovh->post('/me/order/'.$l_order_id.'/payWithRegisteredPaymentMean',
Array ("paymentMean" => "fidelityAccount")
);

vcasse
18/01/2016, 18h35
Bonjour ZeDvd,

J'ai repris ta liste de migrations à effectuer.

Creation multi-domaine
Destruction multi-domaine
Information multi-domaine
Subdomain Create
Subdomain Delete
Subdomain List
J'ai écris des exemples qui utilisent l'api v6. C'est en cours de relecture. Ca se trouve sur github si tu ne veux pas attendre demain !

creation redirection
Bon, c'est pour résumé, car tu m'as déjà indiqué que tu l'as lu. La documentation est ici https://github.com/ovh/php-ovh/blob/...redirection.md

Information domaine
Test si un domaine existe
Prepaid create domain
Prepaid infos
Prepaid renew domain
@romain.beuque je pense que tu sais mieux que moi si des exemples existent

Ajout mail redirection
Suppression mail redirection
Liste mails redirection
Ajout mail a mailing liste
Suppression mail de mailing liste
Liste mail de mailing liste
C'est toujours dans ma liste de todo. Ca arrive les prochains jours

Creation nic handle
Infos nic handle
Ce n'est pas possible actuellement dans l'api. Peux tu nous expliquer quel est ton usage de la "création de nic". Tu fais un nic par client ?

Cordialement,
Vincent

vcasse
18/01/2016, 18h17
Salut Koocotte,

Merci pour le retour sur la librairie Perl. Nous allons l'améliorer prochainement, nous allons donc prendre en compte vos propositions

Cordialement,
Vincent

koocotte
18/01/2016, 17h59
Un petit retour sur la librairie Perl fournie qui est très simple à utiliser. Merci.

Pour ceux qui ne serait pas au courant: lancer la commande perldoc sur les deux fichiers .pm pour avoir la doc. Il y a deux fois une page

Sur une debian:

installer les dépendances:
apt-get install libdigest-sha-perl libjson-xs-perl libjson-perl

La lib Digest::SHA1 n'est plus disponible depuis deux version majeurs de Debian, remplacer "use Digest::SHA1" par "use Digest::SHA" vers de début d'OvhApi.pm. Je pense qu'une amélioration de la lib à coup de BEGIN devrait permettre de rendre très facilement la lib compatible avec les deux solutions.

Pour rendre les fichiers disponibles partout, mettre le contenu du zip dans /usr/local/lib/site_perl (il doit y avoir dedans OvhApi.pm et OvhApi/Answer.pm)

Il devrait être possible de faire un .deb très facilement avec "equivs", ça installerait tout seul les fichiers dans les bon répertoire et tirerait les dépendances.

J'avais un script pour dumper et sauvegarder toute la configuration mail d'un domaine (boites pop3, mailinglist, redirection, répondeurs), je l'ai porté en un peu plus de 2 heures sur la nouvelle interface. Par contre le nombre d'appels à l'API a explosé; avant on avait toutes les infos en un seul appel, maintenant il faut a chaque fois réclamer le détail objet par objet.

romain.beuque
18/01/2016, 10h22
Citation Envoyé par ZeDvD
Savez-vous également dire à quelle date l'API sera complétée pour renouveler les noms de domaine ?
Bonjour,
Pas de date annoncée pour l'instant. La demande a bien été transmise à l'équipe concernée

Bien cordialement, Romain

ZeDvD
17/01/2016, 21h20
C'est ici : http://www.waibe.fr/blog-1-145305392...on-d-ovh-.html

Jacques-ch
17/01/2016, 18h47
Citation Envoyé par ZeDvD
Je vais essayer de te faire un tuto simple et compréhensible, qui va à l'essentiel, je te tiens au courant quand c'est fait
Alors ce sera vraiment bien volontiers!

ZeDvD
17/01/2016, 10h59
Citation Envoyé par Jacques-ch
Désolé mais j'ai l'impression d'être sur une autre planète!!!
J'utilise SoAPI non pas pour géré des comptes, des droits ou autre chose de la sorte comme la plupart des intervenant ici qui maitrise parfaitement la chose mais pour "bêtement" juste lister tous les abonnés à une mailing list. Pour faire ceci, j'ai un simple code PHP que j'ai généré avec l'outil qui était dans SoAPI et qui est ceci :
try { $soap = new SoapClient("https://www.ovh.com/soapi/soapi-re-1.35.wsdl");
//login
$session = $soap->login("mon_login_ovh", "mon_password","fr", false);
//mailingListSubscriberList
$result = $soap->mailingListSubscriberList($session, "mon_domaine", "le_nom_de_la_mailinglist");
//Liste des records
$compteur = 0;
While ($result[$compteur] != "")
{
echo ($result[$compteur]."
");
$compteur++;
}
//logout
$soap->logout($session);

} catch(SoapFault $fault) {
//echo $fault;
}
?>
J'ai maintenant reçu un message d'OVH qui me dit si je le comprend bien que mon bout de code ne va bientôt plus fonctionner, je vous rappèle que je ne suis pas un pro des différents langages de programmation, je maitrise plus ou moins le HTML et PHP et ça s'arrête là. Donc ma question est très simple, qu'est ce que je dois mettre dans ma page PHP pour qu'elle me retourne la liste des abonnés à cette mailinglist une fois que OVH auront arrêté SoAPI ?

Comment envoyer le login (et quel login)? Comment lister les abonnés de la ML? et comment ensuite j'imagine faire le logout?
Merci d'avance si quelqu'un pourrait me donner une réponse "simple"
Jacques
Je vais essayer de te faire un tuto simple et compréhensible, qui va à l'essentiel, je te tiens au courant quand c'est fait

Jacques-ch
16/01/2016, 23h08
Désolé mais j'ai l'impression d'être sur une autre planète!!!
J'utilise SoAPI non pas pour géré des comptes, des droits ou autre chose de la sorte comme la plupart des intervenant ici qui maitrise parfaitement la chose mais pour "bêtement" juste lister tous les abonnés à une mailing list. Pour faire ceci, j'ai un simple code PHP que j'ai généré avec l'outil qui était dans SoAPI et qui est ceci :
try { $soap = new SoapClient("https://www.ovh.com/soapi/soapi-re-1.35.wsdl");
//login
$session = $soap->login("mon_login_ovh", "mon_password","fr", false);
//mailingListSubscriberList
$result = $soap->mailingListSubscriberList($session, "mon_domaine", "le_nom_de_la_mailinglist");
//Liste des records
$compteur = 0;
While ($result[$compteur] != "")
{
echo ($result[$compteur]."
");
$compteur++;
}
//logout
$soap->logout($session);

} catch(SoapFault $fault) {
//echo $fault;
}
?>
J'ai maintenant reçu un message d'OVH qui me dit si je le comprend bien que mon bout de code ne va bientôt plus fonctionner, je vous rappèle que je ne suis pas un pro des différents langages de programmation, je maitrise plus ou moins le HTML et PHP et ça s'arrête là. Donc ma question est très simple, qu'est ce que je dois mettre dans ma page PHP pour qu'elle me retourne la liste des abonnés à cette mailinglist une fois que OVH auront arrêté SoAPI ?

Comment envoyer le login (et quel login)? Comment lister les abonnés de la ML? et comment ensuite j'imagine faire le logout?
Merci d'avance si quelqu'un pourrait me donner une réponse "simple"
Jacques

ZeDvD
16/01/2016, 22h51
Savez-vous également dire à quelle date l'API sera complétée pour renouveler les noms de domaine ?

ZeDvD
15/01/2016, 23h11
Question complémentaire :

/hosting/web/{serviceName}/attachedDomain permet de récupérer les sous-domaines et les multi-domaines.

comment récupère-t-on les sous-domaine uniquement ? Est-on obligé de reparcourir le tableau de résultats et d'éliminer les multi-domaines en filtrant par le nom ? Ou bien y a-t-il une fonction de l'API qui retourne directement les sous-domaines, sans les multi-domaines ?

LouisM
15/01/2016, 14h50
Citation Envoyé par llfister
La méthode telephonyBillDetailsCSV nous permettait d'exporter un fichier CSV avec un certain nombres d'informations en spécifiant si nous souhaitions les appels reçus ou émis.
L'équivalent correspond à /telephony/{billingAccount}/historyConsumption/{date}/document?extension=csv
De quelle manière doit-on procéder pour préciser si nous voulons les appels reçus ou émis?

Merci

Il manque effectivement les appels entrant avec cette fonction actuellement.
J'ai remonté le défaut en interne.

Tout comme bertranddcs, je t'invite a créer un ticket support et a me donner le numéro de ticket. Je l'attacherais à la tache interne pour que tu sois prévenu de la résolution.

LouisM
15/01/2016, 14h24
Citation Envoyé par bertranddcs
Bonjour,

la fonction "/telephony/{billingAccount}/conference/{serviceName}/participants" ne fonctionne pas (elle renvoie systématiquement un tableau vide pour les id des participants alors que pour une conférence démarrée, la fonction "/telephony/{billingAccount}/conference/{serviceName}/informations" va bien indiquer le nombre de participants connectés)

pouvez-vous corriger ce problème afin que nous achevions notre migration vers l'API V6

Cordialement,
Merci pour le retour.
J'ai remonté le défaut en interne.

Je t'invite a créer un ticket support et a me donner le numéro de ticket. Je l'attacherais à la tache interne pour que tu sois prévenu de la résolution.
Je n'ai pas de délais actuellement pour la correction de ce défaut.

llfister
15/01/2016, 14h03
Bonjour,

La méthode telephonyBillDetailsCSV nous permettait d'exporter un fichier CSV avec un certain nombre d'informations en spécifiant si nous souhaitions, les appels reçus ou émis.
L'équivalent correspond à /telephony/{billingAccount}/historyConsumption/{date}/document?extension=csv
De quelle manière doit-on procéder pour préciser si nous voulons les appels reçus ou émis?

Merci

romain.beuque
15/01/2016, 11h37
Bonjour frame,
Citation Envoyé par frame
Tout est clair, mais je pense que d'une certaine manière, vous devriez aussi permettre de recuperer la liste des anciens contacts "nicOwner" (via" GET /me/contact") cree precedement.
Citation Envoyé par frame
Comme tu peut voir le whoisOwner a le format d'un compte OVH mais dans la description de GET /domain/{serviceName} sur le whoisOwner est note que tu peut editer les info via /me/contact/ qui est pas tout correct.
Nous cherchons actuellement à migrer en interne tous les anciens nicOwner qui étaient au format xx12345-ovh vers le nouveau format /me/contact/xxx. Cette migration se fait de manière itérative (actuellement 30% des contacts migrés): cela explique que pour certains services que tu récupères dans /domain/ , le whoisNicOwner est en xx12345-ovh et d'autres sont en /me/contact/xxx

Si tu as besoin de pouvoir récupérer tous tes nicOwner sous le nouveau format pour pouvoir les consulter, n'hésites pas à me contacter en privé pour qu'on envisage de forcer la migration pour ton nichandle (tu peux me contacter en privé par email en ajoutant @corp.ovh.com à mon pseudo ).

Citation Envoyé par frame
J'ai aussi découvert que la liste de nameservers (récupéré via /domain/{serviceName}/nameserver) est toujours dans l'ordre inverse (au premier le NS secondaire et apres le principale). C'est normale?
De ce que m'a confirmé l'équipe domaines, théoriquement il n'y a pas d'ordre dans la liste des nameservers (un vieu mythe semblerait-il....).

Bonne journée,

vcasse
15/01/2016, 10h38
Citation Envoyé par ZeDvD
J'ai vu, et implémenté, ça a l'air de marcher mais je dois faire d'autres tests. C'est le refresh final qui me manquait.

En ce qui concerne l'API V6, pour le moment j'ai laissé tombé car mon API cURL a l'air de fonctionner correctement maintenant que les paramètres du GET fonctionnent, et surtout je n'ai pas d'exceptions type guzzle à gérer, donc ça marche mieux. Pour les tutos, je pourrai mettre quelques exemples de codes pour ceux qui ont besoin

Merci.
Prfait pour la documentation Je vais donc en rediger d'autres sur le même format.

N'hésites pas à poster tes exemples avec Curl directement, ca peut intéresser d'autres clients (Si tu les mets sur un github, on peut même contribuer )

Cordialement,
Vincent

frame
15/01/2016, 09h28
Bonjour Romain,
Je suis désolé, mais je dois d'insister un peu plus sur le sujet. La confusion vient de la documentation (ou de l'absence de celle-la).

Je appelle le GET /domain/{serviceName} et je recupere:

{
owoSupported: true
glueRecordIpv6Supported: true
transferLockStatus: "locked"
offer: "gold"
whoisOwner: "XX123456-ovh"
dnssecSupported: true
parentService: null
domain: "domain.tld"
lastUpdate: "2015-06-13T07:21:08+02:00"
glueRecordMultiIpSupported: true
nameServerType: "external"
}
Comme tu peut voir le whoisOwner a le format d'un compte OVH mais dans la description de GET /domain/{serviceName} sur le whoisOwner est note que tu peut editer les info via /me/contact/ qui est pas tout correct.

whoisOwner: {
fullType: "string"
canBeNull: 0
type: "string"
description: "Contact Owner (you can edit it via /me/contact/)"
readOnly: 1
}
En plus, il est clair que les types ne sont pas compatibles, parce que le whoisOwner est une String alors que le contact id de /me/contact/{contactId} est un long.

Cette situation est seulement pour les domaines créés avec l'ancienne interface SOAP? Comment va ressembler le whoisOwner des domaines créés avec la nouvelle interface APIv6?

Merci
F.

ZeDvD
14/01/2016, 18h50
Citation Envoyé par vcasse
Essaie ce try catch :

J'espère que ca va t'aider ! N'hésites pas si tu as encore des soucis.
Et je pense à toi pour les tutos.

D'ailleurs, as tu lu https://github.com/ovh/php-ovh/blob/...redirection.md ?

Vincent
J'ai vu, et implémenté, ça a l'air de marcher mais je dois faire d'autres tests. C'est le refresh final qui me manquait.

En ce qui concerne l'API V6, pour le moment j'ai laissé tombé car mon API cURL a l'air de fonctionner correctement maintenant que les paramètres du GET fonctionnent, et surtout je n'ai pas d'exceptions type guzzle à gérer, donc ça marche mieux. Pour les tutos, je pourrai mettre quelques exemples de codes pour ceux qui ont besoin

Merci.

frame
14/01/2016, 17h06
Citation Envoyé par romain.beuque
Non, ce n'est plus possible, à moins d'avoir une consumerKey qui t'identifie en tant que XX123455-OVH.
Tout est clair, mais je pense que d'une certaine manière, vous devriez aussi permettre de recuperer la liste des anciens contacts "nicOwner" (via" GET /me/contact") cree precedement.

J'ai aussi découvert que la liste de nameservers (récupéré via /domain/{serviceName}/nameserver) est toujours dans l'ordre inverse (au premier le NS secondaire et apres le principale). C'est normale?

llfister
14/01/2016, 17h04
La méthode telephonyBillDetailsCSV nous permettait d'exporter un fichier CSV avec un certain nombres d'informations en spécifiant si nous souhaitions les appels reçus ou émis.
L'équivalent correspond à /telephony/{billingAccount}/historyConsumption/{date}/document?extension=csv
De quelle manière doit-on procéder pour préciser si nous voulons les appels reçus ou émis?

Merci

s.berry
14/01/2016, 17h04
Bonjour la team OVH !

Je ne comprends pas bien cette partie de la documentation : "To communicate with APIs, the SDK uses a token on each request to identify the user. This token is called Consumer Key. To have a validated Consumer Key, you need to redirect your user on specific authentication page. Once the user has logged in, the token is validated and user will be redirected on $redirection url."

A chaque appel l'utilisateur a besoin de se connecter ?
Je n'arrive pas à passer au-delà de l'erreur "401 : You must login first"

En gros dans mon interface mail je vais proposer à mes clients de récupérer des informations sur l'état de leur répondeur / alias / etc.. ou d'autres opération mais c'est sur mon compte OVH donc ils ne connaissent pas les login/pwd d'accès. (logique me direz-vous)

EDIT : j'ai compris par moi même qu'il y avait une erreur qui s'était glissé dans mon code...

Par contre le processus de génération de la consumer key n'est pas très explicite ... Je l'ai résumé de cette façon dans mon code si ça peut en aider d'autres :
Code:
/**
	 * Fonction utilisée pour récupérer la consumerKey.
	 *
	 * rights = array( (object) [
	 *		'method' => 'GET',
	 *		'path'   => '/*'
	 *	], (object) [
	 *		'method' => 'POST',
	 *		'path'   => '/*'
	 *	], (object) [
	 *		'method' => 'PUT',
	 *		'path'   => '/*'
	 *	], (object) [
	 *		'method' => 'DELETE',
	 *		'path'   => '/*'
	 *	]);
	 *	$credentials = $this->requestCredentials($rights);
	 *
	 * Se rendre sur l'URL $credentials->validationUrl et valider les droits demandés
	 * Attention, pour récupérer la consumer key à enregistrer, afficher : $credentials->consumerKey et remplacez sa valeur dans la classe
	 *
	 * @param array  $accessRules list of rules your application need.
	 * @param string $redirection url to redirect on your website after authentication
	 *
	 * @return mixed
	 */
	public function requestCredentials(array $accessRules, $redirection = null) {
		$parameters              = new StdClass();
		$parameters->accessRules = $accessRules;
		$parameters->redirection = $redirection;

		$response = $this->call('POST', '/auth/credential', $parameters, false);

		$this->consumerKey = $response->consumerKey;
		return $response;
	}
J'ai ensuite eu un problème d'INVALIDE SIGNATURE réglé grâce au poste de romain.beuque en page 10. Ce problème est lié à l'utilisation de la librairie cURL.

Merci

romain.beuque
14/01/2016, 16h49
Citation Envoyé par frame
Donc si j'ai bien compris, maintenant c'est plus possible de recuperer les information sur les "ancienne" contact handler (format string XX123455-OVH)?
Non, ce n'est plus possible, à moins d'avoir une consumerKey qui t'identifie en tant que XX123455-OVH.

bertranddcs
14/01/2016, 16h28
Bonjour,

Ma question semble être passée à la trappe, pouvez-vous m'apporter une réponse SVP

Citation Envoyé par bertranddcs
Bonjour,

la fonction "/telephony/{billingAccount}/conference/{serviceName}/participants" ne fonctionne pas (elle renvoie systématiquement un tableau vide pour les id des participants alors que pour une conférence démarrée, la fonction "/telephony/{billingAccount}/conference/{serviceName}/informations" va bien indiquer le nombre de participants connectés)

pouvez-vous corriger ce problème afin que nous achevions notre migration vers l'API V6

Cordialement,

frame
14/01/2016, 16h23
Citation Envoyé par romain.beuque
OK. Je pense que j'ai compris le cas d'utilisation.

Il y deux solutions qui demandent de ce que tu veux vraiment faire avec ces comptes: le compte créés via nicCreate étaient-ils utilisé en tant que nicOwner, ou bien en tant que nicAdmin, nicTech, nicBilling.

Si c'est juste pour un nicOwner, on ne doit pas utiliser nicCreate mais POST /me/contact. Il s'agit d'un contact, qui n'a pas de mot de passe, et ne pourra pas se connecter dans le manager. Ce contact est rattaché au compte client avec lequel il a été crée via l'API. Il sera visible dans la liste des contacts (GET /me/contact) et les informations pourront être récupérés via GET /me/contact/xxxx. Il convient par la suite d'utiliser le contact crée lors de la commande en indiquant son identifiant (/me/contact/xxxx).

Si c'est dans le cas un nicTech, nicBilling, nicAdmin; ces opérations nécessitent un compte client, et de pouvoir se connecter au Manager.
Il faudra créer un nouveau compte client via POST /newAccount. Une fois le compte client crée, tu recevras une consumerKey, qui est une clé de connexion à l'APIv6. Tu pourras ainsi récupérer les informations à propos de ce compte client en te connectant avec la consumerKey et en faisant un appel à /me

J'espère avoir pu répondre à ta question
Romain
Merci Romain,
merci pour l'explications.

Oui, il s'agit bien de nicOwner et en effet j'avait deja compri l'utilizations des nouvelle methode pour creer le contacts (POST /me/contact) et pour le consulter (GET /me/contact/xxxx).

Donc si j'ai bien compris, maintenant c'est plus possible de recuperer les information sur les "ancienne" contact handler (format string XX123455-OVH)?
C'est correct?

F.

romain.beuque
14/01/2016, 16h04
OK. Je pense que j'ai compris le cas d'utilisation.

Il y deux solutions qui demandent de ce que tu veux vraiment faire avec ces comptes: le compte créés via nicCreate étaient-ils utilisé en tant que nicOwner, ou bien en tant que nicAdmin, nicTech, nicBilling.

Si c'est juste pour un nicOwner, on ne doit pas utiliser nicCreate mais POST /me/contact. Il s'agit d'un contact, qui n'a pas de mot de passe, et ne pourra pas se connecter dans le manager. Ce contact est rattaché au compte client avec lequel il a été crée via l'API. Il sera visible dans la liste des contacts (GET /me/contact) et les informations pourront être récupérés via GET /me/contact/xxxx. Il convient par la suite d'utiliser le contact crée lors de la commande en indiquant son identifiant (/me/contact/xxxx).

Si c'est dans le cas un nicTech, nicBilling, nicAdmin; ces opérations nécessitent un compte client, et de pouvoir se connecter au Manager.
Il faudra créer un nouveau compte client via POST /newAccount. Une fois le compte client crée, tu recevras une consumerKey, qui est une clé de connexion à l'APIv6. Tu pourras ainsi récupérer les informations à propos de ce compte client en te connectant avec la consumerKey et en faisant un appel à /me

J'espère avoir pu répondre à ta question
Romain

frame
14/01/2016, 15h00
Citation Envoyé par romain.beuque
Bonjour frame,
Peux-tu nous dire qu'elle est l'usage dont tu as besoin exactement ?
La fonction nicInfo ne renvoie que les informations du compte connecté, je ne vois pas quelles sont les informations qui diffèrent avec /me .

Quand tu indiques "un contact que j'ai crée", es-ce un compte client en xx1234-ovh ou un contact /me/contact ?
La fonction SoAPI nicPublicInfo permettait de récupérer des informations sur un autre compte client : c'est de ça dont tu parles ?

Cordialement
Merci pour la reponse Romain!

Nous avons toujour utilisé la méthode "nicInfo" pour récupérer les infos sur les contacts (peut-être le nouvel nom est compte client) créé avec la méthode "nicCreate".

Le résultat de "nicCreate" était un "contact id handler" dans le format xx1234-ovh et sur la description sur les API soap s'est marque "Create a new contact handle".

Tu peut controler la signature de la méthode nicInfo e confirmer qui accepte un Nic Handler ID:
http://www.ovh.com/soapi/en/?method=nicInfo

Comment nous récupérons ne l'info sur le contact de Type xx1234-ovh?

vcasse
14/01/2016, 14h44
Citation Envoyé par ZeDvD
Je suis en train d'essayer d'utiliser l'API officielle. Comment doit-on traiter les exceptions guzzle ?
Voici un exemple concret : je teste la disponibilité d'un nom de domaine

try
{
// Recuperation d'un ID de commande
$resp = $ovh->post('/order/cart', array(
'ovhSubsidiary' => 'FR'
)
);
$l_cart_id = $resp ["cartId"];

// recuperation des infos de domaine
$resp = $ovh->get('/order/cart/'.$l_cart_id.'/domain/', array(
'domain' => $p_domain
)
);

$l_return = $resp[0]["orderable"];
}
catch (GuzzleHttp\Exception\ClientException $e)
{
$l_return = false;
}
catch (GuzzleHttp\Ring\Exception\ConnectException $e)
{
$l_return = false;
}



Malgré ça, j'ai cette erreur (parfois - c'est aléatoire):
Fatal error: Uncaught exception 'GuzzleHttp\Ring\Exception\ConnectException' with message 'cURL error 28: Operation timed out after 1014 milliseconds with 0 bytes received' in ...

Le try catch n'est pas bon ???
Essaie ce try catch :
Code:
try {
        $recordIds = $conn->get('/domain/zone/' . $domain . '/record');
} catch ( \GuzzleHttp\Exception\ConnectException $ex ) {
        print_r( $ex->getMessage() );
}
Ce que j'ai changé :
- le \ devant GuzzleHttp
- J'affiche le message retourné, pas toute la trace (souvent c'est plus lisible). Je te conseille de faire çà surtout pour l'exception \GuzzleHttp\Exception\ClientException. C'est l'exception retournée quand l'api indique une erreur.

Pour le ConnecException, il est causé par une erreur retournée suite à un timeout trop court. En gros, l'API met trop de temps à te répondre. Si tu utilises la version 2 du wrapper (sorti cette semaine : https://github.com/ovh/php-ovh/relea...dencies.tar.gz), tu peux changer le timeout comme cela:


Code:
use \Ovh\Api;
use GuzzleHttp\Client;

[....]

$http_client = new Client([
        'timeout'         => 30,
        'connect_timeout' => 5,
]);  

$conn = new Api(    $applicationKey,
                    $applicationSecret,
                    $endpoint,
                    $consumer_key,
                    $http_client);
Si tu utilises encore la version 1, voici le code :

Code:
use \Ovh\Api;
use GuzzleHttp\Client;

[....]

$http_client = new Client();
$http_client->setDefaultOption('timeout', 30);
$http_client->setDefaultOption('connect_timeout', 5);

$conn = new Api(    $applicationKey,
                    $applicationSecret,
                    $endpoint,
                    $consumer_key,
                    $http_client);
J'espère que ca va t'aider ! N'hésites pas si tu as encore des soucis.
Et je pense à toi pour les tutos.

D'ailleurs, as tu lu https://github.com/ovh/php-ovh/blob/...redirection.md ?

Cordialement,
Vincent

- - - Mise à jour - - -

Citation Envoyé par llfister
Merci pour la réponse.
Je sais à quoi sert la modération, mais aucun de mes messages n'apparaissaient depuis hier, d'où mon impatience.
J'ai validé tes messages ce matin. Je crois que tu es passé entre les mailles des modérateurs. Désolé pour cela

Cordialement,
Vincent

romain.beuque
14/01/2016, 13h58
Bonjour frame,
Peux-tu nous dire qu'elle est l'usage dont tu as besoin exactement ?
La fonction nicInfo ne renvoie que les informations du compte connecté, je ne vois pas quelles sont les informations qui diffèrent avec /me .

Quand tu indiques "un contact que j'ai crée", es-ce un compte client en xx1234-ovh ou un contact /me/contact ?
La fonction SoAPI nicPublicInfo permettait de récupérer des informations sur un autre compte client : c'est de ça dont tu parles ?

Cordialement

frame
14/01/2016, 13h48
Bonjour,
nous aimons bien la nouvelle interface REST, mais, comme d'autres nous pensons aussi que des améliorations majeures doivent être effectuées, dans la planification de la fermeture de l'API SOAP et dans la documentation.

Nous avons intégré avec succès l'API php fourni sur github, mais probablement pour la majorité des gens de la solution CURL serait plus facile à intégrer.

Nous essayons maintenant de mettre en œuvre correctement les funcionalities nous avons utilize sur soap (principalement liés de domaine), mais il ya des fonctionnalités qui ne sont pas pleinement realize.

Dans la page Web pour la migration est marque que le function nicInfo est remplacé par la methode /me, mais je ne pense pas est correcte, car avec /me, je peux récupérer uniquement mes coordonnées et je ne peux pas voir les informations relatives à un contact que je ai créé .

Je ne comprends pas pourquoi l'autre méthode /me/contact retourne une liste vide de valeurs long et nous ne pouvons pas utiliser la méthode /me/contact/{contactID} parce que nécessite une valeur long.

L'ID de contact classique est normalement sous la forme XX123456-OVH. Comment pouvons-nous recuperer ces contacts?

Comment pouvons-nous obtenir des informations sur un contact?

Merci
F.

llfister
14/01/2016, 11h14
Merci pour la réponse.
Je sais à quoi sert la modération, mais aucun de mes messages n'apparaissaient depuis hier, d'où mon impatience.

romain.beuque
14/01/2016, 10h59
Bonjour à tous,

Citation Envoyé par ZeDvD
C'est ça. Mon compte prepaid est toujours approvisionné, pas possible de le rendre vide puisque je m'en sers au quotidien.
Vincent (vcasse) a remonté le besoin à l'équipe concerné. On te tient au courant.

Citation Envoyé par ZeDvD
Du coup je vous recommande de mettre à jour la doc qui est fausse ici : https://api.ovh.com/g934.first_step_with_api - chapitre "Signing requests". Il faut prendre en compte ce cas GET qui est particulier et ce n'est pas indiqué.
Noté

Citation Envoyé par llfister
Je peux savoir pourquoi mes moultes messages sont modérés?!
Les messages passent en modération pour lutter contre le spam si je ne m'abuse.

Citation Envoyé par llfister
Pour la énième fois, BONJOUR!

Une fois qu'un token a été créé via https://eu.api.ovh.com/createToken/
est-il possible de revenir dessus pour ajouter des fonctions par exemple? Si oui, de quelle manière?

Aujourd'hui, j'utilise la méthode TelephonyCallList pour avoir TOUS les appels reçus/émis, avec pour seul paramètre le numéro de ligne.
Son équivalent correspond à /telephony/{billingAccount}/service/{serviceName}/voiceConsumption/{consumptionId} ce qui nécessite, en plus du numéro de ligne, un numéro de facture (donc les appels reçus/émis sur un mois).
Cela veut donc dire, que je dois d'abord utiliser /telephony/{billingAccount}/service/{serviceName}/voiceConsumption pour récupérer la liste des numéro de facture, que je vais ensuite passer dans une boucle pour avoir le résultat que me donnait TelephonyCallList?
Et ça veut également dire que je dois créer un token pour chaque numéro de facture?!

... Ou alors je n'ai absolument rien compris.
Normalement, en créant un token avec des droits du style:
Code:
GET /telephony*
POST /telephony*
PUT /telephony*
DELETE /telephony*
Ca devrait fonctionner. Ces droits donneront au script l'autorisation de faire des appels sur toutes les fonctions telephony.
Il est également possible de mettre GET * - POST * etc... pour donner au script l'accès à toutes les fonctions du compte client.

llfister
14/01/2016, 09h50
Pour la énième fois, BONJOUR!

Une fois qu'un token a été créé via https://eu.api.ovh.com/createToken/
est-il possible de revenir dessus pour ajouter des fonctions par exemple? Si oui, de quelle manière?

Aujourd'hui, j'utilise la méthode TelephonyCallList pour avoir TOUS les appels reçus/émis, avec pour seul paramètre le numéro de ligne.
Son équivalent correspond à /telephony/{billingAccount}/service/{serviceName}/voiceConsumption/{consumptionId} ce qui nécessite, en plus du numéro de ligne, un numéro de facture (donc les appels reçus/émis sur un mois).
Cela veut donc dire, que je dois d'abord utiliser /telephony/{billingAccount}/service/{serviceName}/voiceConsumption pour récupérer la liste des numéro de facture, que je vais ensuite passer dans une boucle pour avoir le résultat que me donnait TelephonyCallList?
Et ça veut également dire que je dois créer un token pour chaque numéro de facture?!

... Ou alors je n'ai absolument rien compris.

llfister
14/01/2016, 08h49
Je peux savoir pourquoi mes moultes messages sont modérés?!

ZeDvD
13/01/2016, 21h59
Citation Envoyé par romain.beuque
Sinon, pour le format de la signature qui est incorrecte avec cURL lors des appels GET, j'ai bidouillé un peu le wrapper python pour afficher la tête de la signature lors d'un appel, et l'on me retourne :

Code:
AK+CK+GET+https://api.ovh.com/1.0/order/cart/LECARTIDLECARTID/domain?domain=fdsjfhdsjfhdsfs.com++1452677877
Il faut ainsi signer les paramètres des méthodes GET dans l'URL, tel que l'appel est fait vers l'API, et non pas dans le body.
Merci de me dire si tu as toujours l'erreur en utilisant cette technique de signature
OK, en première approche, j'ai l'impression que ça marche mieux : la signature est correcte si les paramètres sont dans l'URL, j'ai modifié la classe CURL pour cela. Du coup je vous recommande de mettre à jour la doc qui est fausse ici : https://api.ovh.com/g934.first_step_with_api - chapitre "Signing requests". Il faut prendre en compte ce cas GET qui est particulier et ce n'est pas indiqué.

Du coup, si certains veulent la classe CURL, qu'ils me le disent et je la posterai ici.

Je continue à tester le wrapper PHP en parallèle, mais comme j'ai des fatal error de manière aléatoire et incompréhensibles (voir mes précédents messages), CURL marche mieux pour le moment ...

ZeDvD
13/01/2016, 18h52
Citation Envoyé par vcasse
Bonjour ZeDvd,

Peux tu me remonter l'intégralité des exceptions guzzle que tu reçois ? Il y a peut être des améliorations à apporter au wrapper !
catch (GuzzleHttp\Exception\ClientException $e)
catch (GuzzleHttp\Ring\Exception\ConnectException $e)


Pourquoi les catch ne marchent pas ? Peut-on éviter ce fatal error ?

ZeDvD
13/01/2016, 18h45
Citation Envoyé par romain.beuque
En gros, si tu n'as pas reçu la réponse que j'avais mis en screenshot dans mon message précédent, c'est pas bon.
Rien dans le dossier spam ?
Non. Je reçois des mails de la ML, pas les réponses à mes questions

Citation Envoyé par romain.beuque
Quel est le véritable use case pour ces fonctions de tests : es-ce juste pendant l'étape de programmation pour vérifier que tu tapes bien sur la bonne fonction d'API avec les bons paramètres, et c'est un autre usage ?
C'est ça. Mon compte prepaid est toujours approvisionné, pas possible de le rendre vide puisque je m'en sers au quotidien.

romain.beuque
13/01/2016, 18h34
Citation Envoyé par ZeDvD
Je vois passer plein de messages de mailing depuis deux jours seulement, mais aucune réponse à mes questions, uniquement les réponses des autres. Est-ce normal ?
En gros, si tu n'as pas reçu la réponse que j'avais mis en screenshot dans mon message précédent, c'est pas bon.
Rien dans le dossier spam ?

Citation Envoyé par ZeDvD
J'ai le même problème avec Prepaid : comment puis-je tester que mes scripts de renouvellement de domaine fonctionne sans dépenser de l'argent ? Je ne vais pas lancer 10 renouvellement de noms de domaine pour tout valider, à chaque fois ça va débiter mon compte prepaid. Donc comment tester sans payer ?
Actuellement, les fonctions testables pour l'API de commande de domaine vont jusqu'à la génération du bon de commande.
Une fois le bon de commande généré, il faut donc vérifier que tout est correct, qu'il n'y a pas d'erreur.

La fonction POST /me/order//payWithRegisteredPaymentMean génère un vrai paiement via le compte OVH ou le compte fidélité. Il n'y a pas de partie test pour cette méthode disponible actuellement. Si le numéro de bon de commande est valide et le moyen de paiement suffisamment approvisionné, il n'y a pas d'erreur possible de ton côté.

Quel est le véritable use case pour ces fonctions de tests : es-ce juste pendant l'étape de programmation pour vérifier que tu tapes bien sur la bonne fonction d'API avec les bons paramètres, et c'est un autre usage ?
Si c'est la première réponse, je dirais que pour faire les tests, il convient d'appeler la fonction en sachant au préalable que le compte OVH ou fidélité n'est pas assez approvisionné, et tu es censé récupérer une erreur du type: "Votre compte n'est pas suffisamment approvisionné" : cela prouvera que l'appel est correctement effectué, et que lorsque ce dernier sera approvisionné correctement, le bon de commande sera payé.

Si c'est un autre usage, n'hésites pas à me l'expliquer, que je puisse faire remonter le besoin à l'équipe ayant conçu la fonction payWithRegisteredPaymentMean

Bonne soirée!

vcasse
13/01/2016, 18h21
Bonjour ZeDvd,

Peux tu me remonter l'intégralité des exceptions guzzle que tu reçois ? Il y a peut être des améliorations à apporter au wrapper !

Pour la création de redirection, voici le tuto que nous venons de rédiger (avec l'aide de l'équipe domaine): https://github.com/ovh/php-ovh/blob/...redirection.md
Désolé, c'est en anglais, mais nous nous devons de les rédiger de manière à ce que le plus grand nombre puisse le lire. Le niveau d'anglais n'est pas trés élevé/ Si tu as encore des questions, n'hésites pas.

Pour les APIs en testing, j'ai remonté le besoin.

J'ai bien noté ta liste d'appels que tu utilises. Je vais essayer de rédiger des tutos pour l'utilisation du wrappers avec ces fonctions dans les jours qui viennent.

Merci pour tes remontées
Bien cordialement,
Vincent

ZeDvD
13/01/2016, 17h33
Citation Envoyé par vcasse
Bonjour ZeDvd,

Nous comprenons trés bien vos problématiques. Je vous pris de croire qu'elle ont été remontée en interne. C'est d'ailleurs pour cela que nous vous accompagnons. Il est possible que quelques messages passent à la trappe, mais l'outil de forum n'est pas obligatoirement le plus efficace dans ces cas.

Pour le soucis d'API de test, si je résume, le besoin est crucial sur les appels qui gérent de l'argent. Est ce bien cela ?
Dans tous les cas, nous remontons le besoin.

Pour reprendre les demandes précédentes :
1/ Pouvez vous m'envoyer le code avec curl que l'on aide à débugguer ? (sans AK / AS / CK bien entendu )
2/ Nous préparons actuellement un tuto sur les redirections
3/ As tu d'autres appels SoAPI que tu vas devoir migrer ?

Cordialement,
Vincent
En effet, il faut une API de test pour les besoins "argent".
Je suis en train de tester avec l'API officielle, mais je suis emmerdé par les exceptions guzzle qui surviennent aléatoirement, problème qu'on n'a pas avec CURL. Voir mon message précédent

Voici mes premiers besoins identifiés :

Creation multi-domaine
Destruction multi-domaine
Information multi-domaine
Information domaine
creation redirection
Test si un domaine existe
Ajout mail redirection
Suppression mail redirection
Liste mails redirection
Ajout mail a mailing liste
Suppression mail de mailing liste
Liste mail de mailing liste
Creation nic handle
Infos nic handle
Prepaid create domain
Prepaid infos
Prepaid renew domain
Subdomain Create
Subdomain Delete
Subdomain List

ZeDvD
13/01/2016, 17h21
Je suis en train d'essayer d'utiliser l'API officielle. Comment doit-on traiter les exceptions guzzle ?
Voici un exemple concret : je teste la disponibilité d'un nom de domaine

try
{
// Recuperation d'un ID de commande
$resp = $ovh->post('/order/cart', array(
'ovhSubsidiary' => 'FR'
)
);
$l_cart_id = $resp ["cartId"];

// recuperation des infos de domaine
$resp = $ovh->get('/order/cart/'.$l_cart_id.'/domain/', array(
'domain' => $p_domain
)
);

$l_return = $resp[0]["orderable"];
}
catch (GuzzleHttp\Exception\ClientException $e)
{
$l_return = false;
}
catch (GuzzleHttp\Ring\Exception\ConnectException $e)
{
$l_return = false;
}



Malgré ça, j'ai cette erreur (parfois - c'est aléatoire):
Fatal error: Uncaught exception 'GuzzleHttp\Ring\Exception\ConnectException' with message 'cURL error 28: Operation timed out after 1014 milliseconds with 0 bytes received' in ...

Le try catch n'est pas bon ???

llfister
13/01/2016, 16h45
Une fois le token créé en passant par https://eu.api.ovh.com/createToken/ est-ce qu'il est possible de revenir dessus pour y ajouter des fonctions? Si oui, comment?

Aujourd'hui j'utilise la méthode TelephonyCallList qui ne nécessite en paramètre qu'un numéro de ligne et qui a pour équivalent /telephony/{billingAccount}/service/{serviceName}/voiceConsumption/{consumptionId}
D'où suis-je censée trouver l'id de facture? Je suis obligée de passer par la fonction /telephony/{billingAccount}/service/{serviceName}/voiceConsumption qui me donne la liste complète des id facture, pour ensuite faire une boucle?
Et pour le token ça se passe comment? Je vais devoir mettre le path avec chaque id facture?

vcasse
13/01/2016, 16h24
Bonjour ZeDvd,

Nous comprenons trés bien vos problématiques. Je vous pris de croire qu'elle ont été remontée en interne. C'est d'ailleurs pour cela que nous vous accompagnons. Il est possible que quelques messages passent à la trappe, mais l'outil de forum n'est pas obligatoirement le plus efficace dans ces cas.

Pour le soucis d'API de test, si je résume, le besoin est crucial sur les appels qui gérent de l'argent. Est ce bien cela ?
Dans tous les cas, nous remontons le besoin.

Pour reprendre les demandes précédentes :
1/ Pouvez vous m'envoyer le code avec curl que l'on aide à débugguer ? (sans AK / AS / CK bien entendu )
2/ Nous préparons actuellement un tuto sur les redirections
3/ As tu d'autres appels SoAPI que tu vas devoir migrer ?

Cordialement,
Vincent

ZeDvD
13/01/2016, 16h03
Citation Envoyé par vcasse
Bonjour ZeDvD,

Keep calm please. Il me semble qu'on apporte des réponses depuis le début de ce topic. Peut être pas aussi vite que tu le souhaites, mais nous tentons de répondre à l'ensemble des messages
Très simple pour vous de dire "keep calm", moi ce que je vois c'est qu'en septembre on m'a forcé un passage à PHP 5.4, plusieurs dizaines de sites à migrer. Là on me donne 3 mois pour migrer tous mes fichiers de Soap vers l'API V6, sans aucune explication claire, sans tuto, tout en anglais. Plusieurs questions que j'ai posées sont restées sans réponse.

Ca fait 3 semaines que je passe toutes mes WE et mes soirées à reprogrammer mes fichiers, c'est autant de manque à gagner pour ma société, autant de temps perdu. Donc difficile de garder son calme dans ces conditions, n'importe qui peut comprendre ça. Et je pense pas être le seul dans ce cas là. Donc merci de vous mettre à place, et pensez à vos clients : on ne passe pas nos journées à rien faire, donc du temps pour reprogrammer une API, c'est du temps perdu, du manque à gagner pour une boite. Si vous nous forcez à migrer de techno, donnez-nous les moyens d'aller vite : des tutos en Français, des réponses claires et rapides, des installations rapide, n'imposez pas de framework (je n'ai pas envie de me prendre la tête avec composer...). Là ça n'est pas le cas, je suis désolé de le dire !

- - - Mise à jour - - -

Citation Envoyé par romain.beuque
Bonjour ZeDvD,
Concernant ton message sur la mailing-list, j'y ai répondu, dans l'heure (ouvrée) si je ne m'abuse. cf http://demo.ovh.eu/fr/c56f049c1c2f553386d4ffdeba2c547d/
Merci de me dire si tu l'as bien reçu, et de revenir vers moi par rapport à ma question.
Je vois passer plein de messages de mailing depuis deux jours seulement, mais aucune réponse à mes questions, uniquement les réponses des autres. Est-ce normal ?

- - - Mise à jour - - -

Citation Envoyé par vcasse
Bonjour s.berry,

Nous ne proposons pas d'API de test : beaucoup de réponses d'API sont dépendantes d'actions sur des infrastructures.
Si tu as des tests à effectuer, nous t'invitons à les faire sur des produits non critique.

Tu aurais voulu tester quel appel précisémement ?

Cordialement,
Vincent
J'ai le même problème avec Prepaid : comment puis-je tester que mes scripts de renouvellement de domaine fonctionne sans dépenser de l'argent ? Je ne vais pas lancer 10 renouvellement de noms de domaine pour tout valider, à chaque fois ça va débiter mon compte prepaid. Donc comment tester sans payer ?

s.berry
13/01/2016, 15h42
Bonjour vcasse,

D'accord, dommage. C'est dans le cadre de la mise en place d'un service qui appelle anciennement "orderEmailMxPlan" qui correspond à "/order/email/domain/new/" dans la nouvelle API. Avez-vous plus de renseignements que votre collègue sur cet appel avec la disparition du paramètre "payWithPoints" ? Et comment faire pour utiliser les points lors de la commande ?

Merci

llfister
13/01/2016, 15h16
Bonjour,

Une fois qu'on a créé un token via https://eu.api.ovh.com/createToken/
Est-il possible de revenir sur le token créé pour ajouter des fonctions?

J'utilisais la fonction TelephonyCallList dans laquelle je ne passais qu'un numéro de ligne comme paramètre. Aujourd'hui, la fonction équivalente est /telephony/{billingAccount}/service/{serviceName}/voiceConsumption/{consumptionId}
Qui requière désormais l'id d'une facture... Cela veut-dire qu'avant d'utiliser cette fonction je suis obligée de passer par l'autre fonction qui fournit la liste des id facture /telephony/{billingAccount}/service/{serviceName}/voiceConsumption ??

Merci d'avance...

llfister
13/01/2016, 14h50
Bonjour,

Une fois qu'un token a été créé via https://eu.api.ovh.com/createToken/
est-il possible de revenir dessus pour ajouter des fonctions par exemple? Si oui, de quelle manière?

Merci d'avance!

vcasse
13/01/2016, 11h42
Bonjour s.berry,

Nous ne proposons pas d'API de test : beaucoup de réponses d'API sont dépendantes d'actions sur des infrastructures.
Si tu as des tests à effectuer, nous t'invitons à les faire sur des produits non critique.

Tu aurais voulu tester quel appel précisémement ?

Cordialement,
Vincent

s.berry
13/01/2016, 11h30
Citation Envoyé par s.berry
Merci MaxV pour vos réponses !

J'attendrais votre retour concernant le paiement par points lors de la commande de MXPlan alors
J'ai une question concernant le test de l'API. Je vais devoir tester le bon fonctionnement de mes appels dont la commande de MXPlan, mais lors de ces tests je ne veux bien évidemment pas réellement passer de commande. Est-ce qu'il y a un moyen de faire des appels en mode "test" ou un compte spécifique / une configuration à mettre en place ?

Merci d'avance !
Bonjour

Ma question est peut-être passée inaperçue avec les énervements qui ont suivi, pourriez-vous m'indiquer s'il y a un moyen de tester l'API avec un compte de test ?

Merci !

romain.beuque
13/01/2016, 11h03
Citation Envoyé par kinglouis
Bonjour,

Merci d'avoir mis en place cet espace de discussion, je suis content de voir que je ne suis pas le seul à galérer avec tout ça mais que la team OVH est là pour répondre !

J'utilise SoAPI pour commander, installer, renouveler des noms de domaine de manière automatique (dans le cadre d'une plateforme de blogs avec abonnement premium pour ceux qui veulent un domaine).

1 - Comment s'authentifier de manière automatique, via serveur, sans avoir d'url de validation à appeler dans le navigateur web ? Faut-il appeler l'url de validation via le serveur ?
Bonjour kinglouis,
Effectivement il est possible de s'authentifier de manière automatique, deux solutions:
* soit tu crée des tokens unique pour ton script via cette page : https://eu.api.ovh.com/createToken/ (sûrement la méthode la plus simple)
* soit tu t'authentifie une fois via l'URL, puis tu affiches via ton script le Consumer Key associé à la session actuelle. Si tu n'as pas mis de durée de validité du consumer key, cette dernière restera valable à vie, et tu pourras la réutiliser à chaque fois.

Citation Envoyé par kinglouis
2 - Pour certaines méthodes je ne retrouve pas les mêmes paramètres pour les méthodes correspondantes entre soAPI et la nouvelle API. Par exemple pour zoneEntryModify, j'ai ça avec soAPI http://prntscr.com/9o90c2 et ça avec la nouvelle API : http://prntscr.com/9o90eq .

Au passage le tableau de correspondance https://www.ovh.com/fr/soapi-to-apiv6-migration/ est une très bonne idée.

3 - Actuellement j'utilise le système de points fidélité pour acheter les domaines. J'approvisionne mon compte fidélité tous les mois.

Ce fonctionnement est-il toujours possible ou est-ce qu'il est remplacé par le système de "Cart" ?
La partie SoAPI resallerDomain* est bien remplacé par le système de cart (/order/cart/*)
Tu trouveras des exemples de code ici : https://github.com/ovh/order-cart-examples (en Python uniquement pour le moment).

Une fois les domaines ajoutés dans ton panier, et l'appel à la fonction checkout réalisé, tu obtiendras un bon de commande, et notamment un orderId. Cet orderId te permettra d'utiliser la fonction POST /me/order//payWithRegisteredPaymentMean qui va automatiquement payer le bon de commande à l'aide du compte de fidélité ou du compte OVH (au choix en paramètre)

Citation Envoyé par kinglouis
4 - Un tutorial PHP complet me serait très utile. Les étapes pourraient être : vérifier la dispo d'un domaine, l'acheter, le configurer (changer le champ A par exemple), le renouveler.
C'est dans notre TODO list, ça arrive prochainement

Si tu as d'autres questions
Bien cordialement,

romain.beuque
13/01/2016, 10h49
Citation Envoyé par ZeDvD
RAZ LE BOL ! MESSIEURS LES ADMINS, FAITES VOTRE BOULOT, REPONDEZ AUX QUESTIONS SVP

Cela fait plus de trois semaines que j'essaye de remplacer SoAPI par cette foutue API V6, j'ai autre chose à foutre que de passer mon temps à faire une migration FORCEE de mes services. J'ai une entreprise à gérer, pas de temps à perdre, et je ne suis pas aidé, pour moi c'est de l'argent perdu. J'ai eu quelques réponses au début, mais depuis plus rien. Je me suis inscrit à la ML, là non plus pas de réponses à mes questions. Bref Y'EN A MARRE !
Bonjour ZeDvD,
Concernant ton message sur la mailing-list, j'y ai répondu, dans l'heure (ouvrée) si je ne m'abuse. cf http://demo.ovh.eu/fr/c56f049c1c2f553386d4ffdeba2c547d/
Merci de me dire si tu l'as bien reçu, et de revenir vers moi par rapport à ma question.

Citation Envoyé par ZeDvD
Q1 - J'ai tenté l'API CURL, j'ai des problèmes quand j'envoie des requètes GET avec des paramètres: "invalid signature". Exemple : je veux tester si un nom de domaine existe en appelant le GET comme indiqué dans la doc. Voici ce que je fais, soit deux appels CURL
appel curl => https://api.ovh.com/1.0/order/cart => J'obtient un ID, c'est OK
appel curl => https://api.ovh.com/1.0/order/cart/d...0cb050/domain/ et PARAMS =>{"domain":"wobile.org"}
Reponse : [errorCode] => INVALID_SIGNATURE [httpCode] => 400 Bad Request [message] => Invalid signature
SIGNATURE avant sha1 : AK+CK+GET+https://api.ovh.com/1.0/order/cart/d1ac7568-1586-43f8-a1e3-f111100cb050/domain/+{"domain":"wobile.org"}+1452637215

Où est l'erreur ? Pourquoi la signature est-elle déclarée invalide ? Faut-il passer les paramètres dans la signature ?
Dans l'exemple de code du message sur la mailing list, tu utilisais le wrapper php-ovh, tu utilises maintenant la librairie cURL PHP ?

Sinon, pour le format de la signature qui est incorrecte avec cURL lors des appels GET, j'ai bidouillé un peu le wrapper python pour afficher la tête de la signature lors d'un appel, et l'on me retourne :

Code:
AK+CK+GET+https://api.ovh.com/1.0/order/cart/LECARTIDLECARTID/domain?domain=fdsjfhdsjfhdsfs.com++1452677877
Il faut ainsi signer les paramètres des méthodes GET dans l'URL, tel que l'appel est fait vers l'API, et non pas dans le body.
Merci de me dire si tu as toujours l'erreur en utilisant cette technique de signature

Citation Envoyé par ZeDvD
Q2 : Pouvez-vous donner la séquence d'appels à l'API pour créer une redirection visible d'un nom de domaine . Merci de donner un exemple clair et précis, car j'ai testé, et là et je n'y arrive pas : les zones DNS qui sont créées sont incorrectes. Pouvez-vous faire un programme tuto simple et clair en PHP ?

Q3 : pouvez-vous donner au moins un exemple (autre GET, trop simple, par exemple POST avec paramètres), de l'API V6 officielle ? Il n'y a aucun exemple concret, ou presque, donc si vous pouviez faire plusieurs tutos, ce serait sympa, ça a été demandé plusieurs fois dans ce fil, et vous n'y avez jamais répondu. Des tutos SVP !
En ce qui concerne l'API de commande, nous avons des exemples de code pour Python à cette adresse : https://github.com/ovh/order-cart-examples
Les exemples pour PHP devraient suivre bientôt. Sinon, des exemples généralistes d'utilisation du wrapper PHP sont disponibles ici: https://github.com/ovh/php-ovh (dans le README, et le dossier examples).

Je reste à ta disposition si d'autres questions se présentent.
Bien cordialement,

vcasse
13/01/2016, 10h37
Bonjour ZeDvD,

Keep calm please. Il me semble qu'on apporte des réponses depuis le début de ce topic. Peut être pas aussi vite que tu le souhaites, mais nous tentons de répondre à l'ensemble des messages

Voici les réponses que je peux t'apporter :
Q1) Sans le code entier (avec AK / AS et CK cachées), pas facile de t'aider à débugguer ! En l'état, je suis incapable de te dire pourquoi la signature est mauvaise . Je peux essayer de comprendre, mais sans certitude.
C'est pour éviter ce type de cas que nous avons proposés des wrappers. Vous avez été plusieurs à nous indiquer qu'ils sont plus complexe à mettre en oeuvre que de simplement télécharger un fichier. C'est pour cela que nous proposons maintenant une archive contenant toutes les dépendances : https://github.com/ovh/php-ovh/relea...dencies.tar.gz. Est ce que cela ne vaut pas le coup d'essayer à nouveau ?

Pour la question 2, je dois avouer que je ne suis pas expert sur cette partie de l'API. J'ai demandé à mes collégues de regarder et de te répondre. Je les relance.

Pour la question 3, la réponse est oui on peut ! Mais pour avoir des exemples concret, peux tu me donner les appels SoAPI que tu utilises actuellement ?
Pour le format, j'ai répondu à un client sur l'appel SoAPI hostingGetCapabilities : https://github.com/ovh/php-ovh/blob/..._capacities.md. J'attend son retour sur le format. Mais tu pourras probablement aussi me dire si cela te semble correct.

Je résume :
1/ On peut aider à débugguer si on a le code entier. (Mais retest le wrapper ! )
2/ J'attend la réponse d'un collégue et on écrit un tuto !
3/ Donnes moi les appels SoApi que tu utilises, pour qu'on écrive des tutos utile (si ca l'est pour toi, ca le sera aussi probablement pour d'autres clients)

Bien cordialement,
Vincent

ZeDvD
12/01/2016, 23h40
RAZ LE BOL ! MESSIEURS LES ADMINS, FAITES VOTRE BOULOT, REPONDEZ AUX QUESTIONS SVP

Cela fait plus de trois semaines que j'essaye de remplacer SoAPI par cette foutue API V6, j'ai autre chose à foutre que de passer mon temps à faire une migration FORCEE de mes services. J'ai une entreprise à gérer, pas de temps à perdre, et je ne suis pas aidé, pour moi c'est de l'argent perdu. J'ai eu quelques réponses au début, mais depuis plus rien. Je me suis inscrit à la ML, là non plus pas de réponses à mes questions. Bref Y'EN A MARRE !

Donc please, pour les admins : REPONDEZ AUX QUESTIONS, DONNEZ DES EXEMPLES CONCRETS : dans 3 Mois l'API Soap est fermée et vous ne nous aidez pas, la doc est incomplète, il y a zéro tuto, vous nous forcez à utiliser des frameworks dont on n'a pas besoin, bref c'est n'importe quoi !!!

DONC MES QUESTIONS (j'en ai plein d'autres, mais déjà si vous pouviez répondre à celles-là) :

Q1 - J'ai tenté l'API CURL, j'ai des problèmes quand j'envoie des requètes GET avec des paramètres: "invalid signature". Exemple : je veux tester si un nom de domaine existe en appelant le GET comme indiqué dans la doc. Voici ce que je fais, soit deux appels CURL
appel curl => https://api.ovh.com/1.0/order/cart => J'obtient un ID, c'est OK
appel curl => https://api.ovh.com/1.0/order/cart/d...0cb050/domain/ et PARAMS =>{"domain":"wobile.org"}
Reponse : [errorCode] => INVALID_SIGNATURE [httpCode] => 400 Bad Request [message] => Invalid signature
SIGNATURE avant sha1 : AK+CK+GET+https://api.ovh.com/1.0/order/cart/d1ac7568-1586-43f8-a1e3-f111100cb050/domain/+{"domain":"wobile.org"}+1452637215

Où est l'erreur ? Pourquoi la signature est-elle déclarée invalide ? Faut-il passer les paramètres dans la signature ?


Q2 : Pouvez-vous donner la séquence d'appels à l'API pour créer une redirection visible d'un nom de domaine . Merci de donner un exemple clair et précis, car j'ai testé, et là et je n'y arrive pas : les zones DNS qui sont créées sont incorrectes. Pouvez-vous faire un programme tuto simple et clair en PHP ?

Q3 : pouvez-vous donner au moins un exemple (autre GET, trop simple, par exemple POST avec paramètres), de l'API V6 officielle ? Il n'y a aucun exemple concret, ou presque, donc si vous pouviez faire plusieurs tutos, ce serait sympa, ça a été demandé plusieurs fois dans ce fil, et vous n'y avez jamais répondu. Des tutos SVP !

Merci de bien vouloir répondre à ces premières questions avant la fermeture de SOAP, ce serait sympa ....

ZeDvD
12/01/2016, 21h05
Citation Envoyé par ZeDvD
J'avance dans ma migration, mais que c'est long !
Mon nouveau problème : pour créer une redirection, j'utilise ça :
$resp = $ovh->post('/domain/zone/'.$l_domain_to_redirect.'/redirection', array(
'target' => 'www.'.$l_domain_redirect_to,
'type' => 'visible',
'subDomain' => $l_subdomain
)
);


j'ai le message d'erreur suivant :
A, AAAA or CNAME DNS record exists for this subDomain, please remove it before to create a redirection

J'en déduis qu'il faut supprimer toutes ces zones DNS manuellement avant de créer une redirection.
Avec soApi, on n'avait pas besoin de le faire, il y avait un mode écrasement dans la fonction ortDomainAdd

Est-ce que ce mode écrasement existe avec la nouvelle API ? Ca eviterait de se palucher toutes les zones DNS à la main et les supprimer une par une.

Je reviens vers vous car je n'ai pas de réponse sur mon problème, quelqu'un peut-il apporter une réponse : comment créer une redirection avec la nouvelle API ?

s.berry
12/01/2016, 18h08
Citation Envoyé par MaxV
Bonjour,

1er point : Les fonctions de commande de MXPlan sont en deprecated car les offres vont évoluer oui. Pour l'instant je ne peux pas t'en dire plus, juste que normalement les offres email évoluerons pour les offres avec hébergement puis par la suite pour les MXPlan.
2eme : Il faut rentrer une 'duration' car le service en lui même à une date d'expiration d'un an par défaut. Les MXPlan sont un peu spéciaux car ils sont renouvelés automatiquement sans frais (d'ou le 'à vie'). Donc tu dois mettre 12 (12 mois) qui seront renouvelés automatiquement sans frais.
3eme : D'après les information que j'ai tu peux convertir tes points en payement chargé sur ton compte.

Je posterai ici si j'ai plus d'information sur le payement par point et sinon hésite pas si tu as d'autres questions.

En espérant que ça t'aidera,

Merci MaxV pour vos réponses !

J'attendrais votre retour concernant le paiement par points lors de la commande de MXPlan alors
J'ai une question concernant le test de l'API. Je vais devoir tester le bon fonctionnement de mes appels dont la commande de MXPlan, mais lors de ces tests je ne veux bien évidemment pas réellement passer de commande. Est-ce qu'il y a un moyen de faire des appels en mode "test" ou un compte spécifique / une configuration à mettre en place ?

Merci d'avance !

bertranddcs
12/01/2016, 17h27
Bonjour,

la fonction "/telephony/{billingAccount}/conference/{serviceName}/participants" ne fonctionne pas (elle renvoie systématiquement un tableau vide pour les id des participants alors que pour une conférence démarrée, la fonction "/telephony/{billingAccount}/conference/{serviceName}/informations" va bien indiquer le nombre de participants connectés)

pouvez-vous corriger ce problème afin que nous achevions notre migration vers l'API V6

Cordialement,

MaxV
12/01/2016, 14h43
Citation Envoyé par s.berry
Bonjour,

J'ai besoin de mettre en place la fonction Soapi "orderEmailMxPlan" avec la nouvelle APIV6 mais le tableau de correspondance me renvoie vers une fonction de l'APIv6 (POST /order/email/domain/new/{duration}) qui est dépréciée. Pourquoi? Une nouvelle fonction va-t-elle être mise en place pour la remplacer ?

J'ai également quelques questions sur la nouvelle implémentation :
- pourquoi faut-il entrer une "duration" alors que le Mx Plan est sans limite dans le temps ?
- puis-je avoir quelques renseignements sur les formats à utiliser ?
- j'ai besoin de définir le booléen "payWithPoints" à true or il n'est plus dans les paramètres de la nouvelle implémentation. Est-ce qu'elle est automatiquement à true ou faut-il passer par une autre fonction en supplément pour utiliser les points d'un compte ?

Merci d'avance pour vos réponses
Bonjour,

1er point : Les fonctions de commande de MXPlan sont en deprecated car les offres vont évoluer oui. Pour l'instant je ne peux pas t'en dire plus, juste que normalement les offres email évoluerons pour les offres avec hébergement puis par la suite pour les MXPlan.
2eme : Il faut rentrer une 'duration' car le service en lui même à une date d'expiration d'un an par défaut. Les MXPlan sont un peu spéciaux car ils sont renouvelés automatiquement sans frais (d'ou le 'à vie'). Donc tu dois mettre 12 (12 mois) qui seront renouvelés automatiquement sans frais.
3eme : D'après les information que j'ai tu peux convertir tes points en payement chargé sur ton compte.

Je posterai ici si j'ai plus d'information sur le payement par point et sinon hésite pas si tu as d'autres questions.

En espérant que ça t'aidera,

sergead
12/01/2016, 10h00
Bonjour Vincent,

j'ai testé sur CentOS5 avec python 2.4 et à priori j'ai de grosse erreur ça m'a l'air incompatible.

Pour PHP 4.4 je sais très bien le problème, et j'aimerais bien ne plus en avoir mais malheureusement la migration de l'application sur php 5 prend du temps et ça n'est pas gratuit, donc c'est toujours en attente.

Je viens de tester le wrapper en perl et à priori ça m'a l'air compatible sur CentOS 5/6/7, j'arrive à faire un GET mais pas de POST j'ai un "errorCode":"INVALID_JSON","httpCode":"400 Bad Request","message":"Invalid JSON received".
Je ne connais pas du tout perl donc je sais pas si c'est moi qui l'utilise mal peut être :

my $ApiPost = OvhApi->new(type => OvhApi::OVH_API_EU, applicationKey => $AK, applicationSecret => $AS, consumerKey => $CKPOST);
my $Test = $ApiPost->post(path => '/ip/xxx.xxx.xxx.xxx/move', noSignature => 1, body => 'nsxxxx.eu');
my $Test2 = $ApiPost->post(path => '/diedicated/server/nsxxxx.eu/ipmove', body => 'xxx.xxx.xxx.xxx/32');

Il y a moins de doc que pour php et python, je ne sais pas si il y a des exemples d'application en perl qui se base dessus pour que je m'inspire :-)

s.berry
12/01/2016, 09h13
Bonjour,

J'ai besoin de mettre en place la fonction Soapi "orderEmailMxPlan" avec la nouvelle APIV6 mais le tableau de correspondance me renvoie vers une fonction de l'APIv6 (POST /order/email/domain/new/{duration}) qui est dépréciée. Pourquoi? Une nouvelle fonction va-t-elle être mise en place pour la remplacer ?

J'ai également quelques questions sur la nouvelle implémentation :
- pourquoi faut-il entrer une "duration" alors que le Mx Plan est sans limite dans le temps ?
- puis-je avoir quelques renseignements sur les formats à utiliser ?
- j'ai besoin de définir le booléen "payWithPoints" à true or il n'est plus dans les paramètres de la nouvelle implémentation. Est-ce qu'elle est automatiquement à true ou faut-il passer par une autre fonction en supplément pour utiliser les points d'un compte ?

Merci d'avance pour vos réponses

vcasse
11/01/2016, 18h47
Bonjour Sergead,

Nous testons le wrapper python à partir de la version 2.6 : https://travis-ci.org/ovh/python-ovh
Cependant, il se peut qu'il fonctionne dans une version antérieure. A tester.

Le wrapper PHP n'est compatible qu'avec des versions de PHP > 5.2 et nous ne maintenons ce wrapper qu'avec des versions de PHP > 5.4 : https://travis-ci.org/ovh/python-ovh. Pour PHP 4.4, c'est sur qu'il ne fonctionne pas. Dans ce cas, je te conseille d'utiliser curl directement. Mais cela nécessite plus de travail.

Bien que je comprenne les soucis de migration, je ne peux pas m'empêcher de rappeler que :
/!\ PHP 4.4 n'est plus maintenu depuis +7ans : http://php.net/eol.php
Il est possible qu'il contienne de grosses failles de sécurité

Cordialement,
Vincent

- - - Mise à jour - - -

Bonjour Vincent,

Je viens de rédiger une documentation sur l'utilisation de l'api pour récupérer les capabilities d'un hébergement, comme sur soapi.
https://github.com/ovh/php-ovh/tree/...etCapabilities

Peux tu me dire si cela te convient ? Si jamais tu buttes sur quelques chose, n'hésites pas à me le dire. Comme ca, je vais améliorer le guides puis en rédiger d'autres pour domainInfo et email.

Cordialement,
Vincent

sergead
11/01/2016, 10h23
Bonjour,

J'utilise sur beaucoup de serveur les appels SoAPI en python pour migrer les ip, la méthode s'appelle "dedicatedFailoverUpdate".
Le problème c'est que c'est utilisé sur des serveurs très ancien CentOS 5 et je me demande quelle méthode utiliser pour remplacer sur ce genre de serveur ?
Le wrapper Python est il compatible avec du python 2.4 ?
Le wrapper d'ovh PHP-OVH est-il comptabile avec de vieille version de php, j'ai du php4.4 sur certains serveurs ....

WebArtMedia
11/01/2016, 09h30
Citation Envoyé par vcasse
Bonjour WebArtMedia,

Est ce que vous avez des exemples précis d'appels SoApi que vous souhaitez migrer ?
C'est l'occasion de créer des documentations qui correspondent à vos besoins

Cordialement,
Vincent
Bonjour Vincent,

Les appels que j'utilise quotidiennement sont (avec PHP) :
— soAPI->domainInfo()
— soAPI->hostingGetCapabilities()
— soAPI->automatedMailGetErrors()

Entres autres bien entendu, mais ces trois sont les plus importants à mes yeux. J'aurais donc besoin de savoir par quelle nouvelle syntaxe je devrais remplacer ces appels...

Merci pour votre attention et votre écoute.

Vincent (et oui, même prénom, et certainement même génération) ! ^^
WebArtMedia

kinglouis
10/01/2016, 09h44
Bonjour,

Merci d'avoir mis en place cet espace de discussion, je suis content de voir que je ne suis pas le seul à galérer avec tout ça mais que la team OVH est là pour répondre !

J'utilise SoAPI pour commander, installer, renouveler des noms de domaine de manière automatique (dans le cadre d'une plateforme de blogs avec abonnement premium pour ceux qui veulent un domaine).

1 - Comment s'authentifier de manière automatique, via serveur, sans avoir d'url de validation à appeler dans le navigateur web ? Faut-il appeler l'url de validation via le serveur ?

2 - Pour certaines méthodes je ne retrouve pas les mêmes paramètres pour les méthodes correspondantes entre soAPI et la nouvelle API. Par exemple pour zoneEntryModify, j'ai ça avec soAPI http://prntscr.com/9o90c2 et ça avec la nouvelle API : http://prntscr.com/9o90eq .

Au passage le tableau de correspondance https://www.ovh.com/fr/soapi-to-apiv6-migration/ est une très bonne idée.

3 - Actuellement j'utilise le système de points fidélité pour acheter les domaines. J'approvisionne mon compte fidélité tous les mois.

Ce fonctionnement est-il toujours possible ou est-ce qu'il est remplacé par le système de "Cart" ?

4 - Un tutorial PHP complet me serait très utile. Les étapes pourraient être : vérifier la dispo d'un domaine, l'acheter, le configurer (changer le champ A par exemple), le renouveler.

5 - Concernant la doc de l'API, des exemples d'appels me seraient très utiles, comme sur soAPI : http://prntscr.com/9o93l4

6 - Pour info je ne maitrise pas Composer ou Guzzle et mes fichiers ne sont pas compilés. Je suis conscient qu'il y a de nouvelles solutions techniques mais ça prend du temps de se former et je préfère passer ce temps à améliorer mon produit.
Le package ZIP avec toutes les dépendances va dans le bon sens même si j'hésite à appeler Curl en direct pour ne pas dépendre d'une lib externe.

Merci d'avance pour votre aide !

ZeDvD
08/01/2016, 23h24
Citation Envoyé par ksio
Je ne sais pas pourquoi ton code ne marche pas, mais l'API fonctionne puisque c'est une fonction que j'ai implémenté (j'ai mis mon code quelques pages avant celle ci).
Je poste la réponse pour ceux qui la veulent. J'avais plusieurs problèmes : j'appelais la méthode "get", qui prend en paramètre le nom de domaine. Or dans l'API CURL, la méthode get n'a pas de paramètres, donc le domaine n'était pas envoyé. J'ai tenté de rajouter le paramètre à l'API curl, mais sans succès, j'avais un retour d'erreur "invalid signature". Ne voulant pas y passer 3 plombes, j'ai laissé tombé.

J'ai donc décidé d'appeler la méthode post et non pas get : et bien ça marche, tout simplement. Si le domaine n'est pas disponible, un message d'erreur est retourné.

ksio
08/01/2016, 08h49
Citation Envoyé par ZeDvD
Mais en retour j'ai ceci : "Please provide a domain name"

Pourquoi ?
Je ne sais pas pourquoi ton code ne marche pas, mais l'API fonctionne puisque c'est une fonction que j'ai implémenté (j'ai mis mon code quelques pages avant celle ci).

ZeDvD
07/01/2016, 22h47
Bonjour

Mr les admins, pouvez-vous apporter une réponse à ma question concernant les redirections ?

J'ai une autre question : Comment vérifier si un nom de domaine est disponible à l'achat ?
J'ai implémenté ça:

// Recuperation d'un ID de commande
$resp = $ovh->post('/order/cart', array(
'ovhSubsidiary' => 'FR'
)
);
$l_cart_id = $resp ["cartId"];

// recuperation des infos de domaine
$resp = $ovh->get('/order/cart/'.$l_cart_id.'/domain', array(
'domain' => "testerdsdssd.fr"
)
);

L'URL appelée est celle-ci :
api.ovh.com/1.0/order/cart/b2eced9b-55e7-446d-9649-52a4fcb4e939/domain


Mais en retour j'ai ceci : "Please provide a domain name"

Pourquoi ?

LaurentLep
07/01/2016, 11h52
Bonjour,

Pour continuer dans les annonces, les groupes suivants sont complets et seront fermés au 6 Avril 2016 :
- Account
- Infrastructure
- Nic
- Order
- Ticket

Cordialement,
Laurent

romain.beuque
07/01/2016, 10h21
Citation Envoyé par fodjer
Bonjour,

Dans la liste des fonctions soapi (en première page), il n'y a aucune mention de "resellerDomainCreate".

Est-elle abandonnée ?

Merci
Bonjour fodjer,
C'est une coquille, la méthode API est la même que pour les autres fonctions resellerDomainCreate(ASIA/CAT/IT) =>
POST /order/cart/{cartId}/domain

Je vais faire corriger le guide. Merci!

ZeDvD
06/01/2016, 23h56
J'avance dans ma migration, mais que c'est long !
Mon nouveau problème : pour créer une redirection, j'utilise ça :
$resp = $ovh->post('/domain/zone/'.$l_domain_to_redirect.'/redirection', array(
'target' => 'www.'.$l_domain_redirect_to,
'type' => 'visible',
'subDomain' => $l_subdomain
)
);


j'ai le message d'erreur suivant :
A, AAAA or CNAME DNS record exists for this subDomain, please remove it before to create a redirection

J'en déduis qu'il faut supprimer toutes ces zones DNS manuellement avant de créer une redirection.
Avec soApi, on n'avait pas besoin de le faire, il y avait un mode écrasement dans la fonction ortDomainAdd

Est-ce que ce mode écrasement existe avec la nouvelle API ? Ca eviterait de se palucher toutes les zones DNS à la main et les supprimer une par une.

fodjer
06/01/2016, 19h41
Bonjour,

Dans la liste des fonctions soapi (en première page), il n'y a aucune mention de "resellerDomainCreate".

Est-elle abandonnée ?

Merci

ZeDvD
03/01/2016, 17h46
Citation Envoyé par vcasse


$ovh->delete('/hosting/web/waibe.fr/attachedDomain/www.wobile.org'); devrait fonctionner si le script implémente bien les actions de type DELETE. Je dois avouer ne pas avoir vérifié
Ton url est bonne.
L'erreur remontée ressemble plus à un probléme de droits. As tu bien ajouter le droits DELETE lors de la création de ton token ?
=> mode ' coup de gueule ON ' -------------------

C'est en effet un problème de droits, mais encore faut-il que ce soit clairement expliqué car il n'y a aucune documentation claire de comment fonctionne l'API, et la gestion des token. Il se palucher des tonnes de docs pour comprendre, c'est limite admissible de nous forcer à changer d'API sans nous en donner les moyens. Les entreprises n'ont pas de temps à perdre, les heures sont comptées car le temps c'est de l'argent, donc un tuto CLAIR avec toutes les explications devrait être fait par OVH. Et là ce n'est pas le cas, donc comme d'hab, à nous de nous démerder, et perdre du temps.

=> mode ' coup de gueule OFF' -------------------


Donc je donne la solution pour ceux qui cherchent : lors de la création du token, il faut en effet donner les droits pour POST, GET, DELETE.... bref pour toutes les commandes. Je vous la fait courte, mais moi j'utilise l'API OVH curl, pas l'officielle trop chiante à récupérer. Vous la trouverez ici : https://github.com/ovh/php-ovh/tree/master/src



Le code à faire en PHP est celui-là pour obtenir un token avec tous les droits

$ovh = new OvhApi();

$resp = $ovh->post('/auth/credential', array(
'accessRules' => array(
array('method' => 'POST', 'path' => '/*'),
array('method' => 'GET', 'path' => '/*'),
array('method' => 'PUT', 'path' => '/*'),
array('method' => 'DELETE', 'path' => '/*')
)
));

echo '
'; 
var_dump($resp);
echo '
';



Le dump de la variable $resp vous donne une URL de validation à appeler dans le navigateur Web. Lors de la validation, indiquez la durée de validité du token (dans mon cas unlimited). $resp vous affiche également la consumer key : " consumerKey" - à utiliser dans vos scripts.

Voilà, c'est pas compliqué, faut juste que quelqu'un de chez OVH l'explique clairement!

BIRD71
31/12/2015, 11h35
Bonjour,

Ceci est une 2ème tentative d'envoi de ce message car le premier n'apparaît nul part !
Y a t'il un problème sur le forum vu le message "Test" précédent ?

Sinon, est-ce quelqu'un peut nous confirmer si l'application "OVH Android " utilise les fonctions SOAPI ?
Le support OVH nous indique que nous avons utilisé les fonctions suivantes entre novembre et décembre:
telephonyAbbreviatedNumberList
telephonyAbbreviatedNumberOnGroupList
telephonyBillingAccountList
telephonyCallList
telephonyClick2CallUserList
telephonyDdiInfo
telephonyDirectoryInfo
telephonyDirectoryInfoGetSameSiret
telephonyDirectoryListWayType
telephonyFaxCallList
telephonyFaxOptionsList
telephonyFaxOptionsModify
telephonyFunctionKeyAdd
telephonyFunctionKeyList
telephonyGetCitiesFromZip
telephonyHuntingGenericScreenStatus
telephonyHuntingGroupList
telephonyLineGetIpRestriction
telephonyLineList
telephonyLineOptionsList
telephonyLineOptionsModify
telephonyNumberGetFrWayNamesFromInsee
telephonyOfferInfo
telephonyPhonebookContactList
telephonyPhonebookList
telephonyPhonebookOnGroupList
telephonyScreenListBlackWhiteChoice
telephonyScreenListInfo
telephonySmsAccountList
telephonySpareList
telephonyToneStatus
telephonyTonesOptionsList
Mis à part "OVH Android" nous n'avons aucune idée quelle autre application utiliserais ces fonctions et surtout nous ne savons pas comment les pister !

Une idée ?

BIRD71
31/12/2015, 11h07
Bonjour,

Est-ce quelqu'un peut nous confirmer si l'application "OVH Android " utilise les fonctions SOAPI ?
Le support OVH nous indique que nous avons utilisé les fonctions suivantes entre novembre et décembre:
telephonyAbbreviatedNumberList
telephonyAbbreviatedNumberOnGroupList
telephonyBillingAccountList
telephonyCallList
telephonyClick2CallUserList
telephonyDdiInfo
telephonyDirectoryInfo
telephonyDirectoryInfoGetSameSiret
telephonyDirectoryListWayType
telephonyFaxCallList
telephonyFaxOptionsList
telephonyFaxOptionsModify
telephonyFunctionKeyAdd
telephonyFunctionKeyList
telephonyGetCitiesFromZip
telephonyHuntingGenericScreenStatus
telephonyHuntingGroupList
telephonyLineGetIpRestriction
telephonyLineList
telephonyLineOptionsList
telephonyLineOptionsModify
telephonyNumberGetFrWayNamesFromInsee
telephonyOfferInfo
telephonyPhonebookContactList
telephonyPhonebookList
telephonyPhonebookOnGroupList
telephonyScreenListBlackWhiteChoice
telephonyScreenListInfo
telephonySmsAccountList
telephonySpareList
telephonyToneStatus
telephonyTonesOptionsList
Mis à part "OVH Android" nous n'avons aucune idée quelle autre application utiliserais ces fonctions et surtout nous ne savons pas comment les pister !

Gaston_Phone
31/12/2015, 09h55
Citation Envoyé par Fromon
Test
? ? ?

Fromon
31/12/2015, 09h49
Bonjour,

Pour la fermeture prochaine de SoAPI bientôt, plusieurs sections sont déjà fermées.
- dedicatedFailoverList
- dedicatedFailoverUpdate
sont hors service. J'ai appelé le support OVH et on m'a répondu que c'était suite à la migration progressive vers l’APIv6.

Cela oblige ma société à mettre quelqu'un en astreinte pendand cette période de fête!

J'ai essayé d'écrire un script bash en urgence mais la doc est incomplète. J'ai dû m'inscrire à la mailing list puis envoyer un mails à api-faq sans réponse...

Dons votre doc https://api.ovh.com/g934.first_step_with_api
On a : "$1$" + SHA1_HEX(AS+"+"+CK+"+"+METHOD+"+"+QUERY+"+"+BODY+" +"+TSTAMP)

Exemple:
EXEgWIz07P0HYwtQDs7cNIqCiQaWSuHF+MtSwSrPpNjqfVSmJh LbPyr2i45lSwPU1+GET+https://eu.api.ovh.com/1.0/domains/++1366560945

Ok donc j'en déduis :
METHOD : GET

A quoi correspondent QUERY et BODY, si quelqu'un sait? j'ai testé avec succès https://api.ovh.com/console/#/dedicated/server/{serviceName}#GET et je vois pas comment faire cela avec la doc incomplète : https://api.ovh.com/g934.first_step_with_api

J'ai écrit un script en Bash qui ne fonctionne pas car je ne sais pas ou mettre dedicated/server/{serviceName} dans la partie : "$1$" + SHA1_HEX(AS+"+"+CK+"+"+METHOD+"+"+QUERY+"+"+BODY+" +"+TSTAMP)

Je vous donnerai le script si j'arrive à le faire fonctionner. Ce dont j'ai besoin c'est d'un script simple et minimaliste.

Fromon
31/12/2015, 09h39
Test

techos
30/12/2015, 13h55
Citation Envoyé par techos
Bonjour

Je suis en cours de migration de mes scripts d'envoi SMS vers l'APIv6

J'utilise la méthode /sms/{serviceName}/outgoing/{id} pour connaitre le statut de mon message.

Sur un de mes messages de test lorsque je check l'état PTT du SMS je me retrouve avec une valeur absente de la doc : 0

Compte SMS : sms-bc89856-1
ID SMS : 46463525

Je ne suis pas le seul a rencontrer des valeurs de PTT absentes de la doc : https://forum.ovh.com/showthread.php/107589-retour-ptt

Pourriez vous compléter la documentation au plus vite ?

Merci
Bonjour

Encore une fois de nombreux codes retour PTT n'existent pas dans la doc. Ci-dessous l'envoi de ce matin avec le même compte SMS. Pourriez vous compléter la documentation rapidement afin que je mette à jour mes scripts ?

Merci

46612153 => 4
46612157 => 0
46612164 => 4
46612180 => 4
46612188 => 1001
46612197 => 4
46612206 => 0
46612212 => 0
46612217 => 0
46612222 => 3
46612230 => 1001
46612236 => 1001
46612242 => 2002
46612246 => 4
46612252 => 0
46612259 => 0
46612264 => 4
46612269 => 0
46612274 => 0
46612278 => 4
46612281 => 4
46612285 => 4
46612288 => 1001
46612292 => 4
46612297 => 0
46612301 => 1151
46612305 => 0
46612308 => 4
46612311 => 2001
46612315 => 3
46612318 => 4
46612322 => 4
46612325 => 4
46612329 => 4
46612334 => 4
46612340 => 1001
46612343 => 4
46612346 => 0
46612350 => 1001
46612353 => 0
46612358 => 0
46612363 => 0
46612367 => 1001
46612369 => 4
46612371 => 4
46612372 => 1151
46612374 => 4
46612376 => 0
46612378 => 1001
46612380 => 2001
46612383 => 1001
46612385 => 4
46612387 => 4
46612390 => 1001
46612394 => 0
46612398 => 4
46612401 => 4
46612403 => 4
46612407 => 0
46612409 => 4
46612413 => 0
46612415 => 4
46612417 => 0
46612419 => 1001
46612421 => 4
46612424 => 1001
46612427 => 1151
46612429 => 1001
46612432 => 0
46612436 => 4
46612440 => 0
46612443 => 4
46612445 => 4
46612450 => 4
46612455 => 1001
46612457 => 4
46612459 => 4
46612461 => 4
46612463 => 1001
46612465 => 4
46612467 => 1001
46612468 => 4
46612470 => 1001

LaurentLep
29/12/2015, 14h39
Bonjour,

Comme mis à jour sur la première page, voici la liste des premiers groupes de méthodes SoAPI qui vont être fermés au 28 Mars 2016 :
  • Emails
  • Hosting
  • ManagedServices
  • Notepad
  • Prepaid
  • RPS
  • SQLPrive
  • Support


L'annonce de leur fermeture suivra une fois les développements terminés.

Laurent

michelp-oziolab
28/12/2015, 14h51
Question :
La passerelle Http2Sms est-elle aussi appelée à disparaître, comme l'ancienne API,
ou va-t-elle continuer à exister après l'arrêt de SoAPI ?
http://guides.ovh.com/Http2Sms

Si oui, ca me simplifierais grandement la migration de mes petits scripts d'envoi de SMS,
lié à un monitoring maison sous nagios.

Ce qui me semble le gros avantage de cette passerelle c'est de pouvoir envoyer facilement des SMS,
par exemple avec un script PHP unique, très simple, et surtout *sans dépandances*,
et ca ca m'intéresse breaucoup car la nouvelle API est décidément trop lourdingue pour un simple envoi de SMS.

techos
27/12/2015, 16h37
Bonjour

Je suis en cours de migration de mes scripts d'envoi SMS vers l'APIv6

J'utilise la méthode /sms/{serviceName}/outgoing/{id} pour connaitre le statut de mon message.

Sur un de mes messages de test lorsque je check l'état PTT du SMS je me retrouve avec une valeur absente de la doc : 0

Compte SMS : sms-bc89856-1
ID SMS : 46463525

Je ne suis pas le seul a rencontrer des valeurs de PTT absentes de la doc : https://forum.ovh.com/showthread.php/107589-retour-ptt

Pourriez vous compléter la documentation au plus vite ?

Merci

romain.beuque
24/12/2015, 13h43
Bonjour rudddy,
Un incident est en cours sur SoAPI, rien à voir avec la fermeture programmée.

http://travaux.ovh.net/?do=details&id=15885

Merci

- - - Mise à jour - - -

Bonjour rudddy,
Un incident est en cours sur SoAPI, rien à voir avec la fermeture programmée.

http://travaux.ovh.net/?do=details&id=15885

Merci

rudddy
24/12/2015, 13h16
Salut

Soap a fermé ?

Plus de click2call tout d'un coup ...



Warning: SoapClient::__doRequest() [soapclient.--dorequest]: SSL: Connection reset by peer in /home/XXXX/sd/XXX/www/ajax/ovh_click2call.php on line 28

SoapFault exception: [HTTP] Error Fetching http headers in /home/XXX/sd/XXX/www/ajax/ovh_click2call.php:28
Stack trace:
#0 [internal function]: SoapClient->__doRequest(' #1 [internal function]: SoapClient->__call('telephonyClick2...', Array)
#2 /home/XXX/sd/XXX/www/ajax/ovh_click2call.php(28): SoapClient->telephonyClick2CallDo('reXXX', 'oXXX', '018509XXX', '017747XXX', '018509XXX')

vcasse
23/12/2015, 14h34
Salut Benjo2857,

Je ne connais pas bien cette partie de l'API mais il est probable que l'api que tu appeles crée une tache asynchrone (tu dois recevoir un id et un status).
Si c'est le cas, il faut attendre que la tache soit terminée. Tu peux la voir, soit dans ton espace client, mais ca s'automatise pas bien, soit via /email/domain/{domain}/task/mailinglist/{id}

Ps : tu peux afficher d'autres types de taches, mais je t'invites à aller découvrir ici : https://api.ovh.com/console/#/email/domain

Cordialement,
Vincent

Benjo2857
23/12/2015, 13h11
Citation Envoyé par vcasse
Bonjour Benjo2857,
409 [reason phrase] ObjectAlreadyExists
La raison est returnée dans le début de la trace de l'exception. C'est bien un ObjectAlreadyExists.
Cordialement,
Vincent
Oui, j'ai vu ça mais ce que je n'ai pas compris c'est pourquoi cette erreur apparaissait aléatoirement...

A la première exécution du script, je n'avais pas de problème même en présence de doublons. Si je relançais le script une seconde fois quelques secondes après, j'avais cette erreur. Il fallait attendre plusieurs minutes pour relancer le script sans voir d'erreur... Peut-être est-ce lié au délai qu'il faut à la mailing-list pour prendre en compte les modifications?

Bref, je n'ai plus le soucis maintenant que je passe par curl mais ça reste quand même mystérieux.

vcasse
23/12/2015, 10h10
Bonjour ZeDvd,

En effet, je viens de regarder, et certains des messages de cette discussion étaient passées en modération. Je vais voir avec les admins du forum pourquoi.
Maintenant, ma réponse est visible

Cordialement,
Vincent

- - - Mise à jour - - -

Bonjour Benjo2857,

Je viens de valider les deux messages sur le forums. Je me renseigne auprés des admins pour comprendre le fonctionnement de cette modération...

Cordialement,
Vincent

Benjo2857
23/12/2015, 09h28
Citation Envoyé par vcasse
Bonjour Benj82857 et ZeDvD,

Je viens de packager une version comprenant déjà les dépendances et un code d'exemple : https://github.com/ovh/php-ovh/relea...pendencies.zip

J'aimerais votre retour dessus : est ce que cela vous simplifie la vie ? Sinon, qu'est ce qu'il vous manque ?

Cordialement,
Vincent
Bonjour,

J'ai posté 2 messages hier qui n'apparaissent pas sur le forum.

Dans le premier, j'indiquais une Fatal Error php dans le cas de doublons dans une mailing-list. Apparemment, le problème venait de Guzzle...

Finalement, j'ai changé de méthode et j'utilise désormais Curl. Ça fonctionne beaucoup mieux et je n'ai plus le problème avec les doublons...

Merci quand même pour le package qui en aidera surement plus d'un.

ZeDvD
22/12/2015, 20h31
Citation Envoyé par vcasse
Bonjour ZeDvd,

Je t'ai répondu (et posé quelques questions) sur l'API dans un message ci dessus

Cordialement,
Vincent
Désolé, mais je n'ai pas vu de réponse à mes problèmes. A moins que tu ne parles de ton message sur la mailing list. Dans la mesure du possible je ne m'abonne pas aux ML car on y est submergés de mails...

- - - Mise à jour - - -

Citation Envoyé par vcasse
Bonjour Benj82857 et ZeDvD,

Je viens de packager une version comprenant déjà les dépendances et un code d'exemple : https://github.com/ovh/php-ovh/relea...pendencies.zip

J'aimerais votre retour dessus : est ce que cela vous simplifie la vie ? Sinon, qu'est ce qu'il vous manque ?

Cordialement,
Vincent
Merci pour le ZIP, mais j'avais réussi à télécharger les dépendances. Je pense que ça va en aider d'autres
Par contre je suis toujours bloqué sur ma commande de suppression d'un multi-domaine... et mon erreur 500 que je ne comprends pas...

vcasse
22/12/2015, 17h54
Bonjour Benj82857 et ZeDvD,

Je viens de packager une version comprenant déjà les dépendances et un code d'exemple : https://github.com/ovh/php-ovh/relea...pendencies.zip

J'aimerais votre retour dessus : est ce que cela vous simplifie la vie ? Sinon, qu'est ce qu'il vous manque ?

Cordialement,
Vincent

vcasse
22/12/2015, 14h27
Bonjour ZeDvd,

Je t'ai répondu (et posé quelques questions) sur l'API dans un message ci dessus

Cordialement,
Vincent

ksio
22/12/2015, 12h04
Citation Envoyé par ZeDvD

Merci ksio, c'est en effet beaucoup plus simple que l'API officielle, et c'est proche de celle que j'ai trouvée sur le net. Une classe à installer, c'est parfait ;-)
De rien, par contre comme je le dis, c'est encore en test car sans une API complétée chez OVH, mon dev est en stand-by par la force des choses. Mais c'est un point de départ qui peut permettre d'avancer dans l'implémentation pour ton projet.

ZeDvD
22/12/2015, 12h00
OK pour les IP.
Par contre pour mon problème API as-tu pu jeter un oeil ?

- - - Mise à jour - - -

Merci ksio, c'est en effet beaucoup plus simple que l'API officielle, et c'est proche de celle que j'ai trouvée sur le net. Une classe à installer, c'est parfait ;-)

vcasse
22/12/2015, 11h47
@ ZeDvD : Ca devrait être bon pour les IPs. Est ce mieux de ton coté ?

Benjo2857
22/12/2015, 11h32
Citation Envoyé par vcasse
@Benjo2857 : rien n'empêche de faire les appels directement en curl, vu que l'API est accessible en HTTP . J'ai transmis en interne la demande sur la SoAPI mailing list (je ne suis pas expert de cette partie).
Finalement j'ai changé de tactique et j'utilise Curl plutôt Composer, Guzzle et compagnie...
Ça fonctionne effectivement beaucoup mieux!! Je n'ai plus l'erreur dont je parlais précédemment. Je reçois bien des messages propres de l'API qui m'indiquent si les adresses existent déjà sans que ça génère une Fatal Error php qui plante tout et le script est beaucoup plus rapide.

vcasse
22/12/2015, 11h29
Bonjour ZeDvD,

- Quand je teste en local sur easyphp : Uncaught exception 'GuzzleHttp\Ring\Exception\RingException' with message 'cURL error 60: SSL certificate problem
=> Ca sent le certificat SSL non présent, mais je n'en ai pas en local sur mon PC, donc comment je fais ?

- Quand j'upload sur mon hébergement OVH et que j'exécute, ben erreur 500 ! Je n'ai aucun moyen de debugger, pas d'erreur affichée si ce n'est 500
Ca c'est étrange. Peux tu mettre le script que tu utilises (sans tes informations) sur ce forum ou sur github ? Que je fasse l'essai pour voir d'où vient le soucis.

Pour easyPHP : je check le SSL. Pas besoin de l'importer de ton coté. Peux tu me fournir le numéro de version de easyPHP ainsi que le système d'exploitation que tu utilises (qui peut conditionner les accés SSL).

Par contre je n'arrive pas à le détruire.
C'est quoi l'URL à utiliser, pour faire suite à mon exemple précédent ?

J'ai utilisé ça : /hosting/web/waibe.fr/attachedDomain/www.wobile.org
$ovh->delete('/hosting/web/waibe.fr/attachedDomain/www.wobile.org'); devrait fonctionner si le script implémente bien les actions de type DELETE. Je dois avouer ne pas avoir vérifié
Ton url est bonne.
L'erreur remontée ressemble plus à un probléme de droits. As tu bien ajouter le droits DELETE lors de la création de ton token ?

Cordialement,
Vincent

- - - Mise à jour - - -

Bonjour Benjo2857,

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error response [url] https://api.ovh.com/1.0/email/domain/xxxxxxx/mailingList/xxxxxxx/subscriber [status code] 409 [reason phrase] ObjectAlreadyExists' in /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:89
Stack trace:
#0 /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/Subscriber/HttpError.php(33): GuzzleHttp\Exception\RequestException::create(Obje ct(GuzzleHttp\Message\Request), Object(GuzzleHttp\Message\Response))
#1 /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/Event/Emitter.php(109): GuzzleHttp\Subscriber\HttpError->onComplete(Object(GuzzleHttp\Event\CompleteEven t) , 'complete')
#2 /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/RequestFsm.php(94): GuzzleHttp\Event\Emitter->emit('complete', Object(GuzzleHttp\Event\CompleteEvent))
#3 /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/RequestFsm.php(135): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
#4 /home/xxxxxxx/www/ve in /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 89
409 [reason phrase] ObjectAlreadyExists

La raison est returnée dans le début de la trace de l'exception. C'est bien un ObjectAlreadyExists.

Cordialement,
Vincent

Benjo2857
22/12/2015, 10h32
Citation Envoyé par MaxV
Mais je ne comprends pas bien pourquoi tu vérifie que l'adresse est bien dans la liste ?
Tu ne peux tout simplement passer à la suite si la fonction te retourne 'AlreadyExist' ?
Alors effectivement, après de nouveaux tests, il me semble que le problème ne soit pas uniquement lié à la présence de doublons mais qu'il y ait quelque chose d'autre. Ça semble presque aléatoire. Si j'exécute le script une première fois sans vérification préalable des doublons, ça semble fonctionner. Par contre, si je relance le script une deuxième fois derrière, voilà ce que je récolte...

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error response [url] https://api.ovh.com/1.0/email/domain/xxxxxxx/mailingList/xxxxxxx/subscriber [status code] 409 [reason phrase] ObjectAlreadyExists' in /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:89
Stack trace:
#0 /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/Subscriber/HttpError.php(33): GuzzleHttp\Exception\RequestException::create(Obje ct(GuzzleHttp\Message\Request), Object(GuzzleHttp\Message\Response))
#1 /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/Event/Emitter.php(109): GuzzleHttp\Subscriber\HttpError->onComplete(Object(GuzzleHttp\Event\CompleteEvent) , 'complete')
#2 /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/RequestFsm.php(94): GuzzleHttp\Event\Emitter->emit('complete', Object(GuzzleHttp\Event\CompleteEvent))
#3 /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/RequestFsm.php(135): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
#4 /home/xxxxxxx/www/ve in /home/xxxxxxx/www/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 89


ksio
22/12/2015, 08h44
Bonjour,

Voici un bout de mon code qui utilise les appels CuRL standards. Attention, je n'ai pas testé encore tous les cas, par exemple pas la partie $is_authenticated==true, ni les PUT et DELETE.

Mais si ca peut aider quelqu'un a se lancer sans installer tout le bazar des exemples officiels...


class Controller_sbo_util_apiovh {
var $api_url = 'https://api.ovh.com/1.0';
var $application_key = '';
var $application_secret = '';
var $consumer_key = null;
var $time_delta;

function domainCheck( $domaine )
{

$extensions = 'FR';

// POST /order/cart

$infos = $this->docall( 'POST', '/order/cart', array( 'ovhSubsidiary' => $extensions ) );


// GET /order/cart/{cartId}/domain

$params = array(
'domain' => $domaine
);


$infos = $this->docall( 'GET', '/order/cart/' . $infos->cartId . '/domain', $params );

return $infos;
}

private function docall( $method, $url, $params=array(), $is_authenticated=false )
{
$additionnal_headers = array();

$body = json_encode( $params );

if ( $this->time_delta===null ) {
$this->calculateTimeDelta();
}
$now = time() + $this->time_delta;

$additionnal_headers[ ] = 'Content-Type: application/json; charset=utf-8';
$additionnal_headers[ ] = 'X-Ovh-Application: ' . $this->application_key;
$additionnal_headers[ ] = 'X-Ovh-Timestamp: ' . $now;

if ($is_authenticated) {
$additionnal_headers[ ] = 'X-Ovh-Consumer: '. $this->consumer_key;

$signature = '$1$' . sha1( $this->application_secret . '+' . $this->consumer_key . '+' . $method . '+' . $url . '+' . $body . '+' . $now );
$additionnal_headers[ ] = 'X-Ovh-Signature: '. $signature;
}


switch( $method )
{
case 'GET' :

if( count($params) )
{
foreach( $params as $k => $v )
{
$url .= (strpos( $url, '?' )===false ? '?' : '&'). urlencode( $k ) . '=' . urlencode( $v );
}
}

return json_decode( Controller_admin_util_curl::get( $this->api_url . $url, $additionnal_headers ) );

break;
case 'POST' :

return json_decode( Controller_admin_util_curl:ost( $this->api_url . $url, $body, false, $additionnal_headers ) );

break;

case 'PUT' :

return json_decode( Controller_admin_util_curl:ut( $this->api_url . $url, $body, $additionnal_headers ) );

break;

case 'DELETE' :

return json_decode( Controller_admin_util_curl::delete( $this->api_url . $url, $additionnal_headers ) );

break;
}
}

private function calculateTimeDelta()
{
if ( $this->time_delta===null ) {
$response = Controller_admin_util_curl::get( $this->api_url . '/auth/time' );
$this->time_delta = intval( $response ) - time();
}
return $this->time_delta;
}
}

class Controller_admin_util_curl {

public static function get($url, $additionnal_headers=array() )
{

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

if( count( $additionnal_headers ))
curl_setopt($ch, CURLOPT_HTTPHEADER, $additionnal_headers);

$output = curl_exec($ch);

echo curl_error ($ch);

curl_close($ch);

return $output;
}

public static function post($url, $posts, $form_urlencoded=false, $additionnal_headers=array() )
{
$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

curl_setopt($ch, CURLOPT_POST, 1);

curl_setopt($ch, CURLOPT_POSTFIELDS, $posts);

if( $form_urlencoded )
{
$additionnal_headers[] = 'Content-Type: application/x-www-form-urlencoded';

}

if( count( $additionnal_headers ))
curl_setopt($ch, CURLOPT_HTTPHEADER, $additionnal_headers);

$output = curl_exec($ch);

echo curl_error ($ch);

curl_close($ch);

return $output;

}

public static function put($url, $posts, $additionnal_headers=array() )
{

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");
curl_setopt($ch, CURLOPT_POSTFIELDS, $posts);

$additionnal_headers[] = 'Content-Type: application/json';
$additionnal_headers[] = 'Content-Length: ' . strlen($posts);

if( count( $additionnal_headers ))
curl_setopt($ch, CURLOPT_HTTPHEADER, $additionnal_headers);

$output = curl_exec($ch);

echo curl_error ($ch);

curl_close($ch);

return $output;

}

public static function delete($url, $additionnal_headers=array() )
{

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'DELETE');

if( count( $additionnal_headers ))
curl_setopt($ch, CURLOPT_HTTPHEADER, $additionnal_headers);

$output = curl_exec($ch);

echo curl_error ($ch);

curl_close($ch);

return $output;

}

}
Usage pour tester la dispo d'un domaine :

$a = new Controller_sbo_util_apiovh;
print_r( $a->domainCheck( 'machin.fr' ) );

ZeDvD
21/12/2015, 23h34
Autre question : j'ai essayé l'API sans utiliser le wrapper OVH, mais en utilisant CURL, trouvé ici : http://servuc.fr/blog/?p=110
Beaucoup plus simple à installer soit dit en passant.

et j'arrive à créer un multidomaine en faisant ça :
$ovh->post('/hosting/web/waibe.fr/attachedDomain', array(
'domain' => 'www.wobile.org',
'path' => 'mon_path',
)

Par contre je n'arrive pas à le détruire.
C'est quoi l'URL à utiliser, pour faire suite à mon exemple précédent ?

J'ai utilisé ça : /hosting/web/waibe.fr/attachedDomain/www.wobile.org

Mais en retour d'erreur j'ai ça :
Array ( [errorCode] => NOT_GRANTED_CALL [httpCode] => 403 Forbidden [message] => This call has not been granted )

Si je print l'url CURL, j'ai ça : https://eu.api.ovh.com/1.0/hosting/w...www.wobile.org

Où est mon erreur ?
Est-ce que le delete fonctionne pour les multi-domaines ?

ZeDvD
21/12/2015, 22h41
Bon, et bien après plusieurs heures à galérer, ce n'est pas gagné. J'ai réussi à installer et utiliser composer. J'en suis au point où l'appel suivant marche (du moins ça ne plante pas et un print_r ($conn) me donne qq chose)

$conn = new Api( $applicationKey,
$applicationSecret,
$endpoint,
$consumer_key,
$client);


Le coup d'après, je veux faire un truc simple : créer un multi-domaine juste pour tester. Voici ce que je fais

$result = $conn->post(
'/hosting/web/waibe.fr/attachedDomain', array (
'domain' => 'www.wobile.org',
'path' => 'www/sites/adwaibe',
)
);

Et là problème :
- Quand je teste en local sur easyphp : Uncaught exception 'GuzzleHttp\Ring\Exception\RingException' with message 'cURL error 60: SSL certificate problem
=> Ca sent le certificat SSL non présent, mais je n'en ai pas en local sur mon PC, donc comment je fais ?

- Quand j'upload sur mon hébergement OVH et que j'exécute, ben erreur 500 ! Je n'ai aucun moyen de debugger, pas d'erreur affichée si ce n'est 500

Je fais quoi docteur ?

MaxV
21/12/2015, 17h41
Bonjour,

Je vais répondre juste sur la partie de la fonction mailingListSubscriberAdd, je ne veux pas me lancer dans le débat du framework pour l'instant
En effet, nous avons changé le comportement de cette fonction.
Je pense qu'ignorer les doublons, c'est vous cacher une information qui peut être utile pour certain utilisateur.

Mais je ne comprends pas bien pourquoi tu vérifie que l'adresse est bien dans la liste ?
Tu ne peux tout simplement passer à la suite si la fonction te retourne 'AlreadyExist' ?

vcasse
21/12/2015, 17h40
@ZeDvD je me renseigne pour les IPs

@Benjo2857 : rien n'empêche de faire les appels directement en curl, vu que l'API est accessible en HTTP . J'ai transmis en interne la demande sur la SoAPI mailing list (je ne suis pas expert de cette partie).

Cordialement,
Vincent

ZeDvD
21/12/2015, 16h46
Merci Vincent pour ces réponses.
Au passage, est-ce que quelqu'un de la team OVH peut me dire pourquoi mon IP a été bloquée sur le forum, je suis obligé de passer par un proxy pour arriver ici. Je ne suis pas le seul, voir le post "IP bloquée vers le forum ?"

Benjo2857
21/12/2015, 15h30
Bonjour,

J'avoue que je partage un peu l'avis de ZeDvD sur ce coup là. Je ne suis pas fan non plus de tous ces frameworks, outils tiers et autres couches et sur-couches qui transforment des petits projets en usines à gaz. Pour des gros projets gérés par des grosses équipes, admettons, mais pour des petits sites, ça me donne l'impression de prendre un fusil à pompe pour tuer un moustique... Et puis, perdre du temps à reprogrammer des applis qui fonctionnent à cause d'une mise à jour forcée, merci!!

En plus, certaines nouvelles fonctions ne semblent pas tout à fait équivalentes. Par exemple, avec l'ancienne fonction mailingListSubscriberAdd, lorsqu'on essayait d'insérer une adresse email déjà présente dans une mailing-list, la commande était tout simplement ignorée, pas d'erreur, pas de doublon et c'était bien comme ça. Avec son "équivalent" API, ça retourne rien de moins qu'une FATAL ERROR "AlreadyExist", un truc du genre... Je me vois donc obligé de vérifier au préalable que l'adresse n'est pas déjà présente. Comme il n'existe pas de fonction (sauf erreur de ma part) pour vérifier la présence d'une seule adresse, je dois récupérer l'intégralité des adresses dans un tableau et vérifier avec un in_array. Ça me parait bien lourd comme traitement...

vcasse
21/12/2015, 12h33
Bonjour ZeDvD,

Nous avons principalement choisis composer pour une raison : c'est l'outil qui s'est imposé comme standard dans le monde PHP (monde qui a bien changé depuis cinq ans !)

En réalité, si nous avions généré un package zip à notre sauce, c'est nous qui aurions imposé quelque chose de non standard
Mais je note dans un coin : on pourrait tout de même proposer un zip avec les dépendances installées "à la composer".

N'hésites pas à revenir vers nous en cas de soucis

Cordialement,
Vincent

ZeDvD
21/12/2015, 12h03
Merci, je vais tester ça, mais je vais t'avouer que c'est pénible d'utiliser encore un nouveau framework, qu'il faut installer, et apprendre à utiliser. OK on va me dire "tu vas gagner du temps", mais il n'y a pas que composer comme outil à apprendre, et chacun vend sa sauce et impose donc ses outils.

Je comprends bien l'intérêt de composer, mais en ce qui me concerne j'aurais préféré un joli package zip qui contient toutes les dépendances : je dezippe où je veux et ça marche direct en 2 minutes. OK c'est pas ce qu'il y a de mieux pour gérer les upgrade, mais quand on nous impose un changement d'API et qu'en plus on nous impose des outils, au final c'est beaucoup de temps perdu, et pour une entreprise, le temps c'est de l'argent. Et je préfère choisir mes outils, travailler à l'ancienne avec ceux que j'ai choisis.

Allez, J'arrête de faire ma mauvaise tête, j'installe composer, et je reviens ici si j'ai des problèmes.

vcasse
21/12/2015, 10h52
Bonjour ZeDvD,

Il me semble tu es sur le bon chemin Mais qu'il te manque un élément important : l'utilisation de composer.
Ce tutorial sur openclassroom (ex siteduzero) pourra t'aider à comprendre comment l'utiliser : https://openclassrooms.com/courses/d...ace-a-composer

Autant te dire qu'une fois qu'on a commencé à utiliser composer, on gagne du temps dans ces développements en utilisant les librairies existantes

Pour t'aider là, les messages d'erreur que tu obtiens indiquent que tu n'as pas téléchargé la librairie Guzzle. Elle est en charge de simplifier la couche HTTP tout en optimisant l'utilisation de PHP (je passe les détails, mais ca permet un meilleur contrôle de la consommation mémoire entre autre).

Pour télécharger les librairies nécessaires à ton script, il faut que tu crées un fichier composer.json qui contient :

{
"name": "Nom de mon script",
"description": "Une petite description de mon script",
"require": {
"ovh/ovh": "dev-master"
}
}
Ce fichier indique qu'elles sont les librairies nécessaires pour faire fonctionner ton script. Ici, c'est seulement la librairie ovh/ovh qui est nécessaire.

Pour les télécharger, il faut récupérer composer :
- Documentation officielle pour linux/mac : https://getcomposer.org/doc/00-intro...linux-unix-osx
- Documentation officielle pour windows : https://getcomposer.org/doc/00-intro...lation-windows

Une fois installer, il faut que vous lanciez composer pour télécharger les dépendances avec la commande
composer install
Si vous affichez le contenu du répertoire, vous verrez apparaitre un dossier vendor. C'est le dossier où est téléchargé l'ensemble des librairies.
Dans ton cas, il va télécharger le code de ovh (sur github) mais aussi le code de guzzle qui est utilisé par la librairie ovh.

Ainsi, votre script doit commencer comme ceci afin de fonctionner :

require __DIR__ . '/vendor/autoload.php';
use \Ovh\Api;

// Informations about your application
$applicationKey = "your_app_key";
$applicationSecret = "your_app_secret";
$consumer_key = "your_consumer_key";

// Information about API and rights asked
$endpoint = 'ovh-eu';

// Get servers list
$conn = new Api( $applicationKey,
$applicationSecret,
$endpoint,
$consumer_key);
....
Si cela ne fonctionne toujours pas, n'hésites pas à poster des messages d'erreur et ton code (sans les clés, bien entendu) afin que nous puissions t'aider

A titre d'informations :
Pourquoi nous utilisons Composer et Guzzle ?
- Guzzle car HTTP se compose de multiples subtilités ... due à la norme, mais aussi à l'ensemble des soucis qui peuvent se produire entre un script et un serveur (réseau, soucis logiciels sur les machines ...). Ainsi, Guzzle garanti l'utilisation des meilleures pratiques en terme de développement, et limite les consommations mémoire et cpu des scripts.
- Composer évite de devoir transporter des arborescences complétes lors du déploiements de scripts. Comme par FTP par exemple. En effet, lorsque le nombre de librairie devient important, la quantité de fichier est telle que l'upload de ce script peut devenir complexe (avez vous déjà essayer d'envoyer 10000 fichiers par FTP ? ...). Composer permet d'uploader uniquement le script et le fichier composer.json, et de lancer la commande depuis le serveur.
- Composer est composé d'un système de mise à jour (commande : composer update). Cela permet d'avoir les dernières versions des librairies, et permet de boucher rapidement les failles de sécurité.

N'hésitez pas à m'indiquer si quelquechose n'a pas été clair. Ce bout de texte pourrait être une base pour un tutorial détaillé.

Cordialement,
Vincent

techos
21/12/2015, 09h52
Tu trouveras une aide pour intégrer l'API OVH dans ton projet ici : https://www.ovh.com/fr/g1894.install...nts_mutualises

ZeDvD
21/12/2015, 00h42
Bon, ben désolé, mais moi je n'y comprends rien, ça fait des heures que je suis dessus.

J'aimerais avoir un tuto CLAIR afin d'être sûr de bien comprendre, car on ne peut pas dire que le manuel soit explicite. J'ai bien récupéré mes clefs d'application, clef secrète et clef consumer. Et après ?...

Parce que j'ai juste essayé ça dans un fichier PHP :


namespace Ovh;

require_once ("php-ovh-master/src/Api.php");
$ovh = new Api(
$_ak, // Clef application
$_as, // Secret key
"ovh-eu",
$_ck // Consumer key
);

?>

et j'obtiens ça : Class 'GuzzleHttp\Client' not found in ...
Normal quand on regarde le code de Api.php.

Mais à ou se trouve ce GusslezHttp?
Dans le quistart je vois également '/vendor/autoload.php' : d'où ça sort ?

Bref, c'est incompréhensible, donc est-il possible d'avoir un tuto clair ?

Je vous propose un cas concret : comment créer un multi-domaine ?
Est-ce que quelqu'un peut poster le code à implémenter ?

michelp-oziolab
18/12/2015, 16h57
J'ai des serveurs de monitoring qui utilisent l'envoi de SMS via OVH d'alerter ca fonctionne très bien avec l'api SOAP depuis plusieurs années.

L'envoi tient dans un seul script php de quelques lignes, simple, compréhensible, sans chichi ni dépendances en pagailles, et ca fonctionne même sur de vieilles versions de PHP.
C'était même un exemple fourni par OVH à l'époque...

A l'inverse, je trouve cette nouvelle API inutilement compliquée et trèèès lourde.
Tout ca pour un script qui envoi UN sms.

Les exemples fourni , qui font référence à des dépendances à chercher sous github à droite ou à gauche, à replacer en local dans une grande pagaille de dossiers et sous-dossiers, sont bien significatifs de cette lourdeur inutile.

Sur certains vieux serveurs la version de PHP n'est même pas compatible avec le namespace, il n'y a pas de github dessus (pas besoin) et je ne m'aventurerais surtout pas à tenter des mises à jour sur ces vieux coucous au risque d'en rompre le fonctionnement.

Bref, OVH = pourquoi faire simple si on peut faire compliqué >:-(

Je suis très déçu de cette "évolution".

ksio
17/12/2015, 13h59
Citation Envoyé par romain.beuque
Bonsoir,

Je suppose que vous faites référence à l'attribution d'un domaine à un contact facturation/technique/admin spécifique lors de la commande.
Actuellement, le contact associé est le contact connecté via l'APIv6.

Nous sommes en discussion sur une façon sécurisée de permettre la personnalisation de ces contacts dès la commande.
Bonjour,

Oui, je parlais bien de choisir les contacts pour ces rôles.

Merci.

JMGWEB
17/12/2015, 00h41
Bonjour.

j'ai toujour comme réponse :
Not Found (404)
{ "message": "This service does not exist" }
? je loupe quelque chose ?
J'ai la même réponse avec tous ce qui touche a DynHost ...

Edit :

Je m'auto répond , on ne sait jamais ... ca peut servir a d'autre " distrait " ...
Je n'étais tous simplement pas sur le bon nom de domaine ( oui je sais " houuuuu " )

romain.beuque
16/12/2015, 17h44
Bonsoir,
Citation Envoyé par ksio
Bonjour,

Malheureusement, tant que l'on ne peut pas associer un domaine aux NIC qui le concernent, ce n'est pas le cas.
Je suppose que vous faites référence à l'attribution d'un domaine à un contact facturation/technique/admin spécifique lors de la commande.
Actuellement, le contact associé est le contact connecté via l'APIv6.

Nous sommes en discussion sur une façon sécurisée de permettre la personnalisation de ces contacts dès la commande.

Citation Envoyé par ksio
Il nous manque aussi l'info pour savoir si c'est actuellement hébergé par vos services (ce qui pour nous est plus simple à gérer et donc moins cher pour nos clients à transférer sur notre CMS)
C'est un cas d'usage que nous n'avions pas imaginé lors des planifications, c'est noté, je vous tiens au courant.

Bonne soirée
Romain Beuque

JMGWEB
16/12/2015, 11h38
Citation Envoyé par LaurentLep
Bonjour,

Veuillez nous excuser pour cette erreur de communication de notre part.
Comme mentionné précédemment, la date de fermeture du service SoAPI n'est pas encore définie car nous devons implémenter dans un premier temps les fonctions APIv6 manquantes. Ce travail est en cours de développement par nos équipes.

J'aimerais rassurer tous les utilisateurs actuels de SoAPI.
Nous n'allons pas fermer le service sans vous accompagner.
La fermeture se fera section par section en fonction de vos retours a minima 3 mois après la fin des développements.

Cordialement,
Laurent
Bonjour.

Merci Laurent , vous nous rassurer ...
Pour être précis , les fonctions que nous utilisons principalement est la gestion des DynHost.

b.a.v

vcasse
16/12/2015, 10h42
Bonjour WebArtMedia,

Est ce que vous avez des exemples précis d'appels SoApi que vous souhaitez migrer ?
C'est l'occasion de créer des documentations qui correspondent à vos besoins

Cordialement,
Vincent

LaurentLep
16/12/2015, 09h19
Bonjour,

Veuillez nous excuser pour cette erreur de communication de notre part.
Comme mentionné précédemment, la date de fermeture du service SoAPI n'est pas encore définie car nous devons implémenter dans un premier temps les fonctions APIv6 manquantes. Ce travail est en cours de développement par nos équipes.

J'aimerais rassurer tous les utilisateurs actuels de SoAPI.
Nous n'allons pas fermer le service sans vous accompagner.
La fermeture se fera section par section en fonction de vos retours a minima 3 mois après la fin des développements.

Cordialement,
Laurent

WebArtMedia
15/12/2015, 17h23
Bonjour à toutes et à tous,

Nous actons la fermeture de SoAPI !

Cependant, il serait plus que bien d'avoir une documentation en FRANÇAIS pour l'utilisation de la nouvelle APIv6 ; et surtout des exemples détaillés. On ne peut pas remplacer des technologies anciennes par de nouvelles si celles-ci ne sont pas au moins tout aussi simples et efficaces à utiliser.
SoAPI est certainement devenue obsolète mais elle avait le mérite d'être très simple à utiliser, en PHP par exemple, et tout aussi simple à intégrer dans nos scripts de développeur.

Pour le moment APIv6 reste confus, et compliquée à mettre en place. Il faut nous aider à être capable rapidement de mettre à jour tous nos scripts ; nous ne pouvons pas éplucher des dizaines de lignes de codes en plus de notre travail de développeur déjà bien chargé, chaque fois qu'OVH décide de procéder à des changements et à des mises à jour... Et je suis persuadé ne pas être le seul à penser cela !
Par exemple, sous PHP, lors de la création de la nouvelle extension MySQLi, des fonctions équivalentes ont été créées afin de permettre aux développeurs de modifier facilement leurs scripts et de se mettre à jour... Il serait plus que bien de trouver pareille démarche.

En attendant de bonnes nouvelles à ce sujet, je suis preneur de toutes astuces et nouvelles informations à ce sujet !
Bien cordialement à vous toutes et à vous tous,

Vincent

JMGWEB
15/12/2015, 14h28
non , non ...
tous au long du contact support nous parlont du SoAPI...
Et c'est le mot " AVEC " qui l'indique.

La fermeture est planifiée avec la fermeture du manager v3 au 04-01-2016.
J'ai recus cette réponse un peu comme un " va promener " après avoir insister plusieur fois pour avoir une date précise sur la fermeture du SoAPI.

ksio
15/12/2015, 14h22
Citation Envoyé par JMGWEB
Bonjour....


... Ca nous laisse 3 semaines pour s'adapter !
Le support m'annonce ici une FERMETURE au 04.01.
non pas une fermeture progressive comme je peut le lire sur le forum.

Je vois mal comment je vais défendre OVH devant mon boss avec un tel mépris de vos client.
Placer vos clients devant le fait accomplis 3 semaine avant la fin de vos services , c'est difficilement défendable.
Si je lis bien l'email du support, ils parlent de "l'autre" migration forcée et catastrophique, celle du manager.

JMGWEB
15/12/2015, 14h19
Bonjour....

Pour infos voici un mail officielle du support OVH lorsque j'insiste pour avoir une date de fermeture :

De : Support OVH
Voir la version brute du message

La fermeture est planifiée avec la fermeture du manager v3 au 04-01-2016.

Je reste à votre disposition pour toute demande complémentaire.

Cordialement,

Hamida
Conseiller WEB
... Ca nous laisse 3 semaines pour s'adapter !
Le support m'annonce ici une FERMETURE au 04.01.
non pas une fermeture progressive comme je peut le lire sur le forum.

Je vois mal comment je vais défendre OVH devant mon boss avec un tel mépris de vos client.
Placer vos clients devant le fait accomplis 3 semaine avant la fin de vos services , c'est difficilement défendable.

ksio
15/12/2015, 09h04
Bonjour,

Citation Envoyé par romain.beuque
Le fichier order.py est un script interactif pour commander un domaine, il est prêt à être utilisé en état.
Citation Envoyé par romain.beuque
Dans le cadre des créations, actuellement, le processus complet de commande fonctionne et l'on peut donc générer un bon de commande valide avec l'API. Le développement du paiement automatique des bons de commande (équivalent des fonctions du groupe reseller) est également en cours par les développeurs OVH. Ces méthodes SoAPI ne seront donc pas fermées avant l'équivalence en APIv6.
Malheureusement, tant que l'on ne peut pas associer un domaine aux NIC qui le concernent, ce n'est pas le cas.

Citation Envoyé par romain.beuque
Un domaine commandable sur /order/cart/{cartId}/domain signifie qu'il est disponible à la création.
L'information qui a disparu est donc de savoir si un domaine est transférable : ceci sera développé lors de l'implémentation de la commande de nom de domaine en transfert entrant vers OVH.
Il nous manque aussi l'info pour savoir si c'est actuellement hébergé par vos services (ce qui pour nous est plus simple à gérer et donc moins cher pour nos clients à transférer sur notre CMS)

Harck
12/12/2015, 22h35
Que va devenir l'outil MoM avec la fermeture de SoAPI ?

https://forum.ovh.com/showthread.php...haine-de-SoAPI

Merci

romain.beuque
11/12/2015, 16h12
Bonjour,

Citation Envoyé par ksio
Alors pour l'erreur que je mentionnais, après avoir passé pas mal de temps a décortiquer votre code, j'ai fait marcher une fonction simple mais au prix d'un résultat très décevant.
L'API de commande de domaine a été annoncée il y a quelques semaines, sur un post dans le forum.
Nous avons mis à disposition une documentation permettant d'expliquer le workflow de commande d'un domaine, ainsi que des exemples de code pour bien démarrer avec l'API : https://github.com/ovh/order-cart-examples
Le fichier order.py est un script interactif pour commander un domaine, il est prêt à être utilisé en état.

Citation Envoyé par ksio
GET /order/cart/{ cartId }/domain donne beaucoup moins d'info que donnait domainCheck en SOAP.
Nous avions si le domaine était dispo, si il était chez OVH, si il était transférable.

Maintenant nous savons si il est commandable (ca veut dire quoi ?) et nous avons des prix, plusieurs pour un seul domaine (9.99€ et 10.99€, pourquoi ?). incompréhensible et très insuffisant.
Un domaine commandable sur /order/cart/{cartId}/domain signifie qu'il est disponible à la création.
L'information qui a disparu est donc de savoir si un domaine est transférable : ceci sera développé lors de l'implémentation de la commande de nom de domaine en transfert entrant vers OVH.

Les différents prix sont à interpréter avec le "label" associé au prix. A savoir que vous pouvez récupérer actuellement 5 types de prix différents (visibles dans le type de retour de la fonction http://demo.ovh.eu/fr/eaa892b3ba6d948c01a20ae63cbe2db4/ ) :
- "PRICE" : le prix normal HT du domaine
- "DISCOUNT" : le montant de la promotion en cours sur le domaine (HT)
- "FEE" : le montant des frais additionnels ou frais de dossiers sur le domaine (HT)
- "TOTAL" : le montant total HT du domaine
- "RENEW" : le prix du renouvellement actuel pour ce domaine

Les prix détaillés sont donnés à titre indicatif, si vous ne souhaitez que connaître le prix final HT, il convient de prendre TOTAL.
A savoir: TOTAL = PRICE + DISCOUNT + FEE


Citation Envoyé par ksio
Mais il y a pire :

la fonction resellerDomainRenew est en TODO. Comment va-t-on faire ?

Enfin, le ponpon :

la fonction resellerDomainTransfer n'est même pas mentionnée dans votre doc de migration. J'ai supposé que nous pouvions faire comme les fonctions qui ont un nom proche (resellerDomainTransferASIA?). Sauf que la fonction en Soap permetait d'acheter un domaine et de l'assigner à un NIC, la fonction que vous proposez permet de mettre un domaine dans un panier, on y comprend rien, et pas de mention des NIC.
Concernant les actions de renew et de transfer, les fonctions d'APIv6 correspondantes seront implémentées dans une seconde période, nous terminons l'implémentation de la création de domaines pour les extensions avec conditions particulières.

Dans le cadre des créations, actuellement, le processus complet de commande fonctionne et l'on peut donc générer un bon de commande valide avec l'API. Le développement du paiement automatique des bons de commande (équivalent des fonctions du groupe reseller) est également en cours par les développeurs OVH. Ces méthodes SoAPI ne seront donc pas fermées avant l'équivalence en APIv6.

Pour le fonctionnement global, je vous conseille vivement de vous rendre sur la page GitHub que j'ai indiqué plus haut, des explications sont déjà fournies qui pourront répondre à une grande partie de vos interrogations sur l'utilisation des différentes méthodes API; pour le reste, je suis disponible pour un complément d'information, ou envisager des évolutions de l'API si vous avez des besoins plus spécifiques.

N'hésitez donc pas à revenir vers nous pour d'autres questions à propos de la nouvelle commande.

Bien cordialement,
Romain

titiscan
11/12/2015, 16h00
Ok merci pour la réponse.

Ayant lu :
N’hésitez pas à nous remonter vos remarques, besoins, interrogations, blocages…
Tout feedback est le bienvenu afin de préparer au mieux cette transition.
c'est ce que j'ai essayé de faire...
Pour le moment je reste bloqué, les fonctions n'existe pas ou sont inexploitable
et je ne sais pas si les infos que j'ai remonté vont être prises en compte

bon courage

JMGWEB
11/12/2015, 15h22
Citation Envoyé par LaurentLep
Bonjour,

Le service SoAPI ne sera pas fermé au 1er Janvier 2016, la fermeture sera programmée une fois les développements terminés et vous en serez bien entendu informé en amont.
L'objectif ici est de vous accompagner et de faire en sorte que la transition se passe pour le mieux.
Vos retours vont nous permettre de prioriser les développements afin de proposer une équivalence APIv6 pour chacune des méthodes SoAPI utilisées.
La page https://www.ovh.com/fr/soapi-to-apiv6-migration/ sera bien sur maintenue à jour.

Cordialement,
Laurent
Bonjour.

Pour notre part nous utilisons ce qui concerne les Dynhost. pour + - 250 clients.
Mon responsable de projet me demande des dates précises.
Toutes les infos actuellement reçues ne le sont pas.
Nous planifications les tâches sur 3 mois.
Vous comprenez aisément le pourquoi de notre insistance.
Si vous me dite en janvier , on stop SoApi en février pour nous , c'est bye bye ... délais trop court pour planifier l'équipes.

Nous seront " prévenus " OK. Mais dans quel délais ?

Merci d'avance pour vos réponses.

LouisM
11/12/2015, 14h43
Citation Envoyé par Raphy
Nous venons de tester de nouveau mais malheureusement, cette dernière ne fonctionne toujours pas.
(Il s'agit bien du support VIP)
Je regarde ça en privé pour avoir vos références. ( louis.marie@corp.ovh.com )
Pouvez-vous me fournir le groupe et ligne mis en paramètre ?

Citation Envoyé par titiscan
juste l'id ? par ex : 45408752 ou 45408749
Suivant l'opérateur distant, le PTT de transmission en cas de succès est différent. Pour ces 2 sms et leur PTT 2001 / 1001 indiqué la bonne transmission du message

Citation Envoyé par titiscan
et pour le reste ?
C'est à dire ?

J'ai de mon côté remonté le guide aux équipes concerné pour mettre à jours la documentation.

Citation Envoyé par titiscan
string ip : the ip
boolean engage : is the line engaged ?
string status : the status (OK|BLOS|BLOF)
int port : the outgoing router udp port
boolean outOfService : is the phone out of service ?
Tu peux avoir quelque info qui ne sont pas identique mais en lien avec ce qui tu veux

Par exemple ceci te donne les heures et IP des derniers enregistrement (requête REGISTER) de ta ligne
/telephony/{billingAccount}/line/{serviceName}/ips

pour les autres infos, elles ne sont pas disponible dans l'API.

Raphy
11/12/2015, 14h34
Citation Envoyé par LouisM

Côté Telecom nous n'avons pas stopé de fonction.

Je viens de tester celle indiqué :
- telephonyBillingAccountSet

Celle-ci fonctionne correctement.

Cependant si vous avez le support VIP j'avais une tache concernant un défaut sur cette fonction. Celui-ci a été corrigé en fin de journée hier.
Avez-vous toujours le défaut ?
Nous venons de tester de nouveau mais malheureusement, cette dernière ne fonctionne toujours pas.
(Il s'agit bien du support VIP)

Merci d'avance

LaurentLep
11/12/2015, 14h00
Bonjour,

Le service SoAPI ne sera pas fermé au 1er Janvier 2016, la fermeture sera programmée une fois les développements terminés et vous en serez bien entendu informé en amont.
L'objectif ici est de vous accompagner et de faire en sorte que la transition se passe pour le mieux.
Vos retours vont nous permettre de prioriser les développements afin de proposer une équivalence APIv6 pour chacune des méthodes SoAPI utilisées.
La page https://www.ovh.com/fr/soapi-to-apiv6-migration/ sera bien sur maintenue à jour.

Cordialement,
Laurent

titiscan
11/12/2015, 13h52
Citation Envoyé par LouisM
As-tu un id sms concerné que je puisse regarder cela ?
juste l'id ? par ex : 45408752 ou 45408749

et pour le reste ?

merci

LouisM
11/12/2015, 13h47
Citation Envoyé par Raphy
Depuis Vendredi dernier la fonction SoAPI telephonyBillingAccountSet n'est plus fonctionnel et cela est un réel problème pour notre client.
Avez-vous déjà arrêté des fonctions ?
Côté Telecom nous n'avons pas stopé de fonction.

Je viens de tester celle indiqué :
- telephonyBillingAccountSet

Celle-ci fonctionne correctement.

Cependant si vous avez le support VIP j'avais une tache concernant un défaut sur cette fonction. Celui-ci a été corrigé en fin de journée hier.
Avez-vous toujours le défaut ?

Citation Envoyé par JMGWEB
vcasse pourquoi certaine sur ce post reçoive-t-elle des réponses et d'autre pas ?

A qui devons nous nous adresser ?
Pour ma part je vais me permettrait de répondre au question qui concerne la partie telecom de l'API. Ceci afin de pouvoir vous accompagner au mieux dans vos migrations.

Pour les question plus général sur l'API mon collègue Laurent a bien vu vos messages. Vous aurez plus de réponse prochainement.

LouisM
11/12/2015, 12h22
Bonjour,

Citation Envoyé par titiscan
Je commence donc par regarder la correspondance avec la méthode telephonySmsUserHistory qui me renvoie vers /sms/{serviceName}/users/{login}/jobs/{id}
Je pense que /sms/{serviceName}/users/{login}/outgoing et plus adapté mais bon...
Tout à fait , je regarde pour corriger cela.

Citation Envoyé par titiscan
Ca serait bien aussi d'avoir la signification des codes retours. (j'ai trouvé çà http://guides.ovh.com/TelSmsCallBack mais le ptt à 1001 et 2001 c'est quoi?)
As-tu un id sms concerné que je puisse regarder cela ?

ksio
11/12/2015, 11h31
Citation Envoyé par Raphy
Je pense que nous sommes nombreux à attendre des réponses...
Chronique d'une catastrophe annoncée.

Raphy
11/12/2015, 10h50
Je pense que nous sommes nombreux à attendre des réponses...

Raphy
10/12/2015, 16h50
Bonjour,

Depuis Vendredi dernier la fonction SoAPI telephonyBillingAccountSet n'est plus fonctionnel et cela est un réel problème pour notre client.
Avez-vous déjà arrêté des fonctions ?

Merci d'avance

JMGWEB
10/12/2015, 16h48
bonjour.

vcasse pourquoi certaine sur ce post reçoive-t-elle des réponses et d'autre pas ?

A qui devons nous nous adresser ?

titiscan
10/12/2015, 16h46
Nouvel essai pour la méthode telephonyOfferInfo dont la correspondance serait /telephony/{billingAccount}/serviceInfos

mais les information données ne sont pas les mêmes...
une partie des informations sont dans /telephony/{billingAccount}/line/{serviceName}

mais je n'ai pas trouvé celle qui correspondent au 2 structures :

telephonyOfferInfoHardwareStruct hardware : the hardware details
telephonyOfferInfoSipAccountStruct sipAccount : the sip account details

pour la partie hardware, j'ai trouvé /telephony/{billingAccount}/line/{serviceName}/phone qui donne quelque infos mais il manque :

string ip : the ip
boolean engage : is the line engaged ?
string status : the status (OK|BLOS|BLOF)
int port : the outgoing router udp port
boolean outOfService : is the phone out of service ?

Merci

techos
10/12/2015, 16h22
Je trouve également qu'il manque un générateur de code qui nous simplifierait grandement la migration "forcée" et surtout impromptue ... C'est quand même assez moyen d’annoncer la mort de SOAPI 20 jours avant une éventuelle date...

ksio
10/12/2015, 16h20
Alors pour l'erreur que je mentionnais, après avoir passé pas mal de temps a décortiquer votre code, j'ai fait marcher une fonction simple mais au prix d'un résultat très décevant.

GET /order/cart/{ cartId }/domain donne beaucoup moins d'info que donnait domainCheck en SOAP.
Nous avions si le domaine était dispo, si il était chez OVH, si il était transférable.

Maintenant nous savons si il est commandable (ca veut dire quoi ?) et nous avons des prix, plusieurs pour un seul domaine (9.99€ et 10.99€, pourquoi ?). incompréhensible et très insuffisant.

Mais il y a pire :

la fonction resellerDomainRenew est en TODO. Comment va-t-on faire ?

Enfin, le ponpon :

la fonction resellerDomainTransfer n'est même pas mentionnée dans votre doc de migration. J'ai supposé que nous pouvions faire comme les fonctions qui ont un nom proche (resellerDomainTransferASIA?). Sauf que la fonction en Soap permetait d'acheter un domaine et de l'assigner à un NIC, la fonction que vous proposez permet de mettre un domaine dans un panier, on y comprend rien, et pas de mention des NIC.

Je ne comprend même pas comment vous osez présenter une telle API à vos clients, avec un tel support et avec des manques aussi flagrants.

Nous utilisons l'API pour gérer des milliers de domaines, cela nous est indispensable, encore plus depuis la migration forcée et catastrophique à votre nouveau manager. Sans l'API, quelle solution nous reste t'il ? J'ai appelé le support technique VIP au téléphone ce matin, sans la moindre réponse concrète, et je vous avoue que je ne suis pas serein du tout.

A noter que nous avions rencontré votre société en session privée en janvier à Paris, en tant que client important pour la gestion des domaines. Nous avions alerté vos services de l'aspect critique de ces questions pour nous, et déjà nous sentions tout cela arriver.

titiscan
10/12/2015, 16h15
Bonjour,

Voulant anticiper cette migration, je commence par un bout de code me permettant afficher l'historique des envoi SMS.
Je commence donc par regarder la correspondance avec la méthode telephonySmsUserHistory qui me renvoie vers /sms/{serviceName}/users/{login}/jobs/{id}
Je pense que /sms/{serviceName}/users/{login}/outgoing et plus adapté mais bon...

Avec Soapi, je faisais un requête pour récupérer l'ensemble de l'historique. Là il faut récupérer un tableau d'id et faire une requête pour chacun ?
C'est à dire que pour récupérer les informations de 2000 messages il faut faire 2000 GET ?
(pour en récupérer une 50aine il faut déjà 15s. quand tout va bien contre 2s avec soapi)

A moins d'avoir raté un truc c'est juste pas possible !

Il n'y a pas non plus la possibilité de trier par date ou sur une période (la liste des sms envoyés aujourd'hui ou la semaine dernière)
Ca serait bien aussi d'avoir la signification des codes retours. (j'ai trouvé çà http://guides.ovh.com/TelSmsCallBack mais le ptt à 1001 et 2001 c'est quoi?)

Du coup pour le moment la migration c'est stand by...

Merci

vcasse
10/12/2015, 15h37
Bonjour ksio,

Effectivement, nous manquons encore d'exemples. On essaie de s'améliorer là dessus.

Pour le wrapper PHP, nous avons choisis d'utiliser Guzzle, une surcouche HTTP, qui permet de gérer un nombre de cas particuliers assez important lorsque l'on passe par un réseau et le protocole HTTP. Effectivement, pour les personnes ne connaissant pas cette librairie, cela peut sembler complexe la première fois. Mais une fois quelques minutes prises pour le prendre en main, c'est un gain de temps important

Est ce que tu peux partager un bout de code qui produit l'erreur dont tu parles, afin que nous puissons te guider ?

Cordialement,
Vincent

JMGWEB
10/12/2015, 15h10
Bonjour.

Pouvons-nous avoir une réponse plus précise que :
" Vous serez tenu informé de la date exacte de fermeture du service. "

Nous devons prévoir une planification et un refactoring de nos applications utilisant votre services SoAPI.

Cela est TRÈS important pour nous et représente un cout non négligeable.

Merci d'avance de nous apporter une réponse.

ksio
10/12/2015, 10h32
Bonjour,

Comme souvent, je suis assez sidéré par la suppression de services chez OVH. On aurait pu pensé que la miggration forcée de l'ancienne interface client à la nouvelle, incomplète et buggée, avait servie de leçon mais non.

La moitié des fonctions sont indiquées en "TO DO" sur votre nouvelle API, c'est fantastique. Comment on fait ?

Quand au code démo, il aurait été tellement simple de nous donner un code simple d'appel à une fonction, en 10 lignes, en PHP, sans nous donner un code GITHUB à analyser. Code qui n'est même pas fichu d'utiliser une librairie CURL de base, mais utilise "GuzzleHttp", encore une surcouche, encore un projet GITHUB. Vous savez que nous avons un vrai travail, qu'analyser le code des autres alors que nous avons quelques jours pour revoir des pans entiers de nos interfaces à causes de changements que vous décidez unilatéralement, c'est pas trop la passion de notre vie ?

J'essaie par exemple de faire fonctionner un code super simple : POST /order/cart avec les paramètres POST en json : {"ovhSubsidiary":"FR"}.
Réponse : {"message":"The input that you provided isn't valid JSON or not well formatted"}

Ou chercher ? Sans code d'exemple, on va y passer des heures.

pizzapp
10/12/2015, 09h52
Bonjour,

Apres avoir consulté la page consacrée à la migration de SoAPI vers APIv6, nous avons pu constater que telephonyVoicemailMessagesRemoteUpload était en état TODO.

Vous ne ferez pas de coupure de SoAPI avant de passer tous les éléments de la liste TODO ?
Combien de temps laisserez vous entre la finalisation (plus aucun TODO) de l'APIv6 et la suppression de SoAPI ?

Merci

Gaston_Phone
10/12/2015, 08h20
Je n'ai pas reçu de MAIL.

syldor
10/12/2015, 03h30
Bonjour,

l'annonce faite par mail a été envoyée a tous les utilisateurs ou uniquement ceux utilisant SoAPI régulièrement ?

On m'a transféré ce mail car un de nos clients est hébergé chez OVH et je dois identifier l'impact de la migration sur celui-ci.

Merci

Gaston_Phone
09/12/2015, 23h42
Par hasard auriez-vous une documentation en Français ?

JMGWEB
09/12/2015, 23h37
Bonjour.

Comme la si bien décrit " Koocotte " , le générateur de code dans les différents langages étais bien pratique. Devoir commencer a ce promener d'un github à l'autre en fonction que je réalise une interface en php , un programme client en c# ou bien encore d'autre commande , ce n'est pas bien pratique ...

Sans compter que " l'ancien " générateur de code permettais directement de comparer a partir des mêmes informations les différent code générer ... et parfois ca pouvait influencer le choix de tel ou tel langage ...

Bref ... oui à l'évolution , oui au nouvel APIv6 ... mais non à la perte des outils existants.

Ps : Citation : " Vous serez tenu informé de la date exacte de fermeture du service. "

Ça ne fait pas très " sérieux " ... Je doit fournir une date a mes clients et prévoir des budget de refactoring.

b.a.v

vcasse
09/12/2015, 17h41
Bonjour Koocotte,

Nous avons des wrapper d'API qui permettent d'abstraire toute l'encapsulation HTTP dans différents langages :
- PHP : https://github.com/ovh/php-ovh
- Python : https://github.com/ovh/python-ovh
- NodeJS: https://github.com/ovh/node-ovh

La documentation pour chaque langage est stockée sur github.
Est ce que cela peut vous aider ? Ou est ce que vous imaginez autre chose pour simplifier encore un peu plus votre utilisation de l'API ?

Cordialement,
Vincent

koocotte
09/12/2015, 16h53
Je ne suis pas contre le changement; mais au moins pour ce qui est de la gestion du mail, toutes les nouvelles méthodes sont marquées en "Beta", ça serait bien de finaliser l'interface avant de demander aux gens de migrer.

Est-ce qu'il est prévu des petits générateurs de code dans plusieurs langages courants comme dans la documentation de l'ancienne API, ça simplifiait grandement la vie.

LaurentLep
20/11/2015, 12h18
Bonjour,

En vue de la fermeture prochaine de SoAPI, l’heure est à l’état des lieux.
SoAPI, c’est environ 660 méthodes séparées en 21 groupes :


Seules 36% des 660 méthodes ont été appelées en Octobre 2015.
Certains groupes n’ont pas été appelés sur cette période (ManagedServices / Notepad / Prepaid / RPS / Misc / Reseller / Support).
D’autres sont encore largement utilisés (Telephony / Dedicated / Domains / Emails / Hosting…).

L’objectif d’OVH est de désactiver SoAPI groupe par groupe.
Pour cela, il est nécessaire d’identifier ce que vous, clients, utilisez afin qu'OVH puisse vous accompagner pendant votre migration vers l’APIv6.

La correspondance SoAPI / APIv6 est disponible à cette adresse : https://www.ovh.com/fr/soapi-to-apiv6-migration/

N’hésitez pas à nous remonter vos remarques, besoins, interrogations, blocages…
Tout feedback est le bienvenu afin de préparer au mieux cette transition.



la date de fermeture du service SoAPI n'est pas encore définie car nous devons implémenter dans un premier temps les fonctions APIv6 manquantes. Ce travail est en cours de développement par nos équipes.

J'aimerais rassurer tous les utilisateurs actuels de SoAPI.
Nous n'allons pas fermer le service sans vous accompagner.
La fermeture se fera section par section en fonction de vos retours a minima 3 mois après la fin des développements


-------

Voici la liste des méthodes à développer ainsi que leur status :



--
Laurent Lepczynski
Team OVH