orders from the cloud - diva-portal.org233049/fulltext01.pdf · postadress: besöksadress: telefon:...

ORDERS FROM THE CLOUD

BUSINESS INTEGRATION AS A SERVICE

Karl Hammar

MASTER THESIS 2009 INFORMATICS

Postadress: Besöksadress: Telefon: Box 1026 Gjuterigatan 5 036‐10 10 00 (vx) 551 11 Jönköping

Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom ämnesområdet informatik. Arbetet är ett led i teknologie magisterutbildningen med inriktning informationsteknik och management. Författarna svarar själva för framförda åsikter, slutsatser och resultat.

Handledare: Ragnar Nohre Examinator: Vladimir Tarasov

Omfattning: 30 högskolepoäng (D‐nivå)

Datum: 2009‐08‐21 Arkiveringsnummer:

Abstract

/ 73

Abstract

This thesis describes the development of a SOA‐based architecture for integrating large EDI‐using manufacturing companies purchasing processes with smaller non‐EDI capable manufacturing companies, using online services.

The underlying need for this project lies with the fact that these small manufacturing companies risk to miss out on business, due to their inability to communicate via the industry standard EDI format. At the same time, getting EDI‐capable involves significant investments in software licenses, connectivity services and consulting or training that these small companies may not be ready to make. The mentor company of this thesis project, System Andersson, produces resource planning software for this type of companies and would like to be able to provide them with an easy to use way of “jacking in” EDI support into their businesses, without having to make such significant investments. Ideally this feature would be developed as a standalone subscription based service that could be provided to users in such a way that their existing System Andersson software could connect to it and no further hard‐ or software would be needed on site. This EDI‐enabling should be as easy as to be entirely transparent for the end‐user companies. The task handed to the author was thus to develop an architecture for how such a subscription based service could be developed. Furthermore, in order to promote re‐use and simplify development, the architecture was to be based on SOA concepts.

As a result of the project, such an architecture has been developed. The architecture details two services for translating and storing for later delivery a number of EDI message types of the EDIFACT variety. The architecture also specifies communications protocols (SOAP over HTTPS and AS2 over HTTPS) and APIs (web services) for how to communicate with these services. These specifications can be used to implement a system that performs the necessary integration, so that the smaller companies may indeed communicate via EDI.

The fitness of the developed architecture has been tested by implementing a prototype version of such a system based on it. It has also been validated by way of comparing to how well it adheres to SOA design principles. All in all, this design appears to be quite sound and presents a working solution to the studied problem.

Sammanfattning

/ 73

Sammanfattning

Den här uppsatsen beskriver utvecklingen av en SOA‐baserad arkitektur för att bygga integration av mindre och större bolags sälj‐ respektive inköpsprocesser.

Den underliggande problemställningen är att de mindre bolagen riskerar att missa potentiella affärsmöjligheter på grund av att de inte kan ta emot ordrar och andra affärsdokument i EDI‐format, vilket de större bolagen ofta kräver. Samtidigt så kan det vara mycket kostsamt att implementera EDI‐stöd i en organisation, eftersom det ofta krävs såväl mjukvarulicenser som anslutningar till nättjänster och konsulthjälp, varför de här små bolagen kan dra sig för att investera i EDI‐kompatibilitet. Det här examensarbetets mentorföretag, System Andersson, utvecklar materialplaneringssystem för företag i segmentet mindre producerande bolag. Man har önskat se en lösning på det här problemet varvid det skulle bli enkelt för System Anderssons kunder att ”jacka in” EDI‐stöd utan att behöva ha så stora kostnader. Helst skall denna lösning fungera som en fristående online‐baserad prenumerationstjänst, till vilken System Anderssons produkter skall kunna ansluta utan att någon vidare hård‐ eller mjukvara behövs ute hos kunden. Tjänsten bör fungera så enkelt att den är helt transparent för användarna. Författarens uppgift blev alltså att utveckla en arkitektur för hur en sådan tjänst skulle kunna byggas. För att säkerställa framtida flexibilitet och premiera återanvändning av kod så skulle denna lösning bygga på SOA‐koncept.

Under projektets gång så har en sådan arkitektur utvecklats. Lösningen inbegriper två tjänster som används för att översätta respektive mellanlagra inkommande EDI‐meddelanden som följer EDIFACT‐standarden. Vidare innehåller lösningen specificationer för kommunikationsprotokoll (SOAP över HTTPS samt AS2 över HTTPS) och programmeringsgränssnitt (web services). Denna lösning kan användas för att implementera ett system som används för att integrera små och större företag med hjälp av EDI såsom ursprungligen efterfrågat.

Lösningen har testats genom att en prototyp har utvecklats utifrån den. Det har också studerats hur väl lösningen håller sig till SOA‐koncepten. Lösningen verkar på ett tillfredsställande sätt behandla det beskrivna problemet.

Acknowledgements

/ 73

Acknowledgements

The author would like to thank System Andersson for offering to mentor this thesis project. Particular thanks are owed to their head of development Andreas Käll and managing director Thomas Candemar, who have provided time for many interesting discussions as well as advice and guidance. The staff of JTH has also been very helpful throughout the project. Ragnar Nohre, the project’s mentor at JTH, and Vladimir Tarasov, examiner and main teacher of the thesis course, have both provided valuable input and discussions.

Lastly, many thanks are owed to Franz Ferdinand, Atomic Swing, Jenny, and Gordon the Dachshund.

Keywords

/ 73

Keywords

Integration, EDI, SOA, Web Services, MPS, Architecture, SOAP, AS2, BizTalk, ERP.

Contents

/ 73

Contents

1 INTRODUCTION.....................................................................................................................................12

1.1 BACKGROUND.......................................................................................................................................................12

1.2 PURPOSE / OBJECTIVES......................................................................................................................................13

1.3 LIMITATIONS ........................................................................................................................................................13

1.4 THESIS OUTLINE ..................................................................................................................................................14

2 THEORETICAL BACKGROUND ..........................................................................................................16

2.1 STRUCTURE OF THE SWEDISH MANUFACTURING INDUSTRY ......................................................................16

2.2 ELECTRONIC DATA INTERCHANGE...................................................................................................................19

2.3 SERVICE ORIENTED ARCHITECTURE................................................................................................................25

2.4 WEB SERVICES .....................................................................................................................................................29

2.5 EXISTING SOLUTIONS IN THE FIELD OF STUDY..............................................................................................32

3 METHODS................................................................................................................................................35

4 IMPLEMENTATION...............................................................................................................................36

4.1 STAKEHOLDER INTERVIEWS..............................................................................................................................36

4.2 REQUIREMENTS SUMMARIZED..........................................................................................................................39

4.3 FUNDAMENTAL SYSTEM DESIGN SUMMARY ..................................................................................................40

4.4 SERVICES IN DETAIL............................................................................................................................................42

4.5 MORE ABOUT INTERNAL COMMUNICATIONS.................................................................................................46

4.6 EXTERNAL COMMUNICATIONS EXPLORED......................................................................................................48

4.7 THE WEB SERVICE APIS AND DATA FORMATS .............................................................................................48

4.8 PROTOTYPE DESIGN DECISIONS .......................................................................................................................52

4.9 PROTOTYPE IMPLEMENTATION ........................................................................................................................55

4.10 PROTOTYPE TESTS............................................................................................................................................60

5 RESULTS ..................................................................................................................................................62

6 CONCLUSION AND DISCUSSION........................................................................................................64

Contents

/ 73

6.1 GENERALIZABILITY .............................................................................................................................................64

6.2 ARCHITECTURE AS SOA EXAMPLE ...................................................................................................................65

6.3 LIMITATIONS / POSSIBLE PROJECT IMPROVEMENTS ....................................................................................66

6.4 FUTURE USAGE SCENARIOS ................................................................................................................................67

7 REFERENCES...........................................................................................................................................68

8 APPENDICES ...........................................................................................................................................70

8.1 APPENDIX I: MESSAGE CLASSES .......................................................................................................................70

8.2 APPENDIX II: API METHOD CALLS SORTED BY MESSAGE TYPE ................................................................71

8.3 APPENDIX III: COMMUNICATION PROTOCOLS USED ....................................................................................73

8.4 APPENDIX IV: ARCHITECTURE MAP ................................................................................................................73

List of Figures

/ 73

List of Figures

Figure 1 ‐ Components of an X12 Transaction....................................................................................21

Figure 2 ‐ Example X12 850 Purchase Order.......................................................................................22

Figure 3 ‐ UN/EDIFACT PAORES Message............................................................................................23

Figure 4 – SOAP‐formatted RPC method request. .............................................................................30

Figure 5 – SOAP‐formatted RPC method response ...........................................................................31

Figure 6 ‐ System Map Version 1 ..............................................................................................................43



Figure 9 ‐ Mapping of ORDERS Message to SOAP Message ...........................................................58

Figure 10 ‐ BizTalk Orchestration of Incoming ORDERS Message.............................................59

Figure 11 – BizTalk Orchestration of Outgoing INVOIC Message...............................................60

List of Tables

/ 73

List of Tables

Table 1 ‐ Size Distribution of Swedish Companies 1968‐1993....................................................16

Table 2 ‐ Size Distribution of Swedish Manifacturing Companies 1968‐1993 .....................17

Table 3 ‐ Size Distribution of European Companies 1988‐1991.................................................18

Table 4 ‐ Comparison of Common EDI Messages...............................................................................24

Table 5 ‐ Tight Versus Loose Coupling (Banke Krafzig, Slama, p. 47) ......................................28

Table 6 ‐ Description of OrderMessage class.......................................................................................50

Table 7 ‐ Description of Invoice Message API .....................................................................................51

List of Abbreviations

/ 73

List of Abbreviations

SOA – Service Oriented Architecture

ERP – Enterprise Resource Planning

MPS – Materialplaneringssystem (Materials Planning Systems, Swedish term)

AS2 – Applicability Statement 2

EDI – Electronic Data Interchange

EDIFACT – Electronic Data Interchange For Administration, Commerce and Transport

HTTP / HTTPS – Hypertext Transfer Protocol / Hypertext Transfer Protocol Secure

API – Application Programming Interface

XML – Extensible Markup Language

Introduction

/ 73

1 Introduction The following chapter explains why this project is important for the associated company and their customers, what the project entails, and what limitations have been placed upon the project tasks. It aims to give the reader a cursory overview of the problem at hand, to provide context for the rest of the report. There is also a short outline of how the rest of the report is arranged.

1.1 Background System Andersson AB is a software corporation based in Jönköping, Sweden that produces an Enterprise Resource Planning (ERP) system called System Andersson QwickMPS, as well as various software plugin modules for this system. QwickMPS has been developed to be appropriate for use in small businesses in the manufacturing industry, and has a focus on features that are appropriate in this sector. These features, such as time and cost estimates, planning of machine usage, supplies and warehouse management, etc., all help companies increase efficiency of operations and lower costs. Apart from the system itself, System Andersson also develops and produces the terminal computers used to access the system on the industry floor.

Historically, the type of companies that use a system from System Andersson have been too small to have to concern themselves with large advanced IT infrastructures and projects. QwickMPS and the products in the QwickMPS family have therefore been designed to be very easy to use for employees without extensive IT experience. The user interfaces have been designed to be easy to access and use and in the newer versions of the terminal computers all input is performed via touch screen technology, meaning that even demands on typing proficiency have been removed.

Recently however, the demands for ever greater efficiency in the manufacturing industry have led System Andersson to realize an opportunity to add new integration features to the QwickMPS system. The idea is to add the capacity for QwickMPS to recieve industry standard Electronic Data Interchange (EDI) documents. Such a feature could benefit small manufacturers who wish to be able to accept digital orders and other business documents from their medium size customer companies (who are often in turn subcontractors to large industry companies). Currently, business communication between these types of parties is performed via fax or telephone calls. Accepting EDI documents and having them automatically imported into the small manufacturer’s QwickMPS system could save a lot of money in administration costs for both the manufacturer and the medium size customer companies.

Such a feature might also eventually open up possibilities for the small manufacturer to approach and do business with the large end‐user industry companies directly, thereby bypassing the middleman subcontractors. Such

Introduction

/ 73

direct business contact is today very unusual and difficult, due to the high degree of automation of order handling and such that the larger companies require in their business processes, which the small companies cannot handle.

Simply building and bundling an own EDI integration feature with each QwickMPS install would however probably not be a good solution. It would add a large degree of complexity to each customer install, with many new potential error sources. For instance, when the EDI standards are updated, all clients who wish to receive documents in the latest format would require software updates. It would also require that the senders and receivers of EDI documents agree upon network configuration details that might need to be changed over time, requiring occasional reconfiguration of the system. The receiver of the EDI documents would also have to let their QwickMPS server expose at least some ports or interfaces to the sender via the Internet, a configuration that poses serious security risks. Finally, the cost of developing such a solution would in the integrated feature case have to be largely covered by the initial sale of the feature. This would likely put the price of the product at a point where it might be deemed cost‐prohibitive.

It is therefore the opinion of System Andersson that it would probably be a better idea to develop such an integration feature as an online subscription service. The task assigned to the author of this thesis work is to construct an architecture for such a system, as well as a prototype system proving that the developed architecture specifications are sound. In order to simplify development and to promote re‐use of system components and a future‐proof solution, an architecture based on SOA concepts is suggested.

1.2 Purpose / Objectives The main task of the project is to develop an architecture for an online integration system connecting partners who wish to communicate via EDI documents, as described in chapter 1.1. The architecture should be based upon SOA (Service Oriented Architecture) concepts. That is, it should consist of interoperable services that are loosely coupled and that interact using open protocols and standards (for more information about SOA, the reader is advised to read chapter 2.3).

In addition, as described above, there is a demand that a prototype system be constructed according to the concepts developed in the specification. Such a prototype should be able to handle certain EDI messages and deliver them to a QwickMPS client system.

1.3 Limitations There are a few limitations on the task that have been set in discussions with System Andersson, in order to make the project achievable within the allotted timeframe.

Introduction

/ 73

