Chapter 2

Literature Review
In this chapter, literatures related to overview of integration technology, current business
process of legacy systems, ERP and other related development technologies. It introduces the
comparison among integration approaches and comparison among ERP for the information to
decide.

2.1 Enterprise Resource Planning

2.1.1 Overview of ERP

Enterprise Resource Planning (ERP) software programs are at the cutting edge of information
systems technology. ERP (pronounced “E-R-P”) programs help to manage company-wide
business processes, using a common database and shared management reporting tools. ERP
software supports the efficient operation of business processes by integrating business
activities, including sales, marketing, manufacturing, accounting and staffing. Today’s business
people (and tomorrow’s) should understand what an ERP program can do for a company.
(Joseph Brady, Ellen Monk, Bret Wagner, 2001)

The first time of ERP is SAP which relate to software product line for the main information
system. Initial arguments were for integrated system. So, SAP can be sold only module which
the company needs. But SAP is very high cost. Then companies are still trying to find other ERP
systems. The table below shows the business functions potentially supported by ERP.

ERP Enterprise Architecture (http://kazman.shidler.hawaii.edu/619ch04.ppt, ERP)

2.1.2 ERP Advantages and Disadvantages (David L. Olson, David Olson, 2004)
1 

 
There are many reasons to adopt ERP. It offers an integrated system shared by all users rather
that a diverse set of computer applications, which rarely can communicate with each other and
which each possess its own set of data and files. ERP provides a means to coordinate
information system assets and information flows across the organization. The main benefit is
the elimination of sub organizational silos that focus on their own problems rather than serving
the interests of the overall organization. On the downside, ERP systems impose one procedure
for the entire organization, which requires everyone to conform to the new system. But the
benefits of integration are usually much greater than the costs of conformity.

Data can be entered once, at the most accurate source, so that all users share the same data
(data integration). This can be very beneficial. As the shared data are used more and by more
people, it becomes more complete and accurate. As errors are encountered, users demand
correction. Procedures are needed to ensure that changes do not introduce new errors. This
makes it harder to correct data, but again, this added inconvenience is usually well worth the
gains of data integration.

ERP systems also can provide better ways of doing things. This idea is the essence of best
practices, a key SAP system component. The downsides to best practices are that identifying
the best way to proceed with specific business functions takes great effort, and such practices
can involve significant change in how organizational members do their work. Further, as with
any theory, what is considered best by one is often not considered best by all.

ERP systems are usually adopted with the expectation that they will yield lower computing costs
in the long run. Ideally, adopting one common way of doing things is simpler and involves less
effort to provide computing support to an organization. In practice, savings are often not
realized, due to failure to anticipate all of the detailed nuances of user needs, as well as the
inevitable changes in the business environment that call for different best practices and
computer system relationships. Training needs are typically under budgeted in ERP projects.
Furthermore, these training budgets don’t usually include the hidden costs of lost productivity
as employees cope with complex new systems. The table below recaps these pros and cons of
ERP systems.

The key rationales for implementing ERP systems are:

• Technology – more powerful, integrated computer systems,

o Greater flexibility.

o Lower IT cost.

• Business practices – better ways of accomplishing tasks.

o Better operational quality.

o Greater productivity
2 

 
 • Strategic – cost advantages gained through more efficient systems.

o Improve decision making.

o Support business growth.

o Build external linkages.

• Competitive – Keep up with competitors adopting ERP. Greater cost efficiencies.

o Better customer service.

2.2 Method to implement an ERP system

A small or medium enterprise (SME) has several possibilities to implement on and ERP system
but this research will describe only development ERP software individually and Integrate Best of
Breed Choices of ERP packages.

The figure below shows how ERP can support IT process. It shows Modules in an ERP based
integration approach.

Modules in an ERP based integration approach (Thomas Herzog, 2006)

3 

 
2.2.1 Development ERP software individually

If ERP system is not cover the specific requirement, individual module will be developed and
integrated. But the development will base-on ERP framework or other favorite frameworks. A
framework is a software library that makes up reusable design for a specific class of software.
So it’s not necessary to develop system from scratch.

ERP is very interesting in aspect of changeable and reusable. Developer can use the framework
as the template for development, provided you have the source code or good interface
documentation. With this reason, developer can have opportunities to adapt the framework and
share improvement easily.

2.2.2 Integrate Best of Breed Choices

This research already reviewed about the broad concept of integration in the context of ERP
(Figure …).

Because of the many conditions for IT process, ERP becomes the first choice which companies
will think when they need the new systems. For the example of the condition below:

- The company is not big.

- The limit budget
- They want to keep standard approach like out-of-box solutions and easily maintainable
customizations.

2.3 Definition of open source

The definition of open source comes from the open source definition of the Open Source
Initiative (OSI).

According to OSI this means that software must comply to the following conditions (shorted):
1. Free redistribution, including selling or using as component without fee.
2. The Source code must be available in readable form.
3. Derived work must be allowed under the same license conditions.
4. Integrity of the author's source code (licenses may require that modifications are
redistributed only as patches).
5. No discrimination against persons or groups.
6. No discrimination against fields of endeavor.
7. Distribution of license (license applies to all whom the program is redistributed to,
closing up software is forbidden).
8. License must not be specific to a product.
9. License must not restrict other software.
10. License must be technology neutral. Licenses that conform to the above definition
can get certified by OSI and may use its certification mark.

