Cloud Server

Enabling Port 80
If you do not have an existing web server and want to run the Lianja Cloud Server on port 80 as well as port 8001:
Edit the text configuration file /etc/lianja.d/lianja.conf and change the line


Then restart the Lianja Server.
Check the ‘Enable HTTP requests on port 80’ Setting in the Lianja Server Manager:


Then restart the Lianja Server.

Amazon AppStream Update – Access Windows Apps on Chromebooks, MacBooks, Kindle Fires, and More…pps-on-devices
We will be testing this out running Lianja Desktop Apps in the Amazon Cloud and will report back our findings.

implemented in the Cloud Server.
– Cursoradaptor
– NetworkRequest
– COM/ActiveX
– Virtual tables

In the v1.2.4 release we have now made the Lianja ISAPI Extension for IIS available in the distribution.
This provides seamless integration with IIS and the ability to use https/SSL encryption.
Performance is almost as good as the native Lianja Cloud Server as we have implemented it using intelligent connection pooling.

how to bypass the login screen for the cloud server
There is an app setting to run as guest. That should prevent the login screen. If it doesn’t let me know.

Screen Shot 2014-08-15 at 1.14.23 PM

Just to make you all aware of a few changes in the Lianja v1.2 Cloud Server distribution.
1. No sample apps are included so that it can be installed for live use.
2. Port 80 is disabled by default. Port 8001 is enabled. This prevents any conflict with IIS and/or Apache.
The App Builder automatically detects what port the server is running on.
This has been done to make it easier to upgrade existing sites without having to remove the example apps.
Any Apps needing deployed should be done in the “Web App View”, “Tablet App View” or “Phone App View”.
The “Save” button in the Web App View has now been renamed to “Deploy”.
The Lianja App Builder APaaS Developer now handles 50 local/remote connections for testing your Web and Mobile Apps.
Creating a new App now has an “App Wizard” to provide a more streamlined experience.

Yes the Lianja cloud server is used with web and mobile.
The appliance has everything installed to save time.
Lianja Cloud Server is preinstalled as is guacamole.

if you need OData access you will need Cloud Server as SQL Server only supports ODBC Data access.

Whats the difference between “Lianja Sql Server” and “Cloud Server”?.. Cloud server contains “Lianja SQL Server”.. Does it have something to do with “Deploy”? Also.. Is there a routine in the App Builder to Import dbfs into “Lianja Sql Server”?
Is the “Cloud” located on my Server? I dont want to deploy anywhere outside my network.. I just downloaded and installed it.. I’ll play around with it..
Just deployed a database I created.. it appears to just copy the DBFs to C:\Lianja\cloudserver\tenants\public\data\rstock and not to “Lianja SQL Server..
I already wrote a routine to manually put database/tables in the SQL Server from VFP9..via ODBC driver… just thought The App Builder would do it also
Lianja Cloud Server is a complete App Server which has support for serving Web and Mobile Apps into a browser. It has Lianja SQL Server embedded in it so it also provides both ODBC and OData Data access.
The “Deploy” workspace in the App Builder provides the ability to deploy databases and Web/mobile Apps into the Cloud Server. This is in the “Data” workspace.
you can import dbfs into the App Builder then deploy them to the Cloud Server. The Cloud Server runs on either windows or Linux.
Lianja SQL Server only provides ODBC Data access.

Lianja Cloud Server is the server for Cloud/Web Apps running in the Lianja Web/Mobile client, OData and WebSocket Services and Dynamic Page Services (rsp/jssp pages). Lianja SQL Server is the server for third party clients using the Lianja ODBC Driver to access Lianja data. When you purchase the Lianja Cloud Server, you also get the Lianja SQL Server too.
This article in the Wiki explains how to deploy Lianja data for Lianja SQL Server access. Additional Wiki documentation for Lianja Cloud Server and Lianja SQL Server can be found here.

I see that there are “Foxpro server pages” and also “JavaScript Server Pages” A:
The jssp JavaScript Server Pages embed the V8 JavaScript engine as used by Node.js.
javascript server pages (.jssp pages) use the same JavaScript engine as node.js (Google v8 engine). It is embedded in the cloud server (cross platform). To better handle server side page requests it uses synchronous calls not async. You can also call VFP code directly from server side JavaScript.
So if you want you can have data centric JavaScript frontend and backend.
yvonne can point you to example server side pages in both LianjaVFP and JavaScript.
Wiki Code Examples

Lianja SQL Server does not handle OData calls. These are handled by the Cloud Server.
You don’t need to use virtual tables in the Cloud Server. All the SQL is generated and executed dynamically by the OData parser engine.