Primarily, the specification should be workable enough to implement the aforementioned prototype based upon them. Thus, the main components of the system should be laid out and their intercommunication studied and discussed in depth. However, the specification does not need to encompass details on implementation level such as database schemas or the values of every field transmitted in an EDI message. The task is to develop a workable base upon which the service can be built, not to build an exact blueprint for a system.

Furthermore, the specification should not include how the QwickMPS system handles the delivered data. The QwickMPS developers will provide a wish list for methods they would like to see implemented, but studying how they interpret and load the data provided via these methods into the application is outside the scope of the task. The reason for this limitation is twofold – firstly it limits the required work for completing the task, and secondly, System Andersson are currently in the early stages of developing a new version of QwickMPS, meaning that the code handling this data import will be very much in flux during the length of the project, changing based on system design decisions which are outside the scope of this project.

The prototype should work in a lab environment using certain predefined EDI message types/schemas appropriate to a given test customer. The prototype does not have to be elegant or complete in any way, but it does have to deliver the messages under optimum conditions. Error handling and resending of messages that fail to be delivered are not required.

1.4 Thesis outline The thesis is divided into four main content chapters. Firstly there is a chapter on the theory relevant to the task at hand. In this chapter the technological concepts present in the problem context are described thoroughly, and some of the discussions from the background discussion above are revisited and expanded upon. The chapter was written in bursts at various times during the length of the project, when the concepts in question were especially present in the mind of the author. This chapter references primarily printed text on the various subjects, and to a certain degree web based content.

Following this is a chapter on the methods used during the project work. This chapter deals with how the task was achieved, different choices and designs considered during the process, problems faced and how they were overcome. The chapter has been constructed incrementally during the length of the project, detailing the latest issues and questions studied. Most sources here are from technical texts and manuals, which are often published as web pages.

Thirdly, there is a chapter detailing the results of the project. Here the final specifications and the answers to the questions posed in chapter 1.2 are presented, and the code of the prototype solution is analyzed briefly.

Introduction

/ 73

Finally there is a chapter concluding the report, discussing how well the project has gone and what conclusions can be drawn from the presented results, as well as what future work research may complement this project.

Apart from these chapters there are also the mandatory support sections, appendices, etc. It might interest the reader to know that all web sources references in this work are attached as appendixes to the report in digital form. It may however be the case that they are not present in the printed version, depending on space constraints.

Theoretical Background

/ 73

2 Theoretical Background This chapter covers some of the historical background and current trends that necessitate the work presented in the thesis.

2.1 Structure of the Swedish Manufacturing Industry

2.1.1 Company Size Distribution

In most of the industrialized world, there has since the 1970s and onward been a trend away from large companies and large units of production in favour of smaller firms and organisations. In Sweden however, this trend is not seen – as Table 1 shows, the per capita number of companies with more than 200 employees has in fact increased in the period 1970‐1990. The same is true for companies with up to 49 employees. However, in the same time period there has been a decrease in the per capita number of companies employing 50‐200 people.

Table 1 Size Distribution of Swedish Companies 196819931

If one looks at the manufacturing industry specifically a similar pattern can be seen. While the number of companies per capita has in fact decreased in this sector for almost all company sizes, relative to each other, the changes in numbers partially mirror the situation described above – the numbers of larger and smaller companies have decreased less than the number of intermediate size corporations, as displayed in Table 2. The main difference that we can see

1 Henrekson, M. & D. Johansson, ‘Institutional Effects on the Evolution of the Size Distribution of Firms’, Small Business Economics, Vol 12, No. 1 (February 1999), p. 13


/ 73

compared with the situation in the previous table is that the dividing line between relative success and relative failure in the manufacturing industry runs at 10 employees rather than 50, thus indicating that the number of companies within the brackets 10‐19 and 20‐49 employees are decreasing more than average as well.

Table 2 Size Distribution of Swedish Manifacturing Companies 196819932

For companies employing 10‐99 people, these changes over time are very much consistent with a point‐in‐time view of the size distribution of companies in some comparable European countries as displayed in Table 3. Sweden quite simply has few small industrial companies employing 10‐99 people. Henrekson and Johansson show that the reason for this is that these small companies have a hard time growing in Sweden, due to unfavourable entrepreneurial and business conditions for companies of this size.3

2 Henrekson, M. & D. Johansson, p. 14

3 Ibid., p. 18‐21


/ 73

Table 3 Size Distribution of European Companies 198819914

Why are all of these numbers and employee number brackets important or relevant in the context of this project? Well, since System Andersson have defined their customers as being Swedish companies in the manufacturing industry with 10‐50 employees, we can tell that even before the current economic downturn, these customer companies were facing unfavourable conditions and were having a tough time, especially when compared to larger companies. It is therefore logical to assume that they should show an interest in obtaining systems and technologies that would help them to offset this imbalance. The service which this project aims to develop could be such a technology, in that it would allow for small companies to be more efficient and competitive by (a) decreasing the administrative costs associated with sales and purchasing, and (b) allowing them to bid for contracts that they might previously have been unable to aim for, due to not having EDI integration capacity.

2.1.2 Supply Chains

In the Swedish manufacturing industries it is common for firms to have different sourcing and supply chain strategies depending on how critical a certain component or product is for their production, or how many suppliers there are on the market in question. It is generally the case that these companies try to achieve partnership type relationships with suppliers who provide critical or rare components, while they treat other suppliers with a bit more scepticism and keep them at arm’s length. This latter group tends to receive shorter terms on their contracts and are selected largely on price. The term used for this type of

4 Henrekson, M. & D. Johansson, p. 17

Sweden on average has the greatest number of

large industrial firms per capita among the coun-

tries compared. Here Sweden is followed closely

by Germany, but then there is a leap to Finland.

In terms of medium-sized industrial firms per

capita Sweden is about average, while it ranks

below average in the small size class. The impres-

sion that Sweden has many large but compara-

tively few small firms compared to other European

countries is strengthened when we analyze the size

distribution of firms. Sweden now ranks as

number 1 in the large size class, and the distance

to the 2nd ranking country is greater. Sweden also

has a large share of medium-sized firms according

to this definition. The share of small-sized indus-

trial firms, however, is reported to be the second

smallest among the countries included in the com-

parison.

The low number per capita and the small pro-

portion of small sized Swedish firms are particu-

larly interesting considering the analysis carried

out in the previous section. The small size class in

the international comparison includes three of the

four size classes that we named intermediate-sized

firms viz., the 10–19, 20–49 and 50–99 classes.

In the previous section it was shown that the

number of intermediate-sized firms had declined

substantially in manufacturing. Thus, the interna-

tional comparison at a single point in time is con-

sistent with the above finding of a poor

development for intermediate-sized firms.

Taken together these empirical findings raise

the question whether Swedish institutions have

been an obstacle to growth for intermediate-sized

firms (and favoured large-sized firms)? We will

investigate this question in the next two sections.

4. Some evidence on the willingness to grow

2. among Swedish firms

A number of studies have documented a weak

inclination to grow among small firms in Sweden.

For instance, Lundström et al. (1993) find that

merely 10–15 percent of the small firms expand

employment. But do small and newly started busi-

nesses want to grow? In order to shed light on this

question a number of studies are useful to look

at. Aronsson (1991) examined 535 firms estab-

lished in 1988. Three years later turnover

exceeded SEK 1 million in no more than one

fourth of the firms, and one third of them had no

full-time employee, the owner included. From

Aronsson’s study one can infer a number of

reasons why the proclivity to expand was so low

Institutional Effects on the Evolution of the Size Distribution of Firms 17

TABLE V

The average number and the size distribution of firms per million inhabitants in the industrial sector, 1988–91

(rank in parentheses)

Firms per million inhabitants Size distribution Sum

Small Medium Large Small Medium Large

Germany 1187 0(3) 144 0(2) 33 0(2) 87.0 0(7) 10.6 0(6) 2.4 0(6) 100

France 0669 (10) 084 0(9) 19 (10) 86.70 (8) 10.9 0(5) 2.40 (7) 100

U.K. 0650 (12) 075 (11) 22 0(5) 87.1 0(6) 10.0 0(7) 2.90 (4) 100

Sweden 0774 0(8) 112 0(5) 34 0(1) 84.1 (11) 12.1 0(2) 3.7 0(1) 100

Italy 1365 0(2) 077 (10) 11 (11) 93.9 0(1) 05.3 (12) 0.8 (12) 100

Spain 1055 0(5) 074 (12) 10 (12) 92.6 0(2) 06.5 (11) 0.9 (11) 100

Belgium 0678 0(9) 091 0(7) 21 0(8) 85.8 (10) 11.6 0(3) 2.6 0(5) 100

Portugal 1504 0(1) 161 0(1) 21 0(7) 89.2 0(4) 09.5 0(9) 1.3 (10) 100

Denmark 1131 0(4) 124 0(4) 21 0(9) 88.7 0(5) 09.70 (8) 1.6 0(9) 100

Luxembourg 0668 (11) 141 0(3) 26 0(4) 80.1 (12) 16.9 0(1) 3.1 0(2) 100

Finland 0787 0(7) 101 0(6) 27 0(3) 86.0 0(9) 11.1 0(4) 3.0 0(3) 100

Norway 0895 0(6) 086 0(8) 21 0(6) 89.3 0(3) 08.6 (10) 2.1 0(8) 100

Average 0947 106 22 87.5 10.2 2.2 100

Note: Small, medium, and large firms are defined as firms with 10–99, 100–499 and 500+ employees, respectively. The

geographical coverage for Germany is the former Federal Republic of Germany.

Source: Eurostat (1992, 1994), Statistics Sweden and own calculations.


/ 73

business relationship is “adversarial arm’s length with buyer dominance”, indicating quite clearly that the buyer is the one calling the shots. The seller has rather little influence over the process.5

Additionally, the promise of lower labour costs have led a lot of larger companies to source components from other countries. While this purchasing behaviour is not yet as common in Sweden as it is in the rest of Europe (a fact partially explained by the strong labour unions who oppose it here), it is projected to increase faster in the years to come. In the manufacturing industry this scenario is particularly common.6

This is the reality that the small companies previously mentioned operate in. They are under constant threat to loose business to other cheaper competitors, at home or abroad. They are dependant upon their customers, but have little possibility of influencing their customers purchasing patterns, other than by lowering prices and trying to stay ahead of the competition. This again underscores the need these companies likely have for any measure that would make them more efficient or competitive in the market.

2.2 Electronic Data Interchange Electronic Data Interchange, or EDI for short, is a generic term for the transmission of electronic documents between business partners, as well as the standards and technologies used to implement such transmissions. Typical uses of EDI include the ordering and invoice processes in large enterprises, as well as logistics management (where despatch notes are sent electronically). While information exchanges using technology such as web services might semantically qualify as being Electronic Data Interchanges, it is generally considered that when talking about EDI one is referring to a text message formatted according to one of the four established EDI standards: UN/EDIFACT, ANSI X12, TRADACOMS, OR ODETTE.

These four standards were developed at around the same time for similar purposes though in different regions or industries. The UN/EDIFACT standard is the most prevalent today, and is used around the world, supporting a large variety of business domains and documents. It’s name gives away it’s origins – the standard was developed by the United Nations. The X12 standard was developed by the American National Standards Institute (ANSI) and is mostly in use in the USA and Canada. Like the UN/EDIFACT standard, ANSI X12 is used in many different industries. The ODETTE standard is used in the European

5 Håkansson, F., T. Johansson & H. M. Missola, Sourcing Strategies and Supplier Relationships, Växjö University School of Management and Economics, 2009

6 Alajääskö, P., ’International Sourcing in Europe’, Statistics in focus, Nr 4/2009, Eurostat


/ 73

automotive industry and is developed by the Odette Organisation, and industry group representing companies on that market. TRADACOMS, finally, is used on the UK retail market.7

Each of these standards is very large and encompasses a great many message specifications used in many different business scenarios. Each message specification defines what data fields should be used in the message, those fields’ sizes, whether they are mandatory (must be present) or optional, and in what order they appear in the message. In addition to the standardised messages, it is possible for individual corporations to narrow the specifications of the messages they use further, by applying profiles of the messages. A profile is essentially a specification of a number of optional fields in the original message that are mandatory when the profile is applied. By defining a set of profiles, a company can thus define a subset of the chosen EDI standard that it wishes to use in communications, as well as specify what fields from the standard that it requires be present in each message.8

2.2.1 Message semantics

When discussing message syntax and semantics, the two most interesting EDI standards are the largest, UN/EDIFACT and ANSI X12. TRADACOMS is used solely within the UK and is considered likely to be phased out in favour of the EDIFACT standard in the future, and the ODETTE standard actually uses the EDIFACT message syntax for its messages.9

7 Swatman, P., ’Electronic Commerce: Origins and Future Directions’, Proceedings of the 1st Australian DAMA (Data Administration Management Association) Conference, Melbourne, 1996

8 Intervju med Scania InfoMate

9 SAA Consultants, The EDI Zone: EDI Guide – EDI Standards, viewed on 2009‐06‐10, <http://www.theedizone.com/edi_resources/edi_standards.html>


/ 73

Figure 1 Components of an X12 Transaction10

In X12 terminology a single EDI interchange (that is, communication session or file) transmits one or more functional groups. A functional group is a grouping containing one or several related business documents (called transaction sets). If one were to compare these concepts to physical documents, one could say that a transaction set is a business document such as a purchase order or an invoice, whereas a functional group is an envelope that holds several purchase orders that are being sent to the same supplier. The transaction sets, our business documents, in turn consist of a number of tagged segments holding the actual data. A segment can hold a single data element (such as a phone number) or multiple elements (such as a list of line items). Segments are delimited by a control character (normally a linebreak), and multiple elements within one segment are delimited by another control character (normally an asterisk). Special segments define the beginning and end of transaction sets and functional groups, such as the SE segment which indicates the end of a given transaction set or GS which indicates the beginning of a functional group. For an illustration of