4 

 
 11. The availability of the source code reduces investment risk as the development
cannot be abandoned easily. Furthermore you have the possibility to adapt the
software to your needs.(Thomas Herzog, 2006)

2.4 Comparison open source ERP

This section describe about the comparison of each open source ERP. This section is importance
because it provides the information for the decision to choose an appropriate ERP for the
research. The comparison table shows about the evaluation criteria for each open source ERP.

(Remark: The referenced paper use the word “Opentaps” as a synonym for “OfBiz”)

Legend:

√ yes x no
n/a not available ? unknown
+ above average ~ average - below average
(Average refers to the other evaluated open source ERP systems)

5 

 
 6 

 
 7 

 
2.5 OFBiz (not finish)

The ERP started from SAP. Many companies are using some modules from SAP. But SAP has
high cost. So, companies need to use low cost ERP software. OFBiz is also ERP system but it is
an open source. Recently, many developers are interested in OFBiz to do several contributions.
The existing systems can be integrated with OFBiz easily because OFBiz provides the service for
accessing such as web service and RMI.

2.5.1 Introduction to OFBiz (http://ofbiz.apache.org/, 2007)

The Apache Open For Business Project is an open source enterprise automation software
project licensed under the Apache License Version 2.0. By open source enterprise automation
we mean: Open Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, Open
Source SCM, Open Source MRP, Open Source CMMS/EAM, and so on.

Apache OFBiz is a foundation and starting point for enterprise solutions, be they for one
organization or one million. OFBiz can certainly be used OOTB (out of the box), but if you're
looking for something that works really well for that there are many open source projects that
do a great job there. OFBiz is great for creating specialized applications for use OOTB by other
organizations. OFBiz is also great for organizations that need more than what an OOTB
application can offer in order to grow their operations, but find the deployment and
maintenance costs of traditional enterprise systems that can handle such things to be
unreasonable or unjustifiable.

Being open source under the Apache 2.0 license and driven by a community Apache OFBiz
offers both flexibility by design and by access to code, and a solution where you're not alone
but rather can work with many others to get things done.

Apache OFBiz offers a great deal of functionality, including:

• advanced e-commerce
• catalog management
• promotion & pricing management
• order management (sales & purchase)
• customer management (part of general party management)
• warehouse management
• fulfillment (auto stock moves, batched pick, pack & ship)
• accounting (invoice, payment & billing accounts, fixed assets)
• manufacturing management
• general work effort management (events, tasks, projects, requests, etc)
• content management (for product content, web sites, general content, blogging, forums,
etc)
• and much more all in an open source package

2.5.2 OFBiz Framework introduction

8 

 
 xxxxxxxx

2.5.3 How to implement the application on OFBiz

2.5.3.1 Related technologies

2.5.3.1.1 BeanShell

What is BeanShell

BeanShell is a small, free, embeddable Java source interpreter with object scripting language
features, written in Java. BeanShell dynamically executes standard Java syntax and extends it
with common scripting conveniences such as loose types, commands, and method closures like
those in Perl and JavaScript.

You can use BeanShell interactively for Java experimentation and debugging as well as to
extend your applications in new ways. Scripting Java lends itself to a wide variety of
applications including rapid prototyping, user scripting extension, rules engines, configuration,
testing, dynamic deployment, embedded systems, and even Java education.

BeanShell is small and embeddable, so you can call BeanShell from your Java applications to
execute Java code dynamically at run-time or to provide extensibility in your applications.
Alternatively, you can use standalone BeanShell scripts to manipulate Java applications; working
with Java objects and APIs dynamically. Since BeanShell is written in Java and runs in the same
VM as your application, you can freely pass references to "live" objects into scripts and return
them as results.

In short, BeanShell is dynamically interpreted Java, plus a scripting language and flexible
environment all rolled into one clean package.(Beanshell.org)

How does BeanShell relate to OFBiz?

BeanShell can help to develop OFBiz framework by generating action or script for the screen
section actions in process layer. Normally, Screen Section Actions in OFBiz can use service *.xml
(in user interface layer), entitymodel*.xml(in data source layer) and BeanShell script(in process
layer) to create them.

2.5.3.2 The example

2.6 Java EE Technology

2.6.1 JMS API

9 

 
Java Message Service is a Java API that allows applications to create, send receive, and read
messages (Sun Microsystems). JMS API architecture consists of 4 main factors. There are
JMS provider, JMS clients, Message and administered objects.

JMS provider is the messaging system that is used by JMS client. It implements the JMS
interface and provides administrative and control features (Sun Microsystems).

JMS clients can be producer or consumer program that are written in the Java program.

Messages are the objects that communicate information between JMS clients (Sun
Microsystems).

For the Administered objects, the two kinds of JMS admixture objects are destinations and
connection factories (Sun Microsystems).

‐ Destination is the object used by a client for specifying the target and the source of the
messages.
‐ Connection factory is the object use for creating connection to a provider.It is and
instance of the ConnectionFactory, QueueConnectionFactory, or TopicConnectionFactory
interface
(Sun Microsystems).

Messaging Domains

JMS API supports both the point-to-point and the publish/subscribe domains.

Point-Point Messaging Domain is built on concept of message, queues, senders and receivers
(Sun Microsystems). Each message has only one consumer. PTP has no timing dependencies.
It means receiver can fetch the message although the client that sent message is not running.

Publish/Subscribe Messaging Domain has the concept of topic. Each message can have multiple
consumers. Pub/Sub has timing dependencies. It means receiver cannot fetch the message if
the client that sent message is not running. But JMS API solves this problem by allowing the
subscribers to create durable subscriptions which can receive message when the client that sent
the message is not active.

Message Consumption

Message can be consumed in either of 2 ways:

Synchronously: A receiver fetches the messages by calling the receiver method. During the time
that a message still not arrives, the receiver method can block. But if a message does not arrive
within a specified time limit, the receiver method cans time out.

Asynchronously: client use message listener to notify the JMS provider, to delivers the message
by calling the listener's onMessage method, when a message arrives at the destination.
10 

 
This thesis only talks about asynchronously. The example from Java EE 5 Tutorial will show
about how to write JMS API program in the kind of asynchronously message consumption.

AsynchronousConsumer.java is the consumer’s program. It needs to define JNDI name for the
related variables.

@Resource(mappedName = "jms/ConnectionFactory")

private static ConnectionFactory connectionFactory;

@Resource(mappedName = "jms/Queue")

private static Queue queue;

@Resource(mappedName = "jms/Topic")

private static Topic topic;

It needs to create connection before receiving information:

connection = connectionFactory.createConnection();

After create connection, you use it to create a session. The first argument means that the
session in not transacted (Sun Microsystems). The second means that it will be acknowledge
automatically when it successfully received the message:

session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);

