I’ve created a custom soap processor to provide routing support (act as reverse proxy) and it works great with the exception of the SOAPAction. Our services require the Http SOAPAction header to be set, but I cannot figure out a way to get the SOAPAction header value from the originating request sent to the processor. The only inputs currently to the soap processor are soapRequestData and soapResponseData as mentioned in the documentation.
Is there a way to get this http header within the soap processor?
You can obtain the SOAPAction HTTP header using the pub.flow:getTransfportInfo built-in service. The content of the header will be in the “transport/http/requestHdrs/SOAPAction” field. This would work for both RPC/Encoded and Document/Literal style services.
Mark
Awesome - thanks Mark. I’m not a full time wM guy and this document seems to be a list or array. How do I access that record and map it to another string variable? All of the wmSamples seem to show structured documents.
The document is, well, a document. It will have a field named “SOAPAction” as a child of the requestHdrs document. One approach is to add a map step below the pub.flow:getTransportInfo invoke, create a new string field called SOAPAction and use the “Set Value” (blue arrow) to set its value to %transport/http/requestHdrs/SOAPAction%.
-M
Mark,
Thanks a ton. It’s working great. What I’ve created is a route processor that will act like a reverse proxy. I realize it’s not the purpose of webMethods to do this and products like ServiceNet exist specifically for this, but it’s the best option at this point. (All hail Sarbanes-Oxley).
Would you have any suggestions on what road I should go down in providing authorization to the processor? Previously, we had created specificy SOAP-RPC versions of our web services and created a Web Service Connector to allow something like a reverse proxy. This didn’t always work due to things like Custom Soap headers not being supported, some types caused problems, etc. That option did, though, provide us the ability to set the Execute permissions for each operation. We will most likely be required to do the same thing in this case. Any suggestions?
Not quite sure I understand your question. Do you mean how would you go about processing message-level WS-Security tokens to authenticate or authorize the end user represented by the SOAP request or something else?
The soap processor you created to grab the SOAPAction can also access any custom or WS-Security elements in the SOAP header and process them before invoking the pub.soap.processor:processRPCMessage built-in service. Of course, if the message fails your custom authN or authZ, you would just return a SOAP fault either by thowing an exception from your processor or by buiding a soap fault soapResponse to be returned.
HTH,
Mark