10 Tallim, P. & J Zeeman, Electronic Data Interchange: An Overview of EDI Standards for Libraries, International Federation of Library Associations and Institutions, updated 1995‐04‐27, viewed 2009‐06‐10, <http://archive.ifla.org/VI/5/reports/rep4/index.htm>


/ 73

how these concepts relate to each other, see Figure 1. For an example X12 document, see Figure 2. 11 12 13

Figure 2 Example X12 850 Purchase Order14

The X12 standard has specifications for a large number of transaction sets, which are referred to by their three‐digit code number (such as purchase order which goes by the number 850, as displayed in the image). For each of these transaction sets, the required segments that make up the document in question are specified.

11 Tallim, P. & J Zeeman

12 Rawlins EC Consulting, X12 Technical Tutorial Syntax and Control, updated 2007, viewed 2009‐06‐10, <http://www.rawlinsecconsulting.com/x12tutorial/x12syn.html>

13 GXS, Inc., ANSI ASC X12 Standards Overview Tutorial, viewed 2009‐06‐10, <http://www.gxs.com/pdfs/Tutorial/Tutor_ANSI.SO_GXS.pdf>

14 Amosoft, EDI 850 X12 Example, viewed 2009‐06‐10, <http://www.amosoft.com/edi_docs/EDI_850_X12_Example.html>


/ 73

Figure 3 UN/EDIFACT PAORES Message

The EDIFACT standard is similar to X12 in many ways, to the extent that if it weren’t for the difference in tags used, one might confuse an X12 document for an EDIFACT document and vice versa. Functional groups are present in both, the transaction sets from X12 are simply renamed to messages in EDIFACT, and each such message is composed of segments, just like X12. However, there are some significant differences in the details between the two standards. To begin with, EDIFACT allows for composite data elements. Whereas, the smallest possible unit of information in X12 is the data element, an element in EDIFACT can be composed of several values separated by a component data element separator. This means that EDIFACT needs one more control character, to use for the purpose of separating such components. A second new control character has also been added, a release character used to escape occurrences of control characters within the data. Be prefixing such characters by the release character, they are ignored by document parsers. Thirdly, EDIFACT can use two different syntax levels, depending on the environment in which the EDIFACT documents are transmitted and what characters are available for use. Syntax level A disallows the use of certain characters (such as lower case letters and some special symbols) that are not possible to transmit to a telex machine. Syntax level B permits most of these characters, and for this reason cannot be used with legacy telecoms equipment such as telex. Figure 3 gives an example of an EDIFACT PAORES (Product Availability Request) message utilizing both composite data elements (separated by the colon character) and the release character (in this case a question mark).

2.2.2 Common message types

As mentioned previously, the EDI standards X12 and EDIFACT are very large and detailed. In fact, EDIFACT covers over 200 standard messages and X12 is said to


/ 73

be at least as complex.15 Not all of these messages are necessarily used by all companies. In fact, it is common for businesses to mandate use of only a few messages that correspond to their business needs. As discussed previously it is also common for companies to specify the messages they use even further, through the use of profiles. Another usage pattern is when multiple companies or an industry group decides upon a subset of messages and/or message profiles of one overarching standard to use for communications. One example of this is how the Odette group in 1990 decided that the ODETTE standard should migrate from being its own independent standard, to becoming a subset of UN/EDIFACT. 16

The most common messages used in a number of manufacturing and commerce companies studied by Fällén and Holmgren are DELINS, DELFOR, SYNCRO, FORDIS, AVIEXP, INVOIC, KANBAN and ORDERS. 17 Table 4, based on Fälldén & Holmgren as well as Progress Software Corporation and ERPGenie.COM details how these messages correspond to each other and to other X12, EDIFACT and ODETTE EDIFACT subset messages. 18

Table 4 Comparison of Common EDI Messages

Description EDIFACT X12 ODETTE subset of EDIFACT

Planning Schedule/Material Release

DELFOR 830 DELINS

Shipping Schedule DELJIT 862 SYNCRO Shipping Schedule DELJIT 862 KANBAN Ship Notice / manifest (ASN)

DESADV 856 AVIEXP

Ship Notice / manifest (ASN)

DESADV 856 FORDIS

Invoice INVOIC 810 INVOIC Purchase Order ORDERS 850 ORDERR

15 Progress Software Corporation, EDIFACT – UN/EDIFACT and UN/CEFACT Message and Segment Directory, viewed 2009‐06‐15, < http://www.stylusstudio.com/edifact/>

16 Odette International Ltd., Milestones, viewed 2009‐06‐16, <http://www.odette.org/html/about_milestones.htm>

17 Fällén, S. & A Holmgren, EDI mot leverantörer till Sandvik Coromant, Luleå Tekniska Universitet, Luleå, 1997, pp. 22‐23 & 69‐107

18 ERPGenie.COM, ANSI X12 Transaction Sets, viewed 2009‐06‐17, < http://www.erpgenie.com/sapedi/ansix12transactionsets.htm>


/ 73

2.2.3 Transmission methods

Since EDI files are stored as normal ASCII files just like any other in a computer system, transmitting them between business partners can be done in just as many ways as transmitting any other type of file. One can use FTP, SFTP, WebDAV, email (SMTP), or any other transmission method that allows the transfer of computer files. Since EDI files often hold information of significant importance however, transfer methods that provide delivery notification to the sending party are generally preferred. Using such transfer methods the sender can be sure that the file has not been corrupted or lost along the way, but that it has been delivered just as intended to the recipient.

There are a few special protocols for delivering EDI files that have been developed with this need for delivery notification in mind. The most common ones are the OFTP (Odette FTP) and AS2 (Applicability Statement 2) protocols. The OFTP protocol was developed by the Odette group, an industry group for members of the automotive industry in Europe19. While the first version of the protocol initially supported only direct transmissions between communicating partners via point‐to‐point links such as X.25 or ISDN, it has since been extended to include support for operating on top of the Internet protocol stack20. The second version of the protocol supported the TCP/IP protocols natively21.

The AS2 protocol has been developed by the IETF, following the normal Internet protocol standardization process. AS2 operates on top of HTTP, using HTTP POST operations to transfer data files packaged using MIME and (optionally) encrypted using S/MIME, implemented using standard asymmetric cryptography ciphers. AS2 is specified in RFC 413022.

2.3 Service Oriented Architecture This goal of this project is to develop an architecture based on SOA, but what does that really mean? SOA (short for Service Oriented Architecture) is a method of constructing software and information systems that aims to produce flexible, reliable and future‐proof systems. This section discusses the driving forces

19 Odette International Ltd., Milestones

20 Nash, D., ODETTE File Transfer Protocol, September 1997, viewed 2009‐07‐28, <http://www.ietf.org/rfc/rfc2204.txt>

21 Friend, I. ODETTE File Transfer Protocol 2, November 2007, viewed 2009‐07‐28, <http://www.ietf.org/rfc/rfc5024.txt>

22 Moberg, D. & R. Drummond, MIMEBased Secure PeertoPeer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2), July 2005, viewed 2009‐07‐28, <http://www.ietf.org/rfc/rfc4130.txt>


/ 73

behind SOA adoption in the industry, as well as what SOA actually means in practice.

2.3.1 SOA Drivers – Business Agility Requirements

In today’s rapid moving global marketplace the ability to adapt one’s business to meet changing demands is key. One must anticipate and preempt the competition’s moves, as well as stay on top of consumer trends and technological discoveries and inventions. The ability to handle such a changeable environment is dubbed agility, and it is, according to several sources, one of the most important traits in a successful business. The opposite of agility, inflexibility, is then obviously a bad trait for a corporation to display. It is so bad, in fact, that one source claims that it is the “mother of all business problems”, which encompasses all other problems that an enterprise may experience23. The argumentation goes a little bit like this: an agile company can change its behavior to meet any challenge it may come up against. It can change product offerings to match changing customer demand or new technologies. It can change strategy or enter or leave markets to maintain long‐term viability. It can even respond to political events or legislative challenges effectively by being prepared for change.

Whether this claim of inflexibility being the single largest problem for companies is true or not, it can be said with a high degree of certainty that agility or lack thereof is at the very least one of several very important factors for business success. Companies that are unable to change with the times and adapt to their customers’ needs go bankrupt or get bought out by more successful companies.

So, how does one in practice achieve agility in business? What does the word actually imply when you get down to it? Depending on specialization, a broad range of approaches are available, from removing leader figures and decentralizing business24 to performing business process reengineering to outsourcing non critical business functions or performing various other types of management changes. The IT department’s contribution to business agility then becomes to provide IT systems that can handle rapid changes in company strategy and policies25. It is important when discussing agility in IT to distinguish organizational business agility as discussed here from other uses of the word agility common in the IT industry, such as agile software development methods.

23 Bloomberg, J. & R. Schmelzer, Service Orient or Be Doomed!, John Wiley & Sons, Inc., Hoboken, 2006, p. 3

24 Brafman, O. & R. A. Beckstrom, The Starfish and the Spider : the unstoppable power of leaderless organizations, Portfolio, United States of America, 2006

25 Krafzig, D., K. Banke & D. Slama, Enterprise SOA, Pearson Education, Inc., Upper Saddle River, 2005, p. 2


/ 73

These methods (such as SCRUM and Extreme Programming) represent tactics for producing and delivering individual projects. Business agility on the other hand is a more strategic concept and refers to the flexibility of the whole of the organization, rather than individual development teams26.

SOA is by many sources considered to be an architecture and an approach that is well suited for developing and maintaining agile IT systems, that is, systems that flexible enough to accommodate frequent changes in business environments and policies. For this reason, the increasing need for business agility has become the main motivation driving SOA adoption.

2.3.2 What does SOA mean?

The basic idea of SOA is to try and break down large and complex systems into smaller simpler services, that one can then plug together in order to achieve the business functionality that is required. These services should be small and simple enough to be easy to develop, debug and deploy as a unit, yet advanced enough to represent a business concept or activity that makes sense. A good metric for measuring the size or complexity of a single service is to see if non‐technical businesspeople understand what the service does. If the businesspeople do not understand the business need for a particular service, it is possible that the scope of the service is in fact too narrow27. For instance, a good example of a service might be a service that handles outgoing shipments. Such a service maps well to some of the requirements of a business domain, without being large enough to be a complete general logistics system. Businesspeople could certainly understand the need for a shipping service. However, if one were to break such a service down further into even smaller services, each one handling technical details such as transmitting dispatch notices or coordinating GPS trackers, those services would probably be too fine‐grained and narrowly scoped.

That is not to say that the designed services should not be able to handle such more fine‐grained tasks. (Erl, p. 69) discusses services as collections of capabilities, grouped together by functional context. Our shipping service would very likely have capabilities for adding and removing shipments, reporting on shipments, handling dispatch notes, tracking packages by GPS (if there is a business need for this) and so forth, and depending on the needs of the organization, these capabilities might be published and accessible to other services and employees within the organization. However, these capabilities are part of the service and have no life independently of it. The code that invokes all

26 Erl, T., SOA: Principles of Service Design, Pearson Education, Inc., Boston, 2008, p. 63

27 Josuttis, N. M., SOA in Practice, O’Reilly Media Inc., Sebastopol, 2007, pp. 26‐27


/ 73

of these related features is developed, debugged and deployed as a unit within the company infrastructure.

The point of splitting systems up into services like this is to make it easier to reorganize the systems to meet changing needs, and to lessen the impact of failure within any one of the services. Another goal of using a Service Oriented Architecture is to make services reusable within multiple systems. For instance, a customer registry service could be used both within sales systems and customer support systems. All of these requirements mean that one should try to lessen interdependence between services, so that required changes or any instability in one service has as small an impact as possible on other services or the system as a whole. In order to minimize such dependencies, SOA development emphasizes the use of loose coupling between services. Service interfaces should be separate from service implementations, meaning that it should be possible to swap implementations easily without disrupting operation of the system as a whole, provided the new service implementations provide the same interfaces as the ones they replace. This is more difficult than it sounds in a distributed system where services might need to share data or implement distributed workflows. Using loose coupling implies adhering to at least some (if not all) of the principles for connecting systems listed in the Loose Coupling column of Table 5 (Krafzig/Banke/Slama p 47).

Table 5 Tight Versus Loose Coupling (Banke Krafzig, Slama, p. 47)

Level Tight Coupling Loose Coupling

Pysical coupling Direct physical link required

Physical intermediary

Communication style Synchronous Asynchronous Type system Strong type system (e.g.

interface semantics) Weak type system (e.g. payload semantics)

Interaction pattern OO‐style navigation of complex object trees

Data‐centric, self‐contained messages

Control of process logic Central control of process logic

Distributed logic components

Service discovery and binding

Statically bound services Dynamically bound services

Platform dependencies Strong OS and programming language dependencies

OS‐ and programming language independent

All of the rows in the table are important when developing SOA type solutions. However, in the interest of brevity only a few rows are discussed here. The


/ 73

interested reader is strongly encouraged to study Banke, Krafzig and Slama further.

The first row deals with physical coupling of services (unfortunately this is a bit of a misnomer – we are not discussing Ethernet level wire protocols here, but rather how services communicate on a rather abstract level). The row points to the fact that communication in loosely coupled systems most often is performed using a message oriented middleware (MOM) as an intermediary communications bus, rather than using direct connections between services. This makes it easier to swap out individual services without rewriting too much code, since the services do not directly rely on one another. If one were to swap out this MOM one would of course need to modify a lot of code, but hopefully this is a less common occurrence.

Another important line in the table above is the one that deals with interaction patterns. In a tightly coupled system it is not unusual to have a common object model for all involved services or components that make up the system, which means that complex deeply nested objects can be passed around the system easily. This obviously introduces many interdependencies, as all services rely on identical data representations, and if one’s needs for one of the services changes, the entire object model used by all services will have to be updated. In a loosely coupled system this is frowned upon, and simpler data‐centric messages are used as far as possible.

Finally, a SOA system should be as independent as possible of any particular operating system or programming language. Since interfaces and implementations of services should be separated and implementations be interchangeable, the stability and usability of the interfaces becomes very important. It is therefore against such interfaces that one should develop, rather than against any particular implementation in any particular programming language or environment.

