SOAPUI error after uploading SOAP proxy bundle

pxzxz1
Participant IV

Hello Apigeeks

Error returned when I run on SOAPUI.

The content you are trying to view cannot be viewed as XML

I notice that the response Content-Type is application/json instead of text/xml; charset=utf-8.

  1. Am I missing any information when I upload the bundle.
  2. Do I need to change the default Content-Type setting.
0 5 1,441
5 REPLIES 5

Where do you get the message "The content you are trying to view cannot be viewed as XML" ?

SOAPUI displays that message?

Have you examined the output? You want to make sure that the response payload that your API proxy generates, is self-consistent, in that

  • if the API Proxy is sending json (curly braces and so on), then the content-type header in the response is application/json
  • if the API Proxy is sending XML (angle brackets and so on), then the content-type header in the response is application/xml

Hello @dino-at-google

Let me rephrase. The bundle is a SOAP proxy that was exported.

Just for your information, I did not change anything yet after uploading the bundle, hence it should not occur any errors.

when I exported it and upload as bundle,

You imported an existing API Proxy into a new org + environment, is that right?

Check that the proxy is successfully deployed. Apigee by default will return a JSON error message if there is no proxy listening at the specified path + vhost. The failed message looks like this:

$ curl -i https://$ORG-$ENV.apigee.net/this_basepath_is_not_in_use
HTTP/1.1 404 Not Found
Date: Wed, 24 Jun 2020 21:36:15 GMT
Content-Type: application/json
Content-Length: 182
Connection: keep-alive
X-Frame-Options: DENY
Strict-Transport-Security: max-age=86400
X-Content-Type-Options: nosniff
Content-Security-Policy: frame-ancestors 'none'
X-XSS-Protection: 1

{"fault":{"faultstring":"Unable to identify proxy for host: secure and url: \/this_basepath_is_not_in_use","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

With this message, Apigee is saying "I've received your request, but I have no proxy to which to route this inbound request." And that error is in JSON. This means It's possible SOAPUI is looking at the content and saying "Hey, that's JSON, I can't display that as XML." And so the combination of a failed deployment plus SOAP UI's insistence on displaying XML, could lead to the "content you are trying to view cannot view viewed as XML" message that you observed.

But let's not assume. Examine the response content in plain text. I don't know the specific way to do that in SOAPUI but I'm pretty sure you should be able to do it.

The message you see, "the content you are trying to view cannot view viewed as XML", is telling you something, but not much. I suspect that if you actually viewed the content that cannot be viewed as XML, you might be able to learn something, get a better hint about the root problem. In other words "the content you are trying to view cannot view viewed as XML" is a message about a secondary problem. The primary problem is probably something else. Possibly a failed deployment of an API Proxy.

Why would deployment of an API Proxy fail?

Even if an API Proxy is working perfectly in one environment, it may not work perfectly in another. There are numerous environment-specific things that a proxy might depend on.

  • vhosts
  • truststores + keystores
  • KeyValueMaps
  • caches
  • sharedflows
  • target servers
  • resource files

All of those things are defined independently of the API Proxy, but could be referenced from within the API Proxy, or the policies it uses. If Apigee cannot resolve the reference, either the deployment will fail, or the API request will fail at runtime. And the default error format is JSON.

So anyway, examine the actual error message and act on THAT.

Hello @dino-at-google

Beside proxy, I also uploaded shared flow, set up environment for target server. I also checked kvm and caches that it's empty. If I uploaded the bundles, how would the resource files be different?

If I uploaded the bundles, how would the resource files be different?

Resource files can be org or env scoped.

I am not suggesting that you have a problem with resource files specifically. My point was that a valid bundle is not guaranteed to successfully deploy. A better thing to check is Did the deployment succeed? Are you certain that it has been successfully deployed? Please check and confirm. Are you certain the dependent sharedflow has been deployed in the environment? Please check and confirm.

BTW. You said you "uploaded" the sharedflow. There are two things you must do with either a proxy bundle or sharedflow bundle. Import, and deploy. Verify that you have done both with the proxy and any sharedflows it uses.

Another check, perhaps more important, is What is the exact error message returned by the proxy? As I wrote above, the message that SOAPUI gives you that states "this content cannot be viewed as XML" is not helpful in diagnosing anything. It basically tells us that SOAPUI received something that is not XML, but it does not tell us what SOAPUI received. Therefore we are in the dark.

If you cannot persuade SOAPUI to show you the actual message, then invoke the proxy from outside of SOAPUI from curl or some other command-line tool.

You need to do deeper diagnostic efforts. More information is necessary to diagnose the problem.