Pabadis (1999) - ERP Interface

8/8/2019 Pabadis (1999) - ERP Interface

1/58

The PABADIS Consortium

PABADIS

IST-1999-60016

Plant Automation based onDistributed Systems

ERP-Interface specification and design

Task 1.5

Document type : Deliverable

Document version : Final V 1.0

Document Preparation Date :

Classification : Public

Contract Start Date : 01.12.2000

Duration : 31.05.2003

Project funded by the European Communityunder the Information Society TechnologyProgramme (1998-2002)


2/58

Deliverable 1.5 ERP-Interface specification and design IST 1999 - 60016

The PABADIS consortium

Rev. Content Resp. Partner Date

0.1 Set up and structuring Apostolos Vontas ;

Unisoft S.A.

15/03/01

0.2 ERP Potential Uwe Hess, IMS 20/04/01

0.3 Standards Nikolaou Georgios;Unisoft S.A. 05/05/01

0.5 Specifications Valachis Dimitrios;Unisoft S.A.

13/6/01

0.55 Specifications Paterakis Giannis;Unisoft S.A.

22/06/01

0.7 Design Uwe Hess; IMS 05/07/01

0.8 Design Panayiotis Hatzaras;Unisoft S.A.

21/08/01

0.9 Final Update Peter Thebus; IMS 10/09/010.95 Review and comments Roland Bataille; EMA 17/09/01

1.0 Final Approval Christos Fiskas;

Hatzopoulos S.A.

20/09/01

Final approval Name Partner

Reviewer Christos Fiskas Hatzopoulos S.A.


3/58


The PABADIS consortium page 2

TABLE OF CONTENT

0 EXECUTIVE SUMMARY ................................................................................................................................5

0.1 BACKGROUND AND PURPOSE...............................................................................................................50.2 CONTENT OF THE DOCUMENT..............................................................................................................5

1 ERP SYSTEMS POTENTIAL AND STANDARDS.........................................................................................6

1.1 POTENTIAL INVESTIGATION...................................................................................................................6

1.1.1 Flexibility, Agility & Interoperability Enabled by Adaptable Architecture ............................................7

1.1.2 Component Based Architecture..........................................................................................................8

1.1.3 Open Interfaces and Improved Integration .........................................................................................9

1.1.4 Implications of this trend.....................................................................................................................9

1.1.5 An ERP Vendor example....................................................................................................................9

1.2 STANDARDS IDENTIFICATION..............................................................................................................11

1.2.1 Basic elements .................................................................................................................................11

1.2.2 Basic Characteristics ........................................................................................................................13

1.2.3 Architectural Layers ..........................................................................................................................14

1.2.4 Integration.........................................................................................................................................14

1.3 ERPS EVALUATION DESCRIPTION.................................................................................................................16

1.4 PRODUCTION MODULE.........................................................................................................................20

2 INTERFACE SPECIFICATIONS...................................................................................................................23

2.1 TECHNOLOGICAL ENVIRONMENT .......................................................................................................23

2.2 POSSIBLE INTERFACING SCENARIOS.............................................................................................................26

2.3 MANUFACTURING ORDER.............................................................................................................................26

2.3.1 Sending an order for execution ........................................................................................................27

2.3.2 Controlling the status of the order ....................................................................................................29

2.4 LOGICAL VIEW OF THE INTERFACE................................................................................................................31

2.4.1 A direct ERP Database to another ERP Database Interoperability..................................................31

2.4.2 Message to Message Interoperability ...............................................................................................312.4.3 Indirect ERPs Database to ERPs Database Interoperability ..........................................................32

3 INTERFACE DESIGN...................................................................................................................................33

3.1 THE PROPOSED INTEGRATION TOOL ............................................................................................................33

3.1.1 XML Service Module.........................................................................................................................34

3.1.2 SQL Configurator..............................................................................................................................34

3.1.3 The utilised XML Documents............................................................................................................36

3.1.3.1 XML Request Document............................................................................................. 36

3.1.3.2 The Configurator File ..................................................................................................363.1.3.3 The XML Response File.............................................................................................. 36

3.1.4 Master-Detail Structure.....................................................................................................................36


4/58



3.2 PARSING XML ACROSS CMUS TO ERP DIRECTION......................................................................................36

3.3 PARSING XML FROM ERP TO CMUS DIRECTION..........................................................................................37

3.4 UML DIAGRAMS .........................................................................................................................................39

4 ABBREVIATIONS.........................................................................................................................................44

5 REFERENCES..............................................................................................................................................45

ANNEX 1: SAP COMMUNICATION TECHNIQUES ...........................................................................................46

ANNEX 2: XML INTERFACE DOCUMENT DEFINITIONS.................................................................................49


5/58



TABLE OF FIGURES

Figure 1: Ranking of the top 4 of the ERP vendor companies............................................................ 10

Figure 2: SAP Architecture................................................................................................................10Figure 3: Basic ERP logical modules and interconnection pathways amongst them.......................... 12

Figure 4: ERP system Structural Layers............................................................................................14

Figure 5: Four levels for integration of heterogeneous systems......................................................... 15

Figure 6: ERP Production Module in Pabadis.................................................................................... 22

Figure 7: XML description..................................................................................................................23

Figure 8: Open Database Connectivity description ............................................................................ 25

Figure 9: Interfacing scenarios ..........................................................................................................26

Figure 10: Useful information in a manufacturing order ..................................................................... 27Figure 11: Example of structured data of a manufacturing order in an XML file ................................. 28

Figure 12: Appropriate for the Agency metadata from a manufacturing order in an XML file.............. 29

Figure 13: Example of structured data for controlling the status of the machine (continues) .............. 29

Figure 14: Example of structured data for controlling the status of the machine ................................ 30

Figure 15: XML file send to the machines and received back for knowing ......................................... 30

Figure 16: Direct ERP Database - ERP Database Interoperability..................................................... 31

Figure 17: Message to Message Interoperability ...............................................................................32

Figure 18: Indirect ERP Database - ERP Database Interoperability................................................... 32Figure 19: Description of the PABADIS ERP Interface ......................................................................34

Figure 20: The XML service execution structure................................................................................ 35

Figure 21: Communication across the direction from CMUs community to the ERP .......................... 37

Figure 22: Communication across the direction from ERP to CMUs community................................ 38

Figure 23: XML Service Module WorkFlow from CMU, Agency to ERP direction.............................. 39

Figure 24: XML Service Module workflow across ERP to AGENCY direction .................................... 40

Figure 25: Configurator WorkFlow..................................................................................................... 41

Figure 26: Trigger Expector WorkFlow .............................................................................................. 42Figure 27: Agency to ERP interactions representation....................................................................... 43

Figure 28: ERP to Agency interaction representation ........................................................................43


6/58



0 Executive summary

0.1 BACKGROUND AND PURPOSE

This document is part of the needed specifications and designs for the overall model that work-package 1, is providing. This is the fifth deliverable of this WP and describes the work carried out intask 1.5, based on overall specifications of deliverable 1.1 and working in parallel with Tasks 1.2-1.4.This deliverables purpose is to provide PABADIS with the specifications and designs for creating theappropriate interface for connecting the shop-floor of an industry with current ERP technologies inorder to supervise and manage an industry. Following tasks, the implementation and operation of theinterface, will be based on the results of this task.

0.2 CONTENT OF THE DOCUMENT

This document reflects work been carried out during task 1.5 concerning the generic interfacebetween ERP systems and the PABADIS infrastructure. During this task the main activities that wedescribe also in the present document were:

- Investigation of the ERP systems potential and standards

