You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/ROOT/pages/_partials/task-add-api-instance.adoc
+4Lines changed: 4 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -33,4 +33,8 @@ instance.
33
33
34
34
When you are promoting or importing an API instance, you do not have options to alter the configuration. However, when you add a new API instance, you need to the downstream and the upstream configuration settings.
35
35
36
+
The following diagram shows the relationship of the upstream and downstream configurations settings to your upstream service and the downstream consumer application. In this configuration, the downstream service is the service making API requests that are completed by the upstream service. These terms represent the direction of dependency, not the direction of information. A downstream service could make a `POST` request where it provides information to the upstream service. However, the downstream service is still dependent on the upstream service to complete the request.
37
+
38
+
image:api-upstream-downstream-config.png[The API instance is deployed on a gateway between the upstream and downstream configuration]
Copy file name to clipboardExpand all lines: modules/ROOT/pages/_partials/task-configure-proxy.adoc
+11Lines changed: 11 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -91,6 +91,17 @@ NOTE: After adding the API on Anypoint Platform, you will need to bind it to a s
91
91
[arabic]
92
92
.. Enter a name for the new API asset.
93
93
//end::mid-steps[]
94
+
//tag::asset-type-options-flex[]
95
+
.. Select the **Asset type** from the following options:
96
+
97
+
** **REST API:** Select this option if you have a RAML or OAS API definition file you want to include for your asset.
98
+
+
99
+
Upload either a RAML or OAS file for your REST API. Versions 2.0.0 and later are the recommended versions for OAS or RAML specs, because these versions add native OAS support. If you upload an OAS API specification to an API proxy version 1.0 or earlier, your API specification is translated to RAML.
100
+
** **HTTP API:** Select this option if you do not have an API definition file you want to include for your asset.
101
+
102
+
.. Optionally, you can add an **AssetId** and customize the **Version** or **API Version** details by clicking **Advanced**.
103
+
. Click *Next*.
104
+
//end::asset-type--options-flex[]
94
105
//tag::asset-type-options[]
95
106
.. Select the **Asset type** from the following options:
. Configure one of the following upstream configurations:
32
+
** *Single Upstream Service* +
33
+
For Flex Gateway versions 1.4.x or earlier or Flex Gateway version 1.5.x with a single upstream service, configure the following upstream configuration settings:
== Multiple Upstream Services for Flex Gateway Running in Connected Mode
46
+
47
+
Flex Gateway version 1.5.x or later supports API instances that expose multiple upstream services through a single consumer endpoint.
48
+
49
+
Flex Gateway manages request traffic by using different routes that can each direct traffic to multiple upstream services. Flex Gateway directs traffic to the routes by using the route order and the individual route's rules. Additionally, you can add a weighted percentage to each upstream service within a route to manage the percentage of requests sent to the upstream service.
50
+
51
+
In the following diagram, different routes manage requests to flight information databases and to a customer service application. Route one has two upstream services defined, which direct 70% of requests to a stable database and 30% of requests to a beta database.
52
+
53
+
image:multiple-upstreams.png[Flex Gateway manages the traffic to multiple upstreams]
54
+
55
+
=== Routes
56
+
57
+
Each API instance supports up to 10 routes and each route can support up to 10 upstream services. Configure what requests a route can receive by defining route rules and a route order. At least one route per API instance is required.
58
+
59
+
Before adding additional routes, enter an optional *Route label* for clarity.
60
+
61
+
You can add additional routes by clicking *Add Route*, and you can delete routes by clicking the *Trash Can* icon (image:trash-can-icon.png[2%,2%]). If only one route is defined, you cannot delete that route.
62
+
63
+
64
+
==== Route Rules
65
+
66
+
You can direct requests to different routes by using route rules.
67
+
68
+
To view and edit route rules, click *Route Rules*.
69
+
70
+
All rules are optional. If a rule does not have a value, that rule is ignored. For example, not specifying a host means that the route can service any host if the request meets the other route rules. Not defining any rule means that the route can service every request.
71
+
72
+
Different routes can support the same upstream services. If you cannot capture all requests for a particular set of upstream services in a single route rule set, you can define multiple routes with different rules for full coverage.
73
+
74
+
Only requests that meet all of the rules defined in the ruleset are directed to that route. If a request does not meet the rules for any route, Flex Gateway returns a `404` error code.
75
+
76
+
Flex Gateway supports the following route rules:
77
+
78
+
Method::::
79
+
+
80
+
Defines the types of request methods that the route can service.
81
+
+
82
+
You can select multiple methods for each route. Only requests that are one of the defined methods are directed to this route.
83
+
+
84
+
To select the supported methods:
85
+
+
86
+
. Expand the *Method* drop down list.
87
+
. Select all supported methods.
88
+
. Collapse the drop down list.
89
+
+
90
+
Path::::
91
+
+
92
+
Defines the request path that the route can service.
93
+
+
94
+
You can define only one “URI Template Regex" path for a route. Only requests with the defined path are sent to this route.
95
+
+
96
+
To define the *Path* rule:
97
+
+
98
+
. Enter your path template in the *Path* configuration field.
99
+
+
100
+
Host::::
101
+
+
102
+
Defines the request host that the route can service.
103
+
+
104
+
You can define only one host URL for each route. Only requests made from the defined host are sent to this route.
105
+
+
106
+
To define the *Host* rule:
107
+
+
108
+
. Enter your host in the *Host* configuration field.
109
+
+
110
+
Header::::
111
+
+
112
+
Defines what headers and regular expression value must be present for this route to service the request.
113
+
+
114
+
For this rule, you define the header name and a regular expression value. Only requests that meet all of the specified header requirements are sent to this route. Additional headers present in the request that are not specifically defined in the rules are ignored.
115
+
+
116
+
You can define up to 10 headers.
117
+
+
118
+
To define the *Headers* rule:
119
+
+
120
+
. Click *Add header*, if this is not your first header.
121
+
. Enter the header name in the first box.
122
+
. Enter the header's regular expresion value in the second box.
123
+
+
124
+
NOTE: To delete a header, click the *Trash Can* icon (image:trash-can-icon.png[2%,2%]).
125
+
126
+
==== Route Order
127
+
128
+
In addition to using route rules, Flex Gateway directs requests to different routes by using the top to bottom order of how the routes appear on the page.
129
+
130
+
Flex Gateway directs requests to the first route if the request meets the route rules.
131
+
132
+
To define the route order, use the up and down arrows to arrange the routes.
133
+
134
+
Route ordering is very important when a request can meet the route rules of multiple routes. You should order the routes with more complex route rules first. If you do not define a route order, routes are ordered in the order they were created.
135
+
136
+
For example, in a configuration in which route one has the `GET` method defined as a rule and route two has no route rules defined, all `GET` requests are sent to route one and all other requests are sent to route two. If the route order was reversed and route one had no route rules, Flex Gateway would direct all requests to route one before any `GET` requests could reach route two.
137
+
138
+
=== Upstream Services
139
+
140
+
You can use multiple upstream services in a single route to direct requests to similar services. For example, to test the performance of a new beta upstream service without sending all traffic to the new service, you can direct half of the traffic to a stable upstream service and half to the new upstream service.
141
+
142
+
Each API instance route can support up to 10 upstream services, but at least one upstream service is required for each route.
143
+
144
+
What upstream service within the route each request is sent to is random and independent of any previous request. The upstream *Weight* defines the percentage chance of a request being sent to a particular upstream service.
145
+
146
+
Because any upstream service within a route can receive any request, all upstream services within the same route must adhere to the same API contract.
147
+
148
+
You can add an upstream service by clicking *Add Upstream*, and you can delete an upstream service by clicking the *Trash Can* icon (image:trash-can-icon.png[2%,2%]). If only one upstream service is defined, you cannot delete it.
149
+
150
+
Configure the following fields for each upstream service:
151
+
152
+
[%header%autowidth.spread,cols="15%,35%,15%,35%"]
153
+
|===
154
+
| Field Name | Description | Required | Notes
155
+
| *Upstream URL* | URL to access for the proxy or API. This must end with a `/`. | Yes | For example, you can use the URL of your API asset in Exchange.
156
+
| *Upstream Label* | Label for the upstream service | No | If you have multiple upstream service instances, add a label to each one to differentiate it from the others.
157
+
| *TLS* | TLS context used for the outbound traffic to the upstream service | No | xref:gateway::flex-conn-tls-config.adoc[Configure a TLS Context for Flex Gateway] before adding a TLS context to your API. Add a TLS context by clicking *Add TLS Context*.
158
+
| *Weight* | Percentage of requests to send to that upstream service | Yes | This value is configurable only if you have multiple upstream services. The sum of all upstream weights must equal `100%`.
0 commit comments