Question

J'ai quelques autres questions ici concernant ce domaine, mais elles sont un peu redondantes maintenant.Toute réponse à ces questions serait également appréciée, mais cette question est ma principale préoccupation en ce moment.

J'ai suivi de nombreux exemples de fonctionnement de MTOM/XOP dans WSE 3.0 et j'ai configuré mon projet exactement comme il semble nécessaire.J'ai un champ de tableau d'octets désigné comme DataType:-base64Binary.En cela, je mets le tableau d'octets de la pièce jointe que je souhaite ajouter.Lorsque j'exécute l'application et vérifie la demande, les données sont codées en ligne en base64, c'est-à-diresans l'élément XOP Include et la partie MIME associée.

Ma compréhension de MTOM dans WSE 3.0 était que, lors de l'encodage, il prendrait n'importe quel champ désigné comme base64Binary, l'encoderait en binaire et le déplacerait vers une partie MIME, en le remplaçant par un élément XOP Include.C’est-à-dire que cela a fonctionné.Mais j'ai défini le service, dans le fichier de référence, pour qu'il hérite Microsoft.Web.Services3.WebServicesClientProtocol et j'ai fixé le RequireMtom flag sur true, et il n'est toujours pas codé correctement.

Ai-je raté quelque chose ici ?Y a-t-il d'autres étapes à mettre en œuvre pour que cela fonctionne ?

MODIFIER:Après avoir parcouru mon code pour la 100ème fois, je me demande si cela pourrait être dû au fait que je dois sérialiser la charge utile avant d'exécuter la méthode ProcessMessage.Est-ce que cela semble être un problème ?La raison pour laquelle nous avons sérialisé est que la méthode que nous devons utiliser accepte un paramètre "Payload" qui a une propriété de contenu, cette propriété de contenu est une propriété XMLElement et la seule façon d'obtenir cela est de sérialiser la classe requise.Mais cela empêche-t-il le MTOM de reconnaître le type de données du champ base64 et donc de ne pas le convertir en binaire avec les parties MIME et XOP ?Je m'accroche vraiment à des pailles maintenant.

MODIFIER 2 :Bien que j'aie une solution ci-dessous, la société tierce dit maintenant que nos préfixes d'espace de noms sont faux !Nous avons quelque chose comme <q1:Attachment xmlns:q1="http://whatever" /> et ils exigent que ce soit <s:Attachment xmlns:s="http://whatever" />.Est-ce que je deviens fou ou ça n'a pas d'importance ?Existe-t-il un moyen de lui dire comment attribuer les préfixes d'espace de noms ?

Était-ce utile?

La solution

Ok, j'ai finalement compris et c'était lié à la sérialisation avant d'invoquer la méthode.J'ai réécrit la classe qui a été transmise à la méthode afin qu'elle ne nécessite pas de XMLElement comme propriété, et donc une classe pré-sérialisée, et je l'ai transmise.Cela fonctionne correctement, après seulement 3 ou 4 semaines de travail... Si quelqu'un veut plus de précisions, je peux essayer de les mettre ici.

MODIFIER:En réponse au commentaire de John Saunders.Quand je dis pré-sérialisé, je veux dire que la classe, contenant le tableau d'octets, a été sérialisée en XML avant d'être envoyée dans la méthode Web.Cela était dû au fait que la classe envoyée dans la méthode Web acceptait uniquement un XMLElement.J'ai retravaillé la classe, qui était le paramètre de la méthode web, pour accepter l'autre classe sans être sérialisée en XML au préalable.

C'est à dire.Voilà à quoi ressemble la classe maintenant.Le processRepairOrder champ et PRO() propriétés ont été ajoutées et utilisées à la place des anyField

Partial Public Class Content

    Private anyField As System.Xml.XmlElement

    Private idField As String

    Private anyAttrField() As System.Xml.XmlAttribute

    'This was added
    Private processRepairOrder As ProcessRepairOrder

    'This was added
    '''<remarks/>
    <System.Xml.Serialization.XmlElementAttribute([ElementName]:="ProcessRepairOrder", [Namespace]:="http://www.starstandards.org/STAR")> _
    Public Property PRO() As ProcessRepairOrder
        Get
            Return Me.processRepairOrder
        End Get
        Set(ByVal value As ProcessRepairOrder)
            Me.processRepairOrder = value
        End Set
    End Property


    '''<remarks/>
    <System.Xml.Serialization.XmlAnyElementAttribute()> _
    Public Property Any() As System.Xml.XmlElement
        Get
            Return Me.anyField
        End Get
        Set(ByVal value As System.Xml.XmlElement)
            Me.anyField = value
        End Set
    End Property

    '''<remarks/>
    <System.Xml.Serialization.XmlAttributeAttribute(DataType:="token")> _
    Public Property id() As String
        Get
            Return Me.idField
        End Get
        Set(ByVal value As String)
            Me.idField = value
        End Set
    End Property

    '''<remarks/>
    <System.Xml.Serialization.XmlAnyAttributeAttribute()> _
    Public Property AnyAttr() As System.Xml.XmlAttribute()
        Get
            Return Me.anyAttrField
        End Get
        Set(ByVal value As System.Xml.XmlAttribute())
            Me.anyAttrField = value
        End Set
    End Property
End Class

En ce qui concerne les espaces de noms spécifiques, nous avons ajouté un autre champ aux classes requises :

<System.Xml.Serialization.XmlNamespaceDeclarations()> _
Public xmlns As XmlSerializerNamespaces

Ensuite, nous avons pu ajouter l'espace de noms en utilisant :

Dim ns As New Serialization.XmlSerializerNamespaces
ns.Add("s", "http://whatever")

class.xmlns = ns 

Autres conseils

Je sais que ça fait longtemps mais...

J'ai la même chose et il s'avère que mon byte Le tableau est informé lorsque ses 767 octets ou moins :) et il est déplacé pour séparer la pièce lorsque ses 768 (12 * 8 * 8) octets ou plus.

Cela varie donc simplement en fonction de la taille du contenu.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top