2.4 Web Services While Service Oriented Architectures can be developed using a number of technologies and interconnect methods, arguably the most common of these is family of technologies known collectively as Web Services. This chapter introduces web service technologies and some related concepts.

2.4.1 Overview

Web services are software components that are designed to be accessed over a network using standardised open protocols operating on top of the HTTP protocol traditionally used for transmitting web pages. These services have interfaces defined and published in the strictly defined WSDL format, which allows other software components (“service consumers”) to interpret such an interface and use the methods provided by the corresponding service. Interaction


/ 73

with the service is normally performed by way of SOAP messages that hold requests to or responses from the service, in typical RPC (Remote Procedure Call) fashion.

There are a number of other technologies that provide remote invocation of code in similar manners, for instance CORBA, Microsoft’s DCOM, and Java‐RMI. However, none of these technologies have seen as widespread adoption as web services, which are supported by more or less every major programming language on the market, either natively or through the use of extension libraries.

2.4.2 SOAP

The SOAP protocol is a specification for exchanging structured data between systems and services. SOAP uses XML as its message format, meaning that SOAP messages are essentially XML messages following a certain SOAP‐specific schema. Apart from the message format, the SOAP protocol also specifies various other details necessary for establishing communications, such as bindings to underlying transport protocols, message exchange patterns, and how extensions to the protocol should be handled.

While HTTP is the most commonly used transport protocol for SOAP messages, SOAP also supports binding to SMTP or the more uncommon AMQP or JMS protocols. In all of these cases, SOAP operates one level above the application level protocol in the network stack, which means that the protocol draws more overhead than had it been implemented as its own application protocol.

28

The choice of using XML as its message format means that SOAP is fairly verbose, as illustrated by Figure 4 (in this figure, the namespace declarations have been omitted for brevity, so that in real life, this message would be even larger). While this makes the protocol easy to read and interpret for humans, it also means that

28 Snell, J., D. Tidwell & P. Kulchenko, Programming Web services with SOAP, O’Reilly, 2002, p. 25

<s:Envelope xmlns:s="..."> <s:Body> <checkStatus xmlns="..." s:encodingStyle="http://www.w3.org/2001/06/soap-encoding"> <orderCode xsi:type="string">abc123</orderCode> <customerID xsi:type="string"> Bob's Store </customerID> </checkStatus> </s:Body> </s:Envelope>

Figure 4 – SOAPformatted RPC method request.


/ 73

automatic parsing and interpretation of SOAP messages by software can be relatively computationally expensive.

A SOAP message consists of an envelope containing a header section and a body section. The header holds metadata fields and protocol data, whereas the body contains the message that is being transmitted. In a web service scenario, typically a SOAP message would be sent into the service with a body holding service parameters, and the service would respond with a SOAP message with a body holding the response.

Figure 4 and Figure 5 illustrate this scenario for a call to a method with the signature String checkStatus(String orderCode, String customerID); that has been published as a web service. The call in question is invoked as: result = checkStatus("abc123", "Bob's Store"), and the actual messages that are sent down the wire are the ones displayed in the figures.29

30

2.4.3 WSDL

Web Service interfaces are published in the WSDL format, short for Web Service Description Language. By parsing such a published WSDL file a service consumer can learn how to call the service from which the WSDL file was generated. WSDL files are commonly published to the web in the same directory as the service implementation, but can be delivered to the service consumer just like any other file via email, FTP, or any other transfer mechanism.

The WSDL format is rather complex and “heavyweight”, for which reason the whole of the format is not described here. The essentials primitives described in a WSDL file are, however:

29 Ibid.

30 Ibid.

<s:Envelope xmlns:s="..."> <s:Body> <checkStatusResponse s:encodingStyle="http://www.w3.org/2001/06/soap-encoding"> <return xsi:type="xsd:string">new</return> </checkStatusResponse> </SOAP:Body> </SOAP:Envelope>

Figure 5 – SOAPformatted RPC method response


/ 73

• Service – An envelope that represents the service as a whole. Can contain multiple operations.

• Port – Defines a connection point for interacting with the service (basically, an URI on which the service listens)

• Binding – Ties a number of operations to a given service, as well as a transport protocol.

• Operation – In programming parlance, a method. Tied to input and output messages.

• Message – Defines the required schema for any request or response messages used in the service, i.e. what fields must be present in any SOAP messages sent to/from the service.

2.5 Existing Solutions in the Field of Study

2.5.1 VAN providers

The EDI formats were developed before the widespread business adoption of the Internet or other types of always‐on network connections. The prevailing method of data transfer at this time was via dial‐up modem connections, which were quite costly to operate. In this environment, the most common way of sending and receiving EDI documents were through Value Added Networks, or VANs. The VANs provided a number of services to facilitate EDI communications between businesses. Among the services provided were (and still are, to the extent VANs are used):

• Mailboxes – Provides storage of messages that cannot be delivered immediately.

• Protocol conversion – Provides translation and mapping between different EDI dialects, so that companies utilizing different EDI standards can still communicate. Can also sometimes be used to translate to entirely different formats, such as XML, E‐mail, fax, etc.

• Security – Provides auditing and backup of transferred messages, as well as usage reports and other such features.

These VANs were accessed via modem connections or other forms of Wide Area Networks (WANs), often owned and operated by the VAN operators. The VAN operators also often provided the mapping software that translated the output from their clients’ systems into EDI format. In this way, the VAN operator provided everything that their clients needed to use EDI for business‐to‐business communications.31

31 Barnes, S., Ecommerce and vbusiness, Elsevier, 2007, p. 296


/ 73

However, these VAN services were often rather expensive, both in terms of initial setup, monthly cost, and per‐transaction fees32. With the breakthrough of the Internet and the increased availability of cheap network connections, it appears that usage of VAN services has declined, in favour of direct connections between parties, either over the internet or via services such as X.25 or ISDN. The most well known Swedish VAN operator still in business is Strålfors, a subsidiary of Posten AB, formerly the Swedish Post Office.

2.5.2 Web-EDI

Despite not needing to use a VAN any longer, EDI is still quite expensive for small companies to implement (which is the main motivation behind this thesis project). Some larger companies (for instance Husqvarna and Scania) wishing to make it easier for their small suppliers to use EDI have therefore developed web‐based EDI solutions. These Web‐EDI solutions commonly consist of a web page through which the supplier logs in with a username and password, and from which they can retrieve EDI messages such as orders from the company hosting the Web‐EDI solution. Often, these web systems are advanced enough to display the EDI document in a human understandable format, so that the supplier in question can then enter for instance order details into their own systems simply by copying and pasting.

The downside to using Web‐EDI systems is that they still require a lot of manual work, that a fully automated EDI solution does not. The supplier has to sit down at his terminal and use his web browser to go to a certain page, enter authorization credentials, and then copy every order (or other relevant document) into his own system. This work is then repeated for every single customer that the supplier has Web‐EDI access to. This also leaves a lot of room for error, since it is a manual process. For instance, the wrong data could be copied into the wrong field. Finally, while some of these Web‐EDI solutions support the sending of EDI documents (such as invoices or despatch notices), many do not, meaning that a lot of time‐consuming communication still has to take place out‐of‐band.

2.5.3 Watson Research Center Method

Another take on the Web‐EDI method was proposed by a group of researchers at the Watson Research Center in a 1999 paper. The idea was to use the then popular technology of embedded Java applets to build a Web‐EDI type solution. A

32 Fu, S., J. Chung, W. Dietrich, V. Gottemukkala, M. Cohen, & S. Chen, ‘A Practical Approach to Web‐based Internet EDI’, Distributed Computing Systems, International Conference on, 1999 ICDCS Workshop on Electronic Commerce and Web‐Based Applications, 1999, pp. 53.


/ 73

supplier receiving EDI orders from a customer would then log into the customer’s server with a web browser and retrieve both the EDI order document and a Java applet. The Java applet would be used to display the order in a human readable format (along with the possibility of replying to it with an invoice), as well as for forwarding the EDI file to the suppliers back end systems.33

With the development of modern web application technology (AJAX, DHTML, web services, etc), most of the motivations for using a specific language technology such as Java applets for this purpose is gone. Any sufficiently advanced web application toolkit and programming language could be used to build such a solution for reading and responding to EDI documents, and the export of EDI documents into backend systems could most likely be performed using web service technology. However, the Watson Research Center method is interesting nonetheless, as an early example of the viability of web applications in this field.

33 Ibid.

Methods

/ 73

3 Methods This project is largely exploratory in nature. Not only is a solution to the problem of business integration for the small enterprise required, but the problem itself needs to be explored and studied, in order to learn what the requirements of the involved parties are. Thus, in order to provide input for the system requirements, a number of interviews are to be conducted with relevant stakeholders. These stakeholders will primarily be large and small businesses using the system, but also co‐workers at System Andersson who are interested in developing it. The architecture will be developed in accordance with these system requirements.

Apart from these requirements that stem from interviews with stakeholders, a study of existing solutions within the relevant fields (SOA and Business Integration) is necessary. While it is possible that there is little material dealing extensively with both of these topics at once, there must certainly be a breadth of material available on each one separately. The studies of these topics are performed as part of the general background theory studies, and are detailed in chapter 2.

Based upon both the system requirements and the study of existing alternatives, a system architecture is then to be developed. The development process and architectural choices made should be described, discussed and motivated. The resultant architecture should specify the services required within the system and how these services interact, on a level that is specific enough that an implementation of the architecture can be performed by a third party. The architecture should be validated by way of studying how well it compares with the developed requirements and how well it adheres to SOA design principles.

Based upon this architecture, a prototype is also to be developed. The prototype should be used to test whether some integration tasks can be performed as intended, such as for instance, whether a limited number of message types can be passed back and forth through the system. This provides an additional real world test of the architecture.

The results of the project consist of both the architecture and the prototype, and the success or failure of both parts of the project are to be discussed and measured in the results section of the project report.

Methods

/ 73

4 Implementation This chapter deals with what actual work was performed as part of the project and what challenges were met and overcome in the process.

4.1 Stakeholder Interviews In order to learn what standards are in frequent use and will need to be supported by the system, several interviews with representatives of various industries have been performed. The interviews have attempted to find answers to the following questions:

1. How would users (both senders and receivers of EDI documents) of the system like the system to behave?

2. What use do they expect to get out of a system such as the proposed in terms of efficiency gains?

3. What are the users’ security demands, how critical are these, and how does one build a system that lives up to them?

Apart from the interviews detailed below, several attempts have also been made to get in touch with smaller manufacturing companies, who might fit the bill as end users or subscribers to this system. However, there has been very little interest shown by this category of companies and I have been able to perform no interviews with such stakeholders. This is extremely unfortunate, as it means that an important (perhaps the most important) point of view regarding the system’s features, costs and other aspects are not represented in this report.

4.1.1 The Car Industry

The car and vehicles industry is represented by Scania and Volvo. For Scania, an interview was performed at their Södertälje headquarters with Bengt Andersson of Scania InfoMate. For Volvo, questions and answers were emailed back and forth with Lars Cederholm of Volvo IT. Based on the interviews with these companies, it is apparent that EDI usage is common in the car industry and that EDI usage patterns are fairly similar, at least between these two companies. Both of them require their suppliers to be able to communicate via EDI messages, both prefer the use of the ODETTE standards and the OFTP file transmission protocol, and both have future plans to start using OFTP2 over the Internet rather than the traditional point to point connections previously used.

While ODETTE and OFTP are the preferred formats and transport protocols, both companies are in fact rather flexible when it comes to the standards used, and can in fact accept UN/EDIFACT messages as well as ODETTE ones. Scania is of the opinion that it would be strategically beneficial to be able to use the AS2 transmission standard as well as OFTP2 in the future, in order to speed up initialization of new business relations with partners that do not have OFTP solutions in place but have existing AS2‐based systems. Volvo expects to see

Methods

/ 73

usage of AS2 primarily in their North American sites, but aim have the capacity to use this protocol in other locations as well provided that their business partners require it.

It is also interesting to note that neither of these two companies requires order documents to be transmitted via EDI. Since they both mainly use EDI for goods delivered in bulk and used for the production of cars and trucks, they prefer long running purchase agreements that are negotiated and signed on real paper, outside of the automatic computer systems. EDI is instead used for delivery schedules, despatch advice notices, and other activities that require day‐to‐day data transmission. Volvo requires new suppliers who wish to use UN/EDIFACT to implement messages for Delivery Schedule (DELFOR), Despatch Advice (DESADV) and Invoice (INVOIC).34 Scania requires their suppliers to support at least the Delivery Instruction (DELINS/DELFOR) and Despatch Advice (AVIEXP/DESADV) Odette subsets of UN/EDIFACT.35

With regards to the security aspects of the solution, there are two different issues that need to be addressed. One is the confidentiality of the transmitted and processed messages, and the other is the reliability of the system. The first issue is becoming slightly more complex for these companies now that they are planning to transmit messages over the open Internet rather than through point‐to‐point connections. This is however mitigated by the fact that both of the considered transport protocols (OFTP2 and AS2) have built‐in encryption support, meaning that hopefully all that should be needed is a little bit of extra setup and the cost of a signed encryption certificate.

The importance of the second issue, the reliability of the system, can be seen easily when one considers what type of information is transmitted via the service. It is mostly messages dealing with delivery schedules and despatches, which are vital for keeping the supply chain of these companies working properly. If the factory assembly line grinds to a halt because a required assembly component is missing, this could cost many millions of euro in lost productivity. For this reason, Scania thinks it best to have all business responsibilities specified in binding contracts before connecting a service such as the proposed. It is also important to Scania that the receipts that are part of the transfer standards are respected, so

34 Volvo, edifact: Volvo Information Technology – EDI, viewed 2009‐06‐15, <http://www.volvo.com/volvoit/edi/en‐gb/Europe/specifications/edifact/edifact.htm>

