Pabadis (1999) - ERP Interface

PABADIS
IST-1999-60016
Plant Automation based on

Distributed 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 Community

under the “Information Society Technology”
Programme (1998-2002)
© The PABADIS Consortium

Deliverable 1.5 ERP-Interface specification and design IST – 1999 - 60016
Rev. Content Resp. Partner Date

0.1 Set up and structuring Apostolos Vontas ; 15/03/01
Unisoft S.A.
0.2 ERP Potential Uwe Hess, IMS 20/04/01
0.3 Standards Nikolaou Georgios; 05/05/01
Unisoft S.A.
0.5 Specifications Valachis Dimitrios; 13/6/01
Unisoft S.A.
0.55 Specifications Paterakis Giannis; 22/06/01
Unisoft S.A.
0.7 Design Uwe Hess; IMS 05/07/01
0.8 Design Panayiotis Hatzaras; 21/08/01
Unisoft S.A.
0.9 Final Update Peter Thebus; IMS 10/09/01
0.95 Review and comments Roland Bataille; EMA 17/09/01
1.0 Final Approval Christos Fiskas; 20/09/01
Hatzopoulos S.A.
Final approval Name Partner
Reviewer Christos Fiskas Hatzopoulos S.A.
© The PABADIS consortium

TABLE OF CONTENT
0 EXECUTIVE SUMMARY ................................................................................................................................5

0.1 BACKGROUND AND PURPOSE...............................................................................................................5
0.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...............................................................................................31
2.4.3 Indirect ERP’s Database to ERP’s 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 .................................................................................................. 36
3.1.3.3 The XML Response File.............................................................................................. 36
3.1.4 Master-Detail Structure.....................................................................................................................36
© The PABADIS consortium page 2
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

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

Figure 2: SAP Architecture ................................................................................................................ 10
Figure 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 ..................................................................... 27
Figure 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................................................... 32
Figure 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 .............................................................................................. 42
Figure 27: Agency to ERP interactions representation....................................................................... 43
Figure 28: ERP to Agency interaction representation ........................................................................ 43

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 in
task 1.5, based on overall specifications of deliverable 1.1 and working in parallel with Tasks 1.2-1.4.
This deliverable’s purpose is to provide PABADIS with the specifications and designs for creating the
appropriate interface for connecting the shop-floor of an industry with current ERP technologies in
order to supervise and manage an industry. Following tasks, the implementation and operation of the
interface, 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 interface
between ERP systems and the PABADIS infrastructure. During this task the main activities that we
describe 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 PABADIS
system needs, the overall specification of deliverable 1.1 and the other parallel tasks of WP1
- Specification and recommendation concerning the technical requirements for the development
of the Interface
- Interface design
All specifications and designs were done with regard to existing technologies and
interoperability aspects, aspects of openness and state-of-the-art were taken into account. Even if the
PABADiS approach mostly concerns technological issues it is very important always to keep in mind
the customer (market) needs in order not to loose the practical benefit. Therefore it is necessary also
to consider new market trends and development directions. Thus avoid redundant development work
and/or a development in a wrong direction.

1 ERP systems potential and standards

1.1 POTENTIAL INVESTIGATION
The current situation in plant automation can be described as oriented towards centralisation. The
single control (PLC, NC, CNC) have to be connected to the SCADA and then to MES system and all
these systems have to be connected to the ERP system. Whenever connection is done, the real world
situation has to be mapped inside the governing system. Thus changes in the real world always imply
re-programming or re-configuring the software.
However, the borders between the ERP, MES, SCADA and other control systems are not clearly
defined. Some functions of the MES level can either be implemented within the SCADA or within the
ERP 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 terms
of keeping only a reduced set of responsibilities and features that facilitate time-delayed management
of the various enterprise resources and machines. Currently there is a well identified turn of the ERP
vendor community towards systems that enable customisation and adaptation to the specific working
patterns 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 their
integration, automate all of a company's business processes. They have rapidly become the de facto
industry standard for replacement of legacy systems. The major advantage of these systems is that
they 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

Work commenced with the identification of the potential of the most common ERP systems by
investigating some of the major ERP systems in the international market as well as some “thin” ERP
systems. The investigation took place by establishing some of the ERP systems that were in available
versions and also by referring to specialised literature on those ERPs. The investigated ERP systems
were 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 and
functionality always in regard to PABADIS needs. What has been identified about ERP systems
standards concerned their basic elements (Client server principle, Application Modules, Database
management system, Repository, Cross-Application Modules and custom applications Development
Languages), characteristics (i.e. open architecture, customisability, interoperability, portability,
operation in a Real time environment), structural layers (identified as the presentation layer, the
application layer and the database layer) and basic modules (including amongst others Accounting &
Financial Module, Service Module, Warehouse & Commercial Module, Production Module and Fixed
Assets 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, implementation
and 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 desired
and actual features is becoming smaller every day. ERP vendors, on the other hand, are not doing so
well, possibly because they have been busy developing, acquiring, or bundling new functionality so
that 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 no
longer willing to choose between integration and function. Within the next two years, ERP will be
redefined as a platform for enabling e-business globally. Therefore users need to be aware of the
trends within the ERP market so they can take into account all the necessary factors when making an
ERP software selection: product functionality, product technology requirements, vendor corporate
strategy, and vendor corporate viability.
1.1.1 Flexibility, Agility & Interoperability Enabled by Adaptable

Architecture
The rapid pace of global business nowadays places a unique set of challenges on companies looking
to improve and automate their operations, and at the same time, remain poised to adapt quickly to
change. 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 going
to 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 of
users, and whether it will be able to incorporate emerging technologies, all in order to accommodate
increasing 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 the
use of intuitive tools, aids, or wizards that guide users through a set of steps to achieve a desired end
result), 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 individual
modules 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 enhance
software maintainability and to simplify the creation of advanced graphical user interfaces (GUIs).

Object orientation means that design, linkages, etc., use objects as their basic building blocks, which
is 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 to
a relational database table, but this is not necessarily the case. The processing logic comes in
methods, 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 in
which procedures and data are separated.
1.1.2 Component Based Architecture

By breaking up the large applications into components, vendors are able to more quickly fix or add
functionality. A component can be something as simple as a supplier record, or a more complex
business process or workflow. The accounts payable component, for example, could be enhanced
without 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 easier
and safer for IT to customise the systems.
Componentisation proves to be crucial to enable ERP systems to support e-business activity since
the new e-commerce capabilities are being delivered as individual components. Componentisation
also helps the vendors extend the core ERP system with SCM, CRM, and other ERP-adjacent
solutions.
Interest in componentisation, however, began long before e-commerce. The perception at the time
was 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 but
also make it easier for customers to upgrade the software. With componentisation, a customer could
incrementally 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 user
interface 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 fashion
rather 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, although
progress has been moderate. The reason for this lies in the fact that componentisation is enormously
difficult to achieve even when the commitment is solid. With some honourable exceptions, most Tier 1
vendors have mostly succeeded in creating large-grain proprietary components, which are simply
large function modules. On the other hand, IFS leads the pack of more nimble mid-market ERP
vendors that have either entirely or to a significant degree componentized their products.
Implementing a fully component-based architecture requires that vendors completely redesign their
applications and then rewrite it using C++, Java, or a component-based 4GL, and run it under
component object model (COM), common object request broker architecture (CORBA), .NET (in the
future), or Enterprise JavaBeans (EJBs). Some vendors who had attempted this approach have
experienced 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 next
four years (70% probability). We also believe that the first vendors who deliver a truly open, modular
system will capture the lion's share of the remaining non-penetrated ERP market.

1.1.3 Open Interfaces and Improved Integration

While ERP customers may not be fully aware of the benefits of componentisation as yet, they have
been embracing the more open interfaces and improved integration capabilities that the vendors are
providing, capabilities also intended for the componentisation effort.
During the past few years, ERP vendors have opened up their tightly interwoven modules and created
application programming interfaces (APIs) to connect to 3rd-party best-of-breed systems. ERP
vendors are offering a broad range of open integration schemas, including extensible mark-up
language (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) for
use in integrating third-party products with the core ERP system as well as applications linking
enablement (ALE) via interchange documents (IDOCs), standard flat file formats for common
information exchanges. This requires open APIs to enable the integration of third-party data reporting
and 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 "façade" for their existing application.
When done properly, these APIs provide programmatic access to common business objects (e.g., an
order, a business partner, a delivery), which are mapped to the existing application's functionality in a
way that shields users from the complexity of the underlying code. However, APIs alone are not
sufficient. To bridge the differing semantics and business processes enabled within each participating
application in an extended ERP environment, either vendors or users must employ message broker
technology (a special-purpose, preferably 4GL tool that can readily transform and route data as it
moves between applications).
1.1.4 Implications of this trend