- Identification of the requirements from an ERP systems side, always based on PABADISsystem needs, the overall specification of deliverable 1.1 and the other parallel tasks of WP1

- Specification and recommendation concerning the technical requirements for the developmentof the Interface

- Interface design

All specifications and designs were done with regard to existing technologies andinteroperability aspects, aspects of openness and state-of-the-art were taken into account. Even if thePABADiS approach mostly concerns technological issues it is very important always to keep in mindthe customer (market) needs in order not to loose the practical benefit. Therefore it is necessary alsoto consider new market trends and development directions. Thus avoid redundant development workand/or a development in a wrong direction.


7/58



1 ERP systems potential and standards

1.1 POTENTIAL INVESTIGATION

The current situation in plant automation can be described as oriented towards centralisation. Thesingle control (PLC, NC, CNC) have to be connected to the SCADA and then to MES system and allthese systems have to be connected to the ERP system. Whenever connection is done, the real worldsituation has to be mapped inside the governing system. Thus changes in the real world always implyre-programming or re-configuring the software.

However, the borders between the ERP, MES, SCADA and other control systems are not clearlydefined. Some functions of the MES level can either be implemented within the SCADA or within theERP system.

Competing trends that appeared and dominated in the world of ERP vendors in the last years,according to which ERP systems are either "fat" in terms of being assigned the roles of very tightly

and closely managing and/or monitoring manufacturing operations and processes, or "thin", in termsof keeping only a reduced set of responsibilities and features that facilitate time-delayed managementof the various enterprise resources and machines. Currently there is a well identified turn of the ERPvendor community towards systems that enable customisation and adaptation to the specific workingpatterns of the end user, which may be mapped for some task / process categories to the first model("fat" ERP) and for some other task / process categories to the second model ("thin" ERP).

Enterprise Resource Planning (ERP) systems are enterprise wide systems that, because of theirintegration, automate all of a company's business processes. They have rapidly become the de factoindustry standard for replacement of legacy systems. The major advantage of these systems is thatthey provide a common integrated software platform for business processes and functions.

Unlike the traditional systems, the ERP software implementations involving the implementation of pre-

developed comprehensive software applications are characterised by [KAL00]:- Primacy of the architecture; process-oriented configurability

- Primacy and direct participation of the business user

- Early risk resolution

- Early error and gap detection

- Iterative life-cycle process; negligible proportion of scrap and rework

- Changeable and configurable functionality

- Participatory and cohesive stakeholder relationship with non-IT users

- Priority of functionality over tools followed by techniques- Quality of the functional variability and flexibility of the available functionality

- Great emphasis on current, correct, complete, and consistent documentation of customizations

- Great emphasis on integration testing

- Actual demonstration of functionality at all phases of the project

- Twin categories of resource requirements; functional and technical

- Schedules devoid of long-term cascading impact

- Demonstrated performance

- Large span of scalability- Efficient integration between systems


8/58



Work commenced with the identification of the potential of the most common ERP systems byinvestigating some of the major ERP systems in the international market as well as some thin ERPsystems. The investigation took place by establishing some of the ERP systems that were in availableversions and also by referring to specialised literature on those ERPs. The investigated ERP systemswere SAP R/3, J.D.Edwards Oneworld, BaanERP, Peoplesoft 8, ORACLE ERP, Navision Damgard

from German vendors and from Greek vendors Unisoft Atlantis, Computer Logic Omega.The investigation of ERP systems potential and standards was based on their architectures andfunctionality always in regard to PABADIS needs. What has been identified about ERP systemsstandards concerned their basic elements (Client server principle, Application Modules, Databasemanagement system, Repository, Cross-Application Modules and custom applications DevelopmentLanguages), characteristics (i.e. open architecture, customisability, interoperability, portability,operation in a Real time environment), structural layers (identified as the presentation layer, theapplication layer and the database layer) and basic modules (including amongst others Accounting &Financial Module, Service Module, Warehouse & Commercial Module, Production Module and FixedAssets Module).

A typical ERP system now offers broad functional coverage nearing the best-of-breed capabilities;

vertical industry extensions; a robust technical architecture; training, documentation, implementationand process design tools; product enhancements; global support and an extensive list of software,services and technology partners. While it is not a system-in-a-box yet, the gap between its desiredand actual features is becoming smaller every day. ERP vendors, on the other hand, are not doing sowell, possibly because they have been busy developing, acquiring, or bundling new functionality sothat their packages go beyond the traditional realms of finance, materials planning & management,and human resources. Users' visions of ERP are evolving from tactical to strategic, and users are nolonger willing to choose between integration and function. Within the next two years, ERP will beredefined as a platform for enabling e-business globally. Therefore users need to be aware of thetrends within the ERP market so they can take into account all the necessary factors when making anERP software selection: product functionality, product technology requirements, vendor corporatestrategy, and vendor corporate viability.

1.1.1 Flexibility, Agility & Interoperability Enabled by AdaptableArchitecture

The rapid pace of global business nowadays places a unique set of challenges on companies lookingto improve and automate their operations, and at the same time, remain poised to adapt quickly tochange. With increased competition, deregulation, globalisation, and mergers & acquisition activity,buyers increasingly realise that architecture plays a key role in how quickly vendors can implement,maintain, expand/customise, and integrate their ERP products. These products architecture is goingto do much more than simply provide the functionality, the user interface, and the platform support. It

is going to determine whether a product is going to endure, whether it will scale to a large number ofusers, and whether it will be able to incorporate emerging technologies, all in order to accommodateincreasing user requirements.

An adaptable architecture is the least common denominator for a flexible and agile ERP system.Although a component-based architecture is not an explicit requirement for ERP flexibility,component-based applications generally provide greater flexibility than their monolithic counterparts.Further prerequisites for flexibility will be the abstraction of technical complexity (manifested via theuse of intuitive tools, aids, or wizards that guide users through a set of steps to achieve a desired endresult), intelligent messaging and workflow architectures, and an intuitive, easy-to-use user interface.

Componentisation refers to the act of breaking up large, monolithic ERP systems into individualmodules or components that would work together. It is the practical embodiment of object-oriented

programming (OOP). Object-oriented software design and programming were developed to enhancesoftware maintainability and to simplify the creation of advanced graphical user interfaces (GUIs).


9/58



Object orientation means that design, linkages, etc., use objects as their basic building blocks, whichis a radical departure from traditional 'procedural' design and coding methodologies.

An object class is a combination of data and processing logic. The data for a class may correspond toa relational database table, but this is not necessarily the case. The processing logic comes inmethods, which are similar to subroutines or procedures. By maintaining processing logic with the

data it works with, programmers have an easier time finding reusable pieces. Therefore, object-oriented systems can be significantly smaller and easier to maintain than classical procedural code inwhich procedures and data are separated.

1.1.2 Component Based ArchitectureBy breaking up the large applications into components, vendors are able to more quickly fix or addfunctionality. A component can be something as simple as a supplier record, or a more complexbusiness process or workflow. The accounts payable component, for example, could be enhancedwithout having to touch any other financial components or any of the other modules, such as planning

or logistics. And once the ERP vendor has established component architecture, it becomes easierand safer for IT to customise the systems.

Componentisation proves to be crucial to enable ERP systems to support e-business activity sincethe new e-commerce capabilities are being delivered as individual components. Componentisationalso helps the vendors extend the core ERP system with SCM, CRM, and other ERP-adjacentsolutions.

Interest in componentisation, however, began long before e-commerce. The perception at the timewas that ERP applications were too big and unwieldy, and that they needed to be more flexible.Componentisation would not only make it easier for the ERP vendors to enhance their solutions butalso make it easier for customers to upgrade the software. With componentisation, a customer couldincrementally upgrade only selected components without having to upgrade the entire ERP solution,