35 Scania, Frequently Asked Questions, Scania Supplier Portal, viewed 2009‐06‐15, < https://supplier.scania.com/wps/portal/GSP/kcxml/?WCM_GLOBAL_CONTEXT=/wps/wcm/connect/p.gsp~WS/p.gsp.1.Miscellaneous~G1/p.gsp.2.EDI~G2/p.gsp.3.EDI+Europe~G2/p.gsp.4.FAQ~G2/>

Methods

/ 73

that the sending party knows with absolute certainty that the receiving party has in fact received the whole unaltered message.

So, to summarize the answers to the aforementioned questions:

1. Both interviewed companies would like for their EDI partners to be able to handle a variety of EDIFACT/ODETTE messages transferred via the OFTP2 protocol or possibly in the future the AS2 protocol.

2. Both companies mandate the use of EDI for their suppliers already today, meaning that the main gain for them with this system is not one of increased efficiency, but rather of an increased choice of possible suppliers.

3. Both companies are considering transport protocols that pass over the open internet, but which can be encrypted. Scania at least (and possibly Volvo also, though this has not been discussed in interviews) demand that all responsibilites be assigned by contract before connecting to a solution such as the one proposed. The built‐in receipts functionality in the OFTP and AS2 protocols can be used to verify that a message has been receieved by the proper recipient.

4.1.2 Larger Manufacturing Companies

The large manufacturing companies segment is represented by Husqvarna, where an interview was performed with Jenny Sjöblom. At Husqvarna, EDI is used for communications with business partners, but it is not yet mandated as a formal demand on all suppliers. It is possible that this will become the case in the future, as the use of EDI increases efficiency significantly and frees up staff resources. However, the purchasing arm of the company and not the IT department handles such decisions, and as such the decisions have to be guided by business interests and supplier relations.

The EDI standards in use are mostly UN/EDIFACT and Odette. At their British factory the TRADACOMS standard is used as well – however, this usage is outside the scope of control of Husqvarna in Sweden. Husqvarna require their EDI‐using suppliers to support at least DELFOR/DELINS, AVIEXP/DESADV, and INVOIC messages. DELFOR/DELINS messages are sent out by Husqvarna when requesting materials from their suppliers according to pre‐arranged pricing agreements. The second message type, AVIEXP/DESADV, are sent from the suppliers and received by Husqvarna when a shipment has been sent. Finally, INVOIC messages are sent by suppliers to Husqvarna for invoicing purposes. When it comes to the transfer protocols, Husqvarna are quite flexible and try to accomodate their business partners needs. Both OFTP over TCP and AS2 are protocols they recommend for transferring EDI documents.

Safetywise, Husqvarna would prefer if the transfer of EDI documents is encrypted in some manner, but this is not an absolute demand for non‐sensitive data. What is important however, is that the AVIEXP/DESADV messages that suppliers send

Methods

/ 73

are retrieved and processed properly, as without these acknowledgements of shipped goods it is possible that the assembly line will have to slow and wait for components, at great cost to the company.

4.1.3 System Andersson

Since no interviews have been performed with System Andersson’s customers, I have had to try to pick up anecdotal evidence regarding these customer’s needs and requirements from the staff at System Andersson (in particular company contact and mentor Andreas Käll, and MD Thomas Candemar). No regular interviews have been performed with them, but rather, we’ve had a series of discussions throughout the course of the project, which this chapter attempts to summarize.

System Andersson’s main interest at the outset of the project concerned ORDERS and INVOICE messages, which they believed were the most important core features to support for their customers. They were not at the time aware of the requirements as presented by Husqvarna, Volvo and Scania with regard to other messages such as DELFOR or AVIEXP. They also know that a lot of their customers use their system in conjunction with software from Visma/SPCS, a leading provider of economy software for the SME segment in Sweden. It is often the case that Visma/SPCS software is used to perform payroll and invoicing tasks based on data from an Andersson system. Visma/SPCS also provide an online invoicing service with EDI features. The consequence of this is that in System Andersson’s view, being able to send INVOICE messages out through the service that is developed as a part of this project is somewhat less important than being able to receive incoming ORDERS messages via the service.

When discussing the requirements from the larger companies interviewed, it became obvious that supporting the more advanced message flows of delivery notices and despatch advices would require re‐engineering parts of the System Andersson software.

System Andersson has had not particular preference when it comes to transfer protocols or EDI versions used. Rather, they just want the system to work for their customers and their customers’ customers.

4.2 Requirements Summarized

4.2.1 Requirements from interviews

The interviews have been very helpful in defining what the stakeholders would like to see supporten in a system such as the one proposed. It is clear that a number of commonly used EDI messages and protocols must be supported. In brief, the following standards need to be supported:

Methods

/ 73

• Incoming EDIFACT messages DELFOR and ORDERS (or Odette equivalents), sent by EDI using partners outside of the system, received by System Andersson customers using the system.

• Outgoing EDIFACT messages DESADV and INVOIC (or Odette equivalents), sent by System Andersson customers using the system to their EDI using partners outside of the system.

• Transfer of said EDI messages into the system should be performed by OFTP or AS2.

It is important that the security of the system is such that no messages risk disappearing due to system instability or other causes. Obligations between the cooperating partners need to be decided beforehand, possibly by written contract.

4.2.2 Requirements from literature study

Apart from the interviews, possible requirements for the system have been gathered from a study of literature in the fields of business integration and Service Oriented Architecture, described in chapter 2.

If the system is to adhere to SOA design principles, then it should:

• Consist of a number of services, each handling a single business task. • Use loose coupling between these services. • Use standardized and open communications protocols. • Clearly separate service contracts / interfaces from implementation

details.

4.3 Fundamental System Design Summary In this chapter, we try to address the following questions:

1. What distinct processes need to take place in the system, and consequently, what services should the system be divided into?

2. Which communication standards should be used to connect these services? Which communication standards should be used to connect the end‐user to the system as a whole?

3. What should the APIs for accessing the system and its components look like? How open should these be to third party actors?

These questions and topics are then discussed more in‐depth in the following chapters 4.4 through 4.7.

4.3.1 Required services

There are a limited number of processes that need to take place in a system of this sort. Essentially, the system is to receive EDI messages from the sending

Methods

/ 73

parties that are translated into some standardized form and stored until the retrieving end‐user systems log in to fetch them. The SOA type services that would need to be implement in this architecture are thus limited to at most the following:

• An integration service, used when translating messages to and from EDI format. This translation service is the essential core of the system that does the mapping of messages from the standardized EDI formats to the message formats that the System Andersson application expects to receive.

• A storage service for the translated messages. In essence, this would be a web service front end to a relational database. This is needed because the clients receiving the translated messages are most often located behind firewalls or other proxy type devices that do not allow incoming traffic. This means that if one wishes to immediately transfer incoming messages to the clients, all of these firewall devices would need to be reconfigured, which would be a costly and complex operation. Furthermore, the QwickMPS systems located at the clients would need to open up a port to the outside world to allow for data delivery. This is a potential security hazard. Instead, by using a storage service, this service can be polled at given intervals, without having to deal with the network complexity of opening up holes in the firewalls.

• An authentication service, used to check that given usernames and passwords match, and what roles/groups the users belong to. Such a service could then be utilized by the other services to authorize users connecting to the system in order to ensure that they have the access permissions required for whatever action they are trying to perform.

These three services and how they might interact are discussed further in chapter 4.4.

4.3.2 Internal and external communications

In order to adhere to the developed requirements, the architecture should use open and standardized communications formats and protocols wherever possible. There’s a large variety of protocols to chose from that match these requirements. It is however common in SOA scenarios to utilize web service technology as basis for communications, and the author believes it to be a good choice for a lot of the interactions within this system as well, for several reasons:

• Platform support – many modern programming languages and frameworks support web services natively or through well developed libraries, meaning that implementation is greatly simplified.

• Simplicity – operating on top the well‐known and established hypertext transfer protocol (HTTP) means that network setup is fairly simple.

Methods

/ 73

• Mindshare – many books and articles about SOA and distributed systems assume that the communications protocol used will be based on web service technology.

The choice of protocols and standards is discussed more in‐depth in chapters 4.5 and 4.6.

4.3.3 Introduction to the API:s

Since web service technology has already been decided upon, the next step is to design the interface through which entities communicate with these web services, as well as how the data passed via these interfaces should be formatted. This is arguably one of the most important parts of any SOA project (remembering that the focus of SOA development should be on interfaces, rather than implementations, as discussed in chapter 2.3). For this project, a number of methods per supported message need to be designed. How this was done is detailed further in chapter 4.7.

4.4 Services in Detail As discussed in the previous chapter, the initial idea was to use three services for the system.

• An integration service, used when translating messages to and from EDI format.

• A storage service for the translated messages. • An authentication service

Methods

/ 73

Figure 6 System Map Version 1

The first draft of the system map (Figure 6) includes these three services and the connections between them. The glyphs in this image that resemble rack mount servers do not actually represent physical servers, but rather services to deploy in the SOA system.

Upon further analysis it was decided that this first draft of the system map could be simplified significantly by the removal of the authentication service. While it is true that some sort of authentication is needed for this type of application, it quickly becomes obvious that the most efficient way of implementing such features is through using the underlying software platform authentication features. Both of the .NET and Java platforms have built in support for various authentication schemes, and utilizing these features rather than reinventing the wheel can save a lot of development time. As Krafzig, Banke & Slama discuss, this also leads to less code clutter and better portability, as implementation specific authentication details don’t have to be part of the service itself.36

36 Krafzig, D., K. Banke & D. Slama, pp. 187‐189

Methods

/ 73


With this in mind, a new and simpler system map was developed (Figure 7). As you can see in this figure, the authentication service has been removed, and instead authentication is performed through the underlying platform. In practice, this means that the services have to be configured by the operating system or infrastructure on which they are running to allow access only to specific user accounts or groups. Authorization of these user accounts to the data they are trying to access (i.e. the messages being delivered) still happens on a service level however, as the data does not map easily to any security objects present in the operating system or software platform. Had the system been authorizing users against resources that do map to existing security objects, such as for instance files, the infrastructure/platform level might have been more appropriate for the authorization mechanisms. Again, Krafzig, Banke & Slama provide a lot of interesting reading material applicable to this discussion.37


Methods

/ 73


Eventually a third version of the system map was developed (Figure 8). While previously the assumption had been that any messages passing through the system had to pass through the entire “chain” of services in either direction, it became apparent that this approach was not necessary, and in fact, went against the principles of SOA development. The original idea was that incoming EDI messages were first to be translated by the integration service and then stored in the storage service until a client retrieved them. Outgoing messages would travel the same route in reverse, going in via the storage service, which would then call on the integration service to translate the messages to EDI format and then deliver the messages to the outside world.

This idea was motivated by the fact that having only one publicly accessible API located at the storage service seemed to be simpler than having clients access each of the two services separately. It was thought to require less setup on the server side, less duplication of data definitions and schemas, and less work for the client developers. When one looks into the matter however, only the last part of the previous sentence is true. While it is easier for the client developers to keep track of only one service, no less data definition duplication or setup within the system is required. In this scenario the storage service would become a simple proxy, making calls to the integration service that would need to be implemented there all the same. Also, as stated, this would go against the design ideas of SOA, that is, that each service handles one specific task. Thus, rather than making the storage service act as a proxy for outgoing messages on their way to the integration service, it makes more sense to send these messages directly to the

Methods

/ 73

translation service, as shown in Figure 8. The arrows in this figure show how the messages flow through the system, and do not indicate any server‐client relationships.

4.5 More About Internal Communications Many available books or articles about SOA planning and deployment deal largely with the need for and implementation of an Enterprise Service Bus, or ESB (see for instance Chappell)38. The ESB is in these sources is most often viewed as the central component through which all messages passing to and from the deployed services must flow. It is a piece of software that handles routing and transformation of messages, and by way of standards and protocols connects the various services within the SOA landscape. It could be said to be the backbone of the SOA, to which all other components are connected. With this view applied to our scenario, the ESB would be the backplane over which all communications between the services and clients described in the previous chapter take place.

Josuttis takes an interesting view on the ESB concept, pointing out that this type of software component might not be necessary at all. 39 Rather, simply defining the protocols to be used within the SOA solution might be enough to fulfill the communications needs of some small‐scale SOA deployments. While Josuttis still calls this definition of protocols and standards an ESB, I take issue with his terminology. The view of an Enterprise Service Bus as being a software component is firmly entrenched in the industry, and redefining terms at will seems like a recipe for confusion. However, I accept and agree with his statement that this software component might not be necessary for smaller SOA‐like deployments. It is in my view reasonable in a scenario with a very limited number of services (such as the one studied) to limit oneself to defining the communication standards and API:s to be used, but to leave the actual implementation of the communication to the service providers and consumers. Implementing an ESB type solution in this situation would require significant investments of time and money, not to mention that it would greatly increase the complexity of the solution. For this reason, I will design and implement the architecture without an ESB component (as the observant reader might already have noticed when looking at the system maps).

However, while it should not be a necessity to use an ESB to implement the architecture developed in this project, it should be designed to make such an implementation as easy as possible for those who wish to use the developed architecture within pre‐existing SOA deployments.

38 Chappell, D. A., Enterprise Service Bus, O’Reilly, Sebastopol, 2004

39 Josuttis, N.M., p. 50

Methods

/ 73

Removing the ESB component leaves the task of deciding the protocols and standards to employ for communication between the involved services. We have already decided on using Web Service technologies (for reasons stated in chapter 4.3.2). There are a number of standards and protocol versions available for use when building Web Services. According to Erl these protocols can be divided into two generations of technologies.40 The first generation of web services protocols consists of SOAP, XML‐RPC, WSDL etcetera. These protocols are well established and mature, and in use throughout the industry. They do however lack some more advanced features in the security and reliability department, such as message level security and specifications for handling transactional integrity across service boundaries41. In order to use such features, one needs to look into what Erl calls the second generation of web services, the so‐called WS‐* extensions to the web service protocols. These extensions try to add to the existing web service standards, to provide those features that the first generation of web service protocols lack. For instance, WS‐Transaction deals with coordination of long‐running distributed transactions42 and WS‐Security deals with encryption and signature headers for the SOAP protocol43.