Despite 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 an
ongoing stream of smaller ones. Easy integration to 3rd-party applications has become a key selling
point for ERP vendors as thus many of them tout the provision of connectors to/from their systems
and/or provision of integration development tools (e.g., Forte or Progress Software). However, users
should 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-way
connections between applications
1.1.5 An ERP Vendor example

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

42 % 30 %
SAP
Oracle
Peoplesoft
J.D. Edwards
other
5% 8% 15 %
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 to
SAP R/3 solution. This chapter briefly describes the business technology platform and how the
standard SAP communication techniques (i.e. Idocs, BAPIs and RFCs) can be easily enabled for
using XML and the SAP Business Connector version 3.5. A brief description of each of the main
functions 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

1.2 STANDARDS IDENTIFICATION

Standards providing significant benefits for the configuration of the individual systems are an
important issue also for the easy modification and configuration of ERP connection to PABADIS
system. The interface that is going to be developed needs ERP standards identification in order basic
elements 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 broad
variety of standards which have been developed in the field of information technology are available at
various levels and originated from different standardisation bodies. Although it would be desirable
from a technological standpoint to have a single accepted standard world-wide, the variety that exists
reflects the heterogeneity of the individual ERP vendors as also the difference in industrial
needs.[HUB00], [BRO00], [JEN00]
1.2.1 Basic elements
Client server principle: With an optimal functional use of the three tier architecture, that is partitioned
into 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 as
possible onto desktop client computers. Managing desktop applications across hundreds, possibly
thousands of desktop systems, was a maintenance nightmare. Also, as the desktop application
component became more sophisticated, the hardware requirements for the desktop computer
increased, 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 between
the client and the backend corporate server, and also to manage the distribution of software and
applications 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 run
without users logged on to the system making. R/3 still requires batch jobs but is possible to
achieve a greater window of available time.
- A friendlier user interface is possible with PC workstations as opposed to dumb mainframe
terminals.
- The architecture promotes open systems, where components and peripherals can be used from
multiple vendors thus promoting competition and reducing hardware costs.
Application Modules, address functionality commonly used in enterprises. Usually an ERP consists
of the following modules: Asset Management, Controlling, Financial Accounting, Human Resources,
Industry Specific Solutions, Plant Maintenance, Production Planning, Project System, Quality
Management, Sales and Distribution, Materials Management, Business Work Flow.

CRM Service SCM

Module
Accounting & Warehouse &

Financial Module Commercial Module
Fixed Assets Production

Module Module
Figure 3: Basic ERP logical modules and interconnection pathways amongst them
Database management system, which are responsible for the storage of the information. Ew can
define 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 and
proprietary design of these products, however, make them unsuitable for mass use.
• Relational Databases products from vendors like IBM, Informix, Microsoft, Oracle, and
Sybase dominate database use in both the operational transactional and business
intelligence processing environments. These products have evolved from supporting
standard tabular data structures to providing SQL capabilities that handle a wide variety of
different types of data and processing.
• Java Relational Databases provide SQL-driven relational database features, have low
resource requirements, that are easy to install and manage, and that are written entirely in
Java to provide a write once run anywhere capability. The biggest advantage Java
database products bring to IT organisations is the portability offered by the Java
environment. It makes it very simple for these database systems (and thus database
applications) to be rapidly deployed on any system that supports a Java runtime
environment.
• Special real-time database systems are required for real-time acquisition and control of
data, since conventional database systems do not have the responsiveness necessary to
support rapid acquisition of data. For example, data may need to be time-stamped, so
those 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 in
the 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 every
single program, file, and data item in the system. This includes information on the various

components and elements identity, purpose, type, and nature defining attributes, process cycles and
times, 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, payment
programs, and so forth
- Commercial and Warehouse - Availability checking, scheduling deliveries, credit checking,
material shipments, transfers of inventory between plants, material determination, material
exclusion, material substitution, reorder points, and so forth
Custom applications Development Language: That gives the ability of easy customisation and
system 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 class
library.
1.2.2 Basic Characteristics
Open Architecture: Enables the co-operation and integration of applications, data and interfaces with
in all the levels of an ERP system as also with external systems. So an ERP can work flexible
connecting 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 configuring
business processes easily, quickly and efficiently. This capability is an important factor when new
functionality is wanted to be designed to the ERP, so that no many changes take place in the internal
organisation of a company.
Interoperability: The capability of using internationally recognised standards that allow easy
integration with other applications. With this ability to use resources from diverse origins as if they had
been 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 the
problem of interoperability itself never disappears –it simply moves up to a new level of complexity
that accepts earlier integration as a given.
Portability: Which gives the platform independence ability of using different Hardware and O/S
platforms, as also enables any installations to benefit from the latest developments in infrastructure
technologies (hardware, operational systems, DBMS, e.t.c.) without disrupting the ERP system in
production 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 registration
of business transaction. These can happen with supporting real fast communication protocols as also
real time databases and application servers.
1.2.3 Architectural Layers

The figure below shows the shows ERPs components from a functional as well as an infrastructural
point of view (figure 4). From a functional point of view, the top layer is the presentation layer that is
made of the GUI system. The middle layer is the application layer that handles not only business
applications, but also the middleware layer. Integration of all business applications relies on this
system. This system includes components such as ERPs customisation language, systems
administration tools, authorisation and security systems and cross application systems. The lower
layer 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 will
be based will be:
- The presentation layer that manages the dialog between the end-user and the application
program.
- The application layer that performs the actual transformation of the data that make the application
work.
- The database layer that stores, updates and retrieves required data by using the programs in the
application layer.
PRESENTATION LAYER
INTERNET LAYER
APPLICATION LAYER
APPLICATION MIDDLEWARE LAYER
DATABASE LAYER
OPERATING SYSTEM LAYER
HARDWARE LAYER
Figure 4: ERP system Structural Layers
1.2.4 Integration
One of the main issues that enterprises care and ERP vendors are working on is the ability of
integrating ERP systems, with other information systems by building the necessary interface for
establishing communication between these systems. Focusing on this capability of ERP systems we
can 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 longer
practical options. Many organisations are changing their strategies from a traditional point-to-point
integration strategy to a more proactive approach of building and evolving a standardised integration
architecture capability that enables fast assembly and disassembly of corresponding business
software components. Systems integration could differentiate between three types of applications
[OST00]:

- 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 data
exchange between separated applications.
- Homogeneous with several instances: Several identical processes in different business units are
supported 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 transactional
data in physically distributed SAP environments.
- Heterogeneous: Several different processes in different business units are supported by several
different applications. An additional problem compared to the integration in a homogeneous
environment is, that the concerned applications are built upon divergent data models, which
means 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 four
levels (figure 5).
System I System II
Pragmatics Functionlevel
Pragmatics
Semantics Objectlevel
Semantics
Syntax Datalevel
Syntax
Communication Standardsfor datacommunication Communication
Services Services
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. Semantic
is needed to assign real world subjects and notions to the transmitted characters by adding a certain
meaning 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 of
information among anonymous systems will remain illusive because it will require a human
interpreter. The third element - the pragmatic element - is a feature of sophisticated workflow systems
and it makes sure that transmitted data has not only been understood but that subsequent actions are
triggered.

1.3 ERPs evaluation description
JDEdward Navision Computer LogiC