which usually would entail a substantial effort.In summary, component-based architecture is beneficial for the following reasons:

- It allows a developer to create a composite application in which typically a Web-based userinterface accesses functionality in the packaged application.

- It can enable message-broker-based integration of several disparate packages or legacy systems.

- It allows a vendor to roll out new versions of the application in a modular, incremental fashionrather than all at once.

- It may drastically reduce the total application code.

Componentisation is thus necessary for vendors to move their ERP systems into e-business and to

provide other capabilities and therefore most vendors insist they remain fully committed to it, althoughprogress has been moderate. The reason for this lies in the fact that componentisation is enormouslydifficult to achieve even when the commitment is solid. With some honourable exceptions, most Tier 1vendors have mostly succeeded in creating large-grain proprietary components, which are simplylarge function modules. On the other hand, IFS leads the pack of more nimble mid-market ERPvendors that have either entirely or to a significant degree componentized their products.

Implementing a fully component-based architecture requires that vendors completely redesign theirapplications and then rewrite it using C++, Java, or a component-based 4GL, and run it undercomponent object model (COM), common object request broker architecture (CORBA), .NET (in thefuture), or Enterprise JavaBeans (EJBs). Some vendors who had attempted this approach haveexperienced a harrowing, time- and-resource-consuming, make-or-break transition. We believe that

less than 45% of ERP vendors will deliver a completely component-based architecture within the nextfour years (70% probability). We also believe that the first vendors who deliver a truly open, modularsystem will capture the lion's share of the remaining non-penetrated ERP market.


10/58



1.1.3 Open Interfaces and Improved IntegrationWhile ERP customers may not be fully aware of the benefits of componentisation as yet, they havebeen embracing the more open interfaces and improved integration capabilities that the vendors areproviding, capabilities also intended for the componentisation effort.

During the past few years, ERP vendors have opened up their tightly interwoven modules and createdapplication programming interfaces (APIs) to connect to 3rd-party best-of-breed systems. ERPvendors are offering a broad range of open integration schemas, including extensible mark-uplanguage (XML) messaging and proprietary connectors or open APIs, since easy integration to 3rd-party applications has become a key selling point for them.

SAP, for example, has created over 1,000 business application programming interfaces (BAPIs) foruse in integrating third-party products with the core ERP system as well as applications linkingenablement (ALE) via interchange documents (IDOCs), standard flat file formats for commoninformation exchanges. This requires open APIs to enable the integration of third-party data reportingand analysis tools as well as other above-mentioned ERP extension tools.

Instead of the costly, risky moves to full componentisation, most ERP vendors have selected a safer

approach. They use component-based APIs to construct a "faade" for their existing application.When done properly, these APIs provide programmatic access to common business objects (e.g., anorder, a business partner, a delivery), which are mapped to the existing application's functionality in away that shields users from the complexity of the underlying code. However, APIs alone are notsufficient. To bridge the differing semantics and business processes enabled within each participatingapplication in an extended ERP environment, either vendors or users must employ message brokertechnology (a special-purpose, preferably 4GL tool that can readily transform and route data as itmoves between applications).

1.1.4 Implications of this trendDespite the user preference for a single, 'one-stop shop' vendor, componentized software products,interoperability standards and Internet technology will lead to fewer large-scale projects and anongoing stream of smaller ones. Easy integration to 3rd-party applications has become a key sellingpoint for ERP vendors as thus many of them tout the provision of connectors to/from their systemsand/or provision of integration development tools (e.g., Forte or Progress Software). However, usersshould vigorously question their potential enterprise applications providers regarding:

- Their interoperability standards (e.g., Open Applications Group Integration)

- Specifications (OAGIS), XML, etc.) that are supported

- Provision of a message-based flexible interface or a rigid code-based integration

- Provision of basic batch-run interfaces or more advanced real-time, interactive two-wayconnections between applications

1.1.5 An ERP Vendor exampleIn order develop a new solution it is necessary to carry out a deep market analysis to recognise whichproducts with which properties are already established at the market. Concerning this analysis thefollowing figure shows a ranking mention the top 4 of the ERP vendor companies.


11/58



SAP

Oracle

Peoplesoft

J.D. Edwards

other

30 %

15 %8 %5 %

42 %

Turnover in 1999 (licences and services for ERP-products )

Figure 1: Ranking of the top 4 of the ERP vendor companies

As the SAP system is the worlds leading ERP solution the following aspects are mainly related toSAP R/3 solution. This chapter briefly describes the business technology platform and how thestandard SAP communication techniques (i.e. Idocs, BAPIs and RFCs) can be easily enabled forusing XML and the SAP Business Connector version 3.5. A brief description of each of the mainfunctions of Idoc, BAPI and RFC are presented in the AnnexI (A more detailed description can be

found in technical papers in the references).[SAP]

Figure 2: SAP Architecture


12/58



1.2 STANDARDS IDENTIFICATIONStandards providing significant benefits for the configuration of the individual systems are animportant issue also for the easy modification and configuration of ERP connection to PABADISsystem. The interface that is going to be developed needs ERP standards identification in order basicelements and characteristics to be recognised and used to develop the appropriate interface. The

standardisation of data, functions and processes leads to integrated information flows, while a broadvariety of standards which have been developed in the field of information technology are available atvarious levels and originated from different standardisation bodies. Although it would be desirablefrom a technological standpoint to have a single accepted standard world-wide, the variety that existsreflects the heterogeneity of the individual ERP vendors as also the difference in industrialneeds.[HUB00], [BRO00], [JEN00]

1.2.1 Basic elements

Client server principle: With an optimal functional use of the three tier architecture, that is partitionedinto three functional groups for handling the presentation, application and the database services.

The initial strategy of client/server developers was to offload as much application processing aspossible onto desktop client computers. Managing desktop applications across hundreds, possiblythousands of desktop systems, was a maintenance nightmare. Also, as the desktop applicationcomponent became more sophisticated, the hardware requirements for the desktop computerincreased, and so too did the cost of these systems. To help alleviate the impact of this problem,developers added a middle-tier server that was used to balance the application processing betweenthe client and the backend corporate server, and also to manage the distribution of software andapplications to desktop systems. This middle-tier server typically ran Microsoft Windows NT or UNIX,and consisted of hardware built, like desktop computers, from low-cost off-the-shelf components.

A decentralised client server solution can provide the following advantages:

- Possible to achieve near instant response times.

- Greater available time to users. The mainframe solution requires regular batch jobs to be runwithout users logged on to the system making. R/3 still requires batch jobs but is possible toachieve a greater window of available time.

- A friendlier user interface is possible with PC workstations as opposed to dumb mainframeterminals.

- The architecture promotes open systems, where components and peripherals can be used frommultiple vendors thus promoting competition and reducing hardware costs.

Application Modules, address functionality commonly used in enterprises. Usually an ERP consistsof the following modules: Asset Management, Controlling, Financial Accounting, Human Resources,Industry Specific Solutions, Plant Maintenance, Production Planning, Project System, QualityManagement, Sales and Distribution, Materials Management, Business Work Flow.


13/58



Service

Module

Warehouse &

Commercial Module

ProductionModule

Fixed AssetsModule

Accounting &

Financial Module

CRM SCM

Figure 3: Basic ERP logical modules and interconnection pathways amongst them

Database management system, which are responsible for the storage of the information. Ew candefine the above types of databases:

Object Databases are used mainly for Web-based database applications, which by their

nature involve a variety of different types of data. The performance overheads andproprietary design of these products, however, make them unsuitable for mass use.

