ADempiere Rapid Development

From ADempiere
Revision as of 08:35, 24 May 2009 by Red1 (Talk) (See Also)

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

This documentation is started by Red1. You may discuss further improvements at Talk:ADempiere Rapid Development

ADempiere As An Application Framework

HorizontalApp.png
  • 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.

Application Modelling

VerticalDevelopment.png
  • ADempiere acts as a horizontal application where other or new vertical applications can reuse or sit on it.
  • Before a new application is introduced, it need to be designed and modelled accordingly that fits onto the ADempiere Framework.
  • There are various migration tools to do the final integration of legacy application data or model into ADempiere. Among them are the:
    • Import Loaders (incumbent model)
    • ADCK (XML2AD enhanced model by Trifon T.)
    • 2Pack (XML2AD enhanced model by Robert Klein - standard for migrating own apps)
    • Migration Scripts (standard for new apps)
    • OSGI Module deployment (under construction)
  • The importance at the systems design stage is to study the inherent ADempiere model and framework well enough to reuse them to the maximum and to avoid work redundancy and later complications.
  • A succesfully introduced or migrated vertical application will enjoy not only the incumbent multiple rich interfaces and application engine, but also a quantum leap into the open source services market.
  • Intending application developers must realign their Software Business Model to an entirely new one.

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

See Also