XmlError

Version imprimable

1 pièce(s) jointe(s)

Bonjour à tous,
Je reprends un projet débuté il y a quelques années pour mettre en oeuvre des améliorations. L'application est basée sur l'usage de HttpRio créé dynamiquement (sous Delphi Tokyo/VCL/Windows7).

Dans le code suivant,
fgetAllPhysicalIos et fgetAllPhysicalIosResponse sont déclarés et riServer2 est un serviceWeb crée à partir d'une entité WSDL.
Code:

1 2 3 4 5 6 7 8 9 10 fgetAllPhysicalIos := getAllPhysicalIos.create; try try (riServer2 as ISOAPHeaders).Send(riEnteteId); fgetAllPhysicalIosResponse := riServer2.getAllPhysicalIos (fgetAllPhysicalIos); except on E: EXMLDocError do begin ...
avec
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 getAllPhysicalIos = class(TRemotable) private public constructor Create; override; published end; getAllPhysicalIosResponse = class(TRemotable) private Fdata: MimeData; public constructor Create; override; destructor Destroy; override; published property data: MimeData Index (IS_UNQL) read Fdata write Fdata; end; et MimeData = class(TRemotable) private FcontentType: contentType; FcontentType_Specified: boolean; Fdata: TByteDynArray; procedure SetcontentType(Index: Integer; const AcontentType: contentType); function contentType_Specified(Index: Integer): boolean; published property contentType: contentType Index (IS_ATTR or IS_OPTN) read FcontentType write SetcontentType stored contentType_Specified; property data: TByteDynArray Index (IS_UNQL) read Fdata write Fdata; end;
Au moment de l'appel de getAllPhysicalIos j'ai systématiquement le défaut
EXMLDocError : L'élément "data" ne contient pas un noeud texte unique alors que la réponse (stream) est correct et complète.

et une fuite mémoire liée à la non destruction certains objets (getPhysicalIoResponse et le Mimedata) :
Pièce jointe 476169

Je ne trouve pas de solution gérer le MimeData (probablement la cause du défaut et de la fuite mémoire).
Merci pour votre aide,

20/05/2019, 10h18
ShaiLeTroll

Parfois, le code généré n'est pas parfait niveau libération dans le destructor, je te laisse vérifier si Fdata est bien libéré

Tu ne montres pas le finally associé au try du create, c'est pourtant là que se trouve la solution

Curieusement, fgetAllPhysicalIosResponse semble alloué malgré l'exception, il doit falloir le libérer, probablement directement dans le code généré de getAllPhysicalIos qui en cas d'exception doit libérer son Result et propager tout de même l'exception
Toujours ce problème de code généré qui n'est pas toujours top propre

Pour ton erreur XML, en D7 j'avais bidouillé pour utiliser un WS Biztalk pour envoyer un XML qui ne soit pas géré comme un nœud SOAP
21/05/2019, 21h56
Galet
Merci Shai le Troll.
Tu m'avais déjà aidé à la création de cette appli, pour améliorer le code et j'ai beaucoup progressé mais je dois arriver à passer cette étape pour la nouvelle version.

La libération :
Code:

1 2 3 4 finally fgetAllPhysicalIos.Free; end;
Si j'ajoute un fgetAllPhysicalIosResponse.Free, je génère un défaut d'affichage (??!!) avec la disparition du tButton qui me sert à déclencher, en test, la requète... et le fgetAllPhysicalIosResponse n'est pas libéré.
J'ai aussi tenté de le créer, pour pouvoir le libérer mais, j'ai toujours le même résultat.

Il me semble que c'est ce défaut de noeud qui engendre ces conséquences.

Je n'ai pas trouvé accès à ta bidouille.

Merci pour votre aide,

Citation:

Envoyé par Galet

Si j'ajoute un fgetAllPhysicalIosResponse.Free, je génère un défaut d'affichage (??!!) avec la disparition du tButton qui me sert à déclencher

C'est typique d'une non-initialisation
fgetAllPhysicalIosResponse contient une valeur mémoire au pif, et souvent c'est le Sender, le Button

le code doit être

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
begin
    fgetAllPhysicalIos := getAllPhysicalIos.create;
    try
      try
        (riServer2 as ISOAPHeaders).Send(riEnteteId);
        fgetAllPhysicalIosResponse := riServer2.getAllPhysicalIos (fgetAllPhysicalIos);
        try   
          // utlisation de fgetAllPhysicalIosResponse 
        finally
          fgetAllPhysicalIosResponse.Free();  
        end;
      except
        on E: EXMLDocError do
        begin
          ... 
          raise;
        end;
      end;
    finally
      fgetAllPhysicalIos.Free();
    end;
 
