This document discusses moving from EDI to XML for eBusiness transactions. It describes different eBusiness models including B2C, B2B, and information exchange. EDI established business conversations through standardized schemas and message formats. XML simplifies integration by using more verbose tagging and allowing additional message information. The document provides an example of converting an EDI header to XML/EDI format. Future directions discussed include using agents and templates to make XML/EDI systems more adaptive and able to handle message exchanges.
2. Doing eBusiness with XML :
Agenda
• eBusiness Models
– Selling direct to the customer (B2C)
– Business to business (B2B) transactions
– Information and Content Exchange (ICE)
• EDI “business conversations”
• Why move from EDI syntax to XML ?
• From EDI to XML/EDI
• Future directions
3. What is eBusiness ?
• E-Business
– Is about information exchange
– Includes variety of supplemental messages
• Supply chain
– Coordination of a portfolio of assets, logistics,
information & operations involved in fulfilling
the final customer demand.
• Messaging via EDI
– Many web-sites have ERP back-ends being
automated to process orders either via EDI or
proprietary protocols & message formats.
4. eBusiness Models
– Selling direct to the customer
• In B2C transactions, customers use credit cards
while ordering directly- Disintermediation at work !
– Business to business transactions
• In B2B transactions, trading partners have contracts
with supplier- virtual inventory for procurement !
• Rip and read processing is the order of the day!
• XML in eBusiness aims to get rid of rip and read !
– Information and Content Exchange (ICE)
• focussing on extending the enterprise, streamlining
intra-enterprise processes, using infomediaries.
Browser Infomediary Suppliers
5. EDI “business conversations”
• EDI paved the way for eBusiness.
– Americans use ANSI/X12
– Rest of the world uses UN/EDIFACT
• EDI transaction or business conversation
– Uses dynamic messages shared using schemas.
– Schemas are detailed descriptions of format of
data objects mutually agreed upon by parties.
– Message is wrapped in an envelope having
header, segments and elements, and trailer.
– We use mapper software Mercator to translate
messages from and into internal formats.
6. Why move from EDI to XML ?
• When implementing an eBusiness solution
with XML and EDI, it is called XML/EDI.
• XML tagging syntax is much more verbose,
but simplifies integration of messages,
allowing additional information to be used
by the process in addition to data itself.
• Using XML, we can develop the XML/EDI
message formats that need not be translated!
7. Moving from EDI to XML/EDI
• An example of XML/EDI
– Original EDI X12 header :
• ISA^00^ ^ZZ^1019000
ZZ^COLONIAL^980120^1712^U^00200^0000000
05^0^P^>
– The ASC X12 compliant XML/EDI header :
• <ISA AuthorizationQual=‘00’ Authorization=‘’
SecurityQual= ‘00’ Security=‘’ SenderQual=‘ZZ’
Sender=‘1019000’ ReceiverQual=‘ZZ’ Receiver=‘
COLONIAL ’ XchgDate=‘ 980120 ’ XchgTime= ‘
1712’ StdAgency=‘U’ StdVersion=‘ 00200’
AckReq=‘0’ Usage=‘P’ >000000005</ISA>
8. Why XML?
• XML is for loose-coupling
– no recordset sends
– no parameter passing
– not everything is going to be web based!
• Applying XML in eBusiness
– Message Headers
• Multi-tiered Routing Issues
– Message Body
• Using existing Schemas
9. Why XML?
• XML is for loose-coupling
– no recordset sends
• Why return VB collections, database cursors, etc. ?
• Send self describing data as an XML page instead!
– no parameter passing
• Why bother about pass by value or reference ?
• Send XML page- XML parser will help the other
side of the world!
– And not everything is going to be web based!
• E.g. doing behind-the-web, batch mode operations!
– EDI is tightly-coupled, XML loosely-coupled!
10. Why XML?
• Applying XML in eBusiness
– Involves XML message travelling between a
customer and a supplier. XML is used at every
application tier, throughout the supply chain!
– Message Headers
• Multi-tiered Routing Issues
– Routing, Security, Error flagging, Transaction identity,
Batching, Tracking, Transport independence, etc.
– Message Body
• Using existing Schemas
– XML data involves reuse of the domain vocabularies;
since the self describing XML page is for humans too!
11. Future directions
• Agents
– Agent is component that independently acts to
accomplish goal of user or another component.
– Agents allow the XML/EDI systems to be self-
adaptive and able to handle large expansion of
exchanges without excess human intervention.
– We typically use agents in tracking transaction
content, to send an alert to support staff about
the potential failure conditions in EDI input.
12. Future directions
• Templates
– Templates are useful in establishing a common
negotiation protocol at the middle tier.
– Templates are dynamically created by agents,
using message brokering techniques.
• Message Brokers
– “Hub and spoke” architecture for EAI
• Brokering messages between one or more target
entities, networks, middleware, apps or systems,
regardless of how the message is represented!
• Use message translation, rules management and
intelligent routing mechanisms.