U N I V E R S A L E R P - A P I F O R M A G E N T O

tim-daniel m jacobi

Evaluation of an optimal data-interchange format

Department InformatikFakultt fr Mathematik, Informatik und Naturwissenschaften

Universitt Hamburg

July - September 2012 Version 4.0

Tim-Daniel M Jacobi: Universal ERP-API for Magento, Evaluation of anoptimal data-interchange format, c July - September 2012

supervisors:Dr. Guido GryczanDr. Axel Schmolitzky

location:Hamburg

time frame:July - September 2012

As soon as questions of will or decision or reason or choice of actionarise, human science is at a loss.

Noam Chomsky

Dedicated to the loving memory of Walter Jacobi.

1919 2002

A B S T R A C T

The market of electronic commerce has experienced a significant growthsince businesses started to sell products online in the late nineties[1].More products are being sold online every year and the forecast for2012 again promises an increase in sales. The success of the existingmembers of the market encourages additional businesses to start sell-ing their products through electronic commerce which strengthensthe development even more.

Since electronic commerce is heavily dependent on the softwarethat provides platforms to manage and sell a companys products andand represent its appearance on the internet a reliable and fully func-tional software foundation is one of the most essential parts when par-ticipating in this business. In many cases the software needed for elec-tronic commerce has to be integrated in an already existing softwareenvironment the company uses for their enterprise resource planningand selling processes. This integration process can vary from com-pany to company and is often a too less considered problem whenstarting to act in electronic commerce.

This paper aims for providing and documenting a solution for thisproblem. It is the result of my occupation as a student trainee at theLemundo GmbH, Germany that will use the developed software andgained knowledge to serve their clients.

v

C O N T E N T S

i fundamentals 1

1 introduction 31.1 Problem definition 31.2 Structure of this paper 31.3 Requirements 41.4 Architectural prerequisites 41.5 Objectives 5

2 fundamental definitions 72.1 Enterprise Resource Planning Software 72.2 Electronic Commerce Software 7

2.2.1 Mode of operation 72.2.2 Software foundation 8

2.3 Application Programming Interface 82.4 Data-interchange 8

3 market analysis 93.1 Enterprise Resource Planning Software 9

3.1.1 Sage ERP X3 103.1.2 Microsoft Dynamics NAV 103.1.3 OpenERP 103.1.4 JTL 113.1.5 Faktura-XP 113.1.6 Lexware Warenwirtschaft Pro 113.1.7 Siller Intersys 113.1.8 Overview 12

3.2 Electronic Commerce Software 123.2.1 Gambio GX2 123.2.2 Magento 133.2.3 osCommerce 133.2.4 Oxid eShop 133.2.5 PrestaShop 143.2.6 VirtueMart 143.2.7 xt:Commerce 14

3.3 Connectors 143.3.1 Open ERP Connector 143.3.2 Epages for ERP 153.3.3 JTL Connector 15

vii

viii contents

3.3.4 Siller Webshop-Schnittstelle 153.3.5 OpenERP Prestashop sync 15

3.4 Systems overview 153.5 Conclusion 15

ii implementation 17

4 requirements 194.1 System requirements 194.2 Look and feel requirements 194.3 Functional requirements 19

4.3.1 Plugins 194.3.2 Attribute mapping 204.3.3 Data aggregation 214.3.4 Backup 21

5 eligible data-interchange formats 235.1 JSON 235.2 SQLite 235.3 XML 24

5.3.1 XMLReader only 245.3.2 XMLReader + SimpleXML 245.3.3 XMLReader + DOM 245.3.4 YAML 25

5.4 Benchmarks 255.4.1 Environment 255.4.2 Result analysis 265.4.3 Conclusion 26

6 design 276.1 Software design 27

6.1.1 Sketches 276.1.2 Graphical representation 276.1.3 UML Class Diagram 28

6.2 Database design 28

7 development 297.1 Development environment 297.2 Software development process 30

7.2.1 System tests 307.3 Architecture 32

7.3.1 Backend 327.3.2 Frontend 327.3.3 Interfaces 337.3.4 Entities 33

contents ix

7.3.5 Services 347.4 Technologies used 34

7.4.1 Laravel PHP framework 347.4.2 PHPUnit testing framework 357.4.3 CoffeScript scripting language 357.4.4 backbone.js JavaScript framework 367.4.5 Twitter Bootstrap CSS framework 36

