The following is a simple example of running a native clarion win32 application as a cloud service.
For the Impatient
See it running – WazClarion (Waz – Windows Azure!)
Using the PackAndDeploy example from the Smarx Running the Mongoose Web Server in Windows Azure tutorial I have managed to successfully test and deploy a clarion application to the Windows Azure cloud service! Read on for some more info on the steps involved. Leave a comment or send me an email if you have any questions.
Install the Windows Azure SDK to your dev machine.
Step 1 – Git clone the PackAndDeploy to a dev folder.
See Step 1 in the Quick Walkthrough from Smarx.
Additionally I highly recommend following that example and making sure that your Azure SDK and emulator are setup and running correctly and get a little familiar with Azure before you start adding clarion to the mix.
Step 2 – Prepare your clarion APP
I used the “BasicBrowseAndForm” example that comes with NetTalk. Anything that can reply to HTTP requests should work fine.
There were a couple of changes to get the example working
- WebServer procedure, in ThisWebServer.Open, before parent
SELF.Port = Command(‘port’)
SELF._ServerIP = Command(‘ip’)
- WebServer procedure, in ThisWindow.Init
- In application global properties, file control tab set the access mode to ReadOnly.
Step 3 – Adjust the PackAndDeploy example to work with the clarion app
Delete all the files in the WorkerRole sub directory except for the Run.cmd
Edit the WorkerRole\Run.cmd file to look like this:
cd /d "%~dp0"
start /w web1.exe port=%PORT% ip=%ADDRESS%
Copy your clarion EXE and support directories into the WorkerRole folder. Anything in this folder gets included in the deployment package.
Step 4 – Deploy to the cloud
Use the “pack.cmd” from the PackAndDeploy example to create a package for upload and use the Windows Azure portal to deploy your application!
Step 5 – See it in Action!
Ok so it is not perfect yet, I had to tell clarion to only access the files in ReadOnly mode. You would need to look into the various storage options to fix that if you really want to use TPS, a better alternative will most likely be to use SQL server for your data needs. Error handling and diagnostics would need some forethought. There is a way to access a remote desktop session for debugging via a GUI if you want though. The pack and deploy process can probably do with some further automation too .