Relational Databases products from vendors like IBM, Informix, Microsoft, Oracle, andSybase dominate database use in both the operational transactional and businessintelligence processing environments. These products have evolved from supportingstandard tabular data structures to providing SQL capabilities that handle a wide variety ofdifferent types of data and processing.

Java Relational Databases provide SQL-driven relational database features, have lowresource requirements, that are easy to install and manage, and that are written entirely inJava to provide a write once run anywhere capability. The biggest advantage Javadatabase products bring to IT organisations is the portability offered by the Java

environment. It makes it very simple for these database systems (and thus databaseapplications) to be rapidly deployed on any system that supports a Java runtimeenvironment.

Special real-time database systems are required for real-time acquisition and control ofdata, since conventional database systems do not have the responsiveness necessary tosupport rapid acquisition of data. For example, data may need to be time-stamped, sothose events can be synchronised at a later time in a conventional computing environment.

Repository is the central collection area for access or information on every kind of development inthe system. It provides the essential information on structure and design of the whole application to all

the other modules or systems. It records the information model of the system in terms of the entities,attributes, relations, processes, views and scenarios of the system. It contains information on everysingle program, file, and data item in the system. This includes information on the various


14/58



components and elements identity, purpose, type, and nature defining attributes, process cycles andtimes, sizing and so on.

Cross-Application Modules: which provide functionality across the basic application modules. The

interfaces of the module with other modules could be shown for example bellow:- Finance and Commercial - Purchase orders, supplier invoices, payments to suppliers, inventory

movements, quality inspection, stock inventory, physical inventory differences, paymentprograms, and so forth

- Commercial and Warehouse - Availability checking, scheduling deliveries, credit checking,material shipments, transfers of inventory between plants, material determination, materialexclusion, material substitution, reorder points, and so forth

Custom applications Development Language: That gives the ability of easy customisation andsystem integration. This language supported with a specific environment provides all the necessary

facilities, tools and aids for design, development, and testing of application data tables, screens,programs, inquiries and reports. Most of these languages are object oriented and can have a classlibrary.

1.2.2 Basic Characteristics

Open Architecture: Enables the co-operation and integration of applications, data and interfaces within all the levels of an ERP system as also with external systems. So an ERP can work flexibleconnecting for example the levels of the graphical user interface, application, database, hardware,

operational system, e.t.c.

Customisability: by providing a quick and easy environment for analysing, designing and configuringbusiness processes easily, quickly and efficiently. This capability is an important factor when newfunctionality is wanted to be designed to the ERP, so that no many changes take place in the internalorganisation of a company.

Interoperability: The capability of using internationally recognised standards that allow easyintegration with other applications. With this ability to use resources from diverse origins as if they hadbeen designed as part of system. Individual interoperability problems may disappear as such

resources literally become part of a single system through integration and standardisation, but theproblem of interoperability itself never disappears it simply moves up to a new level of complexitythat accepts earlier integration as a given.

Portability: Which gives the platform independence ability of using different Hardware and O/Splatforms, as also enables any installations to benefit from the latest developments in infrastructuretechnologies (hardware, operational systems, DBMS, e.t.c.) without disrupting the ERP system inproduction for example.

Real Time environment: Immediate updates that are available instantly to all logically related

processes and modules. The system must support an online system that provides direct registrationof business transaction. These can happen with supporting real fast communication protocols as alsoreal time databases and application servers.


15/58



1.2.3 Architectural LayersThe figure below shows the shows ERPs components from a functional as well as an infrastructuralpoint of view (figure 4). From a functional point of view, the top layer is the presentation layer that ismade of the GUI system. The middle layer is the application layer that handles not only businessapplications, but also the middleware layer. Integration of all business applications relies on this

system. This system includes components such as ERPs customisation language, systemsadministration tools, authorisation and security systems and cross application systems. The lowerlayer represents the network, the database and the operating system. [LAU00]

The layers of an ERP that could interfere with the PABADIS system and where a needed interface willbe based will be:

- The presentation layer that manages the dialog between the end-user and the applicationprogram.

- The application layer that performs the actual transformation of the data that make the applicationwork.

- The database layer that stores, updates and retrieves required data by using the programs in theapplication layer.

DATABASE LAYER

PRESENTATION LAYER

INTERNET LAYER

APPLICATION LAYER

APPLICATION MIDDLEWARE LAYER

HARDWARE LAYER

OPERATING SYSTEM LAYER

Figure 4: ERP system Structural Layers

1.2.4 IntegrationOne of the main issues that enterprises care and ERP vendors are working on is the ability ofintegrating ERP systems, with other information systems by building the necessary interface forestablishing communication between these systems. Focusing on this capability of ERP systems wecan be able to specify the Interfaces that can interconnect ERP with the PABADIS system.

In the complex and dynamic enterprise environment homogenous ERP architectures are no longerpractical options. Many organisations are changing their strategies from a traditional point-to-pointintegration strategy to a more proactive approach of building and evolving a standardised integrationarchitecture capability that enables fast assembly and disassembly of corresponding business

software components. Systems integration could differentiate between three types of applications[OST00]:


16/58



- Homogeneous with one instance: One process is supported by one application and one database.This model avoids the problems emerging from redundant data storage and asynchronous dataexchange between separated applications.

- Homogeneous with several instances: Several identical processes in different business units aresupported by several identical applications that run on different computers and rely on logically

separated databases. An example for that kind of integration is the Application Link Enabling(ALE) from SAP, which provides a mechanism for the coordination of master and transactionaldata in physically distributed SAP environments.

- Heterogeneous: Several different processes in different business units are supported by severaldifferent applications. An additional problem compared to the integration in a homogeneousenvironment is, that the concerned applications are built upon divergent data models, whichmeans that they provide different semantics of the data to be exchanged.

A common language is required for the integration of heterogeneous systems and could have fourlevels (figure 5).

Pragmatics

Semantics

Syntax

CommunicationServices

FunctionlevelPragmatics

Semantics

Syntax

Objectlevel

Datalevel

Standardsfor datacommunication CommunicationServices

System I System II

Figure 5: Four levels for integration of heterogeneous systems

A common syntax is required which defines the order, length and the type of data being exchanged.The definition of a common syntax is not sufficient for an automated integration of systems. Semanticis needed to assign real world subjects and notions to the transmitted characters by adding a certainmeaning to individual data fields. The bases for such interpretations are key fields that today are

mostly defined by each company itself. Without open semantic standards an automated exchange ofinformation among anonymous systems will remain illusive because it will require a humaninterpreter. The third element - the pragmatic element - is a feature of sophisticated workflow systemsand it makes sure that transmitted data has not only been understood but that subsequent actions aretriggered.


17/58



1.3 ERPs evaluation description

mySAPJDEdwardOneWorld

NavisionDamgard

BaanERP Peoplesoft8 Oracle E

Presentation Web Browser; Java;Windows; MobileDevices

Web Browser / HTML;Java; Windows

32-bit Windows 95;Windows 98;Windows NT (Intel);Windows 2000; WebBrowser

Web Browser/HTML; MSWindows Systems

Web Browser / HTML;PeopleSoft 8 powerHTML; PC,Macintosh, Linux,Unix, Thin ClientComputing Devices,or mobile devices.

Web Browser; HWML; JSP

Client serverprinciple

Multi client structure five functionalelements database, datawarehouse, businessobjects, reporting, andGUI;

Windows-basedclient/server structure

No code on the client Presentation laseperated frombusiness layer

CommunicationEnvironment

HTTP/ XML /SOAP;.NET/COM+;Java/CORBA; ODBC

