Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.


Flows are sequential stages along the processing path of API requests. Flows are how Apigee Edge provides places for you to apply logic and behavior at specific places from client to backend resource, then back to client.

Through your code in these stages, you can:

  • act on specifics of the incoming request.
  • implement logic for security, traffic management, and more.
  • implement processing that varies conditionally according to state expressed as values in variables.
  • act on specifics of the response from a backend resource
  • return an appropriate result to the requesting client

Flows are configured with XML that specifies what should happen in that particular flow. The following illustration shows how flows are ordered sequentially:

The following are larger stages that contain the flows (smaller stages) for processing requests and responses:

  • ProxyEndpoint -- Contains the API proxy flows closest to the client. Provides places for logic to act first on the client request, then last on the client response.
  • TargetEndpoint -- Contains the API proxy flows closest to the backend resource. Provides places for logic to prepare a request for, then handle the response from, the backend resource.

The ProxyEndpoint and TargetEndpoint both contain flows as a sequential set of stages for processing. These flows execute in the following order:

  1. PreFlow

    Executes first. Useful when you need to make sure that certain code executes before anything else happens.

    For example, you usually don't want an API proxy to waste any resources on an unauthenticated user. Also, you don't want to service an app that has exceeded its quota. To support these requirements, you put security and quota policies in the PreFlow segment. That way, you don't need to worry about a condition failing to evaluate. The policies in this flow will always execute before any other processing takes place. 

    In the following example, SpikeArrest and Quota policies execute before processing passes to conditional flows.

    <PreFlow name="MyPreFlow">
  2. 条件 Flow

    Executes after the PreFlow and before the PostFlow. You can have multiple conditional flows, each specifying a different condition that tests for particular state values, effectively branching execution based on conditions. Conditional flows tell Edge, "When you see this, perform this logic."

    You might want to convert XML to JSON only when the requesting app is running on a mobile device; or create a new HTTP response header when the /foo API resource is called; or you might want to return a targeted ad based on the data in the user's request. You can do this by setting up conditional flows.

    For example, by attaching a Quota policy, then specifying a condition, you can enforce quota constraints only for requests where the condition is met. made to that flow URI and verb combination. The following specifies that the Quota policy should execute only if the request matches a particular path suffix and HTTP verb combination.

    <Flow name="issue">
        <Condition>(proxy.pathsuffix MatchesPath "/issue/**") and (request.verb = "GET")</Condition>

    In this configuration, if a GET request comes in on the API proxy with a URI pattern of .../issue/** (/issue/ with anything in the URI after the last forward slash), quota constraints are enforced on that API call.

    In a conditional flow, the condition is evaluated in both the request and response. You cannot have separate conditions for request and response.

  3. PostFlow

    Executes after conditional flows. PostFlow is useful when you need to log some data, send a notification that something happened, transform the message format, and so on.

    In the following example, an AssignMessage policy called SetResponseHeaders sets headers of the response message before Apigee Edge sends the response back to the client.

  4. PostClientFlow (ProxyEndpoint response only)

    ProxyEndpoint には、レスポンスが要求側クライアントアプリに返された後に実行される、オプションの PostClientFlow を追加できます。このフローに添付できるのは、MessageLogging ポリシーのみです。PostClientFlow は、API プロキシのレイテンシを短縮し、client.send.start.timeclient.send.end.time のような、レスポンスの送信後まで計算されない情報を、ログ記録に利用できるようにします。このフローは主に、レスポンスメッセージの開始と終了のタイムスタンプの間隔を測定するために使用されます。詳細については、以下を参照してください。

Help or comments?