ADempiere Rapid Development
From ADempiere ERP Wiki
- Today's needs are on the fast-track. Users want an ERP within 6 months instead of 18 months.
- ERP apps have bloated to become everything to everybody and one size fits all.
- Quality large scale implementations can no longer be done by a single expert and requires open sharing among all parties.
- Speciliasation by differentiated contributors lower total cost of ownership for paying users.
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.
- 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.
- To design a new application on top of ADempiere is perhaps the hardest or biggest portion of the cost of an application development.
- Any application design is hard. The bigger it is the harder it is. The more modules to integrate, the challenge increases exponentially.
- But spend enough time planning it (50%), and enough time designing it (90%), the coding part is only 10%.
- The resulting work to code or migrate the system to is simple.
- 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 (latest version is OSGI HengSin)
- 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.
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'.
- The Reporting Engine in ADempiere (fully inherited from Compiere) is truly on the fly and hot configurable.
- In any window table with records you can click on the Report icon.
- Note the pop up report viewer with your selected single record.
- Click on the Search icon in that viewer.
- Just OK it to select all.
- Note that all records are produced.
- You can thus try to do an Advanced Search to get any report cube you want.
- You advanced preference can be saved for later use.
- Refer to this sample in E-ticketing#Reporting_On_The_Fly.
- You can reformat the fields and its arrangement easily via the PrintFormat
(refer to Figure 3)
- In the same pop up window, select the ToolsBox to zoom into the PrintFormat window
- Click on the Display Order tab
- Select those fields you do not want to appear. You can move them around in your prefered order.
- Click on the back arrow key to remove them for this report
- You can then save your new report for later use.
- Click on the Field Format tab
- You can put in further functions such as getting the total or running sum of a field with amount or countable value.
- When you exit and refresh the report is changed
- Again all changes are automatically saved in your new report definition.
- And all your customised configurations are transferable either via Log Migration scripts (prefered) or 2Pack package management.
- There is already an on-the-fly Advanced Search engine to filter any results whether it is in the display window or the reporting format.
- The boolean rules allow for any set of information imaginable.
- This saves alot of need to create any further engine or tools to produce the right range of reports.
(refer to Figure 4)
- In the Report Viewer, click on the Search icon
- Select the items and boolean rules to values needed.
- Save it with a nice name to recall whenever you want the same advanced search
At the Tab Level
- The AD Framework allows any Field in Table & Column model to have a Callout
- The Callout will do something when OnChange occurs within the field
- Action can be from reading and calculating a new value for any field in the Tab
- Calculation can be accessing any table or changing its value within the Database
- Callouts can be in Java code compiled into source or in metadata form without touching the source
- Metadata Callout allows JSR223 scripting options such as from Python, Beanshell, Groovy and perhaps Ruby as well as Java.
At The Document Level
- There is a button field that can spawn a process written in SQL or Java Code
- The process can determine an elaborate process:
- Accounts Posting
- Workflow Management
- Records Change
- At the end of the process, the button may change its state and the Tab record state is changed.