XML; COM/DCOM;Java/CORBA; ODBC XML, EDIFACT;C/ODBC driver XML; DHTML;ODBC XML over HTTP;COM; CORBA; Java;ODBC

XML (Oracle XMGateway); JavaJDBC; HTML; SODBC; OLEDBOCI; JMS

SupportedCommunicationInterfaces

IBM's MQ Series IBM's MQ Series;Microsoft MS MQ;Biztalk

SAP IDOC and flatfiles, using an XMLstandard via MSBizTalkServer

IBM MQSeries;Wonderware'sFactorySuite(MES module);Seagate reportingtools

X.12 or EDIFACT IBM MQ SeriesMS MQ

ProgrammingLanguages

Java/JavaScript;Visual Basic/C#;C/C++

C; C++; C/AL C++ API (Java, COM,C/C++)

Java

CustomapplicationsDevelopmentLanguage

ABAP Objects OneWorld Toolset;C based APIs;ActivEra

C/Side Dynamic Enterprisemodelling (DEM)


18/58


19/58


20/58



OpenArchitecture

Customisability Interoperability Portability Real Timeenvironment

mySAP XXXX XXXX XXXXX XXXX XXXXX

BaanERP XXXX XXXX XXXX XXXXX XXXX

JDEdwards OneWorld XXXX XXXXX XXXX XXXX XXXX

Peoplesoft 8 XXXXX XXX XXX XXX XX

Oracle ERP XXXX XXX XXX XXX XX

Navision Damgard XXX XXXX XXX XXXX XXX

Unisoft Atlantis XXX XXXX XXX XX XXX

Computer LogiC Omega XXX XXX XXX XX X

Table 2: ERP basic characteristics

In table 1 we have a description of all the basic specifications that followed our investigation and fromwhere we have identified the ERP standards. Also in table 2 we evaluated the ERP based on:

the characteristics that an ERP must have (described more detailed in paragraph 1.2.2) inorder to be able to support efficiently the PABADIS system

As also the specifications of each ERP described in detail in table 1.

Rating of ERP basic characteristics

XXXXX Full support - Best practiceXXXX SupportXXX Partially supportXX Few signs and indicationsX Not available


21/58



1.4 PRODUCTION MODULEThe ERPs production module deals with the implementation and management of the ProductionPlaning process that is a complicated issue and concerns the harmonised management of customerdemands, production capabilities and resources (materials, employees, machines) availability across

the two directions of a companys Supply Chain.ERPs Production Module is responsible for :

- Material Requirements Planning (MRP), that sets off requirements resulting from product demandmanagement and sales against stock. It also enables the unique assignment of requirements andstock on a detailed level.

- Resource Planning, that is responsible for the availability of labour and machines

- Personnel Planning, a planning of employs based on skills of person.

- Material Flow Planning, where allocation and reassignment of Work-in-Process materials

As a common feature Production Planning must handle one or all of the manufacturing processes like

the following:

- Continuous manufacturing, which is mainly driven by the production process infrastructure. Unlikethe traditional MRP II systems, the master production scheduling must be synchronised with thecapacity plan from the beginning. Other characteristic features include coproducts, processmanufacturing, formulation management, maintenance, and multiple units of measure. This typeof manufacturing process typically is for the creation of interim raw materials required by othermanufacturing plants within the same company or by other facilities.

- Repetitive manufacturing is involved with creating large volumes and standard product. Thesystem tracks the material, quality, cost of material, and machinery across all stages of thesystems. Such systems typically backflush consumed materials from inventory or work-in-process.The amount of consumed materials is based on calculated average values rather than actualobserved consumption of inventory. These systems also attempt to schedule runs and certainequipment for fixed intervals of time

- Make-to-stock. For this type of manufacturing, the volumes are not as large as those for repetitivemanufacturing. Often these systems do not have very deep BOMs. They also use standard lotsizes, for which a standard cost can be determined and compared easily with the actual cost.

- Assemble-to-order. This is the only manufacturing process that is customised for the requirementsof the customer at an optimal cost. The manufacturer or its representative dealers must storevarious assemblies, aggregates, and parts to quickly assemble an order in accordance with thespecifications of the customer. Other characteristics include product configuration, contractmanufacturing, shop-floor control and costing, sophisticated routing and tracking, distribution and

inventory staging, multiplant scheduling, and interfacing with engineering and integration.Examples of this process are the manufacturing processes in automobile and personal computerand workstation industries.

- Engineer-to-order. The volume of the products in this type of manufacturing is low, but thecomplexity of the designs and the finished products tend to be very high. They are typicallyengineered and manufactured for a specific customer. Key characteristics required here arecontract manufacturing, shop-floor control and costing, sophisticated manufacturing (CAD/CAM),and integration. Costs and turnaround times are quite high, machinery, airplanes, and defenseproducts.

A production planning for manufacturing an order can be divided into various phases in order to havein a higher level a view of the manufacturing process. A phase can consist of various sub-processes

and individual tasks of machines regarding the amount of detail we want in monitoring amanufacturing order. Available information for every production phase could be the below:

- Detailed set of diagrams about the current production plan for a specific period :


22/58



- Required machines availability for the specific products creation

- Required employees availability for the specific products creation

- Required materials availability for the specific products creation

- Detailed description of the required resources for the specific orders fulfilment.

- Detailed technical Specifications of the ordered product

- Ordered products desired quantity

- Ordered products desired delivery date

- Customers priority

- Products detailed technical specifications concerning the specific phase

- Required materials for the specific phase

- Required employees for the specific phase

- Required machines for the specific phase

- Orders priority

The Production module is identified as the basic "interface" of the ERP system with the PABADISsystem (including in the system also the interface with the ERP) and it is the module where the usersets requests to the machines and receives and processes data from the machines. The productagent PA can carry data from the CMUs to ERPs database concerning:

- Resource's (employees, machines, materials) availability during a specific time interval.

- Prototype technical specifications that the customer requires will be respected, during theproduction process.

- Machine's technical specifications and employees capabilities.

Figure 6, shows the ERPs Production Module involvement in the PABADIS system, where is isresponsible for the realisation of enterprises Production Planing by the harmonised management ofthe required resources, investigating materials, employees and machines availability.


23/58



XM L Service M odule

Materials

availability

Employees

availabilityMachines

availability

C R MS C M

Production

ModuleFixed Assets

Module

Warehouse &

Commercial

Service

Module

Accounting

& Financial

CMU

XM L-parser

RA

. . .XMLDocPA

XMLDocPA XML

DocPAXMLDocPA

CMU

XM L-parser

RACMU

XM L-parser

RA

Agency

Figure 6: ERP Production Module in Pabadis


24/58



2 Interface specifications

Task 1.5 concerning ERP interface specification and design, comprising issues related to the

identification of potential ERP systems and standards, the specification and recommendationconcerning the technical requirements, concluding to the outline of interface design aspects, as thesehave to be implemented in Task 4.1 concerning the Interface development.

In this respect, similarly to the positioning of Work package 1 which stands at the beginning of theentire project, thus laying the fundament for all other work in the project, Task 1.5 is to be understoodas a frame which will ensure that the subsequent work to be taken within the stream of activitiesrelated to the ERP interface will be efficiently implemented taking into account the design of theoverall model from ERP to shop floor, as this is defined by means of both technological choices, e.g.communication languages, protocols and communication infrastructures and the specifiedfunctionality within agents and protocol layers and specification of information flows within the factoryenvironment.

2.1 TECHNOLOGICAL ENVIRONMENT

