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.
Related
What is the best to exporting API & EndPoint & DataService on WSo2 ?
usually I export the API & EndPoint in same car.file then exporting dataservice in other carbon file
If your APIs and the Dataservices depend on each other it may be best to package them together. If not, packaging them together would introduce unnecessary downtime to the other service when updating one service. (Redeploying an API would redeploy the Data services). Also, Carbon Applications are deployed in alphabetical order. So if you have anything that depends on the deployment order you can prefix the carbon application with a number or a letter. For example 1_APIServices.car, 2_AppDataServies.car. So they will always be deployed in a certain order on server restart.
This is based on the use cases and requirements. If you want to reuse the data service or the API, then you can have them in separate car files and deploy. Otherwise you can have those in a single car file.
Can I publish an agent version on an environment using the Dialogflow V2 API?
I can't find any documentation on how to do that.
The doc about versions and environments only mentions doing this using the console (https://cloud.google.com/dialogflow/docs/agents-versions).
And the API doc of the agent environments resource only contains a list method (https://cloud.google.com/dialogflow/docs/reference/rest/v2/projects.agent.environments).
Does it mean that every change done using the API is automatically reflected in production?
Or does it mean that every change done by API is staged, and can only go to production by manually accessing the console and publishing the new version?
Both options seems terrible by the way.
Currently, it's not possible to manage agent versions through the Dialogflow API, it seems that this feature is already being contemplated to be integrated to Dialogflow; however, there is no an ETA for its implementation. You can follow up this request here.
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 have downloaded one API (as api.zip file), which I created in WSO2 API Manager from the Administation console. Is there a way to import this API in different WSO2 instance?
Any suggestions??
Data of a published API from APIPublisher stored in three places.
In file-system [as a synapse config API element]
In database level
-- as registry data [stored API static meta-data]
-- as directly stored data in APIM db [stored API runtime data]
I believe you have downloaded the API element from Metadata-> List-> APIs in management console,which is stored in registry space.To restore a created API in another wso2 AM instance,this downloaded API element is not sufficient.
If you want to backup API data from one APIManager instance and restore in another instance,what you have to do is backup both above file-system and database specific data and restore.Other than that,currently there's no direct download and upload mechanism to do API backup and restoring process in WSO2 APIManager.
Thanks;
We are evaluating multiple ESB products currently (Mule, Fuse and WSO2), and one of our key requirements is to easily migrate services between multiple environments. I can see how this can be done in WSO2 with g-reg for the most part, but am struggling to see how we would parametrise the endpoint uris and maintain them separately in each environment? (This seems fairly trivial in Mule and Fuse).
The preferred way is:
Create/save ALL endpoints as registry resource (either using management console or Developer Studio)
Since the endpoints are saved in the registry, now the ESB configuration is totally independent of the environment. (We can create a Carbon Application out of this, which is basically can be deployed in any environment)
So, if you need to move the configuration from dev->qa, you can use the same .car file created