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

[Patrick Powell]

On 01/27/12 07:09, Patrick Powell wrote:
> 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
>
>
Also, see XML::Compile::Transport,   the 'transport_hook' documentation.


Handlers

$obj->compileClient(OPTIONS)

     Compile a client handler. Returned is a subroutine which is called 
with a text represenation of the XML request, or an XML::LibXML tree. In 
SCALAR context, an XML::LibXML parsed tree of the answer message is 
returned. In LIST context, that answer is followed by a HASH which 
contains trace information.

      -Option--Default
       hook <undef>
       kind    'request-response'

     hook => CODE

         See section "Use of the transport hook" in DETAILS. When 
defined, the hook will be called, in stead of transmitting the message. 
The hook will get a two parameters passed in: the textual representation 
of the XML message to be transmitted, and the trace HASH with all values 
collected so far. The trace HASH will have a massive amount of 
additional information added as well.

         You may add information to the trace. You have to return a 
textual representation of the XML answer, or undef to indicate that the 
message was totally unacceptable.
     kind => STRING

         Kind of communication, as defined by WSDL.

DETAILS ^
Use of the transport hook
XML and Header Modifications

Some servers require special extensions, which do not follow any 
standard (or logic). But even those features can be tricked, although it 
requires quite some programming skills.

The transfer_hook routine is called with a $trace hash, one of whose 
entries is the UserAgent which was set up for the data transfer. You can 
modify the outgoing message XML body and headers, carry out the data 
exchange using the UserAgent, and then examine the returned Reponse for 
content and headers using methods similar to the following:

  sub transport_hook($$)
  {   my ($request, $trace) = @_;
      my $content = $request->content;

      # ... modify content if you need
      my $new_content = encode "utf-8", $anything;
      $request->content($new_content);
      $request->header(Content_Length => length $new_content);
      $request->header(Content_Type => 'text/plain; charset="utf-8");

      # ... update the headers
      $request->header(Name => "value");

      # sent the request myself
      my $ua = $trace->{user_agent};
      my $response = $ua->request($request);

      # ... check the response headers
      $response->header('Name');

      # ... use the response content
      my $received = $response->decoded_content || $response->content;

      $response;
  }

You should be aware that if you change the size or length of the content 
you MUST update the Content-Length header value, as demonstrated above.



-- 
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