Nowadays the world of industry faces significant interoperability issues as it seeks to architectsolutions for distributed systems composed of clients and servers of heterogeneous hosts to enable joint service operations. The extensible Mark-up Language (XML) and related technologies offerpromise for applying data management technology to documents and, also, for providing a neutralsyntax for interoperability among disparate systems. This is an evolutionary metadata language,approved as a standard by the World Wide Web Consortium in February 1998. XML evolved from the

Standard Generalised Mark-up Language (SGML) as a compromise between the complex SGML andthe simple, but non-extensible HTML. It has been described as providing 80% of the benefit of SGMLwith 20% of the effort and it is being embraced by a broad cross-section of the industry as the rightlanguage for defining the APIs necessary to make business software components talk to each other.

Figure 7: XML description


25/58



XML is actually a language for creating mark-up languages that describe data and rules about thedata. It requires applications to be defined to it before it can become truly useful. The process ofdefining applications is done through the use of the Document Type Definition, which defines the tagsand rules within XML for a well-formed XML document. In the context of the project, and taking into

account the available resources as well as the overall project aims, we will head towards definingrepresentative tags and rules for software component interoperability in the supported applications.[XML1]

The adoption of XML and of other leading edge software technologies in order to enableinteroperability among dissimilar databases and message formats seems to be an efficient andeffective solution approach within which is investigated the utility of the XML to write translator(s)between message formats and databases to reduce operator burden and to increase interoperability.Further, we investigated other leading-edge software technologies to address the informationportability issues associated with distributed systems; i.e., JAVA, JINI.

In this respect, the XML Service Integration Application can be implemented in a way that enables itto support all kinds of applications and services that can be connected through a standard TCP/IPport making use of the XML that is data base-neutral, operating system-neutral, and device-neutral,and as a result, an effective tool for defining heterogeneous interoperability. Because of the neutralcharacteristics, the XML integration can be used also from other 3rd vendors / application not only forthe PABADIS scope but also facilitating connectivity of the project developments with further post-project developments.

However, the focus of the experimental distributed architecture that will be implemented deals withthe provision of a solution for the interoperability problems faced by PABADIS consortium which arealso typical of those being addressed by government, industry and academia nation-wide. Theproblems and issues are in the areas of software architecture and database interoperability fordistributed systems and so attempts aiming to leverage middleware (CORBA, JINI, XML, AGENTS,etc.) for implementation purposes were taken during the analysis phase.

Likewise, database interoperability techniques have become very standardised in the past five years,exploiting middleware and open standards; i.e.,Open DataBase Connectivity (ODBC), as a means toallow different databases to interact.

Open Database Connectivity (ODBC) is an open standard Application Programming Interface (API)for accessing different Database Management Systems-DBMSs (Access, dBase, DB2, Excel, andText) with the same source code, based on the Open Group standard Structured Query Language(SQL) aiming to allow programs to use SQL requests that will access databases without having toknow the proprietary interfaces to the databases handling the SQL request and converting it into arequest that the individual database system understands.

Database applications call functions in the ODBC interface, which are implemented in database-

specific modules called drivers. The use of drivers isolates applications from database-specific calls inthe same way that printer drivers isolate word processing programs from printer-specific commands.Because drivers are loaded at run time, a user only has to add a new driver to access a new DBMS.


26/58



Figure 8: Open Database Connectivity description

However, what has been lacking is the ability to merge software architectural approaches anddatabase interoperability techniques into a synergistic approach that offers a unified meta-model tospecify distributed applications. Such a meta-model would be all encompassing, to allow softwarearchitectural, hardware and database requirements to be specified and, once specified, to facilitatethe transition to a working distributed system. In the long-term, the task is to develop an integrated,unified meta-model that is able to support the software architectural specification and databaseinteroperability requirements of a distributed system. In the short term, issues related to databaseinteroperability have to be managed, as well as message translation.

For achieving the technical objectives of this Task, the following has been regarded as yardsticksagainst which the progress of the work will be measured in later reviews and assessments of work inTask 4.1 where the PABADIS ERP interface will be developed:

The first is disconnected operation of devices, and the agents they host or communicatewith. Mobile network bandwidth is generally poor, and interruptions can be frequent andunforeseen. This means that the PABADIS agents must be autonomous: they must havesufficient code and data resources to continue functioning even when their host site hasbecome disconnected. In addition, mechanisms must exist to handle data consistencyissues when the various virtual devices reconnect to a network and data updates must bepropagated.

A second aspect for the agent infrastructure is co-ordination. In a wireless or ad hocnetwork, as the trend in factory environments will becoming more and more apparent, theset of co-operating PABADIS agents will have to be able to change frequently, as agentsbecome disconnected or simply leave the network. The ERP interface must neverthelessprovide a means to co-ordinate the actions of all agents, enable them to gain access to theinformation that they need, and to locate other agents that they need to communicate with.

A third aspect that we studied extensively is security; in a distributed environment, there isa great deal of user autonomy that makes authentication and controlling data access muchharder.


27/58



2.2 Possible Interfacing scenarios

Hardware Interface (HI), the physical and logical arrangements supporting the attachment of anydevice to a connector or to another device. JINI/PINI will be used as background technology for HI

support and implementation.Application Programming Interface (API), the specific method prescribed by an applicationprogram by which a programmer can make requests to the operating system, to another application,device or system. The appropriate combination of required technologies will be thoroughlyinvestigated for APIs support and implementation.

User Interface (UI), consisted of a set of dials, knobs, operating system commands, graphical displayformats and other devices provided by a computer or a program to allow the user to communicatewith the system. ERPs GUI will be used for UI support and implementation.

GUI

?

JINI/PINI

Hardware Layer

Internet Layer

Presentation Layer

Operating System Layer

Database System Layer

Application Layer

Application Middleware Layer

UserInterface

Application

ProgrammingInterfac

e

HardwareInterface

Figure 9: Interfacing scenarios

2.3 Manufacturing order

The manufacturing process according to the PABADIS system starts with the generation of aconventional manufacturing order by the ERP system which consists of all the needed information forthe product to be manufactured. This order comprises the sequence of required processing stepstogether with the appropriate parameters.

his information that consists of structured data will be transmitted to the Agency in an XML formatwhere it is translated into a product agent and joins the multi-agent system. Throughout themanufacturing process, the product agent guides the work. Upon completion, it returns to the agencyand is terminated there. The agency then generates a report to the ERP system, using data the agenthas collected on its way through the production (if so desired by the ERP system in the manufacturingorder). A manufacturing order consists of product's prototype technical specifications, accompanied

with desired delivery date, required quantity and customers priority. A detailed list is showed in figure10.


28/58



order order number / type, description, factory

dates requested, beginning, finished

quantities ordered, sent, cancelled, produced, waste, in work

state and type state / remark, working plan type, parts list type, type, fixing code

category codes phase, state, service type, experiences, knowledge

persons customer, client, supervisor, planner

details priority, batch / series, cost centre, cost unit rate, list of material, short message,

working place / -description

parts availability level, quantity, quantity available, quantity required, loss, deadline, article running time

Figure 10: Useful information in a manufacturing order

In the next paragraphs we will identify two ways of communicating with the PABADIS system from theERP system, by sending an order for execution and by sending some queries for controlling thestatus and the availability of each machine its input and output. These all data and queries arestructured in an XML file. The metadata that describe these data are the "keys" for generating the

appropriate agents from the Agency.

2.3.1 Sending an order for executionOne of the basic functionality that the PABADIS system will have is the capability of sending amanufacturing order to the machines in order to be executed. What has been identified is that not allthe information of a manufacturing order is needed for the CMUs to execute an order.