iii final matters 37

8 post project 398.1 Customer evaluation 398.2 Conclusion 39

iv appendix 41

a systems design layouts 43a.1 First Sketch 44a.2 Refined Sketch 45a.3 Graphical Interpretation 46a.4 Correction 47a.5 Structural Sketch 48a.6 Examplary Mapping Sketch 49a.7 UML Class Diagram 50a.8 Database Model 51

b user interface screens 53b.1 Welcome Screen 53b.2 Plugin Management 54b.3 Backup Management 55b.4 Mapping Management 56

c benchmark results 57

bibliography 61

L I S T O F F I G U R E S

L I S T O F TA B L E S

Table 1 ERP systems overview 16Table 2 Electronic commerce systems overview 16

L I S T I N G S

A C R O N Y M S

x

Part I

F U N D A M E N TA L S

1I N T R O D U C T I O N

1.1 problem definition

When a company which plans to enter the market of electronic com-merce reaches the phase where a new software component - the elec-tronic commerce platform - needs to be integrated in the current sys-tem - most likely an enterprise resource planning platform - prob-lems arise frequently. The aforementioned entities are self-containedsoftware platforms which are designed to support the companies indifferent areas of their business. But when a company starts to ex-pand its business to the internet, all the product, client and orderrelated data needs to be in sync on both platforms furthermore thedata needs to be processed to push them to various electronic com-merce platforms like Ebay or Amazon. Hence the platforms need tobe able to communicate with each other in order to keep their datain sync. As of today there is no standardised way for those softwareentities to communicate with each other. Some of them offer an APIbut are uninformed about the specification of other APIs.

1.2 structure of this paper

This paper consists of three main parts. The first part covers the sub-jects it builds up on. It introduces the reader to the problem coveredin this paper, the theoretical and architectural requirements neededto solve the problem and the aspired outcome. Furthermore it intro-duces the reader to fundamental topics that are important to knowin order to understand the purpose and mode of planning and theimplementation covered in this paper. This is followed by a marketanalysis to show the reader what is currently available and wherethe market still lacks of products. The fundamental part closes witha study on an eligible data-interchange format which is an integralpart of the resulting software system.

The second part of this paper documents the engineering process ofthe resulting software system including its environmental and func-tional requirements as well as the design process. Furthermore the

3

4 introduction

description of the development process is included in this part whichgains the reader an insight of the development environment, the soft-ware architecture and the technologies used to implement the result-ing software system.

The third part than covers the final matters of the project whichinclude a customer evaluation and a conclusion on the whole project.

1.3 requirements

To solve the problem we need to make sure the enterprise resourceplanning and electronic commerce software systems are able to com-municate with each other. Since we only have limited ability to mod-ify the software itself in most cases and we want to be able to useanother product without much effort we need to create an abstrac-tion layer that acts as a connecting entity and is able to communi-cate with both the enterprise resource planning software and the elec-tronic commerce software.

Furthermore the connector exactly needs to know which data inone entity represents what data in the other in order to be able tomaintain steady synchronicity. The connector requires the entities toprovide an interface that it can use. Fortunately this is given by themajority of enterprise resource planning and electronic commercesoftware.

Another important requirement is the ability to aggregate the datafrom both sources and save them in an appropriate format to pushthe data to other sales platforms at any given point of time.

1.4 architectural prerequisites

In order to make the connector software able to communicate with alarge variety of enterprise resource planning and electronic commercesoftware systems it is important that the connector software is easy toextend so that it is able to adapt to the way of communication usedby a specific software system it communicates with. Furthermore thesoftware has to be scalable to be able to adjust to growth in businessa client might experience while he is running the system.

Since the electronic commerce platform is most likely to run onthe Internet it is intended to have the connector software run in thesame environment to offer the client an interface to remote controlthe softwares processes, hence it has to be built on a secure platform

1.5 objectives 5

in order to keep the clients data private. Moreover the environmentsperformance has to be fast enough and its availability high to guaran-tee that the software is responsive and almost always available to theclient. This is necessary because electronic commerce software cur-rently available operates day and night and thus has to be able tocommunicate with the enterprise resource planning software at anygiven point of time.

1.5 objectives

The aim of this project is to reflect the current state of the ma