Was this helpful?


Refining message capture using filters

To enable root-case analysis, filters enable you to target specific calls that may be causing problems. For example, you may need to zero in on requests that have specific content or requests coming from specific partners or apps.

  • HTTP headers - limits the trace to only calls that contain a specific header. This is a good way of helping you troubleshoot issues. You can send a header to your app developer and ask them to include it in the call that is causing issues. Then Apigee Edge will only record calls with that specific header so you can examine the results.  
  • Query parameters - only calls with a  specific value of a parameter will be recorded.

To add a filter:

  1. Open the Filter section of the Trace page.

  2. Enter a name and value into either the Header or Query fields. Blank fields are not evaluated.

    You can add more filters by clicking the Add Filter button. You can delete filters by clicking the (X) button next to the filter. 

HTTP response codes

Because the management API is RESTful, response messages can be interpreted as a combination of an HTTP response code and an  Edge-specific error message.

For example, if you try to create a company entity with the same name as an existing company, the response is:

404
{
  "code": "messaging.config.beans.ApplicationDoesNotExist",
  "message": "APIProxy named WeatherApi does not exist in organization mycompany",
  "contexts": []
}

Example error codes are provided in the API Reference, see API reference getting started.

An explanation of important HTTP response codes follows:

HTTP 2xx: Any response code in the 200 range means 'success'. In some cases only a 204 HTTP response code is issued when an operation succeeds. 204 means that the response is submitted with no content, usually because a DELETE operation succeeded.

HTTP 401: This an authorization failure. It means that the credentials that you used to make a request map to a user who lacks permission to perform the operation. Verify the roles for the account you are using.

HTTP 403: This an authorization failure. It means that the username and password combination you are using is not valid for the organization you specified. To test your credentials, login to enterprise.apigee.com/login. Once logged in check your account settings to see the organization name. In some situations, you may belong to multiple organizations. Make sure that you are using the correct credentials for you organization. Check your spelling.  If you need an account, sign up.

HTTP 404: The object wasn't found. This is usually happens because of misspelling in your request URL, but it may also happen if you try to update an object that doesn't exist (for example, the wrong revision of an API).

HTTP 405: This means 'Method not allowed'. This response code simply means that you, for example, used the GET verb for an API call that requires the POST verb.

HTTP 415: Unsupported media type. This error usually occurs on POST or PUT requests when the Content-type HTTP header is set to the wrong value. For example, imagine that you POST the following to an API that only supports JSON:

$ curl -X POST -H "Content-type:text/xml" -d '<SomeXML>' https://api.company.com/v1/json_service

The result would be an HTTP 415 error.

For GET requests,remember to use the Accept header instead of the Content-type header

.

HTTP 500: This is an internal server error. It means that you should contact Apigee Support to resolve the issue.

Common client issues

Using cURL on Windows

All of the example commands use Linux/Unix command line syntax for quoting arguments. A single quote can be used as a wrapper for double-quote characters inside a pair of single quotes.

If you are using cURL from a Windows command prompt, Windows does not provide such multi-layered quoting. Under Windows, the outermost quotes must be the double-quote character and quotes within that string must doubled, two double-quote characters, where the following examples have one.

curl and HTTPS

The management API requires SSL (HTTPS). If you encounter SSL Certificate problems in response to your cURL commands, you can:

  • Update your certs file.
  • Use a command line option to specify an alternate certs file.
  • Manually decide that you can trust the api.enterprise.apigee.com site and use either the -k or --insecure options in the curl command to override the SSL certificate requirement.

Protocol https not supported or disabled in libcurl

Usually seen on machines running Windows. This means that you downloaded and installed a version of curl that did not include the libcurl package. Download a different package from http://curl.haxx.se/download.html, and make sure it includes libcurl for SSL.

CLASSIFICATION_FAILURE

You may see this error when you submit a request to your API proxy after you deploy it to API Services. This error means that API Services, while attempting to route the request to the appropriate API proxy, cannot find an API proxy that matches the request URI path. This usually happens because your request URL does not match the base path for any API proxies currently deployed in the environment. (Note that API Services validates that all base paths are unique when a new API proxy is imported or generated.)

  • Verify the URI for your API by logging in to the management UI at enterprise.apigee.com. Select the link to your API. At the top of the page, the URI for you API including the base path, displays at the top of the page.
  • Make sure your API proxy is deployed. Your API proxy may be imported to Apigee Edge, but may not be deployed to an environment. API proxies can only be invoked after they have been successfully deployed to an environment. (Note that the deploy tool used in the quick start both imports and deploys your API proxy to the environment you specify.)
  • Make sure your request is being sent to the correct environment: http://{myorg}-test.apigee.net/weather versus http://{myorg}-prod.apigee.net/weather, for example. 

Deploy tool errors

python: can't open file 'tools/deploy.py': [Errno 2] No such file or directory
The path you have provided to deploy.py is incorrect. 

If you see the following result on import, it indicates that you are running the deploy tool from the wrong directory. 

Import failed to /v1/organizations/myorg/apis?action=import&name=weatherapi with status 500:
{
  "code" : "messaging.config.beans.ImportFailed",
  "message" : "Failed to import the bundle : java.util.zip.ZipException: ZIP file must have at least one entry",
  "contexts" : [ ]
}
To fix this issue, run deploy.py from the base directory of the API Services samples distribution. In the deploy tool command, specify the directory that contains the ./apiproxy directory-- in this package that value is simpleProxy.

Get help

If you have other issues, see Apigee Customer Support.

Help or comments?

  • Something's not working: See Apigee Support
  • Something's wrong with the docs: Click Send Feedback in the lower right.
    (Incorrect? Unclear? Broken link? Typo?)