mySAP BaanERP Peoplesoft8 Oracle ERP Unisoft Atlantis
OneWorld Damgard Omega
Presentation Web Browser; Java; Web Browser / HTML; 32-bit Windows 95; Web Browser Web Browser / HTML; Web Browser; HTML; Web Browser / HTML, Web Browser / HTML,
Windows; Mobile Java; Windows Windows 98; /HTML; MS PeopleSoft 8 power WML; JSP Windows Windows
Devices Windows NT (Intel); Windows Systems HTML; PC,
Windows 2000; Web Macintosh, Linux,
Browser Unix, Thin Client
Computing Devices,
or mobile devices.
Client server Multi client structure five functional Windows-based No code on the client Presentation layer is Multi-client system, n- possibilty to distribute
elements — client/server structure seperated from tier on different systems
principle
database, data business layer
warehouse, business
objects, reporting, and
GUI;
Communication HTTP/ XML /SOAP; XML; COM/DCOM; XML, EDIFACT; XML; DHTML; XML over HTTP; XML (Oracle XML XML; COM/DCOM; XML over HTTP;
.NET/COM+; Java/CORBA; ODBC C/ODBC driver ODBC COM; CORBA; Java; Gateway); Java; JSP; CORBA; ODBC COM; CORBA
Environment
Java/CORBA; ODBC ODBC JDBC; HTML; SMTP;
ODBC; OLEDB; JDBC;
OCI; JMS
Supported IBM's MQ Series® IBM's MQ Series®; SAP IDOC and flat IBM MQSeries; X.12 or EDIFACT IBM MQ Series; Tibcon; Flat files using an EDIFACT
Microsoft® MS MQ; files, using an XML Wonderware®'s MS MQ XML standard
Communication
Biztalk™ standard via MS FactorySuite™
Interfaces BizTalkServer (MES module);
Seagate reporting
tools
Programming Java/JavaScript; C; C++; C/AL™ C++ API (Java, COM, Java C++, Delphi C++
Visual Basic/C#; C/C++)
Languages
C/C++
Custom ABAP Objects OneWorld® Toolset; C/Side Dynamic Enterprise U.C.L. OMCL
C based APIs; modelling (DEM)
applications
ActivEra®
Development
Language

Application FI (Financials); LO Supply Chain Navision Axapta Finance; eBusiness; Enterprise Business to Business; Financial Warehouse
(Logistics) ; HR Management (Enterprise Resource Procurement; Performance Business Intelligence; Management; Fixed management;
Modules
(Human Resources) ; (Advanced Planning; Planning; Supply Manufacturing; Management; Customer Relationship; Assets; Production; Customer
APO (Advanced Fulfillment Chain Management; Distribution; Enterprise Service Management; Production Planning; Relationship
Planner & Optimizer) ; Management); Human Resource Integration & Automation; Customer Financials; Human Warehouse Management; Project
CRM (Customer Customer Management; E- implementation; Relationship Resources; Projects; management; Management;Producti
Relationship Relationship Business; Customer Planning; Sales; Management; Tutor; Online Services; Customer on management;
Management); BW Management; Relationship Service & Education and Industries: Aerospace Relationship Financial and fixed
(Business Information Procurement Management; Maintenance; Government; Human and Defense; Management; Assets Management;
Warehouse); CFM Management; Project Knowledge Business portals; Resources; Supply Automotive; Chemicals, Procurement Supply Chain
(Corporate Finance Management; Asset Management); Collaborative Chain Management; Oil and Gas; Management; Project Management;
Management); SEM Management; Navision Attain; commerce; Financials; Industry Communications and Management;
(Strategic Enterprise Financial Navision Financials Business Solutions: Media; Consumer
Management); CA- Management; (Financial Intelligence; Communications; Sector; Education;
JVA (Joint Venture Workforce Management; Industry specific Consumer Products; FInancial Services;
Accounting); Management; Navision Analyst; components: Federal Government; Healthcare; High
Engineering&Constru Implementation and User Portal; Aerospace & Financial Services; Technology;
ction); Industry Systems Manufacturing; Defense; Cable & Healthcare; Higher Pharmaceutical/Biotec;
specific components: Management; Advanced Wire; Automotive; Education; High Public Services; Travel
AP IS-AFS (Apparel Knowledge Distribution; CRM; Chemicals; Food & Technology/Electronic and Transportation;
and Footwear); Management; eCommerce); Beverage; s; Utilities
BANKING (Banking); Collaboration and Navision XAL Pharmaceuticals; Industrial/Automotive
IS-H (Healthcare); Integration; Construction Products;
INSURANCE Marketplace and Contractors; HiTech Professional Services
(Insurance);IS-M Exchange & Electronics; Automation;
(Media); Management;
Database IBM DB2; Informix; IBM DB2; MS SQL- Navision Server; MS Oracle; IBM DB2; IBM DB2; Oracle; Oracle IBM DB2; Oracle; Oracle; Microsoft SQL
MS SQL-Server; Server; Oracle; ... SQL Server 7.0 MS SQL; Informix Microsoft SQL Server; Microsoft SQL Server Server
management
Oracle; SAP DB Sybase; Informix
system
Operating Compaq Tru64 Unix; OS 400; Windows NT Windows NT (Intel); IBM AIX®; OS/2®; NT4; Windows 2000; UNIX; Windows NT UNIX; Windows NT UNIX; Windows NT
IBM AIX; HP UX; / 2000; HP UX; ... Windows 2000; IBM OS/390; OS/400; HP-UX; AIX ; Solaris;
Systems
Linux; Siemens AIX; HP-UX; Reliant- Windows NT®; Tru64 (WebLogic
Reliant Unix; SUN Unix Windows 2000; HP- only) ; Linux
Solaris; MS Windows UX; SCO
2000; IBM / OS 400; OpenServer; SINIX;
IBM / OS 390 Solaris Operating
Environment
Hardware Alpha; Power PC; PA; AS/400®, RS/6000™, Intel; IBM; HP S/390; Intel; Intel; IBM; HP; Intel; IBM; HP Intel; IBM; HP Intel; IBM; HP
Intel; MIPS; SPARC; HP 9000®, Intel, ... RS/6000; AS/400; SPARC
Systems
AS/400; S/390
Table 1: ERP Specifications

Open Customisability Interoperability Portability Real Time

Architecture environment
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 from
where 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) in
order 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 practice

XXXX Support
XXX Partially support
XX Few signs and indications
X Not available

1.4 PRODUCTION MODULE

The ERP’s production module deals with the implementation and management of the Production
Planing process that is a complicated issue and concerns the harmonised management of customer
demands, production capabilities and resource’s (materials, employees, machines) availability across
the two directions of a company’s Supply Chain.
ERP’s Production Module is responsible for :
- Material Requirements Planning (MRP), that sets off requirements resulting from product demand
management and sales against stock. It also enables the unique assignment of requirements and
stock 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. Unlike
the traditional MRP II systems, the master production scheduling must be synchronised with the
capacity plan from the beginning. Other characteristic features include coproducts, process
manufacturing, formulation management, maintenance, and multiple units of measure. This type
of manufacturing process typically is for the creation of interim raw materials required by other
manufacturing plants within the same company or by other facilities.
- Repetitive manufacturing is involved with creating large volumes and standard product. The
system tracks the material, quality, cost of material, and machinery across all stages of the
systems. 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 actual
observed consumption of inventory. These systems also attempt to schedule runs and certain
equipment for fixed intervals of time
- Make-to-stock. For this type of manufacturing, the volumes are not as large as those for repetitive
manufacturing. Often these systems do not have very deep BOMs. They also use standard lot
sizes, 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 requirements
of the customer at an optimal cost. The manufacturer or its representative dealers must store
various assemblies, aggregates, and parts to quickly assemble an order in accordance with the
specifications of the customer. Other characteristics include product configuration, contract
manufacturing, 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 computer
and workstation industries.
- Engineer-to-order. The volume of the products in this type of manufacturing is low, but the
complexity of the designs and the finished products tend to be very high. They are typically
engineered and manufactured for a specific customer. Key characteristics required here are
contract manufacturing, shop-floor control and costing, sophisticated manufacturing (CAD/CAM),
and integration. Costs and turnaround times are quite high, machinery, airplanes, and defense
products.
A production planning for manufacturing an order can be divided into various phases in order to have
in 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 a
manufacturing order. Available information for every production phase could be the below:
- Detailed set of diagrams about the current production plan for a specific period :
- Required machines’ availability for the specific product’s creation

- Required employees’ availability for the specific product’s creation
- Required materials’ availability for the specific product’s creation
- Detailed description of the required resources for the specific order’s fulfilment.
- Detailed technical Specifications of the ordered product
- Ordered product’s desired quantity
- Ordered product’s desired delivery date
- Customer’s priority
- Product’s 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
- Order’s priority
The Production module is identified as the basic "interface" of the ERP system with the PABADIS
system (including in the system also the interface with the ERP) and it is the module where the user
sets requests to the machines and receives and processes data from the machines. The product
agent PA can carry data from the CMUs to ERP’s database concerning:
- Resource's (employees, machines, materials) availability during a specific time interval.
- Prototype technical specifications that the customer requires will be respected, during the
production process.
- Machine's technical specifications and employee’s capabilities.
Figure 6, shows the ERP’s Production Module involvement in the PABADIS system, where is is
responsible for the realisation of enterprise’s Production Planing by the harmonised management of
the required resources, investigating material’s, employees and machines availability.