The latter proves to be interesting for this project. As the confidentiality of transferred messages can be important in the scenario that we are studying, some sort of encryption on messages may needs to be put in place. While the first generation technology of using SOAP or XML‐RPC over HTTPS is a safe method for encrypting direct communications between two parties on the transport layer, it is unable to provide end‐to‐end encryption on the message layer. Since we want to be able to add an Enterprise Service Bus to our SOA architecture in the future, simple point‐to‐point encryption as provided by SOAP or XML‐RPC over HTTPS is not enough. If messages are to be sent out on to a common bus before reaching their intended recipient, we need those messages to remain encrypted all of the way, not just between the service producer and the ESB. This means that we need to implement end‐to‐end encryption of the individual messages that are transferred on top of HTTP or HTTPS, and doing this requires WS‐Security (which in turn requires SOAP).

40 T. Erl, pp. 47

41 Krafzig, Banke & Slama p. 192

42 Ray, R. J. & P. Kulchenko, Programming Web Services with Perl, O’Reilly, 2002, p. 295

43 Kalin, M., Java Web Services: Up and Running, O’Reilly, 2009, pp. 227‐228

Methods

/ 73

Luckily, WS‐Security is supported in both the .NET framework (by way of WCF, Windows Communication Foundation)44 and in Java (through JAX‐WS and the Metro service stack)45. With platform support from the two largest software environments on the market, standardizing on WS‐Security and SOAP as the communications protocol to use seems like a wise choice.

4.6 External Communications Explored For the communications with System Andersson software clients, the same communications protocols could be used as is used internally in the system, i.e. SOAP secured by WS‐Security over HTTP (possibly SSL‐encrypted). Keeping to using the same communications protocols simplifies development and promotes easy re‐use of published services in the future.

For communications with the external clients, there are more protocols to chose from. It is clear from the requirements that at least one of the protocols OFTP or AS2 should be supported. Using the OFTP protocol requires both expensive software and expensive always‐on subscriptions to telecom services such as X.25 or ISDN. OFTP version 2 does away with the need for such connections, but this version of the protocol has just been formalized and has yet to see widespread adoption.46,47 For these reasons, it appears that using the AS2 protocol would be the most cost‐efficient and easy way of communicating with a large number of the EDI‐using companies in the world, and that this is the standard this system should support by default.

4.7 The Web Service APIs and Data Formats Designing a solid and future‐proof yet flexible API for accessing the services, as well as matching data formats to use on the wire, is arguably the trickiest part of any SOA project. To do this well, one must be knowledgeable about things such as loose coupling and data structure homo‐ or heterogeneity, as well as limitations and choices of the infrastructures in use, all of which are complicated subjects in their own right.

44 Sharp, J., Microsoft® Windows® Communication Foundation Step by Step, Microsoft Press, 2007, pp. 84‐85

45 Kalin, M., pp. 227‐238

46 Data Interchange Plc., OFTP 2, viewed 2009‐06‐26, < http://www.di‐international.com/Education/OFTP20.aspx>

47 Odette Sweden, OFTP2implementeringen påbörjas!, published 2009‐06‐25, viewed 2009‐06‐26, < http://www.odette.se/web/1c8e2b78‐e6be‐43af‐a356‐e700e12cc75f.aspx>

Methods

/ 73

4.7.1 Data formats

In this project, one set of data formats are a given to begin with – the EDI dialects used by the outside world and translated/integrated by the developed system. As shown in chapter 4.2, there are four different EDI messages that need to be supported, in either EDIFACT or ODETTE format. As the ODETTE format is more of a niche format used mainly by the automotive industry, it appears to make more sense to support the more general EDIFACT format. Having made this choice leaves us with the task of developing formats for use within the system, and for communicating with end users.

The initial idea for how to do this was to try and develop a general object model and corresponding message schema that was consistent throughout all of the involved services. This was thought to simplify development and keep consistency throughout the system. A general “message” class was to be developed, having all of the attributes that any represented EDI message might require. In this way, all EDI messages could be represented by objects of the same class inside the services, but with different attributes of these objects having values assigned depending on what type of EDI message it in fact was. An order message might not have an invoice number assigned, an invoice might not have a consignment tracking id assigned and so on. These objects would then be mapped to the general message schema through some method (perhaps simply serialization).

However, after reading up on the topic of data heterogeneity in Josuttis, this idea was scrapped48. As has been discussed in the literature study, it is more in line with the principle of loose coupling to use heterogenous data types and map between these data types as needed, rather than to use a single object model throughout the entire SOA system. This makes for a more flexible and future‐proof system, and one lessens the risk of spending an inordinate amount of time on analysing every possible detail of a common object model. A consequence of this is that rather than trying to shoehorn all possible types of messages into one generalized message schema based upon this common object model, each type of supported EDIFACT message can and should be handled on it’s own, and be structured in the most fitting way at each service where it is being processed. After all, there is a good reason for why these messages are considered different messages in the EDIFACT standards to begin with, namely that they convey different meanings and have different uses, and trying to overlook this by mashing them together into one standard message schema inside this system is likely a recipe for confusion.

48 M Josuttis, pp. 38‐41

Methods

/ 73

As discussed in the following chapter, two APIs will need to be implemented for the services that form this system – one will be located at the storage service, and one at the integration service. These APIs will form the basis for how the services and users interact. The data formats that we need to establish are therefore the formats used in these APIs for transmitting data. Both of these services will communicate via SOAP, and the task thus becomes to design the SOAP objects or messages passed by the services. Seeing as how the task of the project is to develop an architecture rather than a very detailed roadmap, I’ve decided to design data classes of which instances can be serialized and sent as SOAP messages, rather than go the low‐level route and design the SOAP messages themselves.

The table below details the attributes used in the example OrderMessage class. Order messages, represented by objects of this class, are input and read out from the storage service by the integration service and end user clients respectively.

Table 6 Description of OrderMessage class

Attribute Type Id Integer Sender String Recipient String itemNumber String itemDescription String orderDate DateTime deliveryDate DateTime Quantity Integer Price Integer Currency String Text String

These attributes map well to the required data fields of an EDIFACT ORDERS message. There is room for more attributes that a partner in an EDI communication might want to see supported – however, based on just these fields, a basic order message can be constructed. If the partners in the communication have more extensive needs, one can of course extend or inherit from this class. Class descriptions of the other designed message types can be found in the appendices.

4.7.2 Web Service APIs

Both the integration service and the storage service need to have public web service APIs available. The integration service API will be used when sending EDI messages out of the system, and the storage service API will be used for storing and receiving incoming EDI messages.

Methods

/ 73

After discussions with System Andersson, it was decided that the most flexible implementation would be to have the APIs designed on a number of method calls for each supported message type, each method call representing an operation upon one or more messages of said type. This means that the APIs will feature quite a lot of methods (the number of message types multiplied by the number of operations that can be performed on each message type). For instance, we will have methods such as getOrders(), deleteOrder(), sendInvoice() and so forth, where each method combines an operation and a message type. Some of these methods will be part of the API at the storage service, and some (the ones sending messages) at the integration service.

One can contrast this design choice against the alternative of having fewer methods but letting each method do more, using method names such as deleteMessage() and sendMessage(), or ordersOperation() and invoiceOperation(). For more on this choice, see the discussion on business driven versus technically driven interfaces in Josuttis49.

Having more methods available is however no major obstacle; instead, it can actually simplify usage of the API by making it clearer to intuitively guess what each method does. Also, using this design philosophy, extending the API becomes simply a matter of adding a few new methods, whereas in the alternative design discussed, one might have to reengineer existing methods, which could break compatibility with deployed service consumers.

The table below details the required methods for supporting the EDIFACT INVOIC message type and in which service these methods should exist if one expects to be able to both send and receive such messages. In actual fact, the requirements on the system does not specify that one needs to be able to receive incoming invoices, merely send outgoing ones – however, in this table methods for supporting incoming invoices are also included, to give the reader an idea of how incoming messages might be handled. A complete list of methods for all supported message types is included in the appendices.

Table 7 Description of Invoice Message API

Method name Returns Location Description GetInvoices InvoiceMessage[] Storage

service This method returns all invoice messages for the calling user stored in the storage service.

DeleteInvoice Bool Storage service

This method deletes a single invoice message from the

49 M Jossutis, pp. 27‐28

Methods

/ 73

storage service (suggested to use after retrieval using above method)

PutInvoice Bool Storage service

This method puts a new invoice message into the storage service. Used by the integration service when passing on incoming translated EDI invoices further into the system

SendInvoice String Integration service

This method sends an outgoing EDI invoice from the system.

4.8 Prototype Design Decisions As a part of the development of the prototype system, at least four new questions arise:

1. What software architecture/platform should be used for developing the prototype? (.NET, Java, or something else entirely?).

2. Which existing software components can be deployed as services in this architecture, and which components will need to be created from scratch?

3. What costs are associated with the construction and maintenance of the system? What prices are the customers prepared to pay to install or subscribe to the service? Is it cost‐effective?

These questions are further discussed below.

4.8.1 Prototype software platform

System Andersson currently do most of their development on the Microsoft .NET platform, and in a meeting with System Andersson representative Andras Käll on 2009‐02‐23 it was decided that we should try stick with this platform during the development of the prototype as well. This decision will simplify further development and support of the system by the System Andersson staff, which does not need to be retrained to a new software development platform.

As System Andersson like to be on the forefront of technology and development, they suggested the use of the very latest in technologies, i.e. Windows Server 2008, .NET 3.5 and Visual Studio 2008. I agree with this suggestion and have used these technologies. As this is an early prototype, I believe that stability and maturity of the solution is less important than breadth of features and using future‐proof tech.

Methods

/ 73

4.8.2 Existing reusable software components

At the above‐mentioned meeting it was also decided that we should try to build the prototype integration service on top of Microsoft BizTalk Server. Using an off‐the‐shelf type product will greatly reduce development time, compared with building and supporting an own EDI translation layer. However, BizTalk is not a turnkey solution – a lot of work needs to be done in order to adapt it to our specific integration needs.

The decision to use BizTalk Server also ties into the decision to try to standardize the prototype to use the .NET platform. BizTalk Server projects are developed in Visual Studio and are deployed to the server as .NET assemblies. While the product itself is rather different from many other Microsoft products, developers who are used to the .NET platform should hopefully have an easier learning curve using BizTalk than using one of the many Java‐based integration platforms available on the market.

BizTalk Server has a requirement on Microsoft SQL Server, which it uses to store messages passing through the system, as well as system configuration data. Since we will therefore be required to license and install Microsoft SQL Server we also decided to use this product as a base on which to develop the storage service. This service will be developed “from scratch” apart from the fact that the back end storage will be in place already in the form of the SQL Server database.

Another off‐the‐shelf piece of software will be used to test the prototype. Mendelson AS2 is an open sourced Java‐based AS2 client/server, which can be used to send and receive EDI messages over AS2 from Windows or UNIX platforms. This product will be used to test and make sure that the developed prototype actually can send and receive messages according to the AS2 standard as specified in the requirements.

4.8.3 Prototype cost efficiency

The cost of a license of Microsoft BizTalk Server 2009 Standard is 8 500 USD. To this, one must add the cost of the components that BizTalk Server requires in order to operate, namely Microsoft Windows Server (minimum cost 999 USD) and Microsoft SQL Server (retail cost 5 999 USD for a processor license). This adds up to a grand total of almost 15500 USD for software, or just above 121 000 SEK at the current exchange rate (2009‐07‐07) 50. In addition to this sum, a server on which to run this system is required. Such a server can cost anywhere between 10 000 and 100 000 SEK, depending on configuration. If one chooses to go with a

50 All software costs listed are taken from the various product pages on the Microsoft US web site, http://www.microsoft.com/, visited 2009‐07‐07.

Methods

/ 73

relatively modest server, the total cost for the software and hardware combined is in the region of 130‐135 000 SEK. A three‐year upgrade cycle is fairly standard in many organisations and in keeping with that, we assume that this expense will be repeated every three years as software and hardware components are replaced or upgraded. In actual fact, this may be an exaggeration, as software upgrade prices rarely cost as much as purchases of completely new licenses. All the same, the yearly investment for software and hardware lies in the 45 000 SEK range for the server environment alone.

This cost pales in comparison with the cost of hiring a staffer to develop and maintain the system. According to the SCB, the average monthly salary of even a junior computer specialist, is 25 500 SEK51. When adding the pension fund costs, insurance costs, and other costs paid by the employer (equating approximately 47 % of the gross salary52), the monthly cost of hiring said computer specialist rises to almost 37 500 SEK. On an annual basis, this adds up to just below 450 000 SEK, or ten times the annual cost of hardware plus software.

In discussions with System Andersson, the monthly subscription costs for users of the service have been discussed, albeit briefly. The number 5 000 SEK per month was floated as being in the vicinity of what customers might be interested in paying. This equates about 12 employee hours per month, at an employee cost of 7 SEK per minute (a number provided by System Andersson and used in their own promotional material). What this means is that if the customers save at least 12 hours of work per month by using a service such as the proposed, this proposed subscription cost would be attractive to them. Whether they stand to save this much time or not is not easily measured or estimated, especially because of the lack of interest from these companies in partaking in interviews for this project.

If the customers would be willing to pay the cost of 5 000 SEK per month to use the system, this would mean that in order to break even and cover software, hardware and employee costs, at least nine subscribers would be required. Whether there is enough interest among System Andersson’s customers to get nine subscribers to use the service at launch is an unknown factor, again owing to the fact that no such customers have shown interest in being interviewed for this project.

51 Statistiska centralbyrån, Genomsnittlig månadslön (totallön), tjänstemän privat sektor (SLP), kronor efter yrkesgrupp (SSYK), ålder, kön och tid, updated 2009‐05‐26, viewed 2009‐07‐08, <http://tinyurl.com/nv3wau>

