16.2. Cloud Development Environment

16.2.1. Information Systems Development Server

Every individual or team developer decides to develop information systems on PostERP platform has to first rent through Tera Rows official website one Debian Linux server. Tera Rows official website then sets up development environment for that server:

• Linux account dba is created.

• PostgreSQL server configuration file pg_hba.conf has this line:

  local all postgres peer map=super

  PostgreSQL server configuration file pg_ident.conf has this line:

  super dba postgres

Hereafter we assume that Tera Rows official website indicates the IP address of this server as 192.168.1.200.

Firstly, if your local machine does not have directory ~/.ssh/, then you can run command ssh-keygen -t rsa to generate one which holds several files. Then copy the content in your local machine's file ~/.ssh/id_rsa.pub, and paste its content to Tera Rows official website. After the pasting, Tera Rows official website immediately append that content to the tail of file /home/dba/.ssh/authorized_keys in your development server and all your cloud customers' servers.

From now on, you can login from your local machine as Linux account dba to that development server and all your cloud customers' servers.

In order to develop information systems on that server, take either one of the following approachs to acquire PostgreSQL super user privileges in that server:

• Please refer to Secure TCP/IP Connections with SSH Tunnels for detail.

  1. Login as Linux account dba to that server and establish a secured tunnel (port# 63333):

     ssh -L 63333:localhost:5432 dba@192.168.1.200

  2. Open another window in your local machine. In this new window connect as PostgreSQL super user postgres to PostgreSQL cluster through the secured tunnel:

     psql -h localhost -p 63333 postgres

• 1. Login as Linux account dba to that server:

     ssh -l dba 192.168.1.200

  2. Connect as PostgreSQL super user postgres to PostgreSQL cluster:

     psql -U postgres

16.2.2. Server Programs

In addition to PostgreSQL server, several server programs are installed and running in each development server and customer's server.

• development server

  • PostERP HTTP server

    This server provides services for developers' development and testing, and visitors' on-line free trials. Developers and visitors use modern browsers to run cloud version of PostERP.

  • PostERP report server

    This server generates reports requested by PostERP HTTP server.

  • desktop version of PostERP server

    This server listens to developers' thin client program requests for connections. Developers run thin client program to design report templates for their customers to generate reports using browsers.

• customer's server.

  • PostERP HTTP server

    Customers use browsers to run cloud version of PostERP. This server responds to customers' browsers' requests.

  • PostERP report server

    This server generates reports requested by PostERP HTTP server.

PostERP HTTP server caches metadata, PostgreSQL tables t2, t5, t37, t20, t30, t39, t13, t16, and t63, in order to shorten reponse time to browsers' requests. Restarting PostERP HTTP server is required in order to refresh cache for table t2. SQL commands INSERT, UPDATE, and DELETE applied to these tables automatically trigger PostERP HTTP server to refresh its respective cache. Howerver, command COPY does not have such effect. Therefore, developers are supposted to run PostgreSQL pg_notify() to tell PostERP HTTP server to refresh its specific cache after executing command COPY. Developers can type \dt t37, etc. commands in psql to display the trigger function name or rule associated with table t37. Then look into the development file trigger.sql to see how pg_notify() is called.

16.2.3. Application System Code

Everytime an information system developer requests to start a new application system, Tera Rows official webite assigns a unique number, known as application system code to that application system. For example, 1 or 5. This document takes 5 as the example application system code hereafter.

16.2.4. Cloud Database Types

Let's re-use the same example application system code "5".

Each cloud database belongs to one of the following types:

• dev5: the database on which you develop the application

  Development tasks are performed on this database in your development server. This database is automatically created and restored from PostERP base metadata database, also known as skeleton database, after you register this new application system code.

• app5: your stable database or template database

  The role of this database follows:

  Every time when a new customer requests to subscribe an instance of cloud version of PostERP from your application system code "5", Tera Rows official website then follows these steps:

  1. Locks database app5.

     During the locked period, you are not allowed to perform these jobs Section 16.3 on application system code "5".

  2. Copies database app5 to the customer's server.

  3. Unocks database app5.

     After unlocked, you are allowed to perform these jobs Section 16.3 on application system code "5" again.

  This database is automatically created and restored from PostERP base metadata database after you register this new application system code.

• try_5: your trial database

  If this database exists in your development server, PostERP server running in your development server allows world web surfers to experiment your application which operates on this database.

  Visitors may enter large number of rows into that database. Files in big sizes may also be uploaded as row attachments to your server under directory /var/www/posterp_uploads/. Therefore it might be essential to periodically drop and rebuild trial database try_5 and clean up uploaded files from directory /var/www/posterp_uploads/try_5.

  This is an example crontab to clean uploaded files:

  * * * * * find /var/www/posterp_uploads/try_5 -type f -mtime +1 -delete >/dev/null 2>&1 * * * * * find /var/www/posterp_uploads/try_5 -type f -size +5M -delete >/dev/null 2>&1

• your customers' databases

  Because you are responsible for maintaining cloud version of all your customers' databases, the aforementioned policy of access privileges Section 16.2.1 must also be applied to all your cloud customers' databases.

16.2.5. Preset Sign In Accounts

Please refer to Section 2.1.3.

The initial passwords of all accounts in databases dev5 and app5 are all NULL after these databases are cloned from the skeleton database. Cloud version of PostERP denies client signing in if t43.f4 is NULL. For the purpose of your development and testing, please manually set them with SQL commands like so: UPDATE t43 SET f4=crypt('my password',gen_salt('bf',7)) WHERE f1 IN ('admin','en','tw','cn'). Note that hash function crypt along with algorithm bf must be applied.

If any database is manually dropped and recreated, run the following SQL statements to enable function crypto: CREATE EXTENSION pgcrypto;

16.2.6. Design Reports

Designing report templates Section 17.9 can only be done using desktop client at present time.

• desktop version of PostERP running in your development host:

  Please specify at Tera Rows official website the PostgreSQL database name to which the desktop server will connect. Then restart the desktop server program on the same web page. From now on, this desktop server accepts desktop clients' connection on port 7500.

• Desktop version of PostERP client software:

  Both client and server programs can be downloaded from and run in Windows or WINE.

There are multiple reporting servers running in the host where PostERP web server also runs. These reporting servers connect as PostgreSQL role reporting to target databases and execute SQL's and generate reports. If any database or table is manually dropped and recreated, run the following SQL statements to grant essential access rights to role reporting:

GRANT USAGE ON SCHEMA public TO public;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO public;
GRANT INSERT,UPDATE ON TABLE t41 TO reporting;
GRANT INSERT,UPDATE ON TABLE t48 TO reporting;
GRANT INSERT,UPDATE ON TABLE t112 TO reporting;
GRANT INSERT,UPDATE ON TABLE t118 TO reporting;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO public;
			

For example, if table t_220 is dropped and then recreated, role reporting loses all access rights to t_220. Therefore, remember to execute this command after droping a table and then recreating it so that report server can SELECT it again:

GRANT SELECT ON TABLE t_220 TO public;
			

Likewise, if any above tables report servers need to INSERT and UPDATE is recreated, please execute the SQL commands like this:

GRANT INSERT,UPDATE ON TABLE t41 TO reporting;