SCM CRM
Service
Module
Accounting Warehouse &

& Financial Commercial
Fixed Assets Production

Module Module
Employees
Machines Material’s
availability
availability availability
XM L Service M odule
Agency
XML
XML PA Doc XML XML
PA Doc PA Doc PA Doc
...
XM L-parser XM L-parser XM L-parser
CMU CMU CMU
RA RA RA
Figure 6: ERP Production Module in Pabadis

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 recommendation
concerning the technical requirements, concluding to the outline of interface design aspects, as these
have 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 the
entire project, thus laying the fundament for all other work in the project, Task 1.5 is to be understood
as a “frame” which will ensure that the subsequent work to be taken within the stream of activities
related to the ERP interface will be efficiently implemented taking into account the design of the
overall 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 specified
functionality within agents and protocol layers and specification of information flows within the factory
environment.
2.1 TECHNOLOGICAL ENVIRONMENT
Nowadays the world of industry faces significant interoperability issues as it seeks to architect
solutions 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 offer
promise for applying data management technology to documents and, also, for providing a neutral
syntax 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 and
the simple, but non-extensible HTML. It has been described as providing 80% of the benefit of SGML
with 20% of the effort and it is being embraced by a broad cross-section of the industry as the right
language for defining the APIs necessary to make business software components talk to each other.
Figure 7: XML description

XML is actually a language for creating mark-up languages that describe data and rules about the
data. It requires applications to be defined to it before it can become truly useful. The process of
defining applications is done through the use of the Document Type Definition, which defines the tags
and 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 defining
representative 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 enable
interoperability among dissimilar databases and message formats seems to be an efficient and
effective 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 “information
portability ” 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 it
to support all kinds of applications and services that can be connected through a standard TCP/IP
port 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 neutral
characteristics, the XML integration can be used also from other 3rd vendors / application not only for
the 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 with
the provision of a solution for the interoperability problems faced by PABADIS consortium which are
also typical of those being addressed by government, industry and academia nation-wide. The
problems and issues are in the areas of software architecture and database interoperability for
distributed 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 to
allow 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, and
Text) 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 to
know the proprietary interfaces to the databases handling the SQL request and converting it into a
request 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 in
the 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.

Figure 8: Open Database Connectivity description
However, what has been lacking is the ability to merge software architectural approaches and
database interoperability techniques into a synergistic approach that offers a unified meta-model to
specify distributed applications. Such a meta-model would be all encompassing, to allow software
architectural, hardware and database requirements to be specified and, once specified, to facilitate
the 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 database
interoperability requirements of a distributed system. In the short term, issues related to database
interoperability have to be managed, as well as message translation.
For achieving the technical objectives of this Task, the following has been regarded as yardsticks
against which the progress of the work will be measured in later reviews and assessments of work in
Task 4.1 where the PABADIS ERP interface will be developed:
• The first is disconnected operation of devices, and the agents they host or communicate
with. Mobile network bandwidth is generally poor, and interruptions can be frequent and
unforeseen. This means that the PABADIS agents must be autonomous: they must have
sufficient code and data resources to continue functioning even when their host site has
become disconnected. In addition, mechanisms must exist to handle data consistency
issues when the various virtual devices reconnect to a network and data updates must be
propagated.
• A second aspect for the agent infrastructure is co-ordination. In a wireless or ad hoc
network, as the trend in factory environments will becoming more and more apparent, the
set of co-operating PABADIS agents will have to be able to change frequently, as agents
become disconnected or simply leave the network. The ERP interface must nevertheless
provide a means to co-ordinate the actions of all agents, enable them to gain access to the
information 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 is
a great deal of user autonomy that makes authentication and controlling data access much
harder.

2.2 Possible Interfacing scenarios
Hardware Interface (HI), the physical and logical arrangements supporting the attachment of any
device 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 application
program 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 thoroughly
investigated for API’s support and implementation.
User Interface (UI), consisted of a set of dials, knobs, operating system commands, graphical display
formats and other devices provided by a computer or a program to allow the user to communicate
with the system. ERP’s GUI will be used for UI support and implementation.
JINI/PINI GUI
?
Programming Interface
Presentation Layer
User Interface
Internet Layer
Application
Hardware Interface
Application Layer
Application Middleware Layer
Database System Layer
Operating System Layer
Hardware Layer
Figure 9: Interfacing scenarios
2.3 Manufacturing order
The manufacturing process according to the PABADIS system starts with the generation of a
conventional manufacturing order by the ERP system which consists of all the needed information for
the product to be manufactured. This order comprises the sequence of required processing steps
together with the appropriate parameters.
his information that consists of structured data will be transmitted to the Agency in an XML format
where it is translated into a product agent and joins the multi-agent system. Throughout the
manufacturing process, the product agent guides the work. Upon completion, it returns to the agency
and is terminated there. The agency then generates a report to the ERP system, using data the agent
has collected on its way through the production (if so desired by the ERP system in the manufacturing
order). A manufacturing order consists of product's prototype technical specifications, accompanied
with desired delivery date, required quantity and customer’s priority. A detailed list is showed in figure
10.

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 the
ERP system, by sending an order for execution and by sending some queries for controlling the
status and the availability of each machine its input and output. These all data and queries are
structured 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 execution

One of the basic functionality that the PABADIS system will have is the capability of sending a
manufacturing order to the machines in order to be executed. What has been identified is that not all
the 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 an
XML file, structured by the use of metadata. Metadata are showed inside the tags (<>,</>) and are
specific for each ERP system. In the case of the PABADIS system generic Metadata are going to be
defined like the ones given in the figures below. However, all these data is not needed from the CMU
to 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 (figure
12) that will generate the agents needed for communication with the machines. In order a
manufacturing order to be executed we use MES functionality Resource allocation, Operations and
scheduling, distributed in PA tasks. These PA tasks are generated by the corresponding metadata.

Order
< number> ……………..… </ number>
< type> ……………..… < /type>
< description> ……………..… < /description>
<customer> ……………..… </customer>
< supervisor> ……………..… </supervisor>
<planner> ……………..… </planner>
< factory> ……………..… < /factory>
< priority> ……………..… < /priority>
Dates
<requested> ……………..… </requested>
< beginning> ……………..… </beginning>
< finished> ……………..… </finished>
Product
< id> ……………..… </id>
<quantity> ……………..… < /quantity>
<phases> ……………..… <phases>
< begin> ……………..… </begin>
< finish> ……………..… </finish>
Materials
< id> ……………..… </id>
< type> ……………..… < /type>
<product> </product>
<quantity> ……………..… < /quantity>
<service types> …………….…. </service_types>
< begin> ……………..… </begin>
Phase
< begin> ……………..… </begin>
Service
<machine> …………….…. </machine>
< begin> ……………..… </begin>
Figure 11: Example of structured data of a manufacturing order in an XML file

Order Materials
< order id> …………….. </ order_id> < id> ……………..… </id>
< factory> …………….. < /factory> <quantity> ……………..… < /quantity>
< priority> …………….. < /priority> < begin> ……………..… </begin>
< beginning> …………….. </beginning> < finish> ……………..… </finish>
< finished> …………….. </finished> < priority> ……………..… < /priority>
Product Phase
< id> ……………..… </id> < description> ……………..… < /description>
<quantity> ……………..… < /quantity> <service types> …………….…. </service_types>
< begin> ……………..… </begin>
<phases> ……………..… <phases> < finish> ……………..… </finish>
< begin> ……………..… </begin> < priority> ……………..… < /priority>
Figure 12: Appropriate for the Agency metadata from a manufacturing order in an XML file
2.3.2 Controlling the status of the order

Working on a different way and trying to receive data from the CMU, in order to control the status of
the machines, is another capability that can be added in the ERP, as also in the PABADIS system. In
Figures 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 also
have data that are needed from the machine to allocate first the product that we are interested for and
also queries for asking data from the CMUs for the status of the machine what is its input, output and
current process.
Materials availability (raw or semiproducts)