For example, in figure 11, all the data of a manufacturing order can be exported from an ERP in anXML file, structured by the use of metadata. Metadata are showed inside the tags (,) and arespecific for each ERP system. In the case of the PABADIS system generic Metadata are going to bedefined like the ones given in the figures below. However, all these data is not needed from the CMUto execute the order, so we have marked with yellow an example of needed data from the machines.

So what is needed is from the Agency is to locate the appropriate metadata from the XML file (figure12) that will generate the agents needed for communication with the machines. In order amanufacturing order to be executed we use MES functionality Resource allocation, Operations andscheduling, distributed in PA tasks. These PA tasks are generated by the corresponding metadata.


29/58



Order< number> ..

< type> .. < /type>< descri tion> .. < /description>

.. < su ervisor> ..

< lanner> .. < factory> .. < /factory>< riorit > .. < /priority>

Dates .. < beginning> ..

< finished> ..

Product< id> ..

< descri tion> .. < /description>

.. < /quantity>< hases> .. < begin> .. < finish> ..

< riorit > .. < /priority>

Materials< id> ..

< type> .. < /type>< descri tion> .. < /description>

< roduct> .. < /quantity>

.. < begin> .. < finish> ..

< priority> .. < /priority>

Phase

< description> .. < /description> ..

< begin> .. < finish> ..


Service< description> .. < /description>

.. < begin> .. < finish> ..


Figure 11: Example of structured data of a manufacturing order in an XML file


30/58



Order< order id> ..

< factory> .. < /factory>< riorit > .. < /priority>

< be innin > .. < finished> ..

Product

< id> .. .. < /quantity>< hases> .. < be in> .. < finish> ..

< riorit > .. < /priority>

Materials< id> ..

.. < /quantity> ..



Phase

< description> .. < /description> ..



Figure 12: Appropriate for the Agency metadata from a manufacturing order in an XML file

2.3.2 Controlling the status of the orderWorking on a different way and trying to receive data from the CMU, in order to control the status ofthe machines, is another capability that can be added in the ERP, as also in the PABADIS system. InFigures 13&14, this XML file that follows can be exported from an ERP and transported to the CMUs,with red colour are information that the ERP needs from the machines. Inside these file,we can alsohave data that are needed from the machine to allocate first the product that we are interested for andalso queries for asking data from the CMUs for the status of the machine what is its input, output andcurrent process.

Materials availability (raw or semiproducts)

< uantit >, , < uantit re uired>

< loss>

Product status

.. ..

.. < roduced> .. < in work> ..

< phase> ..

< service t e> .. < be in> .. < finish> ..

Quantity-Amount of :

Current statusof a product

Figure 13: Example of structured data for controlling the status of the machine (continues)


31/58



Materials status

.. < sent> ..

.. < roduced> ..

< waste> .. < in work> ..

< phase> ..

< service t e> .. < begin> .. < finish> ..

Phase status

.. ..

< waste> .. < in work> ..

< hase> .. < product> ..

< be in> .. < finish> ..

Quantity Amount of :


Current statusof a product ormaterial


Figure 14: Example of structured data for controlling the status of the machine

Knowing the status of the machines from the ERPs site is a useful tool also for the user which canmonitor them but also for information that can be used from production planning for knowing themachine availability and plan schedules for another product. In order to use this information to theproduction planning of an order we use MES functionality Resource Status - Product trackingdistributed in PA tasks (missions). In figure15, we can see a simple form from an XML file that can besend to the CMUs (via Agency of course) and ask about the current status of a product by giving its idnumber and five queries. The CMU tracks the product and sends back its current status by replacingqueries with data.

696996060

< hase> Query < service type> Query

Query < be in> Query < finish> Query

5 tasks for the PAs to beprocessed to Agency--->CMU

696996060 < hase> A

< service t e> drilling Normal < be in> 1130 < finish> 1230

Returned information bythe PA from the Agency

Figure 15: XML file send to the machines and received back for knowing


32/58



2.4 Logical View of the interfaceThe logical view of tasks concerning interoperability is divided into two related views concerning theparticipating entities in the interoperability process [CIERP]:

- A direct ERP Database to another ERP Database Interoperability

- A message to message interoperability concerning message exchange amongst entities of acommunity

- The combination of the above two cases that results to an indirect ERP Database (crossing theCMU community) to another (or same) ERP Database Interoperability,

2.4.1 A direct ERP Database to another ERP Database InteroperabilityAs depicted in Figure 16 that follows, a PABADIS AGENTS Object Translator extracts (by SQLstatements - reads) from an ERP database pertinent data and translates the data into XML. Asshown, XML is input to a second PABADIS AGENTS Object Translator (via the dotted line is on the

same LAN), which translates the XML to inject into the Access database (by SQL statements -writes). The functionality is SQL to XML extract, XML to SQL inject using PABADIS AGENTS ObjectsTranslators.

Figure 16: Direct ERP Database - ERP Database Interoperability

2.4.2 Message to Message InteroperabilityReferring to figure that follows, the XML from the prior database-to-database translation becomes theinput to a third PABADIS AGENTS Object translator and depending on the destination, a message isgenerated. At the receiving end the message is translated to XML via another PABADIS AGENTS

Object translator and serves as an input to the database-to-database interoperability square.


33/58



Figure 17: Message to Message Interoperability

2.4.3 Indirect ERPs Database to ERPs Database InteroperabilityA composite of the two previous cases illustrates the complete solution approach concerning theseamless integration amongst any ERP database with any third party entity by the use of the XMLand PABADIS AGENTS platform.

The above-described approach provides a possible solution to need for message and databaseinteroperability to reduce operator burden. The task investigated the utility of the XML to writetranslator(s) between message formats and databases making use of the already developedPABADIS AGENTS platform to reduce operator burden and to increase interoperability.

This approach, as it was shown above, provides a theoretical background that will be instantiated in aphysical model in order to correspond to the PABADIS integration requirements between ERP andPabadis CMU community.

Figure 18: Indirect ERP Database - ERP Database Interoperability


34/58



3 Interface Design

3.1 The proposed Integration ToolTaking into account the conducted analysis concerned the possible interoperability technologies thatcan be adopted in order to satisfy PABADIS integration requirements concerning communicationactivities that take place between CMU community and the ERP system the to be developedIntegration tool will be consisted of two parts:

The Server (Middle-ware Application) which:

- Allows Multiple Clients connections in separate Threads

- Accepts Requests and Send Responses

The Configurator (Configures the Server) which

- Is responsible for setting up the RDBMS connection

- Prepares the SQL statements for dynamic execution

- Describes the content

Towards the finalisation of the integration, the following are to be taken into account:

- Configuration: Provide a Tool for Configure the Middle-ware Application (Configurator)

- Connectivity: Using Standard TCP/IP Protocol

- Data Exchange: Using XML

- Usage Tools: Provision of specific (Client Side) APIs for develop - implement CustomApplications

- Future Extensions will concern: SOAP and XMIThe manufacturing process according to the PABADIS system starts with the generation of aconventional production order by the ERP system. This order comprises the sequence of requiredprocessing steps together with the appropriate parameters. The production order is passed to theAgency, where it is translated into a product agent and joins the multi-agent system. Throughout themanufacturing process, the product agent guides the workpiece. Upon completion, it returns to theagency and is terminated there. The agency then generates a report to the ERP system using thedata the agent has collected on its way through the production (if so desired by the ERP system in theproduction order). In parallel, plant management agents are created by the Agency to fulfil specificcontrol or supervision tasks that are not related to individual products (figure 19).


35/58



Enterprise Resource Planing

DB TriggerExpector

trigger

SQLRequest

SQLReply

XML Document

XML

Doc

DataBaseXML

ServiceModule

SQLConfigurator

Data Collector

Agency