end;

24/05/2019, 13h46
Galet

Merci pour ton éclairage....
Je teste ça dès que possible.
Cordialement
31/05/2019, 17h25
Galet

Bonjour,

Suite à l'essai, toujours les mêmes défauts :
- l'exception est générée à l'appel de : fgetAllPhysicalIosResponse := pRobotTmp.riServer2.getAllPhysicalIos(fgetAllPhysicalIos);
- fgetAllPhysicalIosResponse et mimeData ne sont pas libérés.

Je vais donc essayer de trouver une solution dans le WSDL.

Si vous avez une autre idée, je suis preneur, sinon, je vais reculer (une seconde fois) pour revenir au code précédent (en oubliant les nouvelles fonctionnalités espérées).

1 pièce(s) jointe(s)

Bonjour,
J'ai récupéré du fournisseur du service Web, un exemple de codage en C# :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
        private void m_btnServer2_GetPhysicalIOs_Click(object sender, EventArgs e)
        {
            if (m_sessionId < 0) return;
 
            m_server2ListboxIo.Items.Clear();
            m_physicalLinks = null;
 
            // Retrive Physical links from IO list
            MimeData l_mimeData = m_cs8ServerV2.getAllPhysicalIos(m_sessionId);
            if (l_mimeData != null)
            {
                MemoryStream l_msMime = new MemoryStream(l_mimeData.data);
                StreamReader l_reader = new StreamReader(l_msMime);
                XmlDocument l_xDocument = new XmlDocument();
                l_xDocument.Load(l_msMime);
                XmlNodeList l_nodelist = l_xDocument.GetElementsByTagName("Io");
                m_physicalLinks = new string[l_nodelist.Count];
                for (int l_i = 0; l_i < l_nodelist.Count; ++l_i)
                {
                    XmlNode l_node = l_nodelist[l_i];
                    m_physicalLinks[l_i] = l_node.Attributes["name"].Value;
                    m_server2ListboxIo.Items.Add(string.Format(System.Globalization.CultureInfo.InvariantCulture, "{0} | {1} | {2}", m_physicalLinks[l_i], l_node.Attributes["desc"].Value, l_node.Attributes["type"].Value));
                }
            }
        }

Il semble que les options de l'importateur WSDL ne configurent pas ma procédure getAllPhysicalIOs de la même manière.

J'ai commencé à faire varier les options de l'importateur mas ne trouve pas la bonne configuration.
Voici ma configuration actuelle :
Pièce jointe 479702

Avez-vous une idée ?
Merci par avance,

09/06/2019, 12h10
Galet

Bonjour à tous,
Après avoir tenté une multitude de configurations différentes, je ne trouve pas de solution traduisant la fonction attendue sous la forme
"MimeData l_mimeData = m_cs8ServerV2.getAllPhysicalIos(m_sessionId);" du C#
Je dois louper une étape...
Merci pour vos idées,
11/06/2019, 14h59
ShaiLeTroll

C'est bien le problème du SOAP
Il y a les partisans du Document/Literal et ceux du RPC/Encoded
C'est une plaie de faire en sorte que cela se comprenne
Il faut parfois modifier le WSDL à la main pour l'importer ou alors modifier le code généré tout en laissant des options contradictoires qui combinées génèrent un truc qui fonctionne mais en théorie non supporté par Delphi
C'est uniquement par tâtonnement que tu y arriveras
11/06/2019, 17h32
Galet

Merci ShaiLeTroll, même si je rêvais d'une réponse du style "Regarde bien, il suffit de..."
Je vais suivre tes conseils...et tâtonner.
12/06/2019, 22h06
Galet

1 pièce(s) jointe(s)

Après de nombreux tests, j'ai enfin trouvé une configuration qui règle une bonne partie des défauts :
- Procédures assez similaires à celles de C#
- Fuite mémoire presque nulle et surtout indépendante du nombre de requêtes Soap

J'ai toujours le défaut de Nœud unique soap à la réponse mais arrive à analyser le fichier.

Au cas où, voici la configuration pour interpréter le fichier WSDL :
Pièce jointe 482982

Merci à ShaiLeTroll pour tes conseils...