Oracle BTM 6.5 and Before: Working with HTTP Return Codes
Last updated on AUGUST 03, 2016
Applies to:APM - Application Performance Management - Version 6.5.5 to 6.5.5 [Release 6.5]
Information in this document applies to any platform.
Checked for relevance on 09-JAN-2012. This note is only relevant for release 6.5 and *before* of BTM.
Checked for relevance on 17-Jul-2013
Checked for relevance on 02-Aug-2016
The SOAP specification states that all successful responses must use HTTP return code 200 in their HTTP headers. By contrast, responses that contain SOAP faults must use HTTP return code 500.
Whereas Oracle BTM's embedded components (e.g., the plug-in agent) have always complied with the specification, early versions of the proxy agent did not and often returned a code of 200 even when the target endpoint returned a SOAP fault. Since Release 4.2.29, the proxy agent has been in compliance with the specification.
However, because different organizations use HTTP codes in different ways, Oracle has added some custom features to its HTTP return code implementation. For example, through a custom command-line switch, you can enable the old, non-compliant behavior to allow the proxy agent to interoperate with clients that require a return code of 200 for all messages. In addition, BTM provides two custom XPath functions to allow you to query the current HTTP return code or to set it to a new value during runtime.
This technote covers the following topics:
- the custom XPath expressions to query and change the current return code.
- the command-line switch to force a proxy agent to always return HTTP code 200.
- some trace flags to help troubleshoot requests, responses, and their HTTP headers.
- a release history of the agent's HTTP-return-code behavior.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms