Академический Документы
Профессиональный Документы
Культура Документы
IST-1999-60016
Task 1.5
TABLE OF CONTENT
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
4 ABBREVIATIONS.........................................................................................................................................44
5 REFERENCES..............................................................................................................................................45
TABLE OF FIGURES
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.
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.
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.
42 % 30 %
SAP
Oracle
Peoplesoft
J.D. Edwards
other
5% 8% 15 %
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]
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.
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.
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.
© The PABADIS consortium page 13
Deliverable 1.5 ERP-Interface specification and design IST – 1999 - 60016
PRESENTATION LAYER
INTERNET LAYER
APPLICATION LAYER
APPLICATION MIDDLEWARE LAYER
DATABASE LAYER
HARDWARE LAYER
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
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.
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
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.
SCM CRM
Service
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
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.
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.
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.
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.
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
Hardware Layer
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.
state and type state / remark, working plan type, parts list type, type, fixing code
details priority, batch / series, cost centre, cost unit rate, list of material, short message,
parts availability level, quantity, quantity available, quantity required, loss, deadline, article running time
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.
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>
< description> ……………..… < /description>
<quantity> ……………..… < /quantity>
<phases> ……………..… <phases>
< begin> ……………..… </begin>
< finish> ……………..… </finish>
< priority> ……………..… < /priority>
Materials
< id> ……………..… </id>
< type> ……………..… < /type>
< description> ……………..… < /description>
<product> </product>
<quantity> ……………..… < /quantity>
<service types> …………….…. </service_types>
< begin> ……………..… </begin>
< finish> ……………..… </finish>
< priority> ……………..… < /priority>
Phase
< description> ……………..… < /description>
<service types> …………….…. </service_types>
< begin> ……………..… </begin>
< finish> ……………..… </finish>
< priority> ……………..… < /priority>
Service
< description> ……………..… < /description>
<machine> …………….…. </machine>
< begin> ……………..… </begin>
< finish> ……………..… </finish>
< priority> ……………..… < /priority>
Order Materials
< order id> …………….. </ order_id> < id> ……………..… </id>
< factory> …………….. < /factory> <quantity> ……………..… < /quantity>
<service types> …………….…. </service_types>
< 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>
< finish> ……………..… </finish>
< priority> ……………..… < /priority>
Figure 12: Appropriate for the Agency metadata from a manufacturing order in an XML file
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>
< finish> ……………..… </finish>
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>
< finish> ……………..… </finish>
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
< finish> ……………..… </finish>
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.
Figure 15: XML file send to the machines and received back for knowing
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).
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
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
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
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.
- 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
SQL Configurator
Figure 21: Communication across the direction from CMUs community to the ERP
DB Trigger
Expector
ERP CMU
Agency
ODBC XML
XML Parsel
Service
Module
Receive Service
SQL
Configurator
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.
Submit XML response Document to Submit SQL query Parse <Parameter> from
the Agency to the ERP's DB request XML Document
Figure 23: XML Service Module WorkFlow from CMU, Agency to ERP direction
Figure 24: XML Service Module workflow across ERP to AGENCY direction
Configurator Stopped
Configurator Started
Trace the appropriate XMLSQL object Trace the appropriate XMLSQL object
based on the data stream information bas ed on the <ObjectName>
Modifications
detected in ERP's DB
Get modification
information from ERP's DB
RequestXMLDoc
XMLSQLObjectRequest
XMLSQLObjectResponse
SQLQuery
DataStream
ResponseXMLDoc
ModificationTriger
ModificationInformation
RequestXMLSQLObject
ResponseXMLSQLObject
SQL Query
DataStream
ResponseXMLDoc
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
[Task13] PABADIS Consortium: "Platform Layer and Host Specification and Design",
Deliverable, 2001
[Task14] PABADIS Consortium: Agent Fabricator Specification and Design, Deliverable, 2001
...
</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.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:
© The PABADIS consortium page 47
Deliverable 1.5 ERP-Interface specification and design IST – 1999 - 60016
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.
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>
<field2>value</field2>
<field3>value</field3>
</record>
<record>
<field1>value</field1>
<field2>value</field2>
<field3>value</field3>
</record>
</xml>
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>
<name>Predefined Object Name.sqlxml</name>
<Parameters>
<Parameter>
<Name>Parameter Name 1</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</Parameter>
<Parameter>
<Name>Parameter Name 2</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</Parameter>
</Parameters>
</xml>
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 -
PARAM3=TableName.FieldName,Datatype,Size,XMLVariable,* or -
Masterkey=TableN1ame.FieldName,Datatype,Size,*=
DetailFkey=TableName.FieldName,Datatype,Size,*=
© The PABADIS consortium page 50
Deliverable 1.5 ERP-Interface specification and design IST – 1999 - 60016
...
[READ_XML]
XMLAlias=TableName.FieldName,Datatype,Size,*-=, Predinined Object
Name.sqlxml( Action, Param Number) or Exact Sql Statement for this field
.. .. ..
(Action = Insert or Read)
A.1.3 UPDATE
A.1.3.1 XML Request Update
<field2>value</field2>
<field3>value</field3>
<Parameters>
<Parameter>
<Name>Parameter Name 1</Name>
<Value><operator> "value1"</Value>
</Parameter>
<Parameter>
<Name>Parameter Name 2</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</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.
[Update]
SQL=Update "TableName" SET (<#SET>) Where (<#PARAMS>)
PARAM1=TableName.FieldName,Datatype,Size,XMLVariable,* or -
PARAM2=TableName.FieldName,DataType,Size,XMLVariable,* or -
PARAM3=TableName.FieldName,Datatype,Size,XMLVariable,* or -
.. .. ..
<#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 version="1.0"?>
<xml>
<action>Delete </action>
<name>Predefined Object Name.sqlxml</name>
<Parameters>
<Parameter>
<Name>Parameter Name 1</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</Parameter>
<Parameter>
<Name>Parameter Name 2</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</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.
PARAM1=TableName.FieldName,Datatype,Size,XMLVariable,* or -
PARAM2=TableName.FieldName,DataType,Size,XMLVariable,* or -
PARAM3=TableName.FieldName,Datatype,Size,XMLVariable,* or -
.. .. ..
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.
A.2.2 Read
© The PABADIS consortium page 54
Deliverable 1.5 ERP-Interface specification and design IST – 1999 - 60016
<?xml version="1.0"?>
<xml>
<action type="Master"> Read</action>
<name>Predefined Object Name.sqlxml</name>
<Parameters>
<Parameter>
<Name>Parameter Name 1</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</Parameter>
<Parameter>
<Name>Parameter Name 2</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</Parameter>
</Parameters>
</xml>
{Optional}
<?xml version="1.0"?>
<xml>
<action type="detail">Read</action>
<name>Predefined Object Name.sqlxml</name>
<Parameters>
<Parameter>
<Name>Parameter Name 1</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</Parameter>
<Parameter>
<Name>Parameter Name 2</Name>
<Value>(<operator> "value1" <keyword> <operator>
"value2") <keyword> <operator> "value3"</Value>
</Parameter>
</Parameters>
</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.
A.2.3 Update
A.2.3.1 Request Update
<field3>value</field3>
<details>
<Parameters>
<Parameter>
<Name>Parameter Name 1</Name>
<Value>(<operator> @Field1) or "value1"</Value>
</Parameter>
<Parameter>
<Name>Parameter Name 2</Name>
<Value>(<operator> "value1" <keyword>
<operator> "value2") <keyword> <operator>
"value3"</Value>
</Parameter>
</Parameters>
<RecordCount>Total Detailed Records affected</RecordCount>
<record>
<detailedfield1>value</detailedfield1>
<detailedfield2>value</detailedfield2>
<detailedfield3>value</detailedfield3>
</record>
<record>
<detailedfield1>value</detailedfield1>
<detailedfield2>value</detailedfield2>
<detailedfield3>value</detailedfield3>
</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.
© The PABADIS consortium page 57