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:

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:

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.

Note

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:

16.2.5. Preset Sign In Accounts

Please refer to Section 15.2.

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.

Important

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.

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;