Announcement

Collapse
No announcement yet.

Mirth as blank SOAP message Proxy?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mirth as blank SOAP message Proxy?

    We have Client<-->SOAPService -service configuration on Mule and it works Ok.

    Is it possible to make config like this:

    Client<->Mirth<->SOAPService where Mirth only acts as plain proxy, storing incoming soap requests (no transformation, parsing, modifying etc)?

    It seems that SOAP Http headers produce AXIS parse error on Mirth if I put Source type as XML (there is no type "RAW"). On other hand I rip headers off, then Mule SOAP endpoint complaints about missing headers.

  • #2
    Re:Mirth as blank SOAP message Proxy?

    It should be possible, but it doesn't seem like an optimal use for Mirth. A simple HTTP proxy would probably be an easier way to re-route SOAP requests like this.

    Is there some reason (logging maybe?) to stick Mirth in the middle of that SOAP conversation when it doesn't have to do any transformation, queries, or routing?
    Jon Bartels

    Zen is hiring!!!!
    http://consultzen.com/careers/
    Talented healthcare IT professionals wanted. Engineers to sales to management.
    Good benefits, great working environment, genuinely interesting work.

    Comment


    • #3
      Re:Mirth as blank SOAP message Proxy?

      jbartels wrote:
      Is there some reason (logging maybe?) to stick Mirth in the middle of that SOAP conversation when it doesn't have to do any transformation, queries, or routing?
      Yep logging on this case. We are already using Mirth on another MLLP -endpoint and preferably do not want to add yet another program for simple soap-request logging.

      Comment


      • #4
        Re:Mirth as blank SOAP message Proxy?

        pnirvi wrote:
        It seems that SOAP Http headers produce AXIS parse error on Mirth if I put Source type as XML (there is no type "RAW"). On other hand I rip headers off, then Mule SOAP endpoint complaints about missing headers.[/quote]

        AH! Try using an HTTP source and sender. SOAP is XML sent over TCP after all!
        Jon Bartels

        Zen is hiring!!!!
        http://consultzen.com/careers/
        Talented healthcare IT professionals wanted. Engineers to sales to management.
        Good benefits, great working environment, genuinely interesting work.

        Comment


        • #5
          Re:Mirth as blank SOAP message Proxy?

          jbartels wrote:
          pnirvi wrote:
          It seems that SOAP Http headers produce AXIS parse error on Mirth if I put Source type as XML (there is no type "RAW"). On other hand I rip headers off, then Mule SOAP endpoint complaints about missing headers.
          AH! Try using an HTTP source and sender. SOAP is XML sent over TCP after all![/quote]

          Won't help; if "incoming data" is XML, then Mirth tries to do some parsing and produces axis error "content not allowed in prolog" (=http headers mess data up..)

          Comment


          • #6
            I have tried to do the same thing (use HTTP Listener to proxy requests) and get the "content not allowed in prolog" error. Did anybody work this out?

            I'm trying to do something similar to the original poster - take advantage of Mirth's logging and queuing functionality without rewriting my client applications. Is there a better way to approach this task?

            Comment


            • #7
              For the record I did resolve this. Actually this post was very helpful - http://www.mirthcorp.com/community/f...read.php?t=889

              In order to configure Mirth as a general SOAP proxy, I used an 'HTTP Listener'. This leads to the "An invalid or illegal XML character is specified" error (which is probably analogous to the "content not allowed in prolog" error for the TCP Listener) due to the SOAP XML embedded in the content.

              To avoid this error, in the configuration for HTTP Listener, set 'Append Payload Variable' to 'Yes', and set 'Payload URL Encoding:' to 'Encode'.

              This encodes the data so that it may be stored in a variable called 'payload'.

              The next step is to add a Transformer to the HTTP Listener, type = Javascript. Here is the content of the transformer I used:

              var nonencoded = Packages.java.net.URLDecoder.decode(msg['payload']);
              globalMap.put('nonencoded',nonencoded);
              message.transformedData = nonencoded;

              I used a SOAP Sender. Maybe another sender can be used, but I wanted to take advantage of the SOAP Sender's Persistent Queues. After entering my WSDL path and generating the desired method. I configured 'Generate Envelope:' to 'No' and 'SOAP Envelope:' to '${nonencoded}', the value saved in the globalMap in the source transformer step above.

              This proxies any request to the SOAP method specified in the Destination. The HTTP Listener source responds with HTTP 200 OK, but appears to be capable of using another Destination to supply a more advanced response.

              Comment

              Working...
              X