E-Business and
B2B Integration
A Tutorial by
Gurpur M. Prabhu
Outline
E-Business
Nature of Business Activities
Business Requests and Responses
Requirements for Business Integration
EAI vs. B2B
XML
RosettaNet, Web Services, BizTalk
Summary
Copyright 2002 Gurpur M. Prabhu
2
What is E-Business?
To some it means Web-enabled selling
To some it means middleware
To some it means Web application servers
To some it means Web Services
To many it is the force that is driving the
fundamental restructuring of every industry
Copyright 2002 Gurpur M. Prabhu
3
E-Business
The value of E-business is clear
How to make it happen is less clear
It demands a very different technology
than current systems
Current technology is developer-oriented
What is needed is a business-oriented
focus
Copyright 2002 Gurpur M. Prabhu
4
Event-Driven Paradigm
E-business is event-driven
An order event instantaneously triggers
other events
Every system affects every other system
in real time
Common business models are needed to
determine the “path” of business events
Copyright 2002 Gurpur M. Prabhu
5
What is Integration?
To some it means integration of data
To some it means integration of
applications
‘Seamless integration of business
processes’ sounds like an IBM TV
commercial
No clear consensus on ‘integration’
Copyright 2002 Gurpur M. Prabhu
6
Nature of Business Integration
A system should be able to communicate
with other systems, automatically and
expediently
Is bound at both data and process levels
Information exchange alone is not enough
– business rules and processes also need
to be mutually accommodated to process
data
Copyright 2002 Gurpur M. Prabhu
7
Business Activities
Strategy
Planning
Intelligence
Marketing
Needed
Making Requests
Operational
Improvement
Handling Requests
Speculation
Inventory Control
Book-keeping
Assembly Line
Economic Benefit
Copyright 2002 Gurpur M. Prabhu
8
Nature of Requests
Special
Shipment
Statistics Report
JIT Data gathering
RFQ
RFQ Response
Standard
Order Fulfillment
User-Initiated
Business Event-Driven
Copyright 2002 Gurpur M. Prabhu
9
Handling Incoming Requests
Special
Shipment
Statistics Report
Account Balance
Credit Payment
Purchase Order
Standard
Low
Decision Making
Copyright 2002 Gurpur M. Prabhu
High
10
Example Process: Request For Quotation
Manufacturer
Supplier
Send RFQ
To Supplier
Response
Shipper
Send request
To Shipper
Response
Time
Make Decision
Business Message
Copyright 2002 Gurpur M. Prabhu
11
Example Process: RFQ (1)
Manufacturer sends request to several
suppliers
Suppliers send responses back
Mfr sends request to several shippers
Shippers send responses back
Mfr has to make decision based on
various responses
For Mfr, all business messages are part of
a SINGLE business transaction
Copyright 2002 Gurpur M. Prabhu
12
Example Process: RFQ (2)
Suppliers and shippers will have multiple
business transactions with multiple
manufacturers, all executing concurrently
Time between response to mfr and order
acknowledgment is critical
All transactions are exposed to partial
updates made by other concurrently
executing transactions
Copyright 2002 Gurpur M. Prabhu
13
Variations in Responses
Accept or Reject our request
Alter our request
Partially accept our request
All the above with respect to one or more
elements in our request
Copyright 2002 Gurpur M. Prabhu
14
Evaluating Responses
Determine context of request
Consider acceptable alternatives
Determine relationships between elements
in the request that affect partial
acceptance
Compare responses from different targets
Copyright 2002 Gurpur M. Prabhu
15
Critical Success Factors for BPI
Ensuring that Business Process
Integration is a business-driven approach
Building a coalition that crosses functional
and enterprise boundaries
Utilizing technology that facilitates BPI
collaboration and deployment
Copyright 2002 Gurpur M. Prabhu
16
Software Requirements:1
To be truly effective, a BPI product must
incorporate all manual and automated
steps within processes being integrated
Triggering of processes or responses to
process-driven requests must be
incorporated into the web environment
Should accommodate a dynamic level of
responsiveness
Copyright 2002 Gurpur M. Prabhu
17
Software Requirements:2
Should accommodate internal and
external processes including those of
supplier environments, distribution chains,
and customer domains
Must be highly scalable
Must manage processes end-to-end,
allowing a series of processes to function
in an uninterrupted manner
Copyright 2002 Gurpur M. Prabhu
18
Characteristics of any Solution
Standard Solutions for:
– Aspects such as communication,
authentication, authorization
Custom Solutions for:
– Handling Special requests
– Variations in decision making
– Variations in processes
– Handling implementation differences
Copyright 2002 Gurpur M. Prabhu
19
Consequences of customization
Customization drives up the cost
Comfort-zone IT budgets are 5 to 7% of
sales revenue
Large corporations have more revenues
but also more establishments
Customization cost can easily exceed 5%
of sales revenue per establishment
Copyright 2002 Gurpur M. Prabhu
20
EAI vs. B2B
Business drivers for Enterprise Application
Integration (EAI) and B2B are different
EAI deals with internal integration and
must be highly structured and controlled
B2B deals with external integration and
must be open and fluid
Much confusion results when proposing
EAI solutions for B2B problems
Copyright 2002 Gurpur M. Prabhu
21
EAI Business Drivers
Transaction focused
End-to-end transaction completeness
Reuse across systems
Standardize and leverage objects/data
across systems
Flexibility to switch applications
Real-time communications and message
delivery
Copyright 2002 Gurpur M. Prabhu
22
Evolution of EAI Systems
Mkting
Fin
Spaghetti Integration
ERP
Mfg
R&D
Internet
CRM
Supply
Chain
B2B
Legacy
ERP
Enterprise Resource
Planning systems were
built without external
integration in mind
EAI
Web
Copyright 2002 Gurpur M. Prabhu
Supply
Chain
23
ERP Systems
B2B integration implies seamless
communication between existing systems
and databases (yours and your trading
partners’)
But packaged applications such as SAP,
Oracle Financials, and PeopleSoft – for
example – were designed NOT to access
anything outside their proprietary
technology
Copyright 2002 Gurpur M. Prabhu
24
B2B Business Drivers
Business Document focused
End-to-end document completeness
Reuse across trading partners
Work with numerous data definitions and
standards
Flexibility to switch trading partners
Communication and message delivery that
fit partners’ capabilities
Copyright 2002 Gurpur M. Prabhu
25
Enterprise
Inter-Enterprise Systems
EAI
B2B
B2B
RosettaNet
XML
Web
Services
ebXML
BizTalk
Suppliers
Customers
Partners
Copyright 2002 Gurpur M. Prabhu
26
Problems with Current B2B
Solutions
Cost and Time needed for
customization very high
Automatic solutions are not geared to
work with the existing manual solutions
Hence the requirement of a large install
base is not being realized
Copyright 2002 Gurpur M. Prabhu
27
What is XML?
eXtensible Markup Language
Was never intended for information
exchange . . .
. . . But has now become a standard for
data interchange
XML’s real power is not the technology but
the fact that it is an accepted standard
Copyright 2002 Gurpur M. Prabhu
28
Sales
System
Data
Legacy
System
XML
ERP
System
Web
applications
Copyright 2002 Gurpur M. Prabhu
29
Example XML specification
<customer>
<name>John Doe</name>
<customer_no>125</customer_no>
<address>111 Main St.</address>
<city>Anyville</city>
<zip>11111</zip>
</customer>
Copyright 2002 Gurpur M. Prabhu
30
What XML does
Large chunks of information are
consolidated into an XML document
XML parsers extract data from XML
documents
XML is a simple format that provides
metadata and information content
Applications must be able to internalize
and externalize XML information
Copyright 2002 Gurpur M. Prabhu
31
XML’s Contribution
Facilitates the development of
Standards
Provides the ability to write programs
that process document content
However, this does not fully solve the
B2B integration problem
Copyright 2002 Gurpur M. Prabhu
32
Data Sources
Trading Partners
THE B2B PROBLEM
IBM
RFQ
1
API-based
XML
GE
RFQ
Middleware
2
XML Document
contains the
specification
of the RFQ
Middleware
calls functions
for processing
the data
API calls
But EVERY
pre-existing
data processing
functions at data
function must
sources
be implemented
N
If there are N trading partners, each one’s RFQ
at EVERY data
process must be implemented at N-1 data sources.
source
To support a single process change for ONE partner,
N-1 implementations must change – a maintenance nightmare.
Copyright 2002 Gurpur M. Prabhu
33
How is Data Accessed today
By sending Requests (Using some distributed
computing method such as RMI, COM, or
CORBA)
Needs pre-determined Semantics for the
Request, the Response, and the Process that
generates the Response
Processes provide fixed functionality
Both Requests and Responses need
customization to integrate into user-side
systems, and the data-side systems
Copyright 2002 Gurpur M. Prabhu
34
Semantic Content of Request
and Response
Mostly implied by pre-determined Semantics
Requests do not have the expressive power to
define dynamic requirements
For the same information in the Request, and
the same process, the content in the Response
cannot be changed dynamically.
XML helps automate processing of Requests
and Responses, but cannot define the
computing that needs to be performed
Copyright 2002 Gurpur M. Prabhu
35
Semantics of Database Process
Description of the Selection of the dataset
Description of the operations on each element in
the dataset
For the same semantics, the code to select the
dataset, and the code to perform the operations,
change from system to system
Therefore, customized code that performs the
same actions is needed for each data source
Copyright 2002 Gurpur M. Prabhu
36
Current Approach to
Collaborative Enablement
Accommodation Phase
– Internal Requirement Definitions
– Collaborative Process Definitions
Agreements Phase
– Business Operations to be covered
– Computer Processes to implement
– Documents to be exchanged
Copyright 2002 Gurpur M. Prabhu
37
Problems with Current
Approach:1
Complicated Accommodation Phase
– Involves complex negotiations with Trading
Partners
– Each organization will try to:
Influence others to implement processes to allow
their own Internal Requirements to be realized
Minimize their efforts in implementing the
functionality needed by external organizations
Copyright 2002 Gurpur M. Prabhu
38
Problems with Current
Approach:2
Compromise-prone Agreements Phase
– When the composition of the trading partners
changes, agreements need to be re-negotiated
– New agreements lead to complex maintenance
issues
– Inherently not an ideal solution – compromises and
added (non-productive) work for all trading partners
All these act as impediments to Collaborative
Commerce
Copyright 2002 Gurpur M. Prabhu
39
Realizing XML’s Potential
XML based Standards are just
specifications – each system is expected
to provide the implementation
But can the ‘How’ (i.e., implementation) of
the XML ‘What’ be the same on every
system?
Such an abstract Write-Once-RunAnywhere programming model is needed
to realize XML’s potential
Copyright 2002 Gurpur M. Prabhu
40
RosettaNet
Defines standard processes and interfaces
Develops common Partner Interface
Processes (PIPs)
Common agreement on “which processes
do what and where”
Focus is more on creating PIPs and less
on any new technology
Copyright 2002 Gurpur M. Prabhu
41
RosettaNet Development Process
Business Process Modeling
Business Process Analysis
Partner Interface Process
Purpose: provide e-Business Interface
Output: XML Docs + model + validation
Dictionaries
Implementation
Framework
Copyright 2002 Gurpur M. Prabhu
42
Web Services
Company A: Web Services Provider
UDDI: Universal Description and
Discovery of Information
ebXML: Electronic Business XML
Company A
Company A publishes
its service to a Registry
Registries
UDDI, ebXML
WSDL: Web Services Description Language
Company B: Web Services Customer
Company B
Company B
queries the registry
If Company B determines that A’s service meets its requirement,
it builds the interface necessary to connect its applications to A’s service.
Potential Limitation: Every company needs an interface for every web
Service that it wants to use.
Copyright 2002 Gurpur M. Prabhu
43
Technology Comparison
XML
Standard for Document Exchange
Specification Oriented
XML-parser helps understand request
Data processing not done in document
API middleware calls predefined functions
Functions must exist at data source
Difficult to extend process functionality
RosettaNet
Standards for common business processes
Specification Oriented
Partner Interface Processes
Data Processing not done
Implementations needed at data sources
Difficult to extend process functionality
BizTalk
Web Services
XML-based Document-centric
BizTalk Server sends and Receives messages
BizTalk Framework defines BizTags
Microsoft is driving force
No adapters available for BizTalk Server
Publish-Discover-Bind paradigm
Uses UDDI, ebXML, WSDL, SOAP
Precise specification of service needed
Functionality extensible but interface
implementations needed for every service
Copyright 2002 Gurpur M. Prabhu
44
Summary
XML not a panacea for B2B problem
Business drivers and solution
requirements for EAI and B2B are different
All existing “solutions” are only partial
Standardizing processes not the way to go
Systems should be allowed to be different
but yet made to look similar for B2B
Semantic Bridge needed on data side
Copyright 2002 Gurpur M. Prabhu
45