And then it uses the session to create consumer. It’s up to dest variable which enter from user
which it will be either queue or topic.

consumer = session.createConsumer(dest);

That’s from the mention before, because this program is about asynchronously message
consumption, it will use the message listener:

listener = new TextListener();

After that, set the listener to consumer

consumer.setMessageListener(listener);

Finally, start the connection:

connection.start();

AsynchronousConsumer.java is the consumer’s program. It needs to define JNDI name for the
related variables. The codes are look like the consumer’s program for defining JNDI name. And

11 

 
then the producer also needs to create the connection and session. Moreover, because of it’s
the server, it needs to create the messages to sent to consumer:

TextMessage message = session.createTextMessage();

2.6.2 JNDI

JNDI is an API specified in Java technology that provides naming and directory functionality to
applications written in the Java programming language. It is designed especially for the Java
platform using Java's object model(Sun Microsystems).It keeps the information about named
Java object in any type.

2.6.3 RMI

RMI is The Java Remote Method Invocation API, or Java RMI, is a Java application
programming interface for performing the object equivalent of remote procedure calls
(http://en.wikipedia.org/wiki/Java_remote_method_invocation, Java remote method
invocation).

The example about RMI can show below:

The interface class must extend Remote interface:

package hello;
// Hello.java
import java.rmi.Remote;
import java.rmi.RemoteException?;
public interface Hello extends Remote {
public String sayHello(String s) throws RemoteException?;
}