<id> ……………………… </id>
<type> ……………………… </type>
<level> ……………………… </level>
<quantity>, ……………………… </quantity>,
<quantity available> ……………………… </quantity_ available>
<quantity required> ……………………… </quantity_required>
< loss> ……………………… </ loss>
<deadline> ……………………… </deadline>
Product status
<ordered> ……………..… </ordered>
<sent> ……………..… </sent>
<cancelled> ……………..… </cancelled> Quantity
<produced> ……………..… </produced> -Amount of :
< in work> ……………..… </ in_work>
<id> <id>
< phase> ……………..… </ phase> Current status
< service type> ……………..… </ service_type> of a product
< begin> ……………..… </begin>
Figure 13: Example of structured data for controlling the status of the machine (continues)

Materials status
<scheduled> ……………..… </scheduled>
< sent> ……………..… </ sent>
<cancelled> ……………..… </cancelled> Quantity –
<produced> ……………..… </produced> Amount of :
< waste> ……………..… </ waste>
< in work> ……………..… </ in_work>
<id> <id>
< phase> ……………..… </ phase> Current status
< service type> ……………..… </ service_type>
of a product
< begin> ……………..… </begin>
Phase status
<cancelled> ……………..… </cancelled>
<produced> ……………..… </produced> Current status
< waste> ……………..… </ waste> of a product or
< in work> ……………..… </ in_work> material
< phase> ……………..… </ sphase>
< product> ……………..… </ product> Current status
< begin> ……………..… </begin> of a product
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 can
monitor them but also for information that can be used from production planning for knowing the
machine availability and plan schedules for another product. In order to use this information to the
production planning of an order we use MES functionality Resource Status - Product tracking
distributed in PA tasks (missions). In figure15, we can see a simple form from an XML file that can be
send to the CMUs (via Agency of course) and ask about the current status of a product by giving its id
number and five queries. The CMU tracks the product and sends back its current status by replacing
queries with data.
<id> 696996060 <id>

< phase> Query </ phase>
< service type> Query </ service_type>
5 tasks for the PAs to be
<status> Query </status> processed to Agency--->
< begin> Query </begin> CMU
< finish> Query </finish>
<id> 696996060 <id>

< phase> A </ phase>
< service type> drilling </ service_type> Returned information by
<status> Normal </status> the PA from the Agency
< begin> 1130 </begin>
< finish> 1230 </finish>
Figure 15: XML file send to the machines and received back for knowing

2.4 Logical View of the interface

The logical view of tasks concerning interoperability is divided into two related views concerning the
participating 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 a
community
- The combination of the above two cases that results to an indirect ERP Database (crossing the
CMU community) to another (or same) ERP Database Interoperability,
2.4.1 A direct ERP Database to another ERP Database Interoperability

As depicted in Figure 16 that follows, a PABADIS AGENTS Object Translator extracts (by SQL
statements - reads) from an ERP database pertinent data and translates the data into XML. As
shown, 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 Objects
Translators.
Figure 16: Direct ERP Database - ERP Database Interoperability
2.4.2 Message to Message Interoperability

Referring to figure that follows, the XML from the prior database-to-database translation becomes the
input to a third PABADIS AGENTS Object translator and depending on the destination, a message is
generated. 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.

Figure 17: Message to Message Interoperability
2.4.3 Indirect ERP’s Database to ERP’s Database Interoperability

A composite of the two previous cases illustrates the complete solution approach concerning the
seamless integration amongst any ERP database with any third party entity by the use of the XML
and PABADIS AGENTS platform.
The above-described approach provides a possible solution to need for message and database
interoperability to reduce operator burden. The task investigated the utility of the XML to write
translator(s) between message formats and databases making use of the already developed
PABADIS 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 a
physical model in order to correspond to the PABADIS integration requirements between ERP and
Pabadis CMU community.
Figure 18: Indirect ERP Database - ERP Database Interoperability

3 Interface Design
3.1 The proposed Integration Tool
Taking into account the conducted analysis concerned the possible interoperability technologies that
can be adopted in order to satisfy PABADIS integration requirements concerning communication
activities that take place between CMU community and the ERP system the “to be developed”
Integration 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) API’s for develop - implement Custom
Applications
- Future Extensions will concern: SOAP and XMI
The manufacturing process according to the PABADIS system starts with the generation of a
conventional production order by the ERP system. This order comprises the sequence of required
processing steps together with the appropriate parameters. The production order is passed to the
Agency, where it is translated into a product agent and joins the multi-agent system. Throughout the
manufacturing process, the product agent guides the workpiece. Upon completion, it returns to the
agency and is terminated there. The agency then generates a report to the ERP system using the
data the agent has collected on its way through the production (if so desired by the ERP system in the
production order). In parallel, plant management agents are created by the Agency to fulfil specific
control or supervision tasks that are not related to individual products (figure 19).

Enterprise Resource Planing PABADIS ERP INTERFACE
SQL
Configurator
DB Trigger
Expector
trigger Agency
XML
SQL Doc PMA
Request XML Fabricator
DataBase XML Document PA
Application Service
Server SQL
Reply Module
Data Collector
Figure 19: Description of the PABADIS ERP Interface
3.1.1 XML Service Module

The XML Service Module receives or sends XML documents from an agreed port using TCP/IP. This
XML service is on the side of IS. On one site there could be an entity of CMUs community or any third
partly application which want to communicate with an ERP system or any Database that resides in the
other 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 ERP’s database. This XML request document has
usually 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 doesn’t have parameters but
fields and values, see more details in SQLXMLFILE Structure) and it’s values.
The XML service module parses this XML request document, gets the name of the “Predefined Object
Name.sqlxml” that has information for the construction of the SQL statement, parses also the
parameters 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 XML
request document in order to construct the SQL statement. Then executes this SQL statement, and
gets 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 is
send to the CMU community.
In general the communication between the XML service module and the CMU community will be
interactive, that means that the CMU community can be connected to the XML service module any
time, request a query and get the result data. On the other hand, the XML service module will be
connected to the community, sending the result data from a query in the ERP system or database
inform 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 the
files which filename is ‘db.ini’ in order to establish a connection with a database. These files are
stored to a different path according to the database aliases. For example if the root directory of the
Configurator is ‘d:\sqlconf’ and a user wants to create a new connection with a database whose alias
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=atlantis
USERNAME=prod
PASSWORD=p123
SELECT * FROM CUSTTBL

Get Customers
XML WHERE ….
Server
SELECT * FROM RTDTBL
RDBMS WHERE ….
Get Transactions
... ...
Configurator SELECT * FROM COMPANY
WHERE …. Get Companies
Configurator
Execute the
Appropriate
predefined
Query as defined
from Configurator
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 the
relationships between Tables for supporting Master - Details Requests
However the Configurator’s main function is to create sqlxml files. In other words is a visual tool from
which SQL statements can be built and then transformed to sqlxml files. The user submits the SQL
statement 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 can
build the SQL query, which will be submitted to the database. The structure of an sqlxml file will be
analysed later on.

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 XML
service, is consisted of :
- <#FIELDDEFINITIONS>, which describe some information about each insert/read/updated/delete
field, like field’s type and size
- <ACTION>, which describes the kind of the query (read=select, insert, update, delete) that the
XML-service must execute
- <NAME> is the name of the predefined “sqlxml” file (Configurator file), which has information for
the SQL statement construction of a specific query
- <RECORDCOUNT>, is the number of the record that has to be affected for each record that must
be affected , the fields and the values
- <PARAMETERS>, 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 delete
section. These four sections has all the necessary data for creating insert, update, select and delete
SQL 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 concerning
parameters like the name, the type and the size of the table’s 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 that
the value of this field will be given from another sql query. The XML Alias are the name of the fields as
the 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 document
follows a standard format, which is described in the Annex II, when the query is either insert or update
or delete. When there is a Read (Select) query the XML response file has a structure like the XML
request file.
3.1.4 Master-Detail Structure

The Master-Detail structure is the definition of relations between two tables that first is the second
table has detail information about the first which is characterised as Master. For example the Order
table has detail information for the Table Customer about the customer order.
The Master-Detail documents (XML-Request ,Configurator and the XML-Response) differs from the
Normal structure and their definition are presented in the Annex II.
3.2 Parsing XML across CMUs to ERP direction

This scenario starts when an entity that is positioned in the shop floor wants to traceroute information
to the ERP system. In this case:
- Initially the CMU parses and organises in an XML document the appropriate information, making
use 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 parsed
XML request document concerning CMU requirements
• Executes the appropriate predefined SQL queries to the ERP’s database
• Responses to the previous request forwarding to CMUS community specific XML
documents taking into account the results from queries execution in database
- The embodied in CMU XML Parsers transform the received XML documents into a recognisable
to CMU elements format.
CMU
Agency
ERP Request Service
XML Parsel
ODBC XML
Service XML
Module
Receive Service
SQL
Configurator
SELECT * FROM STOCK_ITEMS Atlantis ERP