52 Ekonomifakta, Sociala avgifter, updated 2009‐02‐09, viewed 2009‐07‐08, <http://www.ekonomifakta.se/sv/Fakta/Arbetsmarknad/Arbetsgivaravgift/>

Methods

/ 73

With all of these unknowns and estimations, the only certain conclusion that can be drawn about the cost efficiency of a system such as the proposed based on the developed prototype implementation, is that further study is warranted.

4.9 Prototype implementation As part of the project, a prototype implementation of the architecture was to be developed, supporting a limited number of messages appropriate to one of System Andersson’s customers. In cooperation with System Andersson it was decided that the prototype need to be able to receive incoming EDIFACT messages of the ORDERS variety, and send outgoing messages of the INVOIC type. These message types correlate well with the needs of smaller businesses, which need to be able to get orders and send invoices. Some smaller businesses (most notably suppliers to the automobile industries as described in chapter 4.1) also have need of more complex document flows, including the handling of messages such as DELFOR and DESADV. However, mapping and understanding these messages require much more domain knowledge about the manufacturing industry, for which reason they are left out of the prototype.

While the following chapters do not delve into much technical detail and does not cover every piece of code used within the prototype, the entire source code for this project is available for download using the distributed source control management tool git, and can be cloned from the git URI git://github.com/hammar/anderssonlink.git. Also, database schemas, important class definitions, and other technical specifications are available as appendices to this report.

4.9.1 The Storage Service

The storage service is intended to act as a simple web service based front‐end to a relational database holding the messages in transit on their way to recipients (the customers using this system). The only messages that need to be delivered as part of the prototype are incoming orders that have been translated from incoming EDIFACT ORDERS messages by the integration service (discussed later in this chapter). Based on the APIs designed in chapter 4.7, the following methods need to be implemented:

• OrderMessage[] GetOrders(); • bool DeleteOrder(int orderId); • bool PutOrder(OrderMessage newOrder);

Developing this a service from scratch required four major steps:

1) Defining the OrderMessage class, which represents in and outgoing order messages.

2) Modelling a relational database based on the OrderMessage class, and implementing access procedures for it.

Methods

/ 73

3) Wrapping SQL commands accessing the database procedures within the methods whose signatures have been listed above.

4) Publishing these methods as a Web Service.

The first step involved implementing the order message class designed in chapter 4.7 (and detailed in the appendix). It was important to make sure that the implemented class was serializable, as this is required in order to use it as a WCF Data Contract (which in turn is required in order to pass objects of the class via SOAP). Since all of the attributes and subobjects contained in this class are serializable themselves, this worked automatically.

The second step involved putting the schema to support these objects into the database. Since all of the described fields use simple data types it was fairly simple to map them against the database. Strings mapped to nchar or nvarchar, integers to int and DateTime to date. A schema for storing OrderMessage objects in a relational database was thus developed. In order to guarantee safe concurrent access to and modification of these stored objects, a couple of stored procedures (dubbed DeleteOrder and InsertOrder) were developed and added to the database.

The third step was to connect these stored procedures to the method signatures given above. For instance, by developing the DeleteOrder(int orderId) method to actually call the DeleteOrder stored procedure, passing the proper parameter along, I hooked the method into the actual data deletion call. The same goes for the other two calls. Apart from calling the stored procedures, the methods were also constructed to aid in access control, by passing along authentication information for the calling service consumer to the stored procedure in the database, ensuring that a user can only operate upon messages intended for him/herself.

Finally, the fourth step was to make these methods available to the users of the system. This was done by compiling the classes holding the methods into a .NET assembly and deploying that assembly into Internet Information Server. Alongside the assembly a configuration file was deployed specifying what protocols and ports to use. Based on the assembly and the configuration file, web service metadata (in WSDL format) is automatically generated and published, so that it becomes incredibly easy to develop clients for this service (as described in the following chapter about the integration service).

4.9.2 The Integration Service

As has been mentioned, BizTalk Server uses .NET assemblies to package mappings, schemas and orchestrations that are required for an integration task. Such artefacts are most easily developed using the BizTalk SDK for Visual Studio, which can be installed at the same time as the BizTalk Server product itself. For

Methods

/ 73

more information about how BizTalk works and how it compares to similar software products, see Bengtsson & Rumin.53

In order to implement the developed architecture as described in the previous chapters, two tasks need to be performed at the integration service:

1) Incoming EDIFACT ORDERS messages transferred via the AS2 protocol need to be translated into a format that the storage service can understand, and the storage service then need to be called upon to store said messages.

2) An orchestration that generates an outgoing INVOIC message needs to be published as a web service that client software can call upon. This generated INVOIC message then needs to be delivered to the proper recipient via the AS2 protocol.

In order to perform the first of these two tasks, BizTalk needed to be able to interpret ORDERS messages. For this reason, an ORDERS schema (defining the fields used in the message in a dual EDIFACT and XML format) was first added to the project. This schema used the D93A version of the EDIFACT standard, released in 1993, for compatibility reasons. However, newer versions are available and can be used if one so wishes. These schemas are all bundled with the base BizTalk product but need to be unpacked and compiled into the project assembly if one wishes to deploy them as part of a project.

53 Bengtsson, K & P. Rumin, Öppna Integrationsplattformar, Högskolan i Jönköping, 2008.

Methods

/ 73

Figure 9 Mapping of ORDERS Message to SOAP Message

Apart from the ORDERS schema, a remote reference to the previously published storage service WSDL metadata was added to the Visual Studio project. This reference made it possible to automatically generate the schema for the SOAP messages that were to be sent to the storage service, based on the metadata from that service. The ORDERS and SOAP message schemas were tied together via a mapping (Figure 9). In the mapping, certain fields from the incoming message were linked to certain fields of the message sent to the storage service. Some fields from the ORDERS schema were simply linked and thus just copied into the receiving field in the SOAP schema, whereas some were operated upon or transformed more or less extensively. For instance, some strings split over several fields in the ORDERS schema were concatenated into just one field in the SOAP schema.

Methods

/ 73

Figure 10 BizTalk Orchestration of Incoming ORDERS Message

This mapping in turn was inserted into a BizTalk orchestration (Figure 10). An orchestration is a specified path through the integration engine that a message can be set to take. In our case, the incoming EDIFACT ORDERS message is received through a configured port on the outside of the orchestration (top right of the figure) and is transformed into a new message by way of the previously shown mapping, before that new message is then sent out to a request‐response web service port (left hand side of the figure). Additionally (though not a requirement of the prototype) this image also shows the response from that web service port which is returned and immediately resent to a logging port (middle right).

Once this project had then been compiled and deployed to the BizTalk server, the ports in the orchestration on which to expect incoming and outgoing data were configured to match our requirements (incoming EDI data via an AS2 over HTTP port, outgoing data via a SOAP over HTTP and so forth). This required some tedious work with regards to certificates and http server integration, to make sure that the transferred messages were properly secured both when entering and leaving the service.

The second task involved basically the same steps, although in reverse. In this task, the integration service was to receive a web service call from a client, and based upon this call, generate and deliver an outgoing EDIFACT INVOIC message over AS2.

One difference here compared to the previous task is that no reference to an existing web service could be made, which means that the SOAP message schema of incoming web service requests could not be generated automatically. Instead this schema had to be implemented by hand based on the invoice message class designed in chapter 4.7 (detailed in the appendix)

Methods

/ 73

Figure 11 – BizTalk Orchestration of Outgoing INVOIC Message

After developing the schema for incoming invoice generation requests as per above said schema was mapped to an EDIFACT INVOIC message in the same manner as had previously been done with ORDERS messages. This mapping was then inserted into an orchestration (Figure 11) and deployed to the BizTalk Server. This orchestration looks slightly different than the one used for outgoing ORDERS messages, due to the difference in message flows. In this figure, a response‐request port is located on the right hand side and an outgoing EDI port on the left hand side. A request is made from the port on the right, and transformed according to the mapping. The result of the mapping (the INVOIC message) is sent out to the EDI port. If the sending goes well, the orchestration then progresses to generate a completely new message and sends it out as a response to the original request. In the prototype, this new message simply reads “EDI Generation Succeeded”, which is the response the caller of the web service gets if all has gone well. If something has failed along the way, this message is not generated and returned, and in this case the web service client does not get a response and the session hangs indefinitely. This could be used as a very crude form of exception handling, though in a real production environment this is of course not acceptable.

4.10 Prototype tests The prototype was tested in conjunction with the open source Mendelson AS2 client and worked just as expected. When generated EDIFACT ORDERS messages were delivered into the system via AS2 over HTTP, these messages were translated by the integration service and stored into the storage service, from which they could be retrieved using a purpose built test client.

Methods

/ 73

The reverse process worked equally well – when the test client called the SendInvoice() method, an INVOIC message was generated based on the input to the method, and that message was then delivered out to the Mendelson host.

In order to test the cross‐platform compatability of the system, a Java‐based client was also tested. While there were some minor problems (mostly to do with configuration of the Java WSDL importer tool), in the end the process worked just as well.

It should be noted that all the tests performed dealt with standard INVOIC and ORDERS messages that one should expect to work. No exception handling was implemented or tested, so passing an incorrectly formatted message into the service from either end would most likely result in significant problems. However, for a prototype such degrees of stability were not deemed necessary.

Results

/ 73

5 Results As a result of this project, a SOA‐based architecture for integrating different sized manufacturing companies via EDI messages and web services has been developed. The architecture consists of two services, a number of API definitions and specifications for how to access these services, class representations of commonly used message types, and a set of protocols used for communication inside and outside the system.

The services involved are:

1) An integration service, used for two purposes: a. To translate incoming EDI messages for the users of the system. b. To translate outgoing messages into EDI format for delivery to

external business partners of the system users. 2) A storage service, holding incoming messages in a database until such a

time as system users are able to retrieve them.

There are two communication formats/protocols used in the system:

1) UN/EDIFACT messages (via AS2 over HTTP) Used for communicating with external business partners of the system users, who prefer the use of EDI as part of their manufacturing operations.

2) Web Service RPC (via SOAP over HTTP) Used for internal communications and for communications with system users.

The APIs for accessing the services via Web Service RPC consists of a number of methods for each supported EDIFACT message type. For messages types that the system is required to be able to receive from the outside business partners, three methods must exist at the storage service:

1) A method for putting new instances of said message type into storage (e.g. “putOrder”).

2) A method by which system users can get messages of this type out of storage (e.g. “getOrders”)

3) A method for deleting messages of this type from storage (e.g. “deleteOrders”)

For message types that the system is required to be able to send, a single method must exist at the integration service:

1) A method for translating and sending EDIFACT messages of this type (e.g. “sendInvoic”)

Results

/ 73

All of these methods are further detailed in the appendix. Apart from the methods themselves, a number of classes have been defined, detailing the attributes that shall be used to represent instances of these EDIFACT messages when communicating with the services via the methods. These classes are also detailed in the appendix.

Based upon this architecture, a working prototype has been developed to show that the architecture is basically sound. The prototype is based on .NET technology and uses BizTalk Server for the integration service and custom built web services on top of a SQL Server database for the storage service. The prototype supports two of the four EDIFACT messages supported by the designed architecture (ORDERS and INVOIC). When tested with the supported messages, the prototype performed flawlessly.

Conclusion and discussion

/ 73

6 Conclusion and discussion This project was about developing an architecture for how an integration system could be constructed using SOA principles. The author believes that the developed architecture, while by no means being perfect, provides a good solution to this problem and a possible starting point from which System Andersson can start developing such a service. While the proposed architecture is fairly simple, a system built according to it provides the services and specifications that are required in order to allow small manufacturing companies to receive orders and send invoices in EDIFACT format, as well as the other messages typically required by the automotive industry, as was the goal of the project to begin with.

The architecture adheres well to the SOA ideals, is general enough to be adaptable to different types of messages and industries, and there are some exiting possible future usages of such a system. While there are of course also improvements to be made, it is the opinion of the author that the task as presented by System Andersson and the School of Engineering has been solved.

The following sections discuss the various conclusions drawn from the project in greater detail.

6.1 Generalizability Regarding the discussion of how general and “broad” this solution is, there are two aspects that one need to consider. To begin with, one can ask the question: How general is the architecture with regards to technology? Does it depend on any one particular technology, programming language, operating system, or other limitation, or can it be implemented in a wide variety of technology environments and scenarions? Secondly, one would ask: How general is the architecture with regards to business scenarios? That is, how specific is this problem and solution to the SME segment of the manufacturing industry? Can the solution be deployed for other types of business cases?

With regard to the technical aspect, it is the authors belief that the proposed architecture is very flexible and generalizable. The main reason for this is that the specifications that have been developed are rather general in nature and omit lot of more detailed technical specifics. Such details are left to the implementers who build systems based on the architecture to decide. For instance, the architecture does not dictate what internal representations of data to use within the services, such as date formats or integer endianness. Had such details been specified, then it would have been quite difficult to implement the architecture in many different technology environments. As the specifications are currently written, the author foresees little trouble should one choose to develop a prototype in a different environment than the one presented in this thesis, such as for example a Java environment. Had it not been for time constraints, the author might well have


/ 73

developed such a prototype himself, to further prove the basic validity of the proposed model.

With regard to the business aspect, the answer is a little less certain. Other industries have other standards and operating procedures, and the author lacks the specific domain knowledge to make predictions regarding them. However, if the companies in these sectors utilize EDI technology, more specifically, the UN/EDIFACT format messages described in this report, it would appear likely that the architecture could be useful to them as well. In business scenarios where other message types or EDI formats than the ones specified in this project are used, one could probably extend the specifications to accommodate for these facts as well. Adding support for yet another EDIFACT message would in this case be the easiest. It is simply a matter of finding the required fields in the message and adding class definitions matching these messages to the storage service, as well as mappings for the messages to the integration service. Adding support for an entirely different EDI format (such as X12 or ODETTE) could be done similarly, although in that case it may also be desirable to convert messages carrying similar contents in the different EDI formats into one general format, which would be more difficult.

