Project Topics
Get Complete Project Material File(s) Now! »
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.
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:
How would users (both senders and receivers of EDI documents) of the system like the system to behave?
What use do they expect to get out of a system such as the proposed in terms of efficiency gains?
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.
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 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.
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 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:
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.
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.
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.
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 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.
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.
Requirements Summarized
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:
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.
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.
Fundamental System Design Summary
In this chapter, we try to address the following questions:
What distinct processes need to take place in the system, and consequently, what services should the system be divided into?
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?
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.
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 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.
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.
Contents
1 INTRODUCTION
1.1 BACKGROUND
1.2 PURPOSE / OBJECTIVES
1.3 LIMITATIONS
1.4 THESIS OUTLINE
2 THEORETICAL BACKGROUND
2.1 STRUCTURE OF THE SWEDISH MANUFACTURING INDUSTRY
2.2 ELECTRONIC DATA INTERCHANGE
2.3 SERVICE ORIENTED ARCHITECTURE
2.4 WEB SERVICES
2.5 EXISTING SOLUTIONS IN THE FIELD OF STUDY
3 METHODS
4 IMPLEMENTATION
4.1 STAKEHOLDER INTERVIEWS
4.2 REQUIREMENTS SUMMARIZED
4.3 FUNDAMENTAL SYSTEM DESIGN SUMMARY
4.4 SERVICES IN DETAIL
4.5 MORE ABOUT INTERNAL COMMUNICATIONS
4.6 EXTERNAL COMMUNICATIONS EXPLORED
4.7 THE WEB SERVICE APIS AND DATA FORMATS
4.8 PROTOTYPE DESIGN DECISIONS
4.9 PROTOTYPE IMPLEMENTATION
4.10 PROTOTYPE TESTS
5 RESULTS
6 CONCLUSION AND DISCUSSION
6.1 GENERALIZABILITY
6.2 ARCHITECTURE AS SOA EXAMPLE
6.3 LIMITATIONS / POSSIBLE PROJECT IMPROVEMENTS
6.4 FUTURE USAGE SCENARIOS
7 REFERENCES
GET THE COMPLETE PROJECT
ORDERS FROM THE CLOUD BUSINESS INTEGRATION AS A SERVICE
