Servers

Deploying an application created with the OutSystems Agile Platform

Justin James discusses what he did right and what he wrong when deploying the application he created using the OutSystems Agile Platform.

 

Read the previous installments in the series: Getting started with the OutSystems Agile Platform, Learning the basics of the OutSystems Agile Platform, Describing the OutSystems Agile Platform Service Studio experience, and Working with the OutSystems Agile Platform's Integration Studio.

Once I had Rat Catcher at a certain level of functionality, I felt that it was time to put it someplace public for others to see it; however, this meant it was time to deploy the application. Throughout the development process, I had been performing deployments to the local server for testing purposes. I'll tell you about my experiences setting up a deployment environment for the public beta -- specifically, what I did right, and where I made a few mistakes.

When I was ready for my first public deployment, I did not fully think out or consider my infrastructure; to be honest, my staging environment is put together on the cheap. I have a very low-powered Windows 2008 R2 server with a couple of small VMs on it (one for Team Foundation Server, another as a FreeBSD mail/Web server) that is also acting as a local file server, Web server for some small Web sites, and a domain controller. In order to maximize this server's resources, I decided to deploy the OutSystems Agile Platform components directly to the server.

While this was a perfectly functional setup, it really did not fit my needs very well. The biggest issue for me is that the Agile Platform Server must be deployed on the default IIS Web site. In my experience, if this is a requirement of an application, the server should be dedicated to that task, just in case there is ever a similar requirement from another application. The Certificate Authority system on a Windows server is a great example. Do I really want to either start worrying about locking down IIS on a per-directory basis or have my CA's Web site exposed to the outside world? Probably not. So I searched for ways to avoid this requirement. At the end of the day, while I got it (somewhat) working, I was not pleased with the results. I just do not like trying to fight my systems -- it always leads to problems down the road.

So I committed to setting up another VM on the server -- this one is dedicated to being my Agile Platform server. If you have never deployed the Agile Platform on a Windows server before, don't worry... the installer handles it all for you, just like it does on the desktop. One thing I didn't like about the Agile Platform in version 4 was that the installation was a bit tricky. The team did an amazing job with version 5 and getting the install to be smooth and easy. I started with a barebones 2008 R2 installation, where all I had to do was join it to the domain, configure the NIC, and get it up-to-date with patches. The Agile Platform installer even adds the required Windows roles and services like IIS.

Once I got the VM set up, I needed a way to direct my Web traffic to it. In my current scenario, I only have one static, public IP address, which I have directed to my domain controller/physical VM host. I created a Web site on the server that was bound to the DNS names that I am using for my beta test. Then, I used the IIS URL Rewrite module to direct traffic to the VM, creating a reverse proxy (Figure A). You can see the configuration I used in the screenshot (lofn-ratcatcher.titaniumcrowbar.com is a FQDN that the VM will answer to and is bound to "Default Web Site" on the server). The entire process took me less than 10 minutes worth of effort on my end. Figure A

The URL Rewrite Module Inbound Rule needed to redirect traffic to my VM. (Click the image to enlarge.)

Once I had the VM set up, it was time to test it and configure it for use. I pointed my browser to the address for Service Center (http://fqdn.server.name/ServiceCenter) and voila it came up just as expected. This confirmed that my installation and my redirection worked correctly. I immediately performed my initial configuration of Service Center:

  • Server name
  • Email configuration
  • Change the admin password
Next, I wanted to ensure that outside visitors cannot access the Service Center. Is Service Center secure? Sure it is -- once you change the administrator password. At the same time, it is a sound security to entirely block someone who should never have access to something from even trying. Once again, URL Rewrite to the rescue. I created a new rule (Figure B) and then moved it up to take precedence over the first rule I made. Because the server is accessible by a different name internally than is visible externally, I am still able to access Service Center using the internal name for the server. Another quick test shows us that we cannot access the Service Center using the external FQDN, but we can get to it with the internal FQDN. Figure B

URL Rewrite rule to block access to the Service Center. (Click the image to enlarge.)
There is another way to approach this issue. In Service Studio, you can define any given screen to be only internally accessible; in fact, the entire Service Center is set up to be internally accessible. If you go to your Start Menu on the server to deploy to, you will find the configuration tool; from there, you can set addresses (or an address range) of your internal network (Figure C). Once this is set, any requests from outside of this range to internally restricted areas (including all of Service Center) will be blocked. This does not work well for me in my current scenario because, with the redirection, all of the requests to the Platform Server appear to be coming from the reverse proxy server; so, I would need to include my entire network except for one server in my internal range. At the end of the day, for my particular configuration, I feel that it is easier to just stick with blocking it at the reverse proxy. Figure C

The Agile Platform Configuration Tool. (Click the image to enlarge.)

With the server setup completed, it was time to deploy Rat Catcher to the new server. In Service Studio, I clicked the button for Connect To Server and typed in the internal FQDN of the server and the admin username and password. But I was then confronted with a new problem: missing references. The Service Studio project contains the code for the application itself, but not for the needed extensions. Some of the references I needed were from components downloaded from the Agile Network, and some were written by myself in the Integration Studio. I re-downloaded the ones from the Agile Network, and then opened them in Integration Studio to publish them to the new server. (I could have downloaded them from the Service Center in my local machine.) I also published my extensions to the new server. Once I did this, I was able to go back to Service Studio and publish Rat Catcher to the new platform.

This is how I did my initial deployment, yet it turns out that there is a much better way to handle deployments. In the Service Center, you can define a new solution, and its dependencies are automatically calculated for you. Once a solution is made, you can publish it to be live on the server; this will perform versioning, so you can perform rollbacks if needed. In addition, you can download the entire solution (including all the dependencies) as an OSP file to deploy to other servers. This way, you will be able to have discrete versions that can easily be deployed to other systems without needing to worry about catching the dependency trees up to date, and if needed, the OSP file can be unpacked and its parts inspected.

Now, the final test... opening Rat Catcher using the external FQDN. And lo and behold, Rat Catcher is now available to the public to test (Figure D). Please feel free to give it a try and let me know what you think. I still have a lot of work to do; for one thing, I need to integrate a payment processor into the system, and I really need to get the pages spruced up, as you can see. Figure D

Rat Catcher alive and ready for the world to try it out. (Click the image to enlarge.)

This is a start, and thanks to the Agile Platform, it went from an idea in the back of my head to public beta in a very short time as measured by man-hours (as a nights and weekends project, it still took a while looking at the calendar).

In the next installment in the series, I'll discuss some of the work I had to do to get this application ready for prime time.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

2 comments
AcacioPN
AcacioPN

I must say that the first thing that amazed me when I first knew OutSystems back in 2007 was 1-Click Publishing. I came from a world of Java + Tomcat + Eclipse + Ant and I remember the pain that it was to take 20+ minutes just to make a simple test to a new version of a page, and they desperately wait for possible compliation errors that would only appear after a huge number of manual steps. Particularly the way to make web-services (compile them, then create wars, then include wars inside jars, then copy configuration files for multiple instances, all manual & error-prone steps, ... I eventually got things more automated, but I was amazed at the time I found "click once and your web app is deployed". Still am. http://www.outsystems.com/download

verelse
verelse

Removed this comment