Vous pouvez tout de même essayer un scope atomique
Le scope atomique a les effets suivants (de façon un peu schématique):
- l'orchestration ne peut pas être déshydratée pendant ce temps => pas de
sérialisation, les variables tels que pointeurs restent dispos
- Si des composants héritant de ServicedComponent sont appelés, ils
participeront à une transaction dont l'étendue correspond à celle du scope
atomique.
- Si le traitement de ce scope dure plus de 60 s (par défaut), le scope part
en timeout
Concernant votre cas, vous pouvez essayer de mettre votre boucle dans un
scope atomique pour voir si les choses s'accélèrent. Cela dit, je ne pense
pas qu'on puisse avoir une réception de message dans un scope atomique =>
cela risque de ne pas passer à la compilation.
De toutes façons, si on fait comme cela, on peut alors se poser la question
de savoir pourquoi on effectue l'opération dans une orchestration plutôt que
dans un composant.
Sur le temps d'instanciation d'un web service depuis une orchestration, je
n'ai rien trouvé de spécial. Est-ce que l'instanciation est longue depuis un
composant hors orchestration?
Est-ce qu'il n'y aurait pas une tentative de résolution de proxy longue. La
configuration au niveau du "Send Handler" SOAP est-elle correcte (BizTalk
Administration Console, ..., Adapters, SOAP, Send Handlers)
Est-ce que le Send Port est également configuré correctement?
Est-ce que netmon par exemple vous donne des informations sur ce qui se
passe au niveau réseau lors de l'appel du web service?
NB: si vous avez un grand nombre d'instances d'orchestration, il est
important de passer par le messaging plutôt que par l'appel d'un composant
pour ne pas avoir d'appel de composant "long" dans votre orchestration. Une
orchestration gère très bien une attente de message depuis le messaging,
moins bien l'attente du retour d'appel de méthode.
--
Benjamin Guinebertière
Microsoft France
Ce message est fourni en l'état, sans garantie d'aucune sorte, et ne vous
confère aucun droit. Vous assumez tous les risques liés à son utilisation.
Post by Quentin WehrléMerci de votre réponse, je vais essayer de répondre aux différents points.
Il n'y a aucun doute sur le fait que c'est l'instanciation qui prend du
temps; en mettant des points d'arret (ou en traçant l'exécution de
l'orchestration avec les timestamp) apres chaque appel au webservice il
ressort une chose: le temps perdu l'est seulement au 1er appel d'un web
service; pour les appels aux méthodes suivantes il n'y a pas de temps "perdu"
...
Je suis ouvert à toute proposition, mais j'associe ceci à l'instanciation
seule du web service ... J'en veu pour preuve le passage par une bibliothèque
de classes "tampon" permettant de garder la même instance du web service (via
une variable) tout au long de l'orchestration; avec ce système, aucune
lenteur n'est à déplorer ...
Ensuite, pour continuer d'apporter des indices, peut importe le nombre de
message présents (que ca soit 3 ou bien 200 voire 3000) le temps est le même,
approximativement 3 secondes ... je ne pense donc pas que ca ait quelque
chose à voir avec la sérialisation des messages en base ...
Pour finir sur le scope atomique, de toute façon cela est impossible puisque
nous utilisons des web services... (ou alors j'ai loupé quelquechose).
Le problème pourrait il venir du fait que les web service non pas été
indiqué comme [Serializable()] ?
Merci de votre aide
Cordialement
Post by Benjamin Guinebertière [MS]êtes-vous sûr que c'est l'instanciation du web service qui prend du temps?
Si vous implémentez l'ordre sous la forme d'un convoy par exemple et que
vous avez 3000 messages dans votre instance d'orchestration, à chaque
itération de la boucle, les 3000 messages sont peut-être sérialisés dans la
messagebox (voir dans la documentation quand une orchestration est
sérialisée en base pour plus de précisions).
Vous pouvez voir ce qui prend du temps dans l'orchestration debugger.
Sinon, quant à utiliser la même instance de web service, cela supposerait
qu'on puisse mettre des pointeurs en base: souvenez-vous qu'une
orchestration peut être sérialisée dans la messagebox n'importe quand (sauf
dans le cadre d'un scope atomique).
--
Benjamin Guinebertière
Microsoft France
Ce message est fourni en l'état, sans garantie d'aucune sorte, et ne vous
confère aucun droit. Vous assumez tous les risques liés à son utilisation.
Post by unknownBonjour,
Voici mon problème; dans mon orchestration, j'ai plusieurs appels à 2 web
services différents. Je gère la livraison chronologique et je remarque
clairement le temps d'instanciation des web services (2-3 secondes).
Le gros problème est que cette instanciation se produit pour chacun des
messages de mon fichier batch d'entrée.
Je n'ai trouvé nulpart de paramètre permettant d'indiquer qu'on utilise la
même instance du web service tout au long de l'orchestration (j'ai un Loop
dans l'orchestration pour chacun des messages) ...
Vous imaginez facilement la perte de temps que cela occasionne, dans le
meilleur des cas 4secondes par message, ca devient tres vite énorme
avec
200
messages à traiter ...
Merci de votre aide, je reste à votre disposition si mon explication
nécessite des éclaircissements