FabricatorPA

PMA

Application

Server

PABADIS ERP INTERFACE

Figure 19: Description of the PABADIS ERP Interface

3.1.1 XML Service ModuleThe XML Service Module receives or sends XML documents from an agreed port using TCP/IP. ThisXML service is on the side of IS. On one site there could be an entity of CMUs community or any thirdpartly application which want to communicate with an ERP system or any Database that resides in theother side, through (by making use of) the XML service module.

The entity of Pabadis CMU community initially sends to the XML service module an XML request

document, which must be executed on the specific ERPs database. This XML request document hasusually a number of parameters (if the request is for example a read or update or delete action query,the XML request for the insert action query differs from the others it doesnt have parameters butfields and values, see more details in SQLXMLFILE Structure) and its values.

The XML service module parses this XML request document, gets the name of the Predefined ObjectName.sqlxml that has information for the construction of the SQL statement, parses also theparameters and the values or the fields and the values for the insert.

Finally the XML Service module gets all the information from the .sqlxml file and from the XMLrequest document in order to construct the SQL statement. Then executes this SQL statement, andgets back a result dataset (records) or a standard XML response document for the insert, update,insert (see SQLXMLFILE Structure). This output is transformed again in XML (XML response) and issend to the CMU community.

In general the communication between the XML service module and the CMU community will beinteractive, that means that the CMU community can be connected to the XML service module anytime, request a query and get the result data. On the other hand, the XML service module will beconnected to the community, sending the result data from a query in the ERP system or databaseinform it about changes in the ERP system or database and expect or not answer from it.

3.1.2 SQL Configurator

The Configurator is an application, which helps the user to create SQLXML file. The program uses thefiles which filename is db.ini in order to establish a connection with a database. These files arestored to a different path according to the database aliases. For example if the root directory of theConfigurator is d:\sqlconf and a user wants to create a new connection with a database whose alias


36/58



is Atlantis then in the path d:\sqlconf\atlantis a new file with name db.ini will be created. The db.ini(see figure below) file has all the necessary parameters for the user to logon to the database.

[CONFIGURATION]

DATABASE_ALIAS=atlantisUSERNAME=prod

PASSWORD=p123

SELECT * FROM CUSTTBL

WHERE .

SELECT * FROM RTDTBL

WHERE .

. . .

Get Customers

. . .

SELECT * FROM COMPANY

WHERE .

Execute theAppropriatepredefinedQuery as defined

from Configurator

Configurator

Get Transactions

Get Companies

XML

Server

Configurator

RDBMS

Figure 20: The XML service execution structure

All Configurator Communication activities are Based on specific Files:

- One file, shows the Initiation of RDBMS (Holds Username, Password and Database Alias)

- All Other Files Describes the SQL Statements (Insert, Read, Update, Delete) and also therelationships between Tables for supporting Master - Details Requests

However the Configurators main function is to create sqlxml files. In other words is a visual tool fromwhich SQL statements can be built and then transformed to sqlxml files. The user submits the SQLstatement and the application transforms it and saves it with a user define filename.

This file is used from the XML service with the XML request file so that the XML service module canbuild the SQL query, which will be submitted to the database. The structure of an sqlxml file will beanalysed later on.


37/58



3.1.3 The utilised XML Documents

3.1.3.1 XML Request Document

The request XML document, which is document that is sent from the CMU community to the XMLservice, is consisted of :

- , which describe some information about each insert/read/updated/deletefield, like fields type and size

- , which describes the kind of the query (read=select, insert, update, delete) that theXML-service must execute

- is the name of the predefined sqlxml file (Configurator file), which has information forthe SQL statement construction of a specific query

- , is the number of the record that has to be affected for each record that mustbe affected , the fields and the values

- , which are parameters with their values in the where clause of the sql

statement.

3.1.3.2 The Configurator File

The SQLXML document is consisted of four sections: the insert, the update, the read and the deletesection. These four sections has all the necessary data for creating insert, update, select and deleteSQL queries respectively. The structure of each section consists of three basic group of elements :the SQL, the PARAMS (Parameters) and the XML Aliases.

In the SQL section resides the SQL query structure. In the Params there is information concerningparameters like the name, the type and the size of the tables field. Also in the end there is an * or an

- which means if the field is mandatory or optional. After this there may be an = which means thatthe value of this field will be given from another sql query. The XML Alias are the name of the fields asthe are presented in the XML file.

3.1.3.3 The XML Response File

The XML response file is the file that has the results of the query. The structure of the documentfollows a standard format, which is described in the Annex II, when the query is either insert or updateor delete. When there is a Read (Select) query the XML response file has a structure like the XMLrequest file.

3.1.4 Master-Detail StructureThe Master-Detail structure is the definition of relations between two tables that first is the secondtable has detail information about the first which is characterised as Master. For example the Ordertable has detail information for the Table Customer about the customer order.

The Master-Detail documents (XML-Request ,Configurator and the XML-Response) differs from theNormal structure and their definition are presented in the Annex II.

3.2 Parsing XML across CMUs to ERP directionThis scenario starts when an entity that is positioned in the shop floor wants to traceroute informationto the ERP system. In this case:


38/58



- Initially the CMU parses and organises in an XML document the appropriate information, makinguse the embodied in it Parser. Then traceroutes the XML document to the XML Service module.

- The XML service module receives the XML request with specific format from the CMU

Parses (analyses) XML request

Interacts with SQL Configurator and traces the appropriate query based on the parsedXML request document concerning CMU requirements

Executes the appropriate predefined SQL queries to the ERPs database

Responses to the previous request forwarding to CMUS community specific XMLdocuments taking into account the results from queries execution in database

- The embodied in CMU XML Parsers transform the received XML documents into a recognisableto CMU elements format.

CMU

XML

Service

Module

Request Service

Receive Service

SQLConfigurator

ODBC

SELECT * FROM STOCK_ITEMSWHERE .

SELECT * FROM ITEMS_IN_STOCKWHERE .

. . .

Atlantis ERP

SAP

. . .

BAANSELECT * FROM STOCK_TABLEWHERE .

Trace theappropriatepredefinedquery

SQL Configurator

XMLParsel

XML

ERPAgency

Figure 21: Communication across the direction from CMUs community to the ERP

3.3 Parsing XML from ERP to CMUs directionAcross CMUs to ERP direction XML parser, traces the unstructured data (requests or information)that concern the controlled by CMUs execution devices. Parser organises them in a structured XMLDocument with specific format which then is forwarded to the XML Service module carried by a PA.Data structured in XML documents from XML Service Module to embody in CMUs XML Parsers.


39/58



XMLService

Module

SQLConfigurator

ODBC

SELECT * FROM STOCK_ITEMSWHERE .

SELECT * FROM ITEMS_IN_STOCKWHERE .

. . .

Atlantis ERP

SAP

. . .

BAANSELECT * FROM STOCK_TABLEWHERE .

Trace theappropriatepredefinedquery

SQL Configurator

DB Trigger

ExpectorERP CMU

Receive Service

XMLParsel

Agency

Figure 22: Communication across the direction from ERP to CMUs community

This scenario starts when the EPR system wants to traceroute information to the CMUs community.In this case:

- The information concerning the ERPs tracerouting intention is initially noticed by the DB TriggerExpector module, while any modification to ERPs Database (eg concerning the ProductionPlanning) raises a trigger in it

- Then DB Trigger Expector module locates the modification and informs the XML Service Moduleabout it

- The XML Service Module

interacts with SQL Configurator and traces the appropriate que

Date post:	29-May-2018
Category:	Documents
Upload:	antilohije
View:	219 times
Download:	0 times