WHERE ….
Trace the
SELECT * FROM ITEMS_IN_STOCK appropriate
SAP
WHERE …. predefined
... query
...
SELECT * FROM STOCK_TABLE BAAN
WHERE ….
SQL Configurator
Figure 21: Communication across the direction from CMUs community to the ERP
3.3 Parsing XML from ERP to CMUs direction

Across CMUs to ERP direction XML parser, traces the unstructured data (requests or information)
that concern the controlled by CMU’s execution devices. Parser organises them in a structured XML
Document 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.

DB Trigger
Expector
ERP CMU
Agency
ODBC XML
XML Parsel
Service
Module
Receive Service
SQL
Configurator
SELECT * FROM STOCK_ITEMS Atlantis ERP

WHERE ….
Trace the
SELECT * FROM ITEMS_IN_STOCK appropriate
SAP
WHERE …. predefined
... query
...
SELECT * FROM STOCK_TABLE BAAN
WHERE ….
SQL Configurator
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 ERP’s tracerouting intention is initially noticed by the DB Trigger
Expector module, while any modification to ERP’s Database (eg concerning the Production
Planning) “raises” a trigger in it
- Then DB Trigger Expector module locates the modification and informs the XML Service Module
about it
- The XML Service Module
• interacts with SQL Configurator and traces the appropriate query based on the parsed
SQL request concerning ERP’s modification
• Executes the appropriate predefined SQL queries to the ERP’s database
- A specific formatted XML documents taking into account the results from queries execution in
database is forwarded to the appropriate CMU
- Finally the embodied in the CMU XML Parser receives as input from XML Service module the
XML document that contains structured data, and transforms it in a recognisable to CMUs format.
ERP to CMUs direction receives as input from XML Service module side XML documents, containing
structured data concerning responses to CMUs requests, traces and transforms them in a
recognisable to CMUs format.

3.4 UML Diagrams

As it is a guarantee for the quality of software architecture design, for the efficiency of
communications between all involved partners and for a broad range of diffusion, the UML language
seems to impose itself as the modelling language to be used for the development of the PABADIS
system. The UML provides users with a ready-to-use, expressive visual modelling language so they
can develop and exchange meaningful models and supports the entire software development
lifecycle. The UML can help application designers to communicate easily and efficiently and because
it is an open standard and independent of particular programming languages and development
processes, it provides extensibility and specialisation mechanisms to extend the core concepts.
[QUA98][OMG]
XML Servi ce Module Stopped

XML Service Module Started
Reply from ERP's DB received Information organized in a request XML

organized in a data s tream Wait for message Document received from CMUs community
or event
Analyze data Parse <ObjectName> from
stream request XML Document
Load appropriate XMLSQL object from

Configurator based on <ObjectName>
Read XML
aliases
Submit XML response Document to Submit SQL query Parse <Parameter> from
the Agency to the ERP's DB request XML Document
Create the response XML Create SQL query based on

Document based on data stream <ObjectName> and <Parameter>
XML REQUEST DOCUMENT CONSISTENCY
<ObjectName> ... <\ObjectName>

<Parameter> ... <\Parameter>
<XMLAliases> ... <\XMLAliases>
XML RESPONSE DOCUMENT CONSISTENCY
<FieldsDescription> ... <\FieldsDescription>

<Action> ... <\Action>
<ObjectName> ... <\ObjectName>
<Data> ... <\Data>
Figure 23: XML Service Module WorkFlow from CMU, Agency to ERP direction

XML Service Module Stopped XML Service Module Started
Reply from ERP's DB received Information concerning modifications

organized in a data stream in ERP's DB received from Trigger
Wait for message Expector organized in a datastream
or event
Analyze data
stream Analyze data
stream
Load appropriate XMLSQL object from

Read XML Configurator based on dat a st ream
aliases
Submit XML reply Document to Submit SQL query

the CMUs community to the ERP's DB
Reply with an XML Document based on Create SQL query based

data stream and XML aliases on dat a s tream
XML REQUEST DOCUMENT CONSISTENCY
<Obj ectNam e> . .. <\ Obj ectNam e>

<Parameter> . .. <\ Param eter>
<XMLAli ase s> .. . <\XMLAl iases>
XML RESPONSE DOCUMENT CONSISTENCY
<FieldsDescri ption> . .. <\ Fiel dsDescri pti on>

<Action> ... <\Action>
<Obj ectNam e> . .. <\ Obj ectNam e>
<Data> . .. <\ Data>
Figure 24: XML Service Module workflow across ERP to AGENCY direction

Configurator Stopped
Configurator Started
Wait for message

or event <ObjectName> information received
Data stream received from
Tri gger Expector from XML Service Module
Trace the appropriate XMLSQL object Trace the appropriate XMLSQL object
based on the data stream information bas ed on the <ObjectName>
Submit the appropriate XMLSQL

object t o the XML Service module
Figure 25: Configurator WorkFlow

Trigger Expector Stopped Tri gger Expector Started
Wait for message

or event
Modifications
detected in ERP's DB
Submit ERP's DB modification Locate modifications in

information to XML Service Module ERP's DB
Get modification
information from ERP's DB
Figure 26: Trigger Expector WorkFlow

Agency XMLServiceModule Configurator ERPDB TriggerExpector
RequestXMLDoc
XMLSQLObjectRequest
XMLSQLObjectResponse
SQLQuery
DataStream
ResponseXMLDoc
Figure 27: Agency to ERP interactions representation
ERP's DB TriggerExpector XMLServiceModule Configurator Agency
ModificationTriger
ModificationInformation
RequestXMLSQLObject
ResponseXMLSQLObject
SQL Query
DataStream
ResponseXMLDoc
Figure 28: ERP to Agency interaction representation

4 Abbreviations
API Application Programming Interface
BOM Bill of Materials
CMU Co-operative Manufacturing Unit
DCOM Distributed Component Object Model
ERP Enterprise Resource Planning
GUI Graphical User Interface
JINI Java Internetworking Initiative
JVM Java Virtual Machine
IP Internet Protocol
LAN local area network
MES Manufacturing Execution System
OS Operating System
OSI Open System Interconnect
P&P Plug & Participate
PA Product Agent
PABADIS Plant Automation Based on Distributed Systems
PLC Programmable Logical Controller
PMA Plant Management Agent
RA Residential Agent
SCADA Supervisory Control And Data Acquisition
SGML Standard Generalised Mark-up Language
SQL Structured Query Language
SOAP Simple Object Access Protocol
TCP Transmission Control Protocol
UML Unified Modelling Language
VM Virtual Machine
XML Extensible Markup Language

