Client de test - Notes sur l'édition

© Copyright International Business Machines Corporation 2005. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Notes sur l'édition

1.0 Description
2.0 Restrictions
   2.1 Le client de test d'intégration requiert que les classes Java aient un constructeur sans argument
   2.2 Transactions et client de test d'intégration
3.0 Incidents recensés et solutions palliatives
   3.1 Il se peut que le débogueur ne s'initialise pas lors du premier appel à partir du client de test
   3.2 Le type d'appel asynchrone n'est pas directement pris en charge
   3.3 Les types de matrices en codage SOAP ne sont pas pris en charge pour l'appel
   3.4 Le module de médiation doit être achevé avant le test

1.0 Description

Ce fichier de notes sur l'édition contient des informations de dernière minute sur les restrictions, les incidents recensés et les solutions palliatives pour le client de test de WebSphere Integration Developer.

2.0 Restrictions

2.1Le client de test d'intégration requiert que les classes Java aient un constructeur sans argument

Le client de test d'intégration nécessite des classe Java (qui sont des arguments dans les signatures de méthode) ayant un constructeur sans argument ainsi que des méthodes de définition et d'obtention (get et set) appropriées pour chaque zone.

2.2Transactions et client de test d'intégration

Le client de test d'intégration est exécuté indépendamment de toutes les transactions des applications : il ne participe donc pas à ces transactions. Par conséquent, l'émulation de l'annulation des transactions n'est pas prise en charge.

3.0 Incidents recensés et solutions palliatives

3.1Il se peut que le débogueur ne s'initialise pas lors du premier appel à partir du client de test

Le client de test d'intégration démarre WebSphere Process Server 6.0 avant d'appeler le test si le serveur n'a pas encore été démarré.

A ce stade, vous pouvez choisir de démarrer le serveur en mode débogage ou en mode normal. Si vous choisissez le mode débogage, le client de test peut appeler le test avant l'initialisation complète du serveur. Les appels suivants seront correctement effectués.

Une solution à ce problème consiste à réexécuter le test après un échec ou à lancer le serveur avant d'appeler le test.

3.2Le type d'appel asynchrone n'est pas directement pris en charge

Le client de test d'intégration permet d'appeler un composant en utilisant le type d'appel synchrone.

Cela convient pour la plupart des composants, même si un composant ne prend en charge que le type d'appel asynchrone, car l'architecture SCA sous-jacente convertit l'appel synchrone en appel asynchrone. Mais un composant peut prendre en charge les deux types d'appel et présenter des chemins de code différents selon le type d'appel.

Vous pouvez tester les deux chemins de code. Dans ce cas, vous pouvez créer un composant Java qui effectue l'appel asynchrone et appeler ce composant à l'aide du client de test d'intégration, ou bien vous pouvez appeler le composant de façon asynchrone en utilisant un autre client, tel qu'une page JSP.

3.3Les types de matrices en codage SOAP ne sont pas pris en charge pour l'appel

Le client de test ne peut pas être utilisé pour appeler les composants qui définissent des données à l'aide de matrices en codage SOAP.

Exemple de snippet XSD :

..
<xsd:restriction base="soapenc:Array">
                        <xsd:attribute ref="soapenc:arrayType"
                            wsdl:arrayType="typens:ResultElement[]" />
  </xsd:restriction>

..

Une solution à ce problème consiste à créer un composant Java pour appeler le service. Le composant Java peut alors être appelé à l'aide du client de test.

3.4Le module de médiation doit être achevé avant le test

Avant le test d'un module de médiation au moyen du client de test d'intégration, tous les références de composants de flux de médiation doivent être connectées et une liaison doit être définie pour toutes les importations.  Si tel n'est pas le cas, des exceptions, telles que la suivante, sont générées lors de l'appel du composant :

Caused by: org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException: index=0, size=0
 at org.eclipse.emf.common.util.BasicEList.get(BasicEList.java(Compiled Code))
 at com.ibm.ws.sibx.mediation.flowaction.impl.sca.FlowActionFactoryImpl.getWire(FlowActionFactoryImpl.java:923)
 at com.ibm.ws.sibx.mediation.flowaction.impl.sca.FlowActionFactoryImpl.createRequestSCAFromSMO(FlowActionFactoryImpl.java:854)
 at com.ibm.ws.sibx.mediation.flowaction.impl.sca.SCAInvocationAction.invokeSync(SCAInvocationAction.java:343)
 at com.ibm.ws.sibx.mediation.flowaction.impl.sca.SyncInvocation.complete(SyncInvocation.java:122)
 at com.ibm.ws.sibx.mediation.flowaction.impl.sca.FlowActionFactoryImpl.complete(FlowActionFactoryImpl.java:706)
 at com.ibm.ws.sibx.mediation.flowaction.impl.sca.FlowActionFactoryImpl.create(FlowActionFactoryImpl.java:393)
 at com.ibm.ws.sibx.scax.mediation.engine.SCACalloutElement.invoke(SCACalloutElement.java:134)
 at com.ibm.ws.sibx.scax.mediation.engine.MediationPrimitive.invokeConnections(MediationPrimitive.java:242)
 at com.ibm.ws.sibx.scax.mediation.engine.Input.invoke(Input.java:125)
 at com.ibm.ws.sibx.scax.mediation.engine.RequestFlow.invokeFlow(RequestFlow.java:123)
 at com.ibm.ws.sibx.scax.mediation.engine.MediationFlow.invokeRequestFlow(MediationFlow.java:112)
 at com.ibm.wsspi.sibx.mediation.flow.ejb.MediationFlowBean.invokeRequestFlow(MediationFlowBean.java:189)
 ... 53 more