In a cluster, where does WSO2 APIM store the configuration files that, in a non-clustered deployment are kept under:
<wso2_home>/repository/deployment/server/synapse-configs/default/api
I published a Ticket API through Publisher in a clustered deployment of WSO2 but haven't found the corresponding 'admin--TicketAPI_v1.0.xml' file anywhere. The clustering guide creates several databases. Would this xml file be stored in any of the WSO2 databases? If so, where? What I need to do is to add Custom Handlers to my API by adding to the "handlers" section of the 'admin--TicketAPI_v1.0.xml' file, as explained in the Writing Custom Handlers doc. How is this accomplished in a clustered deployment?
You should be able to find admin--TicketAPI_v1.0.xml file in your gateway node
/repository/deployment/server/synapse-configs/default/api
Your admin--TicketAPI_v1.0.xml file should be there in one of the gateway worker nodes.
However, It is not recommended to update the API source code via the source view UI or file system when engaging a custom handler to selected APIs, because the customizations get overridden by the publisher updates.
So the recommended way is to add the custom handler that you wrote to the velocity_template.xml found in /repository/resources/api_templates/velocity_template.xml
Related
I have another question on WSO2 APIM 2.6.0
I am working in one scenario where I have to store one file which is in json in gov registry. I can do that manually from the dashboard but I am looking for a way to perform that using API or in automated way.
Research done till now
1) Checking on the link which ideally enable WSO2 ESB to maintain a remote registry. But I am unable to get how the registry DB will be shared between the applications (APIM and ESB).
Like, ESB has property where we can store the data in registry directly from proxy or an API and also enables us to retrieve them accordingly.
But how do we do in APIM to store the file with json content.
Any suggestions here.
Thanks
I've published an API named as "DocumentAPI", after publishing I can find two API's with the name "DocumentAPI" in publisher. Can find only one API with name "DocumentAPI" in store. Tried deleting, recreating and republishing the API and also restarted my server.
Two gateways(internal(MZ) and external(DMZ)) are there in the current environment which means some the APIs are specific to internal and some are specific to external and some are published to both the gateways(cuurent problematic API is published to both the gateways)
There is no synchronize method setup between these two nodes.
We are on APIM-2.6.0
There is no duplicate entries in AM_API, REG_PATH tables with repect to problematic API. Only in publisher UI we are seeing two APIs with same name,version & conetxt and when I modify any one API the change immediately relfecting into other API as well. In store only one API it is showing and when I test this API through Postman subsequent calls are getting failed.
Note: Publishing in fully distributed environment.
Are you using APIM wum updated pack or vanilla pack? If it is wum, what is the wum level(AM_HOME/updates/wum)?
Did you try to recreate a new API instead of that "DocumentAPI" name (with a different name) and did you see the same issue for this when publishing to both GW nodes?
In APIM 2.6.0 we have seen a similar issue if we have created an API with uppercase (eg: AbcAPi) and published it. Then remove it and try to recreate the api with the same name but lowercase (eg: abcApi) and publish it. Then we can see two API in the publisher portal but not in Store UI. And AM Table has one record. But in the registry has two paths (as you have seen).
eg:
/_system/governance/apimgt/applicationdata/provider/admin/AbcAPi
/_system/governance/apimgt/applicationdata/provider/admin/abcApi
One path for that old api name and another path for the new API. Since currently, we have fixed this, and that fix is available in the latest wum updated pack of the APIM 2.6.0. Therefore did you notice such differences in both reg paths (select * from REG_PATH where REG_PATH_VALUE).
If yes, it has fixed in the latest wum of APIM 2.6.0. The reason here is when removing API, it remains some metadata of old API and when recreating registry keep both paths.
When creating an API in wso2 APIM, it doesn't allow to create two APIs with the same name, context and version (name, context and version should unique).
As per the provided mentioned details, we hope that both APIs in the publisher node has the same name, context and version.
In your distributed set up how many GWs are available(one or many)?
If has multiple GW nodes, are you using any deployment artefact syncronize method like NFS?
What is the APIM version
Are you noticing two records for the above API in the AM database(AM_API table)?
I am trying to setup WSO2 api manager(as windows service) with clustering, used steps at the end of the page found at this link.
https://docs.wso2.com/display/CLUSTER44x/Clustering+API+Manager+2.0.0
<clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent"
enable="true">
I have 2 nodes in a load balancer, I have all 4 components(Publisher
,Store,Key Manager,Gateway) on both nodes. When setup individually, both nodes work.
However, when clustering is enabled, store does not replicate from one node to another. I have hosts file updated as needed. I tried making several changes to axis2.xml, api-manager.xml; some of these changes cause api manager to stop working altogether.
Does anyone have suggestions for a successful clustering setup? Is there something that is needed, is not mentioned in the steps mentioned at above link?
I think the documentation that you are following is not the relevant one. If you are clustering WSO2 API Manager 2.1.0 version please use API Manager 2.1.0 clustering docuemntation which is inside the API Manager product documentation itself.
deploying the WSO2 APIM 2.1.0 using puppet, we consider to deploy the API itself with the CICD as well.
In theory - I could copy (template) the synapse files (proxy, api) and the api is available for the call, however - the API is not visible in the store. I assume there's more data in the database than just a synapse config file.
Is there a way to define / deploy API (including to the store) using the configuration files or it needs to be done manually?
Edit:
I thought there's a way to deploy API using the API Admin Services. But when calling addAPI with the metadata XML, looks ok. But trying to see the API in the publisher throws an exception
ERROR - index:jag org.wso2.carbon.apimgt.api.APIManagementException: Unable to find the API: admin-myapi-v1.0.0 in the database
Thank you for any hint
g.
Based on your requirements it looks like you can use one of the following options.
Migrate APIs - You can export APIs from one environment and import those APIs to the new environment. When you import APIs in the new environment, those APIs will be in created state. You need to manually publish those APIs. May be using the jaggery API or REST API you will be able to publish the APIs.
REST API
Jaggery API - This is deprecated at the moment and discourage for using this.
Once you create the APIs, APIs related details will be saved in the database. Additionally, synapse configuration can be found in the file system. If you point the previous database to the new deployment and deploy the synapse artifacts, APIs will work. But then again API creation/publishing and entire flow will not be tested. For CICD, you need to consider above mentioned options. In the future releases, there is more focus towards the REST API and it will be more useful for the CICD.
WSO2 API manager has 4 components
API Gateway
API Publisher
API Store
API Key Manager Server
I would like to run each of these components on separate boxes. While doing so on box where I have API Publisher component I want to remove other 3 components from the api manager so on with other components. By this I would like to achieve that only 1 component exists at run time of each instance of wso2 api manger.
I would like to know how can we remove each of these components from wso2 api manager?
You can remove the relevant features from the product via Carbon Feature Management (Or you can add necessary features as well).
You can find more information regarding how to uninstall a particular feature here.
You can also find more information regarding feature management for WSO2 Carbon products here.
HTH,
Lasantha
To add to Lasantha's answer, this article describes how these 4 components can be deployed separately in a cluster with an ELB.
Installing High Level components is supported from API Manager 1.5.0 onwards. If you want to start API Manager as one of the components, that can be achieved by starting as a server profile. You can find more information here.