I need to work around a weird behaviour of WSO2 ESB. Whenever the ESB is started, all carbon files are redeployed. This means to reset all changes made in files after last deploy(restart), such us, configuration xml files (endpoints, custom config files...) .
So I guess the only way to avoid modifing this configuration files during the start up is to take them out from the carbon file. Thus, I would upload app files as carbon app, and app config files (EP, custom config files...) using an alternative way.
So, in this situation, how could I upload these config files in and easy and automatic way?
Regards
I presume you are using a CApp (Carbon Application) to deploy the esb artifacts like endpoints. The number rule for this procedure is that you need to do all the modifications you need to do via the WSO2 Developer Studio, build a CApp, and re-deploy it in WSO2 ESB. You should try to avoid using management console to perform esb artifact (proxy services, endpoints, sequences, templates etc.) modifications. You can of course use the management console for other administrative tasks like configuring data-sources, BAM mediation data publishing etc.
If you are using the Management console to modify artifacts, then you can do that too, but avoid using CApps as the method of deploying esb artifacts. You should probably copy all the config xml files to relevant folders at $ESB_HOME/repository/deployment/server/synapse-configs/default/. And then go ahead with your modifications via mgt console.
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.
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.
I have a requirement to version control my "registry" artifacts (i.e. wsdls, xsds, xsls), that I currently upload to the WSO2 ESB 4.8.1 server. I'm not using WSO2 GREG at the moment. I came across the "Registry Resources Project" facility which I think would help me achieve this. However I'm unsure as to whether this facility can only be used with GREG or with ESB as well. Is there a way for me to generate a CApp Project, include the the above "Registry Resources Project" in it, and deploy it to my ESB server?
I've come across blogs which deploy standard ESB artifacts in the way, but not the registry. -
Please help....
You can create required registry resources as specified in the creating registry resources documentation. Once you have created your registry resource project, then you need to create composite application archive as specified in the Creating a Composite Application Archive (CAR) file documentation.
When you are creating CAR file, you need to specify server role as EnterpriseServiceBus to deploy your registry resources in ESB.
Thanks.
I am using WSO2 DSS, ESB and BPS for my project.
They are working fine in respective servers. But my idea is to integrate DSS, ESB & BPS into one car file(or some other deployment archive file) and thus making the deployment easier.
I have a Carbon application project created in Developer studio which has DSS project, ESB Config project, BPEL workflow and a Web application in it.
When I export it, it exports only the ESB & BPS and excludes Web application.
Is there a way to generate one deployment archive which would contain all the mentioned project? And is it possible to deploy a java application in WSO2 server since it has tomcat in it?
Thanks in Advance.
You can deploy webapplications in WSO2 Application server. Refer this. There is a server role which is defined in the server and also in the CAR file for each deployable artifacts. So if you are going to use one server lets say application server with DSS,ESB and BPS installed you need to add DSS's ESB's and BPS's server roles so artifacts which has respective servers role can be deployed in bundled server. Please refer following for server role management.
http://docs.wso2.org/wiki/display/AS510/Introduction+to+Server+Roles
Q>
Is there a way to generate one deployment archive which would contain all the mentioned project?
Ans>> Yes. It is possible. Carbon Application Archive(CAR) file is the single deployable module to package all the above mentioned different artifacts type to a single deployable archive.
You can use either IDE or Maven to generate the CAR file for your artifacts. Please refer to Dev Studio Documentation for more information.
Q> And is it possible to deploy a java application in WSO2 server since it has tomcat in it?
Ans>> You can deploy a Java application in WSO2 Application Server but in order to do that you need to convert your application to a Web-Services since WSO2 provides mechanism to expose your applications as Web Services. For that you can use either Axis2 Web Service or Jax-WS web-Service.
WSO2 Developer Studio supports creation of Axis2 Web-Services as well as Jax-WS web services. Please refer to Axis2 Artifact and Jax-WS Artifact Documentation for more information.
Also if you have a Java based Web-Application, you may deploy that Web-Application in WSO2 Application Server and WSO2 Dev Studio supports implementing Web-Applications as well.
Thanks and Regards,
Harshana
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