Class HelloImpl must extend UnicastRemoteObject and implements Hello interface

package hello;
// HelloImpl?.java
import java.rmi.Remote;
import java.rmi.RemoteException?;
import java.rmi.server.UnicastRemoteObject?;
public class HelloImpl? extends UnicastRemoteObject? implements Hello
{
public HelloImpl?() throws RemoteException? { }
public String sayHello(String s) throws RemoteException? {
System.out.println("Activation form " + s);
return "Hello! I am HelloImpl?.";
}
}
12 

 
For hello server, it needs to bind the instance.

Naming.rebind("rmi://localhost/HelloServer?", new HelloImpl?());

For hello client, it will look into the name that is binding from server:

Hello h = (Hello) Naming.lookup("rmi://localhost/HelloServer?");

2.6.4 Message-Driven Bean

MDB is a kind of Enterprise bean. “…it’s similar to session bean, except it responds to a JMS
message rather than an RMI event. MDBs were introduced in the EJB 2.0 specification which is
supported by Java 2 Platform, Enterprise Edition 1.3 or higher. The message bean represents
the integration of JMS (Java Message Service) with EJB to create an entirely new type of bean
designed to handle asynchronous JMS messages.”
(http://en.wikipedia.org/wiki/Message_Driven_Bean, Message-driven bean)

Message-driven bean using topic with a durable subscription, and it also using a message
selector.

2.7 Integration Technologies

2.7.1 Approach to integration

From EAI: Approaches to Integration (Jude Perira, February 2006), he organizes the
approaches to integration as below:

1. Broker Based (Hub-and-Spoke) Approach – Centralized server is used by application to send

and receive data

IBM’s WBI Message Broker

2. Bus Based Approach – All nodes link to the communication backbone. The data is sent via
the bus to adapter. This adapter use for data transformation, translation and subsequence
routing to the receiving node.The bus architecture is different from the broker based

13 

 
 approach since the data transformation and routing is distributed in each of the application
adapters.

Bus Architecture

3. JCA Based Approach

JCA (JavaEE Connector API) is the standardize contract that allow the connection between the
legacy system. The contract parties are the backend enterprise information system (EIS), the
different application components, the application server, and the resource adapter. Prior to the
introduction of JCA, each EAI vendor provided their own proprietary interface or resource
adapter to integrate with various EIS. So a resource adapter from one vendor would be
different compared to a resource adapter provided by another (roseindia.net).
The definition from WikiPedia, “JCA is a Java-based technology solution for connecting
application servers and enterprise information systems (EIS) as part of enterprise application
integration (EAI) solutions. While JDBC is specifically used to connect Java EE applications to
databases, JCA is a more generic architecture for connection to legacy systems (including
databases). JCA was developed under the Java Community Process as JSR 16 (JCA 1.0) and
JSR 112 (JCA 1.5). As of 2006, the current version of JCA is version 1.5.”

WikiPedia also describe about the Contracts below:

The J2EE Connector Architecture defines a standard for connecting a compliant application
server to an EIS. It defines a standard set of system-level contracts between the J2EE
application server and a resource adapter. The system contracts defined by Version 1.0 of the
J2EE Connector Architecture are described by the specification as follows:

• Connection management: Connection management enables an application server to pool

connections to the underlying EIS and enables application components to connect to an
EIS. This leads to a scalable application environment that can support a large number of
clients requiring access to an EIS.

• Transaction management: Transaction management enables an application server to

use a transaction manager to manage transactions across multiple resource managers.
This contract also supports transactions that are managed internal to an EIS resource
manager without the necessity of involving an external transaction manager.
14 

 
 • Security management: Security management provides support for a secure application
environment that reduces security threats to the EIS and protects valuable information
resources managed by the EIS.

The additional system contracts defined by Version 1.5 of the J2EE Connector Architecture are
described by the specification as follows:

• Life cycle management: Life cycle management enables an application server to manage
the life cycle of a resource adapter. This contract provides a mechanism for the
application server to bootstrap a resource adapter instance during its deployment or
application server startup, and to notify the resource adapter instance during its
undeployment or during an orderly shutdown of the application server.

• Work management: Work management enables a resource adapter to do work (monitor

network endpoints, call application components, and so on) by submitting work
instances to an application server for execution. The application server dispatches
threads to execute submitted work instances. This allows a resource adapter to avoid
creating or managing threads directly, and allows an application server to efficiently pool
threads and have more control over its run time environment. The resource adapter can
control the transaction context with which work instances are executed.

• Transaction inflow management: Transaction inflow management enables a resource

adapter to propagate an imported transaction to an application server. This contract also
allows a resource adapter to transmit transaction completion and crash recovery calls
initiated by an EIS, and ensures that the Atomicity, Consistency, Isolation and Durability
(ACID) properties of the imported transaction are preserved.

• Message inflow management: Message inflow management enables a resource adapter

to asynchronously deliver messages to message endpoints residing in the application
server independent of the specific messaging style, messaging semantics, and
messaging infrastructure used to deliver messages. This contract also serves as the
standard message provider pluggability contract that allows a wide range of message
providers (Java Message Service (JMS), Java API for XML Messaging (JAXM), and so on)
to be plugged into any J2EE compatible application server with a resource adapter.

JCA Architecture (oreilly, enterprise service bus, ch10)

15 

 
From the figure above, An ESB that supports a JCA container allows applications to be plugged
into an ESB using a standard set of off-the-shelf adapters. These adapters can be made
available from the application vendors themselves, such as SAP, or from vendors who specialize
in providing adapters, such as iWay and DataDirect (oreilly, enterprise service bus, ch10).

The vendors who provide the JCA container:

‐ http://jencks.org/
‐ https://jmsjca.dev.java.net/

4. ESB Based Approach

The definition from WikiPedia, “In computing, an enterprise service bus (ESB) refers to a
software architecture construct, implemented by technologies found in a category of
middleware infrastructure products usually based on standards, that provides foundational
services for more complex architectures via an event-driven and standards-based messaging
engine (the bus).”

ESB as per Gartner definition is "a new architecture that exploits Web services, messaging
middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous
integration backbone through which software services and application components flow."(Jude
Pereira, EAI: Approaches to Integration, February 2006)

