Talk:Sponsored Development: Replication

This Wiki is read-only for reference purposes to avoid broken links.

 This article is under construction  

How To Implement

Basically, I see two ways to implement:

1) DB Replication: using the replication provided by your DB.

• a. Advantages:
  • i. Could be more quickly implemented if you know it.
  • ii. Should work (if it's well configured).

• b. Disadvantages:
  • i. DB dependent: if you have more than one DB that support (as Adempiere case), you must configure to each database.
  • ii. Could be not easy to configure and manage.
  • iii. Could be not easy to adapt it to your needs.
  • iv. The replication features could be available with fee.

2) Replication Agent: developed by us.

• a. Advantages:
  • i. Adapted to your needs.
  • ii. Easy to change, extend and manage.
  • iii. DB independent.

• b. Disadvantages:
  • i. More hard work to implement, since you need to develop it.
  • ii. Require more testing.

So, first Question could be: What do we want?

• Option 1

• Option 2
  • +1 Vote
    • This way we have: a) DB Independence - b) Adapted to our needs. Alejandro

Stores Architecture

We have 2 possibilities:

• a) Store with one POS only: in this case the most common is the POS is server as well. Not replication required, into the Store. But we need replication between Store and Central.

• b) Store with more than one POS: here the most common is that the POS are connected to a server. In this case, we must considere to provide the POS to have a local DB. Some considerations and details here. So, here we'll need both replications:

b.1) Between POS and Local Server.

Summary:

• The POS operate connected to a Store Server (the transactions are stored into the DB of the Server).
• When the POS can't communicate with server, must commute to operate with their local DB. (the transactions will be stored in the local DB).
• When the communication be established again, all transactions (stored into the Local DB) will be stored into the database of the store server. And the master tables from local database of the POS will be updated with the changes from the server database of the Store.

b.2) Between Local Server (Store) and Central.

Detailed down.

Stores and Headquarter

Here we introduce an aditional communication case, between the Stores and the Headquarter. Some details here.

Some considerations to this case:

• The master tables will be updated only at Headquarter (one way). If any master table is updated in the store, those changes not will be updated to the Headquarter.

• This proposal was thought with some type of direct communication between the Store and the Headquarter (ADSL, Point to Point, ect). Here the replication agent will connect to both databases simultaneously (Store and Headquarter). If we want to implement the replication in different way (email, magnetic device, etc), then some changes must be done. We can think to build packages (containing the changes), to be transferring from one location to other.

• The replication agent of the store will search the changes into the Headquarter DB. This mean, the central DB will not push the changes to the stores, since you don't know when the store is on-line with the headquarter.

How to control the changes and the replication

We could evaluate the possiblitity to use a special column id to replication. I think, we can’t use the ID from each record (C_BPartner_ID as example), because we could have the possibility to introduce Duplicate Keys Errors, if in some store was added a new record to a master table (Business Partner, Products, Prices, etc). And I think we can’t prevent that they can add any record into some master table. So, an unique ID for each master table will be necessary to all Stores and Headquarter, only to replication purpose. Those numerations will be managed by the replication agent into the Headquarter. Then when the replication agents, into the store, retrieve the changed records from the Headquarter, they will search for all records into the Headquarter tables that be greater than your last number retrieved for each master table that they have. To implement this option, we must create a new column (as example, Replication_ID) into the AD_TABLE, for each master table (not will be used for transactional tables). To Think: Can we use the AD_Sequence table?.....

Note: this implementation, also will serve to implement the internal replication between the server and the POS into the store.

To Think:

• In some cases, could be need that some column don't be updated from the Central to the Store (as example some statistical columns). In this case we need to add a new column into the AD_Column table to indicate it. What do you think?

• Customer Credit Status: How we control the credit for a customer, if he buy in more than one store in a short time. Is possible to control it?