[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-26。"],[[["\u003cp\u003eThis content is applicable to both Apigee and Apigee hybrid platforms, detailing the use of flow variables within API Proxy Flows.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003emessage\u003c/code\u003e flow variable is universally accessible across all contexts within the API Proxy Flow, unlike \u003ccode\u003erequest\u003c/code\u003e or \u003ccode\u003eresponse\u003c/code\u003e which are context-dependent.\u003c/p\u003e\n"],["\u003cp\u003eA key use case for the \u003ccode\u003emessage\u003c/code\u003e variable is during the error flow where \u003ccode\u003erequest\u003c/code\u003e and \u003ccode\u003eresponse\u003c/code\u003e variables are out of scope, making it useful for setting response headers.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003emessage\u003c/code\u003e variable, along with the \u003ccode\u003eerror\u003c/code\u003e variable, can be used in JavaScript policies to set response headers during an error flow, while the \u003ccode\u003eresponse\u003c/code\u003e variable cannot.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003emessage\u003c/code\u003e variable is valuable for logging response data in the PostClientFlow and can also be used in the AssignMessage policy to assign values to the \u003ccode\u003eresponse\u003c/code\u003e object in any context.\u003c/p\u003e\n"]]],[],null,["*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nAccess to the [`message`](/apigee/docs/api-platform/reference/variables-reference#message) flow variable and its properties depends on the point within\nthe API Proxy Flow in which it is accessed. It is available in all contexts, whereas some objects,\nsuch as [`request`](/apigee/docs/api-platform/reference/variables-reference#request) or [`response`](/apigee/docs/api-platform/reference/variables-reference#response) are not.\n\nUse cases\n\nThe principal use case for the [`message`](/apigee/docs/api-platform/reference/variables-reference#message) flow variable is when your proxy enters the\nerror flow: the [`request`](/apigee/docs/api-platform/reference/variables-reference#request) and [`response`](/apigee/docs/api-platform/reference/variables-reference#response) flow variables are out of scope.\n\nFor example, in the error flow, the `response` object is not available. You will not\nbe able to set response headers on the `response` object with the [JavaScript policy](/apigee/docs/api-platform/reference/policies/javascript-policy)\nif you are in the error flow. Instead, you can use one of the following:\n\n- [`error`](/apigee/docs/api-platform/reference/variables-reference#error)\n- [`message`](/apigee/docs/api-platform/reference/variables-reference#message)\n\nBoth of these objects are available in the error flow, and can be used to set response\nheaders from within a JavaScript policy or be accessed in other policies that can use flow\nvariables.\n\nYou can use the [AssignMessage policy](/apigee/docs/api-platform/reference/policies/assign-message-policy) to assign values, such as headers,\nto the **response** object. AssignMessage automatically handles the switch in\ncontext from request/response flow to error flow.\n\nAnother use case for the [`message`](/apigee/docs/api-platform/reference/variables-reference#message) variable is to log response data in the\nPostClientFlow with the [MessageLogging policy](/apigee/docs/api-platform/reference/policies/message-logging-policy). If you use the `message` object,\nyou can seamlessly log response information following both success and error conditions in the\nproxy.\n\nExamples\n\nIn an error flow, you can set a response header from a [JavaScript policy](/apigee/docs/api-platform/reference/policies/javascript-policy) using either\n[`error`](/apigee/docs/api-platform/reference/variables-reference#error) or [`message`](/apigee/docs/api-platform/reference/variables-reference#message). For example: \n\n```scdoc\ncontext.setVariable('error.header.FOO-1', 'error_header');\n```\n\n**OR** \n\n```scdoc\ncontext.setVariable('message.header.FOO-2', 'message_header');\n```\n\nThe following expression, however, will *not* work: \n\n```scdoc\ncontext.setVariable('response.header.FOO-3', 'response_header');\n```\n\nIn this case, the [`response`](/apigee/docs/api-platform/reference/variables-reference#response) variable is out of scope in the\nerror flow. (Note that, in a trace, this is visually indicated by variables shown with an equals\nsign with a slash through it.)\n\nTo set response headers for both success and error flows in a single policy, you\ncan use [`message`](/apigee/docs/api-platform/reference/variables-reference#message) inside a [JavaScript policy](/apigee/docs/api-platform/reference/policies/javascript-policy). For example: \n\n```scdoc\n\u003cfaultrules\u003e\n \u003cfaultrule name=\"invalid_key_rule\"\u003e\n \u003cstep\u003e\n \u003cname\u003eSetResponseHeaders\u003c/name\u003e\n \u003c/step\u003e\n \u003ccondition\u003e(fault.name = \"InvalidApiKey\")\u003c/condition\u003e\n \u003c/faultrule\u003e\n\u003c/faultrules\u003e\n```\n\nIn the policy, code like the following sets the error/response header in any flow context: \n\n```text\ncontext.setVariable('message.header.FOO-1', 'the header value');\n```\n\nYou can reuse this same policy on the normal ProxyResponse flow and it will succeed because\n`message` is available from all contexts."]]