One request to apigee calling one target endpoint twice with two separate soap message one after the other

Not applicable

I have one JSON request which i need to modify and convert it to soap msg and send(POST) it to target server. after I receive ok response from target server again i need to modify the soap msg and send it back to target server.

Can you help how to go with the flow.. I have tried hitting the target with first soap msg.. and it worked fine. Then i added service callout in response flow of proxy endpoint and i am stuck.. getting 500 error

{ "Envelope": { "encodingStyle": "http://schemas.xmlsoap.org/soap/encoding/", "Body": { "Fault": { "faultcode": "soap:Server", "faultstring": "Execution of ServiceCallout Call-Update failed. Reason: ResponseCode 500 is treated as error", "faultactor": {}, "detail": { "source": { "errorcode": "steps.servicecallout.ExecutionFailed" } } } } } }

Please help..

Solved Solved
0 3 802
1 ACCEPTED SOLUTION

Sorry about the delay in responding. Your flow is not an unusual one. What you describe should work just fine.

It may be a little tricky in getting the right message formats to each message.

What I see in that response is:

Execution of ServiceCallout Call-Update failed. Reason: ResponseCode 500 is treated as error

That tells me the ServiceCallout policy is being invoked, and is receiving a 500 status code in response. Your backend server is replying with a 500. This normally indicates a "Server Error" - in other words the server is broken.

However, in some soap-based systems, I have seen servers respond with 500 when the client sends a misformatted message. Bad XML, or wrong schema, or etc. In these cases, the server responds with "500 Server Error" even though the appropriate response for a mis-formatted message ought to be "400 Bad Request" or something in the 4xx range.

My suggestion is to check that the message being send by your Call-Update policy is exactly what is required by the backend system .

If that looks ok, then check the logs of your backend system - there may actually be an error on the server side.

good luck!

View solution in original post

3 REPLIES 3

Not applicable

@anilsagar

Sorry about the delay in responding. Your flow is not an unusual one. What you describe should work just fine.

It may be a little tricky in getting the right message formats to each message.

What I see in that response is:

Execution of ServiceCallout Call-Update failed. Reason: ResponseCode 500 is treated as error

That tells me the ServiceCallout policy is being invoked, and is receiving a 500 status code in response. Your backend server is replying with a 500. This normally indicates a "Server Error" - in other words the server is broken.

However, in some soap-based systems, I have seen servers respond with 500 when the client sends a misformatted message. Bad XML, or wrong schema, or etc. In these cases, the server responds with "500 Server Error" even though the appropriate response for a mis-formatted message ought to be "400 Bad Request" or something in the 4xx range.

My suggestion is to check that the message being send by your Call-Update policy is exactly what is required by the backend system .

If that looks ok, then check the logs of your backend system - there may actually be an error on the server side.

good luck!

This issue is resolved now. The request sent to URL in service callout was not proper. So i use assigned msg policy before service callout to set the request correctly and assigned it to one variable using <AssignTo>

<AssignTo createNew="true" transport="http" type="request">updateRequest</AssignTo>

and then used this variable in service callout as

Request clearPayload="true" variable="updateRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request>

Thanks for your response @Dino