Hi folk, 

I am new at Api Connect V5,

I am trying to invoke a SOAP service in API Connect(v5) . its working fine with happy flow. but, it is failing in some cases with "soap:Fault"  so how  can I target that soap fault code and tranform it into  json?

my scanerio is I have json request packet then Mapping not to map json to soap request and then Mapping that SOAP response into JSON for out Json Response.

Hi Abdul,
Api Connect V5 has been out of service for over two years now, so hopefully your organization is looking to migrate to v10 as you'll get no official v5 support.  On v10, there is a v5 compatible gateway which behaves as v5 did.  It provides a fully compatible migration path although we are not investing in any functionality there and I would recommend moving to the v10 API Gateway.  There is the API Connect Migration Utility (AMU) that is documented to assist you in migration to either gateway.

Having said that, the strategy to handle soap faults is the same, although v5(c) does have some quirks that are different from the v10 API Gateway.  v5(c) has an invoke and a proxy policy to communicate with your backend web service.  I would suggest that you use the invoke policy to communicate with this backend.  Do NOT specify a stop-on-error property for the invoke.  This will allow the assembly to continue regardless of the success or failure of your invoke call.  Following the invoke policy, assuming the output property of the invoke is message, then message.body should have your payload, message.headers should have your response headers, and message.status should have your status code (200, 500, etc).  You should have a switch policy that tests the value of message.status.code.  If 200, then continue with whatever assembly you would have following the invoke, but otherwise, since your backend is a web service you should have the SOAP Fault in message.body.  The easiest way to do this transformation in this case would be a map policy that would map from the soap fault (from message.body) to whatever JSON schema you wish to create, with the output updating message.body which would be returned to the client.

Best Regards,
Steve Linn 

Hi Abdul, 
message.body will be the result of your invoke policy assuming you did not configure an output property sending the response to another context message.  The message.status will be readily available to you.  In v5(c) the switch conditions are GatewayScripts which will evaluate to true or false, so for one switch condition you could have either:

message.status.code === 200

or 

apim:getvariable('message.status.code') === 200

Both will work, but since the message object is available to the switch policy I'd use the first option.  So if you had a good status code, I don't know what else you want to do.  If there is more work todo, then the rule for that condition would be whatever else you need to do.  For example, since you want to convert a soap fault XML to a JSON object, I'd assume you might also want to convert a SOAP response to some JSON object too???

You'd also have a switch otherwise condition that would handle the non 200 cases which should have a soap fault in message.body

In both cases (200 or non-200), I'd use the map policy.  The map policy is schema based, so you should have a definition as input on both your successful response schema and your soap fault schema, assuming you created the API where you provided your policy the web service wsdl.  Again, since you're wanting to return JSON, that would imply to me that your input is JSON which you would first need to convert to a SOAP XML request so I'd assume something like the following would be needed:

Policy 1: Map Policy - takes request.body and maps to message.body.  You would need a schema defining your input JSON and you should have a definition defining your SOAP request where you would specify both input and output schemas and wire your input properties to your output properties.

Policy 2: Invoke policy to your web service.  message.body should now have your soap request, output undefined is the same as output = message.

Policy 3: Switch Policy
Policy 3a: condition message.status.code === 200
Policy 3a-1: Map policy, input message.body, uses good soap response schema, output also message.body, uses a JSON response schema to return JSON to the client.
Policy 3b: otherwise (ie condition is simply a "true")
Policy 3b-1: Map policy, input message.body, uses fault soap response schema, output also message.body, uses a JSON error response schema to return JSON to the client.

Best Regards,

Steve Linn