I have configured 2 wso2 api gateways (say gw1 and gw2) behind a load balancer (say lb1) . I have configured publisher in another node( say pub1). In pub1 box /etc/hosts file I have api gateway url to that of lb1. Now whenever I update or add a new api on pub1 it does not get immediately reflected on both gw1 and gw2, it gets reflected on one of the two. Is there a way programtically force api manager to refresh the list of published api's?
You need us deployment synchronizer to sync the artifacts across the gateway nodes. In your scenario, one gateway will need to be treated as the manager whilst the other one as the worker node.
Pls refer the documentation here on how to configure deployment synchronizer.
Related
WSO2 API Manager needs to restart after creating and publishing a new API in the new version (4.1.O). In old versions, there is no need to restart it.
Do you have a distributed API Manager deployment (not an all-in-one setup)? I suspect there could be a misconfiguration between the Control plane and the gateway node. Better to verify the configurations first (refer [1]).
In a distributed setup, gateway nodes listen to a JMS topic in the control plane. when API is deployed, gateway gets an event and after that, it queries the CP and gets the API-related artifacts. I suspect this CP->GW event is not reaching the gateway. As a result, APIs are not deployed in the gateway and cannot invoke it.
Gateway node does not keep the API artifacts stored. When there is a restart, gateway node calls the control plane directly and gets the available API-related artifacts and deploys them. That is why it works when you restart the gateway.
This is the new event-based mechanism we use in the APIM versions 3.2 onwards. That is why it worked in old versions.
[1] https://apim.docs.wso2.com/en/latest/install-and-setup/setup/distributed-deployment/deploying-wso2-api-m-in-a-distributed-setup/
I am trying to add Amazon Connect integration to an existing lex-web-ui instance running in a React app. The bot has not been created using the CloudFormation deployment template provided in the aws-lex-web-ui repo, and I am instead using one that has been manually created. Same goes for cognito and connect instances.
The Amazon Connect configuration for this requires apiGatewayEndpoint (provisioned by CF template) - however, due to the above, this is not present in my current config. What exactly is this gateway endpoint, what is its purpose and what does it connect to? It looks like it's absolutely needed for the config otherwise it throws a refusal error.
I've configured the connect instance and contact flow ID, the last piece missing is this API GW url.
I have several questions about WSO2 API Manager that I am not able to figure out reading the documentation:
Is it possible to setup a "default" basepath for all API? for example if I have to switch my endpoints from localhost:8080/rest/myapi to 12.43.56.89:8080/rest/myapi is it possible to do it without editing any single API's enpoint?
Is it possible to create create a role which allows access only to sandbox endpoint but not to production endpoint? The only way to do this, as far as I know, is to manually block the access to production once the user has subscribed the API. My idea is to allow all users to access the sandbox but enable only trusted users to access the production APIs once their applications have been validated.
Is it possible to distribute several instances of the AM Gateway? Accordingly with documentation it seems that is only possible to run gateway, store, and publisher+keymanager on different servers but not to run multiple instance of the gateway in parallel.
Thank you!
1) You can use a variable for endpoint base path like this.
http://{uri.var.host}:{uri.var.port}/apis/weather
These variables can be taken from system variables. See this for how to do it.
2) You can use Key Generation (i.e. OAuth App Registration) Workflows for this. This will send a approval request to admin user. If you want to automate it to approve based in user roles or something, you can customize workflows.
3) You can have multiple gateways.
I have a question on WSO2 API Manager Clustering. I have gone through the deployment documentation in detail and understand the distributed deployment concept where in one can seggregate the publisher, store, key manager and gateway. But as per my asessment, that makes the deployment architecture pretty complex to maintain. So I would like to have a simpler deployment.
What I have tested is to simply have two different instances of the WSO2 API Manager to run in two different boxes pointing to the same underlying data sources in MySQL. What I have seen is that, the API calls work perfectly and the tokens obtained from one WSO2 instance would work for API invocation on the other API Manager instance. The only issue with this model is that we need to deploy the APIs from individual publisher components for as many WSO2 API Manager instances that are running. I am fine to do that since the publishing will be done by one single small team. We will have a hardware load balancer in front having the API endpoint URLs and token endpoint URLs for both the API managers and the harware LB will do the load balancing.
So my question is - are there any problems in following this simple approach from the RUNTIME perspective? Does the clustering add any benefit from RUNTIME perspective for WSO2 API Manager?
Thank you.
Your approach has following drawbacks (there can be more which I do not know);
It is not scalable. Meaning - you can't independently scale (adding more instances of) store or publisher or gateway or key manager.
Distributed throttling won't work. It will lead to throttling inconsistencies since the throttling replication won't happen if you don't enable clustering. Lets say you define 'Gold' tier for an API. Doesn't matter how many gateway instances you are using, a user should be restricted to access no more than 20req/min to this API. This should have been implemented based on a distributed counter (not sure the exact implementation details). So if you don't enable clustering, one gateway node doesn't know the number of requests served by other gateway nodes. So each gateway node will have their own throttle counter. Meaning - a user might be able to access your API more than 20req/min. So this is one of the throttling inconsistencies. Further, lets say one gateway node is throttled out a user but the other gateway node is not. Now, if your LB routes the request to 1st gateway node, user will not be able to access the API. If your LB routes the request to 2nd gateway node, user will be able to access the API. This is another instance of throttling inconsistency. To overcome all these issues, you just need to replicate the throttling across all the gateway nodes by enabling clustering.
Distributed caching won't work. For example, API Key validation information are cached. If you revoke a token in one API Manager node, cache will be cleared in that node. So a user can't use revoked token via that API Manager node, BUT he is able to use the token via the other API Manager node until the cache is invalidated (I guess 15 min by default). This is just one instance where things can go wrong if you don't cluster your API Manager instances. To solve these issues, you just need to enable clustering, then the cache will be in sync across the cluster. Read this doc for more details on various caching available in WSO2 API Manager.
You will be having several issues if you don't have above features. WSO2 highly recommends distributed deployment in production.
I am setting up the API Manager in a cluster and have one version of the store and one version of the publisher which are clustered so they update each other on change. I also have the gateway setup up in a master and worker cluster. All of this I found out how to do on the wso2 site. The issue is I want to cluster the key manager as well for higher load but I can't find any documentation on how to cluster the key manager specifically. I assume it's not just a case of running more than one behind a load balancer as they need to know when the tokens etc have changed?
Any help would be appreciated
Please follow this documentation on API Manager clustering. Please follow Configuring the connections among the components -> Key Manager section and Configuring component features section accordingly. This blog post explains when IS is used as Key Manager. But the explanation might be helpful to you to understand when using several urls.