This is probably an unusual case as I'm trying to define a new Proxy Endpoint in an API Proxy.
Let's say I have a default Proxy Endpoint with a Conditional Flow to match /myflow and action == GET and that works fine.
then I defined a new Proxy Endpoint (new_endpoint) with its own Conditional Flow to match /mynewflow and action == GET.
/mynewflow works fine and goes to the new_endpoint as expected.
however
/myflow is also now going to new_endpoint! (i used the Trace tool and confirmed it).
Here is the HTTP Proxy Connection Settings for both:
<HTTPProxyConnection>
<BasePath>/v2</BasePath>
<Properties/>
<VirtualHost>default</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
Is this expected? If it is, how do I make sure that /myflow routes to default Proxy Endpoint?
Looks like you're missing your <RouteRule> in your proxy. Just like the ConditionalFlow, you need a second RouteRule to point to your new target, which would look something like this:
<HTTPProxyConnection>
<BasePath>/v2</BasePath>
<Properties/>
<VirtualHost>default</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="new_endpoint">
<TargetEndpoint>new_endpoint</TargetEndpoint>
<Condition>(proxy.pathsuffix MatchesPath "/mynewflow")</Condition>
</RouteRule>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
You don't need to include individual verbs, because we can assume everything to /mynewflow is going to go to the new_endpoint target.
Also, make sure you put the conditional RouteRule above the default RouteRule -- Apigee will match the first one so if default (no condition) is first, you will never match the condition on the remaining rules.
I learned something today: apparently it's HttpProxyConnection/BasePath dictates which Proxy Endpoint is selected
as soon as made sure that the BasePath is different for both endpoints, routing started the way I expected it to.
Related
In order to connect my bot to the local bot API server and in order to turn curl's SSL verify_host and verify_peer off, how can I change irazasyed/telegram-bot-sdk's default request values of BASE_BOT_URL and the handler's verify option, not hard coding?
I know that I can change the BASE_BOT_URL constant in telegram-bot-sdk's TelegramClient class. And I know that I can change the verify option of my request handler to be false in guzzle's CurlFactory class. But, I'm not interested in hard-coding or overwriting these vendor files to avoid any update challenges in the future. I am more interested in something like longman/telegram-bot's setCustomBotApiUri function. The closest I could get is working with telegram-bot-sdk's setHttpClientHandler function, but I'm having trouble how to work with that.
Appreciate any help
P.S. I am using irazasyed/telegram-bot-sdk:^3.6 in my laravel:^9.2 app.
I have a variable named primary_address_id which can be set or updated via several API requests. For example, I may call AddAddress and specify that the new address should be the primary, or I can call MakePrimaryAddress to set an existing address as the primary.
I'm coming from Postman where I have tests defined for each of these API endpoints to update primary_address_id -- simple. But I can't find a way to do this in Paw; it seems I have to set the value to the response of just a single request. Am I missing something obvious? Or is this feature planned for a future release?
A workaround is to set the value of primary_address_id to the response from GetPrimaryAddress, but that means if I'm adding or updating an address I have to make a second call just to update my environment (which I may forget to do). If I could trigger GetPrimaryAddress to run after the Add/Update/List/etc endpoints that would be an acceptable workaround, but I shouldn't need to manually make two separate requests to accomplish this.
It sounds like you will need to make two subsequent requests but you can make groups of requests that will execute in sequence from one command.
Right click the request list and click "New Group" then within that group you can make a sequence of requests that will update your desired environment variable each time.
Create a new group of requests
To run a group of requests click on the group name; in this case "Address" and then click "Send Requests"
Execute group of requests in sequence
Hope this helps.
I reach a limit in the number of requests I can get using the default httpClient that my API wrapper provides.
//I was getting something like this at the beginning
Head www.example.com:80/: lookup example.com: no such host
To solve this I want to change the MaxIdleConnsPerHost setting for the httpClient.Transport of my client. It looks much more like this:
However, the Transport my client uses is a RoundTripper and subsequently, it doesn't have a MaxIdleConnsPerHost param.
&oauth2.Transport{Source:(*oauth2.reuseTokenSource)(0xc2082ac0c0),
Base:http.RoundTripper(nil),
mu:sync.Mutex{state:0, sema:0x0},
modReq:map[*http.Request]*http.Request(nil)
}
The one I'm providing is mostly a default one and it lacks the proper configuration I suppose or simple what I want to do is not feasible.
&http.Transport{idleMu:sync.Mutex{state:0, sema:0x0},
idleConn:map[http.connectMethodKey][]*http.persistConn(nil),
idleConnCh:map[http.connectMethodKey]chan *http.persistConn(nil),
reqMu:sync.Mutex{state:0, sema:0x0},
reqCanceler:map[*http.Request]func()(nil),
altMu:sync.RWMutex{w:sync.Mutex{state:0, sema:0x0},
writerSem:0x0,
readerSem:0x0,
readerCount:0,
readerWait:0},
altProto:map[string]http.RoundTripper(nil),
Proxy:(func(*http.Request) (*url.URL, error))(nil),
Dial:(func(string, string) (net.Conn, error))(nil),
TLSClientConfig:(*tls.Config)(nil),
TLSHandshakeTimeout:0,
DisableKeepAlives:false,
DisableCompression:false,
MaxIdleConnsPerHost:200,
ResponseHeaderTimeout:0}
Can someone guide me on the right direction?
i have just started working with Apigee.
I want to create one API proxy which will call two target endpoints based on 'if' condition.
i have created an API and added resources to it but the problem is in this case i am getting two API's .
If thetype='abc' target point should be target1
if thetype='xyz' target point should be target2
Can anyone please tell me how to proceed with it ?
Check out the answer to this question. The details of finding the RouteRules is listed there. The ProxyEndpoint documentation will also be helpful.
You can accomplish what you are attempting using this code:
<RouteRule name="routeToTarget1">
<Condition>thetype == "abc"</Condition>
<TargetEndpoint>target1</TargetEndpoint>
</RouteRule>
<RouteRule name="routeToTarget2">
<Condition>thetype == "xyz"</Condition>
<TargetEndpoint>target2</TargetEndpoint>
</RouteRule>
These RouteRules will be evaluated in order.
Note that you probably want the bottom RouteRule to have no condition, which means it will always match. What happens when thetype does not equal "abc" or "xyz"? Assuming target1 is the default, your code would look like this:
<RouteRule name="routeToTarget2">
<Condition>thetype == "xyz"</Condition>
<TargetEndpoint>target2</TargetEndpoint>
</RouteRule>
<RouteRule name="routeToTarget1">
<TargetEndpoint>target1</TargetEndpoint>
</RouteRule>
If you are using the API Proxy Editor UI, then you can do the following:
(1) Choose New / New Resource from the API Proxy Editor toolbar.
You will then see this:
(2) For the input field, Optional Target URL, enter the target URL that corresponds to that resource.
This tool will then generate both a conditional flow for that resource to which you can optionally attach resource-specific policies.
This tool will also add the needed route rule, and your generated XML will look like this:
<ProxyEndpoint name="default">
<RouteRule name="Resource-1">
<Condition>(proxy.pathsuffix MatchesPath "/someResource") and (request.verb = "GET")</Condition>
<HTTPTargetConnection>
<URL>http://myAlternateEndpoint</URL>
</HTTPTargetConnection>
</RouteRule>
....
I have the following. The parameter "g" is allowed to be "on" or "off", otherwise go to an error policy. However, the exception case is never called. Instead, the "on" case is called if something that is not "on" or "off" is passed as "g". Why is that? Or, is there a better way of expressing this?
<PreFlow name="PreFlow">
<Request>
<Step>
<Condition>message.queryparam.g := "on"</Condition>
<Name>GOn</Name>
</Step>
<Step>
<Condition>message.queryparam.g := "off"</Condition>
<Name>GOff</Name>
</Step>
<Step>
<Condition>!((message.queryparam.g := "off") || (message.queryparam.g := "on"))</Condition>
<Name>GError</Name>
</Step>
</Request>
I just tested your conditions and they work properly. If the request has the following query parameter values:
g=on or g=ON, the GOn policy will execute.
g=off or g=OFF, the GOff policy will execute.
g={anythingelse}, the GError policy will execute.
The := operator is the equals case-insensitive operator. How are you determining that the conditions are not working? Using your example, I made each of the policies a RaiseFault with a different fault response payload. This allowed me to verify which policy was executed depending on the value of g.
I agree with Michael, the code as shown is correct.
Thinking about possible issues that could cause this code to not work as expected:
Make sure that the names are correct inside your GOn, GOff, and GError policies. (If you are working offline, the name of the file has nothing to do with which policy gets called.) For example, the outer element of the GOn policy should look something like
<AssignMessage name="GOn">
If GOn uses AssignMessage to modify message, you might blow away the g query parameter during a step, and your later checks might fail. If you are modifying the message, store message.queryparam.g into a different variable before you do your checks.
I would use the trace tool and a tool like Postman to see what is happening for each request. The trace should tell you the variables that have been checked and their values, and you might be able to see where you are going wrong.
If you have multiple conditional checks try using javascritp.In the java script check the various conditions and set flag.And in the flow based on the value of flag execute the required policy.But for the above instance ,as Michael pointed out , the conditions should work as expected.