According to the SOAP Developers guide, in order to set up a ‘Challenge/Response’ interaction (ie HTTP 401) with a calling client, webMethods requires an Access Controlled SOAP processor to be implemented with an appropriate ACL rule. Such a beastie should have 1 and only 1 line of code in it (otherwise the known world will explode by the sound of it). This line of code calls either the default doc lit SOAP processor or the rpc SOAP processor.
This is all very fine and we have managed to get this working for both doc literal and rpc encoded services … except when it comes to handling soap faults.
Here is what we are trying to do:
If a low level flow service has an error we want to throw an exception (eg via the Exit $flow signal Failure call with an appropriate Error Message set). This exception is passed back up the calling hierarchy till eventually it hits the SOAP processors. We do see a soap fault comming back, but the only thing we see is a ‘Cannot process soap body’ type soap fault with nothing meaningful (eg the error message set by the original service that threw the exception is nowhere to be seen. If we take out the access controlled SOAP processor and only use the default/rpc processor then we do get a meaningful SOAP fault. Therefore something is happening between the default/rpc SOAP processor and the Access Controlled SOAP processor.
Question 1: how can we create meaningful soap faults using an access controlled soap processor?
Question 2: why is an access controlled custom soap processor only allowed 1 line of code in it, ie to call either the default or rpc processors. Has anyone dared write any extra code in this type of processor (eg acting like any other custom soap processor and bypassing the default/rpc processors).
My soap box whine:
The way that webMethods handles soap/web service calls sucks majorly. It is really, really counter-intuitive and downright bodgy especially when it comes to access controlled soap processors. When are they going to fix this mess!