Amalka Subasinghe's Blog

This blog explain how you can add a new app type to the WSO2 App cloud. Step 1: Get a clone of WSO2 app cloud code base git clone https://github.com/wso2/app-cloud Step 2: Create the docker files for the runtime Please refer our existing docker files when creating new docker files for particular runtime. https://github.com/wso2/app-cloud/tree/master/modules/resources/dockerfiles Following blog post gives you some details about structure of the docker files http://amalkas.blogspot.com/2016/09/add-new-runtime-to-existing-app-type-in.html Step 3: Required database changes When adding new app type you need add some database records, following diagram gives you an idea of database schema. AC_CLOUD defines the cloud types AC_APP_TYPE defines app types AC_RUNTIME defines runtimes AC_CONTAINER_SPECIFICATIONS defines container specs AC_TRANSPORT defines the ports we expose for end users -- insert app type -- insert app type, cloud mapping -- insert runtime -- inser

Currently we have 6 app types in WSO2 App Cloud and when we load a app home page of created applications we can see a section called "Endpoints". This blog post is about how we load endpoints per each and every app type and it's implementation Loading endpoints for Java web application, Jaggery and PHP app types for these 3 app types, user have to define the application context, when creating an application as shown in below image. Then we append that context to the app version url/default url and display in app home page as below. Loading endpoints for Microservices app type for microservices app type, microservices 2.0.0 itself provides a swagger url, we just display the swagger url here. Loading endpoints for WSO2 dataservices app type for dataservices app type, we need to invoke the ServiceAdmin soap service to get the endpoints. So we developed a axis2service and deployed in dss runtime, which invokes the ServiceAdmin and return the endpoints

This blog post explains how you can add a new runtime to a existing app type. Recently WSO2 Carbon team released WSO2 AS 6.0.0 M3 release. I'm gonna explain how we can add this WSO2 AS 6.0.0 M3 as a new runtime of war app type. Step 1: get a clone of app-cloud code base git clone  https://github.com/wso2/app-cloud Step 2: Create required docker files When creating docker files, please refer the existing docker files we have created for other runtimes and get an idea. You can find the existing docker files here https://github.com/wso2/app-cloud/tree/master/modules/resources/dockerfiles You can find the wso2as docker files here. We need to add dockefiles related to WSO2AS 6.0.0 M3 dockerfiles here https://github.com/wso2/app-cloud/tree/master/modules/resources/dockerfiles/wso2as dockerfiles/wso2as/base  This folder contains docker files required to build wso2as base images dockerfiles/wso2as/default  This folder contains docker files which require to

Currently, WSO2 App Cloud follows the container based approach to provide different runtime to deploy application artifacts. Likewise we can follow the same approach to deploy ESB car file as a app type in WSO2 App Cloud. But, our requirement is to provide a separate cloud perspective (view) for end users for integration solutions, so we thought to generalize the app cloud to operate in two modes (as app cloud and integration cloud) on single app cloud deployment. 1. We need two different URLs ( https://apps.cloud.wso2.com and https://integration.cloud.wso2.com ) to login to separate clouds. How SSO works : Currently, when a user login, it redirect to WSO2IS for SSO and then it comes to app cloud with https://apps.cloud.wso2.com url. Same as when user requests integration cloud it should redirect to WSO2IS and then it comes to the app cloud with https://integration.cloud.wso2.com url. For that we use 2 different issuers and 2 SPs configured in IS side. When the r

This blog post gives you some examples on how to use createApplication REST API correctly in WSO2 App Cloud  https://docs.wso2.com/display/AppCloud/Published+APIs Before invoke createApplication API, you need to login to the WSO2 App Cloud and get the session cookie. curl -c cookies -v -k -X POST -k https://apps.cloud.wso2.com/appmgt/site/blocks/user/login/ajax/login.jag -d 'action=login&userName=amalka.wso2.com@<tenant>&password=<password>’ This are some basic example to create applications in WSO2 App Cloud. Create application via upload from file system curl -v -k -b cookies -X POST https://apps.cloud.wso2.com/appmgt/site/blocks/application/application.jag -F action=createApplication -F applicationName=SampleFile -F applicationDescription=desc -F runtime=1 -F appTypeName=war -F applicationRevision=1.0.0 -F uploadedFileName=sample.war -F runtimeProperties=[] -F tags=[]  -F fileupload=@/home/amalka/Downloads/sample.war -F isFileAttached=true

Let's say I have a Jaggery application deployed in WSO2 AS, I want to log the user events to audit.log file via Jaggery block layer. We can log adding following code: var audit = org.wso2.carbon. CarbonConstants.AUDIT_LOG; audit.info("log message");

App Cloud SaaS application provides an user interface & REST API for app cloud users to deploy their application artifacts. The web UI is developed by Jaggery, and it invokes the REST API, which invokes following backend components to provide the app cloud solution. Docker Client provides an interface to build images and push to the docker registry. Kubernetes Client provides an interface to deploy applications in kubernetes cluster DAO provides an interface to manipulate database operations to store meta data required for App Cloud in App Cloud DB SOAP Client uses to invoke WSO2 Storage Server admin services to create databases and users WSO2 Application Server provides an hosting environment to deploy App Cloud SaaS application WSO2 Identity Server provides identity management configuring SSO with App Cloud SaaS application WSO2 Storage Server provides RSS instances for app cloud developers to store application data. WSO2 Data Analytics Serv

Considering two SAML service providers configured under the same tenant, they are by default in single sing on, so after I login in Service provider A I can use the same browser to access Service provider B without inserting my credentials again. This blog explains in details how this happened with commonauth service during the second login What happens here is: On the first login to service provider A, it stores a cookie with a name "commonAuthId" When the first request comes; DefaultRequestCoordinator.handle() [1] method invokes DefaultAuthenticationRequestHandler.handle() method, see [2] within the DefaultAuthenticationRequestHandler.handle() it invokes concludeFlow() private method [3] , that sets the 'commonAuthId' cookie via setAuthCookie() method [4] private void setAuthCookie(HttpServletRequest request, HttpServletResponse response, AuthenticationContext context, String sessionKey, String tenantDomain) throws Fram