Merge pull request #531 from mulesoft/W-12992498-traffic-management-connected-mode-eng-review-gr

W-12992498 traffic management connected mode eng review gr

Author: glenn-rodgers-sf

modules/ROOT/pages/create-instance-task-flex.adoc

@@ -46,15 +46,15 @@ include::partial$task-configure-proxy.adoc[tags=last-steps]
 
 Flex Gateway version 1.5.x or later supports API instances that expose multiple upstream services through a single consumer endpoint.
 
-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.   
+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.    
 
 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.  
 
 image:multiple-upstreams.png[Flex Gateway manages the traffic to multiple upstreams]
 
 === Routes
 
-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 router per API instance is required. 
+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. 
 
 Before adding additional routes, enter an optional *Route label* for clarity.
 
@@ -67,11 +67,11 @@ You can direct requests to different routes by using route rules.
 
 To view and edit route rules, click *Route Rules*.
 
-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.
+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. 
 
 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.
 
-Only requests that meet all of the rules defined in the ruleset are directed to that route.
+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.
 
 Flex Gateway supports the following route rules:
 
@@ -134,8 +134,8 @@ To define the route order, use the up and down arrows to arrange the routes.
 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.
 
 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.
- 
-=== Upstreams
+
+=== Upstream Services
 
 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.