[Xml-compile] error: element `SLAObject' not processed at {http://brixworks02.example.com:8080/API/SOAP/Utils/}getSLASResponse/sla_list

[Patrick Powell]

On 01/26/12 22:07, Joshua Keroes wrote:
> Thank you for the educated review - I'll pass your statements back to 
> EXFO ASAP.
>
> I am, in fact, using XML::Compile - and it's working - but I'm doing 
> horrible things to make that succeed. We had a lot of money on the 
> line, dozens of eyeballs, and needed to make things work with three 
> whole days. XML::Compile (and Dancer and Moose) made that possible. 
> Today, I was able to get a fully functioning WSDL-REST middleware online.
>
> Working around the broken XML required pulling it from the 
> XML::Compile::SOAP::Trace object (so glad that was made available), 
> fixing it, manually handling the errors, then serializing it with 
> Dancer::Plugin::REST, and sending it along.

>
> As long as I've already bought my handbasket and punched my ticket, 
> I'm wondering is there's a place to insert an XSLT in XML::Compile's 
> processing chain? If I could get my hands on the XML response fresh 
> from the SOAP server, correct it, then XML::Compile would be able to 
> proceed correctly. On the scale of evil, that seems more like level 
> three of Hell than level seven.
Ahhh!  Another poor sod who has to deal with broken apps sending and/or 
receiving  mangled XML.

Hats off to Marko who put in hooks in the Server and Client code so you 
can do mods to the XML.
For the server,  there is a way to intercept the reply message just 
before it
gets sent.  You get a reference to the XML string and can then bend, 
folk, hack and
whack the XML until it meets your needs.   You can even reorder some of 
the elements
so that they are in the order some legacy apps want, even though the 
Schema indicates
that this is a list of unions and there is no required ordering. (I 
could be wrong on this,  but the
client code rejects the XML unless they are in a particular order...)

See XML::Compile::SOAP::Daemon::NetServer  (version 3.01).  I have added 
a bit
of detail here for interested users:

Look for the 'Running the Server':
    Running the server
        $obj->process(CLIENT, XMLIN, REQUEST, ACTION)
            See "Running the server" in XML::Compile::SOAP::Daemon

        $obj->run(OPTIONS)
            See Net::Server subroutine run, but the OPTIONS are passed 
as list,
            not as HASH.

             -Option     --Default
              postprocess  undef

            postprocess => CODE
              When defined, the CODE is called when the response message is
              ready to be returned.

              It is called with:
&(CODE)($request, $response, $status, \$xml_out )
                    CODE is the postprocess routine
                    $request is the object that is also passed to the
                      handler for this request
                    $response is the HTTP::Response object generated from
                      the information returned by the handler for this
                      request.  This can be used to set or modify the
                      HTTP reponse headers.
                    $status is the HTTP return code
                    $xml_out is a reference to the xml response
>
> What do you think?
>
> All apologies to Dante,
> Joshua


-- 
Patrick Powell                 Astart Technologies
papowell at astart.com            1530 Jamacha Road, Suite X,
Network and System             San Diego, CA 92019
   Consulting                   858-874-6543
Web Site: www.astart.com