1. The Lianja Cloud Server is an app server. This is detailed at:…a-cloud-server
It is a web server, database server and dynamic page server combined.
It can operate on its own without apache or IIS or (available soon as per the roadmap) it can just be used as an extension to apache (module) or IIS (ISAPI plugin). All these extensions do is let it be installed as a “handler” for certain page request extensions and OData calls. Other than that it works in the same way as how .asp .php or .py server side pages work.
The subtle differences from just handling dynamic pages is that it has embedded within it the Lianja/VFP data centric scripting language which includes Lianja/SQL (Lianja/VFP dynamic server pages), JavaScript (.jssp) Server pages, and OData API using standard URL calls. You basically have the Lianja/VFP scripting language and database engine to use to dynamically generate HTML5/JavaScript pages.

2. The Lianja Cloud Server listens on both port 80 and port 8001 (by default) after installation. This allows you to develop Web Apps as “standard Lianja Apps”, view then alongside your development view “click the Web App View icon in the page header to see how it looks in a browser”. Try running the “example_webapp” or “example_webapp2” apps in chrome on your desktop and you will see what can be achieved with NoCode. Type http://localhost/apps/example_webapp/index.html into the Chrome address bar (IE11 is supported in the next v1.0.1 build). You can run the “Lianja Server Manager” from the control panel and disable port 80, then restart the service and it will not interfere with your existing IIS port usage. You would then always postfix :8001 to the URL hostname when making requests. After we make the ISAPI plugin available for IIS then requests for .rsp pages, .jssp pages, OData requests, and Lianja Web App requests will automatically be routed to the Lianja Cloud Server.

3. Our implementation of .jssp pages (and .rsp pages for that matter) are very similar to .asp and .php pages (all the PHP _request[] array etc) is made available to the dynamic page). The V8 JavaScript engine has been integrated in with Lianja/VFP. The structure of javascript server pages (.jssp files) have the same functionality (plus more) of .asp and PHP pages. You can call VFP procedures and evaluate VFP expressions from inside the javascript code of your dynamic page or you can use plain javascript — whatever you prefer.

4. Node.js typically is not used with apache or IIS. Typically this is at a much lower level whereby you create worker threads in javascript by accepting URL requests and route then to your javascript handler code. IMO Async “everything” does not fit in well with client side database apps that make a request to a server side URL that will return some HTML/JavaScript that is then injected into a dynamic area to the web page DataView that the user is currently interacting with. A web browser dispatches async (ajax) HTTP requests that are sent to an IP, inspected and routed to the actually producer of the dynamic HTML/JavaScript code. The browser then reads the response from the remote web server. There are timeouts on ajax requests (these are browser dependent) and if the server does not respond in a certain timeframe then the request fails.
If your are comparing Lianja Cloud Server with node.js then really they are two different things altogether. If you want to write in JavaScript on the backend, they both allow that. Both use the google V8 JavaScript engine in different ways. Node.js is all async operation which as i’ve mentioned is problematic for database oriented web apps. Lianja Cloud Server runs javascript code synchronous so that it can generate dynamic HTML5/JavaScript in a meaningful order so that the browser receives it in a properly structured HTML5 document format. You can for example open a database, create a “recordset” using a Lianja SQL query and then iterate over the data generating HTML5/javascript dynamically. The “introduction to Lianja Cloud Server describes how to accomplish this”. If this is all async on the server side you get into “callback hell”. Synchronous is much simpler to code for this purpose.
Another important distinction between node.js and Lianja Cloud Server is that the Lianja Cloud Server has complete javascript dynamic page processing support built-in. This is an important distinction between the two. So, a .jssp page is structured like an .asp or .php page, which has HTML5 and dynamic code execution all handled for you using the familiar code tags (and quite a few more such as codebehind).

5. You mention that you want to process millions of records and generate huge reports from a web request. What happens to the huge report when the job completes? Is this emailed or what? Obviously you would not want to display a 10000 page report in a web browser tab. If you want to handle background work on the server then Lianja Cloud Server has support for “background services” that can be written in Lianja/VFP. If you open up the “Lianja Server Manager” from the control panel you can see how these are setup. There is an example in the distro. The way these are typically used is through a “work queue table”. So your web request page handler adds a “job” (inserts a record) to your work queue table. Your background task looks at this periodically and if there are any requests it handles them and iterates this process until all jobs have completed. Obviously your “Report job scheduler” can spawn background processes to handle individual jobs. These can then email the user or notify them in some other way when the report job has completed.
On linux you would use “cron jobs” that do the same thing as described above.

I hope that provides a better understanding of what Lianja Cloud Server is and how it is used to serve Lianja Web and Mobile Apps, dynamic HTML5 page content, and handle third party data requests using OData.