ADempiere Rapid Development

From ADempiere
Revision as of 18:12, 22 May 2009 by Red1 (Talk)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

ADempiere As An Application Framework

  • Since ADempiere's Application Dictionary resolves the need to touch sourcecode or base software to a minimum, and allow changes to be made rapidly and conveniently to not only the look and feel of the Data Model but also the Business Model, we can call it an Application Framework.
  • An Application Framework basically helps you to develop an application without starting from scratch. ADempiere already has the look and feel and many accessories resolved to work stably and marvelously. Such features and accessories need not be coded further in a fresh software design.
  • A new software to be created can just introduce its DataModel as Tables and Columns arranged within Windows and attached to Menu Trees.
  • Each User login will be controlled by its allowed Role or Roles to access or not to access certain Menu of Windows or Processes or Reports.

Data Modeling

NOTE that where the word 'must' is used would mean that it is mandatory and non-negotiable for successful implementation. 
The word 'should' would mean that it is optional but encouraged for maintainability and scalability of the system.
  • SQL scripts for each data model can be executed first in the Database. Then the AD's Table and Column can bring in those created tables into the Application Dictionary.
  • Each table must have the compulsory fields for model persistence and management within the ADempiere Framework:
    • AD_Client_ID - signifies the highest level and distinct identity that owns all the organisational activity.
    • AD_Org_ID - signifies sub-levels below and within the Client.
    • Created - signifies the time-stamp each record in this table at the time of its creation
    • CreatedBy - signifies the User_ID that creates the record
    • Updated - signifies the time-stamp each record is last updated
    • UpdatedBy - signifies the User_ID that last updated the record
    • IsActive - signifies whether the record is active or otherwise.
  • Each table name must have its primary key as its respective table name plus underscore ID. For example a new table 'Cigars' will have its PK as 'Cigars_ID'. Any erroneous naming convention that deviates from this will result in a failed model during execution.
  • Each table should have a 'value' field for search key purposes. In short 'value' is another reserved name in ADempiere's table modeling.
  • Entity Relationships between tables can be introduced by having fields that possess the table ID convention. For example another table 'Cigar Smokers' will have 'Cigar_ID' and this means that it is a Foreign Key to the 'Cigar' table. This is a loosely stated relationship.
    • The presentation of such an entity relationship is within the Window, Tab & Field setup where a sub-tab will have its its parent key linkage specified. This will tightly state the relationship but only during Window displays.
    • Such apparent master-detail relationship through this PK-FK statement is enforced during data entry where each detail line possess the parent's ID or primary key.
    • Of course you can constraint further within the database constraint setting to say that if the parent cannot be deleted while having a child still in existence.
  • Master Detail table naming should be that the Detail table has suffix 'Line' added to its name taken from the Master table. For example a 'Cigar' table can be a master table with a detail table as 'CigarLine'.

Document Modeling

Sequence Numbering

Report Modeling

Process Modeling