Best practice, test to live...

[alexmcclune]

Hi,

Is there any best practice for designing forms in a test environment before migrating to the live?

We have developed our forms on a test environment, these currently use databases/web services etc which need to be amended when migrating to the live site. At the moment migrating the forms include copying the form within the test environment and amending all the settings and resources to live before copying the copied form to the live environment. Basically each form will only have either TEST or LIVE resources attached but not both. This is a bit of a nightmare migrating as resources etc need remapped after name changes etc etc.

Now the two methods I have come up with which maybe better are:

• -> Set a variable to configure the "environment" for the form and use an if statement to call specific environment resources.

This variable is then used in a simple if statement which calls all the appropriate resources for the environment:

Code: Select all

var environment = fields.ENVIRONMENT.value;
if (environment == 'TEST'){
  //call test external resources
else{
 //call live external resources
}

• -> Set a variable to configure the "environment" for the form but actually use this variable within the external resources.

With this approach we use the word TEST/LIVE within the URL/database table names and this will mean we only need one resource for both environments and the use of the variable will determine which external resource is actually called ie:

Code: Select all

var environment = fields.ENVIRONMENT.value;
tables.DBTABLE.fetchtable;
resources.WEBSERVICE.call();

However I have encountered one problem with the latter version, our tables are currently titled as "...TEST_formpurpose" is it possible to use this in the "from" aspect of the database resource: ..dbo.&&ENVIRONMENT_formpurpose". The problem is it reads &&ENVIRONMENT_formpurpose as the form field, not just &&ENVIRONMENT.

Thanks, I hope it makes sense. Just trying to plan more efficient forms for the future.

[Jon]

Best practice is to externalize all these "environment" variables into some sort of properties file where you adjust the properties for each environment. The objective is that you should never have to change any of the forms you design to deploy them to another environment - all server-dependent variables should be externalized.

There are two ways of achieving this externalization: environment variables and property files. In this post I'm only going to talk about environment variables - let me know if you'd like to explore the property file route.

Environment Variables
These are entered in the web.xml file for the webapp on the server e.g. UfsServer/tomcat/webapps/ufs/WEB-INF/web.xml. So each server can have different values for each variable. See the online documentation Index > Using Environment Variables for details. You refer to an environment variable in the same way as a form field. Here are some examples:

Variable name (as entered in web.xml): VAR1
Environment field name in Ebase: $ENV_VAR1

Web Services Resource:
You can enter the variable in the Target URL e.g.

http://&&{$ENV_VAR1}/flights

In script code:

FPL:
set F1 = $ENV_VAR1;

Javascript:
var x= system.variables.$ENV_VAR1.value;

In texts, control properties such as URLs etc:
&&$ENV_VAR1 or &&{$ENV_VAR1}

Database Connections
Normally the database configuration parameters vary with each server e.g. target url, username, password etc.
You have a choice on how these connections are configured: you can use a pooled connection (where these parameters are configured in the Ebase Database Connection) or an application server pooled connection where they are configured in an xml file on the server. If you choose the first route - the Ebase pooled connection - you do have to adjust these on your deployed system. This is an exception to the general rule.

Database Tables
In general you do not want the environment to form part of a table's name i.e. don't call a table test_mydata or prod_mydata. Instead it's preferable to use a different schema or database system for each environment and specify this in the database connection. Then you only have one change to make.

Please ask if you have any questions.

Regards
Jon

[alexmcclune]

Thanks Jon,

I'll begin making this change now - it'll take us a while to change but I can really see the benefit in this (certainly save hours and hours in the future).

I will be configuring the environment variable in the web.xml and we will be using application server pooled connection with environments removed from the table names.

Cheers for your help in making that clear.

Alex

[dvanhussel]

Hi,

I think that a tomcat restart is necessary when new environment variables where to be added to a production server? We try to do all server maintenance/restarts between 23:00 and 08:00 and only restart the server during daytime when an incident urges us to to that.

When using a property file would that be the same?

In addition to what Jon wrote about recourses, for other settings (like urls to call from scripts) we have one single global script with JavaSctipt constants that have environment specific settings. This script is included on al forms.

Regards,

David

[alexmcclune]

That's essentially what we have just now, but as we learned the environment we made a few mistakes and I am hoping to tidy them all up now.

Tomcat restarts were necessary when editing any of the xml files for reference.

[alexmcclune]

I've managed to amend the server and convert one of our forms today, the following are the elements of the form I have found are not easily "externalised"?

1. Username/passwords built into Web Services
2. URLS in components built from HTML controls.
3. Within the html element controls (we use jquery a fair bit and some include URL's for redirection on error)
4. URL's built into HTML enabled text controls.

Three of them are likely the same sort of thing but I have tried the various different syntax's and the &&{$ENV_VAR1} is always read literally when running the form. The same goes for the jquery.

Thanks.

[Jon]

Alex,

It's an interesting list.

1. Username/passwords built into Web Services

You should be able to include the &&{$ENV_VAR1} in the username/password fields of a Web Service Resource (i.e. a web service you are calling). But not in the corresponding parameters of an Integration Service (i.e. a web service you are publishing) configured in Web Services in the designer. This is an oversight and I'll log it as a bug.

2. URLS in components built from HTML controls.
3. Within the html element controls (we use jquery a fair bit and some include URL's for redirection on error)

I don't really have an answer for these. It's possible to devise a solution using Javascript to resolve the variables, but you may decide it's just not worth the trouble.

4. URL's built into HTML enabled text controls.

These should work - you should be able to enter substitutable variables into any text.

Regards
Jon

[alexmcclune]

You are absolutely right, the only remaining problem after I went through and checked the syntax is the html controls (and html elements of other controls). We can live with this... to note the text controls just required a little syntax change - removing any quotation marks from url's -

Code: Select all

a href="url goes here/stuff"

using the variable it worked like this:

Code: Select all

a href=&&{$ENV_VAR1}/stuff

Thanks for your help. Can really see the benefit this will bring, short term pain for long term gain. I am now ready to rollout the changes to our other forms with the aim to roll those out to the live server next week sometime.