Enterprise Service Bus (Jude Pereira, EAI: Approaches to Integration, February 2006)

The vendors who provide ESB using JBI (Java Business Integration):

‐ Java.net: https://open-esb.dev.java.net/index.html
‐ Apache: http://incubator.apache.org/servicemix/home.html

2.7.2 Area of Integration Technology

16 

 
 ………..

2.7.3 Xxx

2.7.4

2.8 Recent business architecture

Before now, HTPCL used to have Asset Controlling. A responsible employee controlled all
assets in company by using Excel file. She/he did the controlling in manual. The company never
had Asset Management System. Now, all assets cannot track and retrieve information about
each. The executives cannot know about the asset information. So, benefit calculation cannot
be done correctly.

Asset controlling relate to these systems:

‐ General Ledger – Accounting, Finance

‐ Purchase Control – Procurement information

‐ Reserved Store

‐ Budget Control

‐ Marketing Asset

‐ Computer Asset

2.8.1 General Ledger

2.8.1.1 Overview

General Ledger (GL) is the main system that is used by Accounting Department. This
system manages about journals. User can post general journals, post standing journals, post
standard journals, post spread journals, reverse general journals, reverse standing journals,
reverse standard journals, reverse spread journals and past period journals. The processes are
actually about accounting processes.

2.8.1.2 System Architecture

