none
Test de charge avec appel de web service Sharepoint 2010 RRS feed

  • Question

  • Bonjour,

    Je prépare des tests de charge sur un portail intranet basé sur Sharepoint 2010. J'ai enregistré un scénario web avec VS 2010 Ultimate. Lorsque je le réexécute unitairement depuis VS 2010 j'ai des erreurs sur tous les appels de web services Sharepoint (le scénario invoque des opérations du web service taxonomyinternalservice.json) avec un code erreur 500 peu explicite.

    Avez vous déjà rencontré ce type de problème ? Auriez vous une piste pour corriger cette erreur ?

    Je vous remercie.

     

     

     

     

    • Déplacé Hengzhe Li mardi 21 février 2012 05:28 merge forum (Origine :Développement Sharepoint 2010)
    lundi 16 janvier 2012 16:30

Réponses

  • Le bon fonctionnement avec la sécurité désactivée tend à confirmer que c'est bien le header "_REQUESTDIGEST" qui est en cause.

    En fonctionnement classique (lorsque vous enregistrez le test), ce header est automatiquement ajouté à vos requêtes.

    Lorsque vous exécutez votre test en revanche, soit ce header est manquant, soit il a une mauvaise valeur (probablement la même que celle de l'enregistrement, mais elle n'est plus valable).

    L'idéal serait de trouver comment paramétrer vos tests pour permettre le génération de ce header. A défaut votre solution de contournement semble être ce qu'il y a de mieux.


    Sébastien PICAMELOT - http://blogs.developpeur.org/gribouillon/

    samedi 21 janvier 2012 22:42
    Modérateur

Toutes les réponses

  • Bonjour,

    Est ce que le projet (visual studio) target bien une plateforme x64 et non x86?

    Est ce que le projet (visual studio) utilise le framework 3.5 et non 4.0?


    Bien cordialement, Adrien MARIE.
    mardi 17 janvier 2012 08:28
  • Bonjour,

    Le projet cible bien une plate-forme x64 et utilise le framework .NET 4.0

    Merci pour ce retour.

    Cdt;

     

    mercredi 18 janvier 2012 16:14
  • Bonjour,

    Pouvez-vous préciser comment le service est référencé ? S'agit-il d'une référence de service faite depuis Visual Studio ou bien de la propriété "ServiceUrl" d'un contrôle modifiée depuis le code ?

    S'il s'agit d'un contrôle, il a certainement une propriété "Context", et j'imagine dans ce cas que sa valeur n'est pas la même en situation de test de charge que lorsque vous testez l'application depuis l'interface. Si je vois juste, il vous faudra modifier le contexte HTTP pour ajouter un header spécifique. Le site http://www.multisy.com/Features/MMS/Wiki%20Pages/Services.aspx semble indiquer que le header "_REQUESTDIGEST" doit avoir le token "x-requestdigest" pour que le contrôle fonctionne bien.

    Si toutefois il ne s'agit pas d'une référence gérée directement par le contrôle, pouvez vous indiquer comment est faite la référence ?

    J'espère que ma réponse vous aidera.


    Sébastien PICAMELOT - http://blogs.developpeur.org/gribouillon/

    vendredi 20 janvier 2012 09:55
    Modérateur
  • Bonjour,

    Je vous remercie pour ce retour.

    En fait je me contente de réexécuter un test web de performance enregistré depuis VS 2010 Ultimate. Je n'ai pas modifié le code généré, j'exécute donc le fichier d'extension webtest. Je rencontre des erreurs http 500 lors du run du test capturé sur les appels de web service Sharepoint 2010.

    Les appels de web service Sharepoint se font au niveau de Contrôles de la page web.

    J'ai trouvé une solution de contournement qui consiste à désactiver la validation de la sécurité (Turn off security validation) de l'application web dans Sharepoint 2010, cela fonctionne mais ce n'est pas très satisfaisant.

    Merci bien.

     

     

     

    samedi 21 janvier 2012 12:59
  • Le bon fonctionnement avec la sécurité désactivée tend à confirmer que c'est bien le header "_REQUESTDIGEST" qui est en cause.

    En fonctionnement classique (lorsque vous enregistrez le test), ce header est automatiquement ajouté à vos requêtes.

    Lorsque vous exécutez votre test en revanche, soit ce header est manquant, soit il a une mauvaise valeur (probablement la même que celle de l'enregistrement, mais elle n'est plus valable).

    L'idéal serait de trouver comment paramétrer vos tests pour permettre le génération de ce header. A défaut votre solution de contournement semble être ce qu'il y a de mieux.


    Sébastien PICAMELOT - http://blogs.developpeur.org/gribouillon/

    samedi 21 janvier 2012 22:42
    Modérateur