5 References
[HUB00] T. Huber, R. Alt, H. Österle, “Templates – Instruments for Standardizing ERP
Systems”, Proceedings of the 33rd Hawaii International Conference on System
Sciences, 2000
[LAU00] K. Laudon, "Management Information Systems", Prentice-Hall`, New Jersey 2000
[CIERP] CIERP, "ERP: A-Z Implementer's Guide For Success", http://www.cibres.com/
[KAL00] V. Kale, “Implementing SAP R/3”, SAMS Publishing,Indiana,2000
[BRO00] A.T. Bromwich "Peoplesoft Erp Reporting", Prentice Hall, 2000
[JEN00] R. Jendry, “BaanERP Business Solutions”, Prima Tech, California, 2000
[XML1] XML Schema Part 0: Primer. W3C Candidate Recommendation, 2000.
XML Schema Part 1: Structures. W3C Candidate Recommendation, 2000.
XML Schema Part 2: Datatypes. W3C Candidate Recommendation, 2000.
[QUA98] T. Quatrani, "Visual Modeling with Rational Rose and UML", Adison-Wesley Object
technology, 1998
[OMG] OMG “UML Notation guide”, Version 1.3 , June 1999
OMG “UML Semantics”, (), Version 1.3 , June 1999, www.omg.org
[SAP] Business Connector Documentation, http://service.sap.com/connectors
Internet Adviser, http://service.sap.com/internetadviser
SAP Interface Repository, http://ifr.sap.com
SAP XML Schemas http://www.cis.ohio-state/edu/hypertext/information/rfc.html
[Task11] PABADIS Consortium, "Industrial requirements and overall specification", Deliverable,
2001
[Task12] PABADIS Consortium: "Agent Specification and Design", Deliverable, 2001
[Task13] PABADIS Consortium: "Platform Layer and Host Specification and Design",
Deliverable, 2001
[Task14] PABADIS Consortium: Agent Fabricator Specification and Design, Deliverable, 2001

ANNEX 1: SAP communication techniques

A.1Accessing business connector functionality
To access functionality in the Business Connector, so called are called via HTTP. This is done by
posting a document containing the parameters to the service. In our case, we always post documents
containing the XML format of the Idoc or BAPI/RFC-call to a service of the Business Connector that
converts the document and calls the SAP system.
The following statements must be used to post a document to the /sap/InboundIdoc service of the
Business Connector. The keyword invoke must not be omitted. The empty line that follows the header
is also very important!
POST /invoke/sap/InboundIdoc HTTP/1.0
<?xml version="1.0" encoding="iso-8859-1"?>
<ALEREQ01>
<IDOC BEGIN="1">
Which services of the Business Connector should be used for the different SAP communication
objects are explained in the next sub-chapters.
A1.1 IDOC Communication

In the ALE customising (transaction SALE) you specify the sender and the receiver for an Idoc (e.g.
sender SAP and receiver EXTERNAL, Idoc message type MATMAS). Then you can send this Idoc to
the Business Connector using an appropriate RFC destination.
A1.1.1 Creating the routing rule
You need to add the following Routing Rule, to convert the Idoc into XML and send it from the
Business Connector with HTTP to an external webserver:
A1.1.2 Receiving the IDOC
Your external webserver will receive an HTTP request containing a header with HTTP parameters
and an XML document containing the Idoc in XML format. You can see that the routing information in
the control record of the Idoc matches with the Routing Rule in the Business Connector.
Content-type: application/x-sap.idoc
Content-length: [length of XML doc]
X-tid: [TID]
<?xml version="1.0" encoding="iso-8859-1"?>
<MATMAS02>
<IDOC BEGIN="1">
<EDI_DC40 SEGMENT="1">
<RCVPRN>/</RCVPRN>
<SNDPRN>3</SNDPRN>
<MESTYP>6</MESTYP>
</EDI_DC40>
<E1MARAM SEGMENT="1">
...
</E1MARAM>
</IDOC>
</MATMAS01>
You need to answer the HTTP request that was initiated by the Business Connector. With the BC 3.5,
you need to answer the request with an empty Idoc or you must apply a patch (is included in the
partner documentation package)!!
Content-type: application/x-sap.idoc
<IDOC/>
A1.2 BAPI communication

A1.2.1 BAPI outbound processing
BAPI calls are sent to the Business Connector using an appropriate RFC destination.
The routing information of a BAPI call consists of the SAP systemID (e.g. SAPSYSTEM), the used
RFC destination (e.g. EXT_DEST) and the name of the function module representing the BAPI (e.g.
BAPI_CUSTOMER_SEARCH). The Routing Rule in the Business Connector must match this
information. In the Routing Rule, the Business Object and the Method of the BAPI must be specified.
A1.3 RFC communication

A1.3.1 RFC outbound processing (SAP is client)
RFC calls are sent to the Business Connector using an appropriate RFC destination.

The routing information of a RFC call consists of the SAP systemID (e.g. SAPSYSTEM), the used
RFC destination (e.g. EXT_DEST) and the name of the RFC function module (e.g.
QIRF_SEND_CATALOG_DATA). The Routing Rule in the Business Connector must match this
information.
The following 2 example show how the SAP R/3 system is connected using the above described
communication techniques with external system.
A1.3.3 Example I: Exit handlers and user exits on the outbound server
Outbound server
SAP R/3 other
IDoc
Exit handler application
e.g.
User exit
code
An R/3 application sends some invoice data to a non-SAP application. The data from the R/3
application is always in IDoc format. It´s possible to write a user exit for the outbound server to:
• Extract the relevant data from the IDoc in the message

• Build a new message with the data in the format expected by the receiving application
The server then puts the new message on its outbound message queue, where an application can
access it. For the inbound server, you can use the reverse procedure to convert incoming data from a
non-SAP application into an R/3 IDoc format.
A1.3.4 SAP R/3 link solution by IBM: MQSeries

MQSeries link for R/3 connects R/3 systems to other applications that use MQSeries messaging. This
can be an application directly or an database.
application link
SAP R/3
enabling layer
ALE
intermediate
documents
(IDocs)
MQSeries link
MQSeries
(queue manager)
other other
application DB application
e.g. e.g.

Annex 2: XML Interface document

definitions
A.1. Normal Structure Definition Documents
A1.1 Insert
A.1.1.1 XML Request Insert
The request file in an insert XML request document contains information necessary for the insert
query execution. The #Fielddefinitions , action, name and recordcount entities has the semantic that
was described in the XML request Document.
The record entities with the fields sub-entities contains the values of fields. The name of the entity of
the fields is the XML aliases for the Configurator File.
<?XML VERSION="1.0" ?>
<xml>
<#FIELDDEFINITIONS>
<action>Insert</action>
<name>Predefined Object Name.sqlxml</name>
<RecordCount>Number of records affected</RecordCount>
<record>
<field1>value</field1>
</record>
<record>
</record>
</xml>
A.1.1.2 Configurator Insert

The #field mark are the table’s fields and the #values are the values that will be inserted in the field
and these values come from the XML File. The field names, which were entities in the XML request
file, substitutes the #field mark and their values substitutes the #values mark.
[Insert]
SQL=insert into "TableName" (<#FIELDS>) VALUES (<#VALUES>)
[Insert_XML]
XMLAlias=TableName.FieldName,Datatype,Size,*-=, Predinined Object
Name.sqlxml( Action, Param Number) or Exact Sql Statement for this field
.. .. ..
A.1.2 READ
A.1.2.1 XML Request Read

The request file in an insert XML request document contains information necessary for the select
query execution. The #Fielddefinitions , action, name and recordcount entities has the semantic that
was described in the XML request Document.
The parameter entities with the name and the value sub-entities contain the values of parameters of
the select query. In every parameter there is definition about the name and the value of the
parameter. The value of the parameter can contain operators and keywords, which allow complex
structure. The operator and the keywords are described in the Annex.
<?xml version="1.0"?>
<xml>
<#FIELDDEFINITIONS>
<action>read</action>
<Parameters>
<Parameter>
<Name>Parameter Name 1</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</Parameter>
<Parameter>
</Parameter>
</Parameters>
</xml>
A.1.2.2 Configurator Read

The configurator file consist of two basic marks the #Fields and the #Params marks. The #fields
marks has different semantic from the insert configurator document and in this situation it represents
the fields whose that would be arise after the sql query execution. These fields will be used to build
the response document later on.
The second important mark is the #Params Mark which contains information for the parameters of the
query. The parameter values would come from the XML request file.
The Masterkey and the DetailFkey contains information about the Master table primary and the Detail
table foreign key respectively. These section variables are used when the configurator file will be used
in a master-detail structure. In this case it is necessary for the consultant, who create the configurator
file, to provide with this information which is essential for the join of the master and the detail table.
The DetailFkey is also used when the value of a field is retrieved from another sqlxml file.
[READ]
SQL= select <#FIELDS> from "TableName or Tables" where “join” and <#PARAMS>
PARAM1=TableName.FieldName,Datatype,Size,XMLVariable,* or -
PARAM2=TableName.FieldName,DataType,Size,XMLVariable,* or -
Masterkey=TableN1ame.FieldName,Datatype,Size,*=
DetailFkey=TableName.FieldName,Datatype,Size,*=
...
[READ_XML]
.. .. ..
(Action = Insert or Read)
A.1.2.3 XML Response Read

The XML response read document is the result of the query execution formated exactly as the Insert
request document. This facilitates the insert after a read.
<?xml version="1.0" ?>

<xml>
<#FIELDDEFINITIONS>
<action>Read</action>
<record>
</record>
<record>
</record>
</xml>
A.1.3 UPDATE
A.1.3.1 XML Request Update

<xml>
<#FIELDDEFINITIONS>
<action>Update</action>
<Parameters>
<Parameter>
<Value>(<operator> @Field1) or "value1"</Value>
</Parameter>
<Parameter>
</Parameter>
</Parameters>
<record>
<Parameters>
<Parameter>
<Value><operator> "value1"</Value>
</Parameter>
<Parameter>
</Parameter>
</Parameters>
</record>
…………………….
</xml>
This XML Update request document that is send from the XML 3rd partly application to the XML
service. The XML document has information like:
<#FIELDDEFINITIONS>, which describe some information about each updated field, like typefield
and size
action, which describes the kind of the query (read=select, insert, update, delete) that the XML
application server must execute
name, is the name of the predefined “sqlxml” file (configurator file), which has information for the
sql statement construction of a specific query
recordcount, is the number of the record that has to be updated
for each record that must be updated, the fields and the values (set part)
Parameters, which are parameters with their values in the where clause of the update sql
statement.
In the update we can have 2 XML request documents, which has to do with the position of the
Parameters tag in the XML document. The parameters could be inserted within in each record (for
each record we have an update), so we can for each record (or update) different parameters or we
can insert the parameters before the record so all records will have the same parameters, but with
different values (@FIELD1) that is takes from the value of field1.
A.1.3.2 Configurator File
[Update]
SQL=Update "TableName" SET (<#SET>) Where (<#PARAMS>)
.. .. ..
[UPDATE_XML] <#SET> (Partial)


.. .. ..
<#SET> are the fields that must be updated. The XML application server substitutes this <#SET> with
the fields that are written in UPDATE_XML section from the ini (.sqlxml) file. The update values of the
fields are been taken from the XML request update document (Partial).
<#PARAMS> are the parameters in the where clause. The XML application server substitute this
<#PARAMS> with the fields that are written in UPDATE section from the PARAM1, PARAM2, …….
The values of the variables are been taken from the XML request update document.
A.1.4 DELETE
A.1.4.1 XML Request
<xml>
<action>Delete </action>
<Parameters>
<Parameter>
</Parameter>
<Parameter>
</Parameter>
</Parameters>
</xml>
This XML Delete request document that is send from the 3rd partly application to the XML service. The
XML document has information like:
action, which describes the kind of the query (read=select, insert, update, delete) that the XML
service must execute
name, is the name of the predefined “sqlxml” file (configurator file), which has information for the
sql statement construction of a specific query
Parameters, which are parameters with their values in the where clause of the delete sql
statement.
From this XML document the XML Service parse the name, the parameters and their values, and with
all the information that it gets form the “sqlxml” file it construct the query.
A.1.4.2 Configurator file

[DELETE]
SQL=Delete From "TableName" Where (<#PARAMS>)
.. .. ..
A.2. Master – Detail Structure Definition Documents
A.2.1 Insert
A.2.1.1 Request XML
The Master-Detail XML request document differs from the normal XML request document in two
points. The first is the Action entity which now has an type attribute with value ‘md’.
The second and most important is that every record entity has two kinds of sub-entities the Field and
the Details. In the fields entities there is information about the Master Table Fields. In the detail
information there is information about the detail table fields.

<xml>
<#FIELDDEFINITIONS>
<Action type="md">Insert</Action>
<RecordCount> Number of Total Master records affected</RecordCount>
<record>
<details>
<RecordCount>Total Detailed Records affected</RecordCount>
<record>
<detailedfield1>value</detailedfield1>
</record>
<record>
</record>
</details>
</record>
</xml>
A.2.1.2 Configurator Insert

There are two sqlxml files that are use in insert section. The first is for the Master table and the other
is for the Detail table. In these two sqlxml files there ought to be a Masterkey and a DetailFkey for the
Master table and the Detail table respectively.
[INSERT]
MASTERSQL="FileName.sqlxml of Master Insert Statement"
DETAILSQL="FileName.sqlxml of Detail Insert Statement"
A.2.2 Read
A.2.2.1 Request XML

The Master-Detail read request XML document is structurally the same to the normal read request
document except the action entity that come by the type attribute. Also optionally can send a second
XML document that contains information about the parameters for the Detail table.
<xml>
<action type="Master"> Read</action>
<Parameters>
<Parameter>
</Parameter>
<Parameter>
</Parameter>
</Parameters>
</xml>
{Optional}
<xml>
<action type="detail">Read</action>
<Parameters>
<Parameter>
</Parameter>
<Parameter>
</Parameter>
</Parameters>
</xml>
A.2.2.2 Configurator Read

There are two sqlxml files that are use in read section. The first is for the Master table and the other is
for the Detail table. In these two sqlxml files there ought to be a Masterkey and a DetailFkey for the
Master table and the Detail table respectively.
[READ]
MASTERSQL="FileName.sqlxml of Master Read Statement"
DETAILSQL="FileName.sqlxml of Detail Read Statement"
A.2.2.3 Response XML

The XML response read document is the result of the query execution formatted exactly as the Insert
request document. This facilitates the insert after a read.

<xml>
<#FIELDDEFINITIONS>
<Action type="md">Read or Insert</Action>
<record>
<details>
<record>
</record>
<record>
</record>
</details>
</record>
</xml>
A.2.3 Update
A.2.3.1 Request Update

<xml>
<#FIELDDEFINITIONS>
<Action type="md">Read or Insert</Action>
<Parameters>
<Parameter>
</Parameter>
<Parameter>
</Parameter>
</Parameters>
<record>
<details>
<Parameters>
<Parameter>
</Parameter>
<Parameter>
<Value>(<operator> "value1" <keyword>
<operator> "value2") <keyword> <operator>
"value3"</Value>
</Parameter>
</Parameters>
<record>
</record>
<record>
</record>
</details>
</record>
</xml>
This XML master-detail Update request document that is send from the 3rd partly application to the
XML service. The XML document has information like:
• <#FIELDDEFINITIONS>, which describe some information about each updated field, like
typefield and size
• action, which describes the kind of the query (read=select, insert, update, delete) that the
XML application server must execute
• name, is the name of the predefined “sqlxml” file (configurator file), which has information
for the sql statement construction of a specific query
• Paramters, which are parameters with their values in the where clause of the update sql
statement of the master.
• recordcount, is the number of the record that has to be updated in the master
• for each record that must be updated, the fields and the values of the master (set part)
• details, which has the records that must be update in the detail
• Parameters, which are parameters with their values in the where clause of the update sql
statement of the detail.
• recordcount, is the number of the record that has to be updated in the detail
• for each record that must be updated, the fields and the values of the detail (set part)
From this XML document the XML Service parse the name, the parameters and their values of the
master (where clause) and the detail, the fields and their values of the master (set part) and the detail,
and with all the information that it gets form the “sqlxml” file it construct the 2 queries, that are
executed separately.

Pabadis (1999) - ERP Interface

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Pabadis (1999) - ERP Interface

Caricato da

Copyright:

Formati disponibili

PABADIS

Plant Automation based on

ERP-Interface specification and design

Document type : Deliverable

Project funded by the European Community

© The PABADIS Consortium

Rev. Content Resp. Partner Date

Final approval Name Partner

Reviewer Christos Fiskas Hatzopoulos S.A.

© The PABADIS consortium

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

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

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

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

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

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

© The PABADIS consortium page 3

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

© The PABADIS consortium page 4

0.2 CONTENT OF THE DOCUMENT

© The PABADIS consortium page 5

1 ERP systems potential and standards

© The PABADIS consortium page 6

1.1.1 Flexibility, Agility & Interoperability Enabled by Adaptable

© The PABADIS consortium page 7

1.1.2 Component Based Architecture

© The PABADIS consortium page 8

1.1.3 Open Interfaces and Improved Integration

1.1.4 Implications of this trend

1.1.5 An ERP Vendor example

© The PABADIS consortium page 9

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

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

Figure 2: SAP Architecture

1.2 STANDARDS IDENTIFICATION

1.2.1 Basic elements

© The PABADIS consortium page 11

CRM Service SCM

Accounting & Warehouse &

Fixed Assets Production

© The PABADIS consortium page 12

1.2.2 Basic Characteristics

1.2.3 Architectural Layers

OPERATING SYSTEM LAYER

Figure 4: ERP system Structural Layers

© The PABADIS consortium page 14

Figure 5: Four levels for integration of heterogeneous systems

© The PABADIS consortium page 15

1.3 ERPs evaluation description

JDEdward Navision Computer LogiC

© The PABADIS consortium page 16

Table 1: ERP Specifications

© The PABADIS consortium page 17

Open Customisability Interoperability Portability Real Time

Table 2: ERP basic characteristics

Rating of ERP basic characteristics

XXXXX Full support - Best practice

© The PABADIS consortium page 19

1.4 PRODUCTION MODULE

- Required machines’ availability for the specific product’s creation

© The PABADIS consortium page 21

Accounting Warehouse &

Fixed Assets Production