in reply to Preserve the sequence of xml elements in the generated SOAP Envelope

How are you generating the messages? Please show some code.

As far as I can see the order of those elements should be irrelevant, so I'm not even sure why you would want a specific order.

  • Comment on Re: Preserve the sequence of xml elements in the generated SOAP Envelope

Replies are listed 'Best First'.
Re^2: Preserve the sequence of xml elements in the generated SOAP Envelope
by chanakya (Friar) on Apr 13, 2005 at 13:18 UTC
    Joost,
    Here's the client code, where the messages are generated.
    #!/usr/local/bin/perl #CLIENT use strict; use warnings; use SOAP::Lite +trace => qw(debug); use MIME::Base64; my $HOST = "http://localhost/perl/soap-dbi.pl"; my $NS = "urn:Delivery"; my $MsgHdr = "urn:MsgHeader"; #Data to be added to the request my (@data) = ( #Common MessageHeader SOAP::Data->name(MessageHeader => { ( AgreementId => "urn +:xxx-xxx:::" ), ( ConversationId => " +20050904-13:30:03.469-857" ), ( Sequence => { Id => +"What id is this", Number + => "123", Total +=> "6" } ), ( Service => { type => + "service.type. What servicetype is this?" } ), ( Action => "Problem +Submit" ), ( MessageData => { Mes +sageId => "20050904-13:30:03.469-8572\@xxx.xxx.xxx", Tim +estamp => SOAP::Utils::format_datetime(localtime), Ref +ToMessageId => "Which reference is this", Tim +eToLive => SOAP::Utils::format_datetime(localtime) } ), ( Description => "Thi +s is the message header" ), ( ErrorList => { Error => { + Description => "Error Description", + codeContent => "code + content", + errorCode => "Error Code", + severity => "seve +rity.type", + location => "error location" + } } ), ( highestSeverity => +"severity.type" ), ( id => "Which id is +this" ) } )->uri($MsgHdr)->prefix(''), ); #Enable fault management globally use SOAP::Lite on_fault => sub { my($soap, $res) = @_; eval { die ref $res ? $res->faultstring : $soap->transport->stat +us }; return ref $res ? $res : new SOAP::SOM; }; #print $soap->fault ? $soap->faultstring. "\n" : $soap->result; my $soap = SOAP::Lite -> proxy($HOST) -> uri($NS); #my $res = $soap->byName(@headers,@data); my $res = $soap->GetbyName(@data); #print $soap->retrieveDocument->result; print $res->fault ? $res->faultstring. "\n" : $res->result;
    Many thanks

      The reason that the elements are not coming out in the order that you think you put them it, is that you are passing a hash reference as the second argument to SOAP::Data->name(), the elements in a hash are effectively in a random order which you cannot control. If you want more control over the structure of the generated XML you will need to explicitly create every element with SOAP::Data - you can find an example in Re: SOAP Beginner ... I hate to impose.

      As to the question of why the elements need to be in a particular order, in general with XML this shouldn't matter but I have seen some XML parsers get upset about this when validating against a DTD, but you generally aren't doing this in a Web Service. If you (or the owner of the web service) care at all about interoperability, you will fix the server so that it behaves in an interoperable manner rather than hacking the client to work around it's quirks.

      /J\

        The question why I want the elements in a particular order is because the SOAP packet generated by the client is pretty complex. What I've given in the example in my earlier post is just a part of that.

        If the elements come in order, it makes life easy for debugging the required elements. Otherwise its going to be pretty tough hunting for checking a given element within the envelope.

        The suggestion to explicity create element with SOAP::Data holds promise. The link given will definetely help me in ordering the elements as needed.

        Many thanks

        Actually, most web services are described with WSDL these days, which for the most part used XML Schema (XSD). If a complex-type is defined as being a sequence, and not all, then they are required to be in that order. All has the limitation that each element may appear at most one time, which means that you have to use a bunch of other elements that act as arrays, and makes the XSD much more complex.

        More and more clients are being written by people who have no control over the server, and so, suggesting that the server be re-written is not practical. It may only have a published API that the programmer is trying to comply with, and they have no idea how it is actually implemented.