Application Dictionary Layers

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

Please Improve

  • This is just trying to make sense of the power of the AD. By no means authoritative yet. Any ideas and graphics are welcome! - Red1 21:04, 25 September 2008 (EDT)
AD Model.gif


  • Basically the architecture or model of ADempiere is based on Compiere's Application Dictionary or AD Engine. It resolves the Model-View-Logic model of modern software design.
  • AD's Model Layer takes care of all the entities such as the core database table & field structure, its datatype, reference and validation rules.
  • AD's View Layer takes care of its presentation in both the Java and HTML clients without the developer needing to code a single line of extra user interface code.
  • AD's Logic Layer is where all the business logic and auxilary activity happens.
  • The software is built from the ground up with inherent capabilities namely the MULTIs features such as multi-language, multi-org, multi-currencies, and Log4Java debugging set, and powerful Java Objects such as Environment & Context, Persistence, Web and Application Service.
  • Its CRM and Webstore components are custom-built and thus do not fully rely on the AD particularly the AD Menu and AD Window.
  • The AD Framework is very important that it enforces discipline in the the software application to separate its tasks into distinct layers and allow the developer to dive straight into business functionality without distraction from the scaffolding.

At the Model Layer

  • All Table and Field structure are defined in the AD Table & Column window.
  • Each field's properties such as datatype and reference are defined in the same window.
  • Such reference can call up any resident Database table to return any value defined.
  • A field can possess a validation rule is defined in the AD Validation window.
  • Such validation can inject JavaScript, Java code or SQL script into the application to filter the returning value of a reference.
  • A field can update other fields on the window or the underlying database via core callouts. The Java framework to introduce such callouts is simply by extending the and accessing the MTab to getValue or setValue.
  • Any changes to the model such as introducing a new table to the database is done via the AD Table & Column window.
  • The AD Engine resolves the preparation of the table and field structure for the View level such as displaying via the standard user interfaces or reporting formats.

At the View Layer

  • As the Model is taken care of, the View Layer shall present the Model to the UI be it the Java Swing or HTML Clients.
  • All CRUD (create, read, update, delete) functions are automatically taken care and shall appear in the client interfaces without any further changes or effort during definition of new model changes.
  • The UI is aware of new records, mandatory fields and saving errors.
  • It allows powerful search functions and field preference setting according to the User ID.
  • The View Layer is handled by AD Menu, AD Window and AD Process & Report
  • They communicate with the earlier Model Layer efficiently.

At the Logic Layer

  • Alot of visible power of the ERP Application happens here beginning with auxilary and accesorry functions such as User Login, Role Access and Workflow reactions.
  • In a way, the Logic Layer is further separated from this Accesory portion as its own Business Logic area which the functional developer is most interested in.
  • The Accessory portion is isolated from all the others so that it can function without any bug introduced into it from the other layers. The developers are left free to modify the Application Dictionary as the business demands.
  • Logic that are not handled in the above layers are handled by Callouts and Model Classes under the control of the ModelValidator.
  • Core business logic processes such as Aging Analysis, Convert Requisition to PO or Complete Orders are handled by Java classes that are called by the AD Report & Process engine. Input parameter selection are facilitated for easy configuration by the developer without much supportive coding in the fully Object Oriented Java environment.
  • The ADempiere project has refined the logic portion of the application further by introducing:
    • Separation of extended logic from core logic
      • This is acheived by strictly extending the ModelValidator scheme to cover dynamic usage instead of just static as inherited from Compiere.
      • This is used in the Table and Column window where a 3rd tab for Table Script Validator is allocated.
    • Introduction of JSR223 Scripting in Rule Engine.
      • A callout may now utilise different programming scripting such as Groovy, Python or Ruby if compliable.
      • This gives scalability of application design and also 'developer scalability' can improve tremendously.


  • ERP is complex and an ERP Software Application can be even more complex. The role of the AD is very vital and ingenious in dealing away with as much complexity of the software components as possible to leave the users a clearer learning curve into the application.

Please See

  • ADempiere Rapid Development shows how ADempiere acts as a development framework to do fast prototyping and eventual enterprise software development.