ATM, InterWeb, EIPE Commerce, Data Centre Solutions, ERP Software

Go to content

C:\Documents and Settings\Administrator\Desktop\bcnits\images\bcn-erp.jpg
Error File Open Error

Enterprise Applications (ERP/ CRM /MRP)
Applications Development Framework
Data Model

Is BCN-ERP for you?
Applications & Capabilities
Underlying Technologies
Developing and Deploying OFBiz

Products and Stores

eCommerce Highlights
Multiple stores
Custom catalogs and pricing
Price and Promotion Rules
Associations: upsell/crosssell/substitution
Site search and product reviews

Order Manager
Create and manage orders
Quotes: create quotes, get bids, convert to orders
Returns: create, approve, receive returns
Purchasing: multivendor,multicurrency

Inventory and Warehouse
Multiple facilities
- Receive inventory
- Track locations
- Serialized vs. nonserialized inventory
- Create shipments
- Pick & Pack
- Carrier Integration

Point Of Sales (POS)
Based on JavaPOS
Independent POS station
Webenabled synchronization with store and corporate servers

Other Applications
Blogs, wikis, surveys in Content
Billing accounts, payment gateways in Accounting
Material resource planning in Manufacturing
Affiliate, PPC campaigns in Marketing
People and Security in Party Manager

Developing Applications with OFBiz - An Overview
Before getting started with developing in OFBiz, it might be helpful first to go through the general principles of developing applications in OFBiz and compare with other frameworks you might already be familiar with. I will try to compare developing with OFBiz with traditional Java and PHP/Perl applications.
Generally, Java development processes emphasize high separation or tiering of code, which is appropriate for large development groups with separate functional teams. There are usually separate tiers for handling business logic, managing databases, and presenting results to users. Data is modeled as objects, with members for fields and get and set methods for accessing those fields. These objects are "persisted," or stored into a relational database, using a persistence framework. Typical Java applications include many libraries, classes, property files, definition files, and deployment files. The code itself is organized into separate classes, each of which is in its own file, and the class files are grouped into packages in separate directories.

PHP and Perl
PHP and Perl, by contrast, emphasize fast development and immediate results, probably by a small and integrated development team. Most Perl and PHP code is single-tiered. For example, a single page or script could parse form inputs, interact with a database, and render output. Although both PHP and Perl are object-oriented, data is usually handled with lists and maps, rather than as declared objects. Database access is handled by SQL statements directly in pages and scripts. PHP and Perl are scripting languages which are interpreted at run time, allowing incremental testing and development.

OFBiz combines the speed of PHP/Perl with the structure of Java. The overriding goal of OFBiz is to reduce the amount of code required. This is achieved by allowing the developer to create higher-level definitions of data model, business logic, and presentation and then providing with a set of generic API to work with these definitions.

For example, a common task for business applications is to create tables for storing data and write forms for updating those tables. This often requires HTML code with many repetitive formatting elements to mirror the fields of the database table. With OFBiz, the entity engine and form widget allow such forms to be created directly based on meta definitions.

Like Java, OFBiz is highly tiered and componentized. The pieces of the OFBiz framework and the OFBiz applications are in separate components, and OFBiz allows external or custom applications to be added easily. Each application is separated into view (presentation), business logic, and data model tiers.
The view tier of OFBiz is built around a Model-View-Controller (MVC) framework and decorator pattern. In PHP or CGI Perl, the visitor requests specific pages or scripts, which gather data and generate an entire page and returns it back to the visitor. In OFBiz, by contrast, a controller parses the requests first, then determines what to do. (Hence, MVC.)

The view tier is further separated into presentation (ie, HTML or XSL:FO) and view logic (ie, gathering data for a form.) Presentation documents are themselves separated into pieces, such as header, footer, leftbar, rightbar, and applilcation header, that are composed together in a "decorator" fashion.
The advantages of MVC and decorator patterns become apparent for larger applications, where the same actions and elements are repeated over and over again. OFBiz allows the reuse of design elements, view logic, and form actions, reducing the need for creating and, even worse, maintaining repetitive code.
The business logic of OFBiz applications is not tied to particular pages (as in PHP), particular objects (as in Java), or particular server requests (as in CGI Perl or Java servlets.) Rather, they are usually created as "services," which are small, reusable pieces of code that can be written in a variety of languages, including Java, Jython, beanshell, or the OFBiz minilang. Services can then be called directly from a web application, with automatic form parsing, from within other services, from declared workflows, or remotely via SOAP or RMI.

Data access, or persistence, is handled with the OFBiz entity engine, which allows data to be modeled in XML files and accessed with a single GenericDelegator object. Instances of data entries are handled as GenericEntity and GenericValue objects rather than as their own objects. Thus, there is no need to write (or generate) set and get methods or separate persistence code. Instead, working with data in OFBiz is very similar to working with lists and maps in Perl or PHP. Storing data is even simpler. There is no need to write your own SQL INSERT or UPDATE code any more--just use a .store() method.

Because most of the view layer and much (though not all) of the business logic is written in scripting languages such as beanshell or minilang, the OFBiz framework allows incremental testing and development in a style similar to Perl or PHP. Finally, because OFBiz presents an integrated stack from data model to business logic to view layer, it can be mutually self-aware. For example, changes to the data model can automatically change the services (business logic) and forms (UI) working with the data. This can significantly reduce the amount of maintenance required for an application.

Framework Highlights
Platform and DB Independent
Highly Versatile Development Style
PlugIn Architecture: add new apps easily
Mutually Aware Tiers

Java Persistence Frameworks
Model data as classes with fields and accessors
Map fields from Java to SQL
Autogenerate Java and SQL code

OFBiz Persistence Framework
Entity: small unit of data model

Key/value pairs
Related to other entities
Declared in XML file
Found by delegator
Generic class with get, set, store methods

Using the Entity Engine
Modeling the Data:
- Entitymodel.xml, entitygroup.xml
Interfacing the Database:
- Entityengine.xml, fieldtype.xml, cache properties
Accessing the Data:
- Generic Delegator
- Generic Entity / Generic Value

Business Logic: The Service Engine
Service: small unit of business logic
Central clearinghouse of business logic. “API layer”

Service Engine Highlights
Defined in services.xml
Accessed via Generic Dispatcher
Map in, Map out
Builtin transactions
Exception handling using Map fields

Services Maximize Code Reuse
Linked together in SECA or XPDL workflow
Directly plugs into controller: no parsing needed
Automated form generation

Presentation Layer

Deployment Possibilities
Single Instance


Load Balancing

Copyright © 2016 BCN Information Technology & Solutions Pte Ltd, All rights reserved. |

Back to content | Back to main menu