6.2 Architecture as SOA example As the literature study has shown, and as has been summarized in the requirements, a SOA solution should meet the following goals:

• It should consist of a number of services, each handling a single business task.

• It should use loose coupling between these services. • It should use standardized and open communications protocols. • It should clearly separate service contracts / interfaces from

implementation details.

The proposed architecture lives up to all of these goals;

• It consists of two services, each handling a single task – the integration service translates incoming messages and the storage service holds the messages for delivery.

• These two services are deployed independently and share no object definitions or other dependencies, and are thus rather loosely coupled (though the coupling could be even looser – see the next section for a discussion on this).

• The communications protocol used within the system is the open and standardized SOAP, deployed in a widely documented and understood Web Service RPC pattern.

• The interfaces provided to use these services are described in WSDL files that can be separated from the services implementations.


/ 73

The author therefore considers this proposed architecture to be built in accordance with at least some, if not all, of the concepts of a Service Oriented Architecture design.

6.3 Limitations / Possible project improvements As has been mentioned above, the coupling between the services could be even more SOA‐like, had a number of design changes been made. For instance, in a full‐blown SOA environment with many services, an Enterprise Service Bus is a requirement. This bus acts as an intermediary, so that the services do not have to be aware of connection details for one another. This makes it easier to plug services in and out of the SOA landscape without rewriting a lot of code every time. In this very small deployment however, an ESB was not implemented, as it would have complicated the scenario significantly. If these services were to be deployed in an organization that already used SOA to a large degree, the architecture would have to be modified to include an ESB however.

Another related issue concerning loose coupling is the recommended usage of payload semantics rather than interface semantics. In this project, interface semantics have been used exclusively, an approach that is not in line with the ideal SOA design. Using payload semantics means that one should control application flow by using different message formats rather than calling different methods on the services. This concept is discussed in Krafze, Bankig & Slama and shown in the table in chapter 2.3. While the goal of this design pattern is to make the message formats more flexible and lessen the impact of changes on the system as a whole, the approach also complicates the system a great deal, which is the main reason it has not been used in the project. Furthermore, Krafze et al. agree that this approach in a lot of cases merely moves the problem of inflexibility from the compiled code to the configuration files.54

One thing to note about the design of the classes and message schemas is that in this project they have been simplified to hold only one particular message or business communication per object or message. What this means is that EDI message envelopes that hold multiple EDI messages would need to be split up into multiple messages by the system, and that individual messages that pertain to multiple business transactions/events would also need to be split up into individual messages for each such transaction or event. For instance, an order containing several line items should be split up into several order messages, each holding one line item. This design was decided upon together with System Andersson, and the main motivator behind the choice was to simplify development of end‐user clients of the system. However, this splitting up does add significant overhead to each such multi‐part message. The solution would be



/ 73

more elegant if this were not the case and if multi‐part messages were supported through and through.

With regard to the project work itself, there are of course also some possibilities for improvements. Most notably, the interviews with project stakeholders left out a very important group (possibly the most important), namely, the small manufacturing businesses who would subscribe to the system if it were built. Over the course of the project the author has tried to find such companies willing to partake in the project on various occasions, but with no success. Even after emailing the whole of System Andersson’s customer stock, in excess of 500 companies matching this description, no responses were received. The requirements therefore mirror what the larger EDI‐using companies believe to be necessary, as well as what System Andersson believe their customers would have use of, but these beliefs are not backed up by any interviews with primary sources.

6.4 Future usage scenarios The web service APIs that were developed in this project could possibly be used in a wide variety of ways not first anticipated when the project was initiated. These APIs in essence provide a general way of interacting with a subscribing manufacturing company’s systems, by way of sending orders or other business documents into them. If one takes this view, one could envision a scenario in which the subscribing manufacturers could easily send orders and invoices to one another and thus trade with each other directly using these APIs, without having to have their business documents translated to EDI format at all. In a way, the system would work similarly to the way that the old EDI VANs did, as a mediator or broker between different business partners. This scenario would enable the efficiency gains of using automated B2B purchasing and supply chains, even for interactions between these rather small businesses.

In System Andersson’s original vision, only software clients developed by System Andersson would connect to this type of system. Taking the scenario described above one step further though, one can consider a situation where the developed APIs are widely published and where a large number of differing clients from various developers (including System Andersson) communicate with a system developed to these standards. In this scenario, the developed APIs could become a general standard for business interaction among small‐scale businesses in this sector. Such a development could benefit System Andersson by letting them implement certification programmes or perhaps running marketing drives based on selling the idea that they provide the most compatible implementation of this general standard.

References

/ 73

7 References • Alajääskö, P., ’International Sourcing in Europe’, Statistics in focus, Nr

4/2009, Eurostat • Amosoft, EDI 850 X12 Example, viewed 2009‐06‐10,

<http://www.amosoft.com/edi_docs/EDI_850_X12_Example.html> • Barnes, S., Ecommerce and vbusiness, Elsevier, 2007 • Bengtsson, K & P. Rumin, Öppna Integrationsplattformar, Högskolan i

Jönköping, 2008. • Bloomberg, J. & R. Schmelzer, Service Orient or Be Doomed!, John Wiley &

Sons, Inc., Hoboken, 2006. • Brafman, O. & R. A. Beckstrom, The Starfish and the Spider : the unstoppable

power of leaderless organizations, Portfolio, United States of America, 2006 • Chappell, D. A., Enterprise Service Bus, O’Reilly, Sebastopol, 2004 • Data Interchange Plc., OFTP 2, viewed 2009‐06‐26, < http://www.di‐

international.com/Education/OFTP20.aspx> • Ekonomifakta, Sociala avgifter, updated 2009‐02‐09, viewed 2009‐07‐08,

<http://www.ekonomifakta.se/sv/Fakta/Arbetsmarknad/Arbetsgivaravgift/>

• ERPGenie.COM, ANSI X12 Transaction Sets, viewed 2009‐06‐17, < http://www.erpgenie.com/sapedi/ansix12transactionsets.htm>

• Erl, T., SOA: Principles of Service Design, Pearson Education, Inc., Boston, 2008

• Friend, I. ODETTE File Transfer Protocol 2, November 2007, viewed 2009‐07‐28, <http://www.ietf.org/rfc/rfc5024.txt>

• Fu, S., J. Chung, W. Dietrich, V. Gottemukkala, M. Cohen, & S. Chen, ‘A Practical Approach to Web‐based Internet EDI’, Distributed Computing Systems, International Conference on, 1999 ICDCS Workshop on Electronic Commerce and Web‐Based Applications, 1999

• Fällén, S. & A Holmgren, EDI mot leverantörer till Sandvik Coromant, Luleå Tekniska Universitet, Luleå, 1997

• GXS, Inc., ANSI ASC X12 Standards Overview Tutorial, viewed 2009‐06‐10, <http://www.gxs.com/pdfs/Tutorial/Tutor_ANSI.SO_GXS.pdf>

• Henrekson, M. & D. Johansson, ‘Institutional Effects on the Evolution of the Size Distribution of Firms’, Small Business Economics, Vol 12, No. 1 (February 1999), pp. 11‐23.

• Håkansson, F., T. Johansson & H. M. Missola, Sourcing Strategies and Supplier Relationships, Växjö University School of Management and Economics, 2009

• Josuttis, N. M., SOA in Practice, O’Reilly Media Inc., Sebastopol, 2007 • Kalin, M., Java Web Services: Up and Running, O’Reilly, 2009, pp. 227‐238 • Krafzig, D., K. Banke & D. Slama, Enterprise SOA, Pearson Education, Inc.,

Upper Saddle River, 2005

References

/ 73

• Moberg, D. & R. Drummond, MIMEBased Secure PeertoPeer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2), July 2005, viewed 2009‐07‐28, <http://www.ietf.org/rfc/rfc4130.txt>

• Nash, D., ODETTE File Transfer Protocol, September 1997, viewed 2009‐07‐28, <http://www.ietf.org/rfc/rfc2204.txt>

• Odette International Ltd., Milestones, viewed 2009‐06‐16, <http://www.odette.org/html/about_milestones.htm>

• Odette Sweden, OFTP2implementeringen påbörjas!, published 2009‐06‐25, viewed 2009‐06‐26, < http://www.odette.se/web/1c8e2b78‐e6be‐43af‐a356‐e700e12cc75f.aspx>

• Progress Software Corporation, EDIFACT – UN/EDIFACT and UN/CEFACT Message and Segment Directory, viewed 2009‐06‐15, < http://www.stylusstudio.com/edifact/>

• Rawlins EC Consulting, X12 Technical Tutorial Syntax and Control, updated 2007, viewed 2009‐06‐10, <http://www.rawlinsecconsulting.com/x12tutorial/x12syn.html>

• Ray, R. J. & P. Kulchenko, Programming Web Services with Perl, O’Reilly, 2002

• SAA Consultants, The EDI Zone: EDI Guide – EDI Standards, viewed on 2009‐06‐10, <http://www.theedizone.com/edi_resources/edi_standards.html>

• Scania, Frequently Asked Questions, Scania Supplier Portal, viewed 2009‐06‐15, < https://supplier.scania.com/wps/portal/GSP/kcxml/?WCM_GLOBAL_CONTEXT=/wps/wcm/connect/p.gsp~WS/p.gsp.1.Miscellaneous~G1/p.gsp.2.EDI~G2/p.gsp.3.EDI+Europe~G2/p.gsp.4.FAQ~G2/>

• Sharp, J., Microsoft® Windows® Communication Foundation Step by Step, Microsoft Press, 2007

• Snell, J., D. Tidwell & P. Kulchenko, Programming Web services with SOAP, O’Reilly, 2002

• Statistiska centralbyrån, Genomsnittlig månadslön (totallön), tjänstemän privat sektor (SLP), kronor efter yrkesgrupp (SSYK), ålder, kön och tid, updated 2009‐05‐26, viewed 2009‐07‐08, <http://tinyurl.com/nv3wau>

• Swatman, P., ’Electronic Commerce: Origins and Future Directions’, Proceedings of the 1st Australian DAMA (Data Administration Management Association) Conference, Melbourne, 1996

• Tallim, P. & J Zeeman, Electronic Data Interchange: An Overview of EDI Standards for Libraries, International Federation of Library Associations and Institutions, updated 1995‐04‐27, viewed 2009‐06‐10, <http://archive.ifla.org/VI/5/reports/rep4/index.htm>

• Volvo, edifact: Volvo Information Technology – EDI, viewed 2009‐06‐15, <http://www.volvo.com/volvoit/edi/en‐gb/Europe/specifications/edifact/edifact.htm>

Appendi

/ 73

8 Appendices 8.1 Appendix I: Message Classes

8.1.1 OrdersMessage (EDIFACT ORDERS message)

Attribute Type Id Integer Sender String Recipient String itemNumber String itemDescription String orderDate DateTime deliveryDate DateTime Quantity Integer Price Integer Currency String Text String

8.1.2 InvoicMessage (EDIFACT INVOIC message)

Attribute Type Id Integer Sender String Recipient String InvoiceNumber String DueDate DateTime Reference String Adress Adress ItemDescription String Amount Integer Currency String

Where the Adress type used by the attribute of the same name is a simple structure per the below table:

Attribute Type Street String City String Zipcode String Country String

Appendi

/ 73

8.1.3 DelforMessage (EDIFACT DELFOR message)

This message type is sent by customers of the manufacturing companies in order to request delivery of a certain set of goods at a certain date. This differs from ORDERS messages in that payment information for the requested goods is not part of the message.

Attribute Type Id Integer Sender String Recipient String itemNumber String itemDescription String orderDate DateTime deliveryDate DateTime Quantity Integer Text String

8.1.4 DesadvMessage (EDIFACT DESADV message)

This message is sent by a manufacturing company to their customers to indicate that a certain consignment of requested goods have been sent off. The Adress type used is the same simple structure as used in the INVOIC message type.

Attribute Type Id Integer Sender String Recipient String itemNumber String itemDescription String Quantity Integer Adress Adress Reference String ConsignmentId String ShippingEquipment String ShippingDate DateTime EstimatedDeliveryDate DateTime Text String

8.2 Appendix II: API Method Calls Sorted by Message Type

8.2.1 ORDERS

Method name Returns Location Description GetOrders OrdersMessage[] Storage

service This method returns all order messages for the

Appendi

/ 73

calling user stored in the storage service.

DeleteOrders Bool Storage service

This method deletes a single order message from the storage service (suggested to use after retrieval using above method)

PutOrders Bool Storage service

This method puts a new ORDERS message into the storage service. Used by the integration service when passing on incoming translated EDI orders into storage.

8.2.2 INVOIC

Method name Returns Location Description SendInvoic String Integration

service This method sends an outgoing EDIFACT INVOIC message from the system.

8.2.3 DELFOR

Method name

Returns Location Description

GetDelfor DelforMessage[]

Storage service This method returns all DELFOR messages for the calling user stored in the storage service.

DeleteDelfor Bool Storage service This method deletes a single delivery schedule message from the storage service (suggested to use after retrieval using above method)

PutDelfor Bool Storage service Used by the integration service when passing on incoming translated EDIFACT DELFOR messages into storage.

8.2.4 DESADV

Method name Returns Location Description SendDesadv String Integration This method sends an

Appendi

/ 73

service outgoing EDIFACT DESADV message from the system.

8.3 Appendix III: Communication Protocols Used

8.3.1 Internal communications & external communications with system users

Application layer: Web Service RPC calls (transmitted as SOAP messages) Transport layer: HTTPS (SSL‐encrypted Hypertext Transfer Protocol) Link layer: TCP/IP (Transmission Control Protocol over Internet Protocol)

8.3.2 External communications

Application layer: EDIFACT files transferred via AS2 protocol Transport layer: HTTPS (SSL‐encrypted Hypertext Transfer Protocol) Link layer: TCP/IP (Transmission Control Protocol over Internet Protocol)

8.4 Appendix IV: Architecture Map

orders from the cloud - diva-portal.org233049/fulltext01.pdf · postadress: besöksadress: telefon:...

Documents