2.8.1.2.1 Use case diagram

2.8.1.2.2 Business process

2.8.1.3 System Environment

2.8.1.3.1 Visual Foxpro

17 

 
 2.8.1.3.2 Dbase Database

2.8.2 Purchase Control

2.8.2.1 Overview

Purchase Control System is the system that is used by procurement department. The
main task is verifying the expenditure of each department to match with budget. Moreover, it
provides the utility for the information about request for ordering, ordering and receiving with
the efficient process. However, Cash bills need to send the copy to accounting department for
keeping information.

The main purpose for Purchase Control System is to develop system which supports
procurement for the related person.

2.8.2.2 System Architecture

2.8.2.2.1 Use case diagram

Figure. Purchase control system‘s use case

2.8.2.3 System Environment

2.8.2.3.1 PHP 4

2.8.2.3.2 MySQL Database

2.8.2.3.3 Apache Server

18 

 
2.8.3 Reserved Store

2.8.3.1 Overview

Reserved Store is the system that is used by Store Department. Received bills are keyed
into the system when store department received bills from procurement department. Store
department respond to distribute anything which are buy to other departments. Stock
maintenance is also important process. Before now, store department respond in asset
controlling when they distributed anything. But when a responsible human are resigned, some
store department’s process are changed, especially asset controlling process. Before now all
assets must be submitted the bill to store department, but process nowadays is not need to
pass any assets’s bills to store department, each department can order and receive assets
directly. So, store department don’t keep any information about assets in company. It means
company cannot track any information of assets.

Recently, reserved store system still is a kind of DOS system. Computer department’ve
tried to upgrade the system to visual foxpro system but it’s not finish. The plan to upgrade the
system to visual foxpro now obsolete. The new plan is to develop in java.

2.8.3.2 Business Process

2.8.3.2.1 Use case diagram

19 

 
 Figure. Reserved Store system‘s use case

2.8.3.3 System Environment

2.8.3.3.1 Foxpro for DOS

2.8.3.3.2 Dbase database

2.8.4 Budget Control

2.8.4.1 Overview

Budget Control is the system that is used by all departments. Any departments need to
key in their budget information to the system in the defined time. Each department can manage
their budget on this system. Accounting department will revise each department’s budget in
each period. Users can retrieve information about each department’s budget and overall
budgets.

2.8.4.2 System Architecture

2.8.4.2.1 Use case diagram

Figure. Budget control system‘s use case

2.8.4.3 System Environment

2.8.4.3.1 Visual Foxpro

20 

 
 2.8.4.3.2 DBase Database

2.8.5 Marketing Asset

Marketing Asset system is the system that is used by Sale Center department. Normally,
marketing asset can be controlled by sale center directly. It means ordering, buying and
keeping the assets are not necessary to be done by purchasing or store department. Sale
center respond to distribute marketing asset for each branch and keep track of any marketing
assets. However, Cash bills need to send the copy to accounting department for keeping
information.

2.8.5.1 Overview

2.8.5.2 System Architecture

2.8.5.2.1 Use case diagram

2.8.5.2.2 Business process

2.8.5.3 System Environment

2.8.5.3.1 Visual Foxpro

2.8.5.3.2 Dbase Database

2.8.6 Computer Asset

2.8.6.1 Overview

Computer Asset System is the system that is used by Computer department. The system
keeps information for only computer assets. Normally, ordering, buying and keeping the
computer assets are done by computer department itself. Each department who needs to order
computer asset must inform computer department to order. Cash bills need to send the copy to
accounting department for keeping information.

2.8.6.2 System Architecture

2.8.6.2.1 Use case diagram

21 

 
 Figure. Computer Asset system‘s use case

2.8.6.3 System Environment

2.8.6.3.1 Visual Foxpro

2.8.6.3.2 Dbase Database

22