| |
Table of contents | Author | City | Company | Country | State/Province | Term | Interchange | |
Garfinkel, Yossi , Product Manager , Enigma, Inc., Israel
Email: yossig@enigma.com
Web site:www.enigma.com
Yossi Garfinkel works for Enigma, the Support Chain company, as Product Manager for Parts Catalog solutions. In this role, he oversees development of spare parts catalogs that deliver integrated aftermarket-related catalog content and provide functionality to generate and support eCommerce transaction activity.
This paper focuses on how XML storage, integration and interchange capabilities come to play in upgrading illustrated parts catalogs from published paper tomes to eCommerce applications driving aftermarket sales of spare parts.
Aftermarket Parts Catalog Parts Aftermarket Parts Catalogs provide detailed information about repair and replacement parts needed by equipment operators to maintain complex capital equipment.
Parts Catalogs are a key selling tool in aftermarket sales of heavy equipment spare parts. Aftermarket sales generate a disproportionate amount of revenue and profit when compared with the sale of the initial equipment. For example, a $10 million airplane engine will sell itself again three times over in the value of spare parts with profits derived solely from the spare parts sales. The content of aftermarket Parts Catalog is the virtual product sold to the customer before the first replacement part is ordered. A competitive advantage can be gained in the aftermarket by providing the most complete, accurate and up-to-date equipment maintenance and repair content that supports and drives the parts ordering decision. The efficient and timely locating and ordering of correct replacement parts is a significant cost-saver for complex equipment operators.
A typical aftermarket parts catalog will include the following contents: Parts Configuration information in the form of parts hierarchies and assembly parts lists, Part Details such as description, inventory levels and pricing, graphic illustrations of part assemblies and technical documents such as Service Bulletins and Maintenance Manuals required as guidebooks for equipment maintenance.
Evolution of parts catalogsOver the last decade, Aftermarket parts catalogs have developed from being static published paper tomes to dynamic eCommerce applications driving and enabling spare parts sales. Their evolution can be divided into three main phases: Paper catalogs, electronic publications and eCommerce applications.
Parts catalogs are still published today as paper encyclopedias of detailed parts information. The catalog content is assembled from a variety of sources such as paper documents, graphic illustrations and computer report listings, complemented by faxes and telephone calls. All mediums are acceptable input and the publication process is tedious. The catalog fulfills the role of reference manual much in the same way as a paper telephone directory. Orders for spare parts are initiated as a distinct and separate activity from catalog browsing.
Paper catalogs are published once or twice a year and work on the next edition begins as soon as the previous edition is released. The information is obviously not always up-to-date and the catalog generally needs to be complemented, checked and corrected by the catalog user in real time. This obviously obstructs the free-flow of the business process. Microfiche catalogs are based on the same hard copy principle as paper catalogs. Physical storage space is saved but the user process of collecting data from multiple reference points in the catalog can be very tedious.
First generation parts catalogs Heavy equipment manufacturing Published paper catalogs can be considered as first generation parts catalogs. They are still in widespread use today, particularly in old economy industries such as heavy equipment manufacturing.
As catalog content sources became more available in digital form, second generation catalogs emerged that transformed the paper or microfiche parts catalog to an electronic publication distributed on CD and accessed via a computer screen.
Electronic publications Second generation parts catalogs The catalog publication process involves assembling disparate data from multiple enterprise sources and offering the user a single, navigable interface to parts information. Information Technology speeds up existing user processes of catalog referencing and searching whilst at the same time saving trees. Other benefits of electronic publications include increased accuracy of data (no print or binding errors), manageability of partial or full updates and ease of distribution.
The internet-age technology and commerce context of aftermarket parts catalogs have given rise to third generation catalogs that focus on harnessing technology to support the business driver of the catalog-spare parts sales. As information system boundaries have fallen, the demand has grown for catalogs that in addition to delivering comprehensive parts information from existing enterprise systems, allow commerce communication with business partner systems on the opposite side of the firewall.
Procurement Third generation parts catalogs eCommerce The main commerce-related features of an eCommerce application are the enabling of initiating parts orders on-line directly from the context of the catalog content, and the ability to pass catalog content to multi-supplier catalogs, exchanges or buy-side procurement systems.
This paper focuses on the role of XML in supporting the content requirements of Aftermarket Parts Catalogs created to serve as eCommerce applications.
|
Aftermarket Parts Catalog--User View |
Content requirements Data integration Data interchange Data storage formats Aftermarket Parts Catalogs contain a wealth of information about equipment components in a variety of data and content formats. Creating an Aftermarket parts catalog eCommerce application which delivers this assorted content, and supports associated eCommerce transaction processes, generates three main content needs:
the assorted catalog content must be stored in an electronic format
the varied catalog contents need to be integrated from their multiple sources
the catalog must support data interchange with related systems.
Graphic images Structured tabular data Text documents Aftermarket catalog contents can be loosely divided into the following types of content structures:
The catalog contents can be a representation of any one or more of the three content structure types. The following table maps aftermarket parts catalog contents to the three types of content structures:
| Content Structure | |||
|---|---|---|---|
| Catalog Contents | Unstructured Text Document | Structured Tabular Data | Graphic Image |
| Part Configurations | • | ||
| Part Details | • | ||
| Service Bulletins | • | ||
| Assembly Illustrations | • | ||
To enable delivery of the catalog content by an electronic publication, and benefit from search and retrieval functionality facilitated by digital content structures, the catalog content must be represented and stored in electronic format supporting one of these structures.
Catalog contents held in electronic form are represented and stored in content repositories ranging from file systems to relational databases to enterprise applications.
Despite the trend to move all enterprise data into one application or one repository source, most enterprise data, including catalog contents, remains in disparate and unconnected information systems. Data or content remains separated not only because the different structures find their repose in different storage systems (file systems, relational databases) but also because the different business processes associated with the content places them in specific enterprise applications. Sources of catalog content are characteristically enterprise applications such as ERP , CRM , PDM , and DMS and their underlying file system or relational database based repositories.
The content of the parts catalog has to be identified each in its source location and format. The main catalog contents and their typical sources are summarized in the table below:
| Content Sources | ||||||
|---|---|---|---|---|---|---|
| Applications | Repositories | |||||
| Catalog Contents | ERP | CRM | PDM | DMS | Relational Database | File System |
| Part Configurations | • | • | • | |||
| Part Details | • | • | • | |||
| Service Bulletins | • | • | ||||
| Assembly Illustrations | • | • | ||||
Enterprise applications Repository source The table shows how catalog contents are typically dispersed over a variety of enterprise application and repository sources. Integration of content from these multiple sources and formats is required to enable unified content delivery . In addition, content integration is needed to support catalog functionality requiring interaction between content from different sources. For example, to support hotspot highlighting, the catalog must support an active link between an assembly parts list and a graphic assembly illustration. Clicking on a part in an assembly parts list sourced from one enterprise application highlights a corresponding hotspot in the assembly illustration drawn from a separate repository source. In this case, in addition to integration of content from separate content sources, two very different types of content structures, structured text and image files, are inputs to the integration process.
Content Interchange for eCommerceThe interchange of data between enterprise applications and across company boundaries forms the basis of eCommerce. A prerequisite to an eCommerce application is the ability to interact with business partner systems. The parts catalog initiates the part sales transaction by sending parts orders to local or remote enterprise applications such as Order Management or Procurement systems. Parts orders data consists of basic details of ordered parts and additional information such as order quantities and customer information.
In Addition, the whole catalog or subsections of it may be sent to multi-supplier catalogs for the purpose of driving spare parts sales at a remote site such as Buyers' Procurement systems or web trading exchanges. The catalog content in this case includes the full assortment of catalog content structures and types.
|
Data Storage, Integration and Interchange Requirements of Aftermarket Parts Catalogs |
Aftermarket Catalog ContentXML is the prolific standard for representing data. Its flexibility makes it suitable for structuring almost any form of data. Additionally, the ongoing developments of XML-related business logic functionality make it a popular choice for content representation and storage.
As described earlier, the main contents of Aftermarket parts catalogs (Service Bulletins and Maintenance Manuals, Part Configurations, Parts Details and Assembly Illustrations) can be broken down into their respective content structures
Assuming that all catalog content is stored in electronic form, what can XML provide in terms of representing and storing these types of content structures?
Data representation Storage XLink XPath XPointer XQL The main benefit touted by XML is that it gives structure to unstructured data. It does this by embedding metadata tags in the data. Without these metadata tags, the fluid, unstructured contents of text documents would be difficult for software to reference other than as a single body of text, or as a random collection of individual words. XML tags provide meaning to segments of data that are associated with a particular topic, usage or context and mark access points for data segment reference and retrieval. Data stored as XML benefit from the numerous search techniques developed for XML formatted data including keyword searching, querying languages XPath and XQL, and linking functions XLink and XPointer.
XML is particularly suited to adding structure to text document content delivered in aftermarket parts catalogs. Below is an example of a Service Bulletin text tagged with XML:
<PARA> Improve the reliability of the <PNR>1891M46G01</PNR> by eliminating the possibility of contact and subsequent fretting with the air duct, which is located on the right side of the engine aft looking forward. </PARA>
The tagging of the part number as <PNR> means that instead of this instruction being related to as a single body of text or as a meaningless collection of words, the part mentioned in the text section can be retrieved in searches and linked to additional appearances of the same part in related XML tagged documents.
XML can also be used to tag part details data appearing in structured tabular data structures. Following is an example:
<InventoryItems>
<Item>
<ItemNumber>ABC123</ItemNumber>
<ItemDescription>Filter</ItemNumber>
<InventoryQty>53</InventoryQty>
<SalePrice>120</SalePrice>
</Item>
<Item>
<ItemNumber>DEF456</ItemNumber>
<ItemDescription>Pump</ItemNumber>
<InventoryQty>36</InventoryQty>
<SalePrice>160</SalePrice>
</Item>
<Item>
<ItemNumber>GHI789</ItemNumber>
<ItemDescription>Gasket</ItemNumber>
<InventoryQty>62</InventoryQty>
<SalePrice>65</SalePrice>
</Item>
</InventoryItems>
XML can amply represent tabular data's structure and contents, and benefit from XML-related retrieval and linking mechanisms. However, the nature of the part details data, made up mainly of short text phrases or numbers, requires as much XML tag text as the data itself. Representing parts details data as XML documents is not an efficient option for data storage. Handling numbers in XML is currently not straightforward because at the moment XML has no data types and considers all data textual. Maintaining and updating parts details becomes similar to manually editing a text document.
The natural place for parts detail data is in enterprise applications such as ERP and CRM . It is rare to find any business that does not store this information in an relational database based system of this nature.
Part Configuration data establishes the relationships between parts in an assembly hierarchal tree structure. This may be in the form of complex rules or simple parent-child relationships, or a combination of the two. Part assembly configurations can be represented in XML:
<Assembly ID="Engine1234">
<SubAssembly>
<SubAssemblyID>SUBASS01</SubAssemblyID>
<SubAssemblyDesc>Cylinder Block</SubAssemblyDesc>
<Part>
<Pn>PN456A</Pn>
<Dsc>CRANKCASE</Dsc>
<Qt>1</Qt>
</Part>
<Part>
<Pn>PN5678E</Pn>
<Dsc>BOLT</Dsc>
<Qt>3</Qt>
</Part>
</SubAssembly>
</Assembly>
As with parts details, XML seems less suitable than a relational database based structure for storing relatively small enterprise text and numeric data fragments. Also, as sub-assemblies can be reused in different parts of a configuration, the parts configuration content structure must support re-use of groups of data. XML's reuse of data is less flexible than that of a relational database. XML formatted data tends to include full or partial duplication of reused data to avoid XML document pointer and linking complexity. Part configuration information is typically stored in a Product Data Management System ( PDM ) or other parts configuration application that uses a relational database for data storage.
Graphic images SVG XML appears to have no relevance to representing Graphic images that are a collection of colored pixels. However, CGM is an example of a readable text file format that stores information for presenting an image in a compatible image viewer. XML can be used to represent graphic image data and offer functionality that equals or rises above that of the cgm image format. The XML format for graphics is known as Scalable Vector Graphics (SVG). SVG attained W3C Recommendation Status in September 2001.
Although SVG has not yet gained widespread adoption, it is gaining acceptance and is now supported by Adobe, IBM, and Sun amongst others. SVG has great potential for becoming the standard for graphic image data representation. Its features include the ability to reuse defined graphic elements, support dynamically and programmatically constructed graphic images, enable interactive graphic applications, and use of parameters for image data values determined at run-time.
An example of SVG XML code in an aftermarket parts catalog context is the definition of hotspots appearing in an assembly illustration. SVG XML-compliant syntax can record an illustration hotspot's rectangle size, color, position and display text. The following sample SVG file draws a hotspot on an assembly illustration as a small red box with a part number written to its right:
|
SVG-encoded Hotspot Data on Assembly Graphic Image |
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20001102//EN"
"http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd">
<svg width="21cm" height="13.5cm">
<path id="35" fill="none" style="stroke:red; stroke-width:2"
d="M 210 30 L 210 40 L 230 40 L 230 30 Z"/>
<text x="170" style="font-size:14;
text-anchor:start" y="20">PART 30</text>
<image style="opacity:.5" x="0" y="0" width="600" height="400"
xlink:href="72-00-00-31-001.gif"/>
</svg>
The <path> element holds the hotspot rectangle drawing directions. The x and y coordinates can be parameter values dynamically positioning the hotspot at program runtime. The <text> element holds the hotspot display text. The <image> element holds a reference to a graphic assembly image, although it could also be represented using SVG syntax.
The same hotspot graphic element definition can be reused by defining a hotspot as an element in the <defs> section at the start of the SVG XML document. For example:
<defs> <rect id="hotspot " x="50" y="80" width="20" height="15" stroke="red" stroke-width="1"/> </defs>
The declared graphic element is called upon using an XLink reference:
<use xlink:href="#hotspot" transform="translate(20,60)"/>
The hotspot position is determined by the transform attribute and function translate.
The storing of textual and graphic hotspot and assembly information together in one XML formatted file is a simplification over graphic formats that require separate source files for assembly graphic data, hotspot graphics, hotspot text and programmed links to other XML document sources.
To summarize, practically all forms of catalog content can be represented in XML format. However, the suitability of XML storage for catalog content depends to a large extent on the underlying content data structure. Text documents and graphics are suitable for representation and storage as XML. XML adds structure to the unstructured data, and provides linking and search mechanisms for accessing logical segments of data. However, it should be noted that as updating XML remains a rather tedious task, similar to that of editing a text document, XML format is best suited for the storing of relatively static data not requiring frequent updates.
Parts Configuration and Parts Details data are not suited for storage as XML. This kind of data is best suited for storage in relational databases. Relational databases are designed to hold large amounts of relatively small and related text and numeric data fragments, whilst providing powerful lookup and retrieval abilities. Although there are interesting developments under way, there is currently no standard XML querying language or database that is able to match the querying capabilities of a relational database on structured data.
Data integration Aftermarket parts catalog unite content from multiple and disparate sources. The types of content sources include enterprise applications such as
ERP
,
CRM
,
PDM
and
DMS
, and relational databases and file system repositories.
XML layerXML and XML related technologies play a significant role in enabling Aftermarket Parts Catalog content integration. All of the catalog content structures are suitable for representation in XML, even if not for storage. By assuring commonality of tagging names and document structures, XML based application logic can relate to all the disparate catalog data as one integrated schema of information. The unified representation of all the varied catalog contents can be termed an XML layer.
The XML Layer can have a number of XML documents and set of DTDs, which when taken together integrate all the catalog content data into a unified and coherent structure. The XML documents and DTDs can be used to define the nature of the data integration between data from disparate sources, and allow application logic to mimic seamless sourcing of data from multiple enterprise applications and relational database and XML repositories.
The XML Layer is based on the same principle as Enterprise Application Integration (EAI) but is more suited to data integration needs of aftermarket parts catalogs. Aftermarket Parts Catalogs are typically a unification of disparate content for read-only purposes, requiring only a finite set of viewing and searching functions. Enterprise application integration solutions tend to support a far-wider range of functionality, such as data processing workflows and updates associated with operational systems, and are therefore a far larger undertaking than creating an XML Layer.
Business Logic layer The XML Layer provides data integration at the business logic layer. The business logic layer is a more suitable point for data integration than at the repository source level. By nature of its usage and operational processes associated with it, different types of Catalog content is stored in different repository systems or enterprise applications. Integrating catalog content at the data repository layer is a cumbersome task, typified by costly data warehousing projects and the complexity of storing different kinds of data structures in a single repository source. Also, the flexibility of XML allows inconsistent data structures to be represented together in the XML Layer. Where XML tags and document structures are inconsistent, application logic can reconcile the differences using the common XML context of the data.
Most, if not all, of the XML data in the XML Layer is dynamically generated. Data that is stored as XML (Text documents and Graphic Images) undergoes XSL transformations to ensure document tag names and structure conform to those defined for the XML Layer. Data that is not stored in XML form (Enterprise application and relational database data) is converted to a suitable XML format as the data is extracted from these systems.
Relational Database systems can be made to generate XML on the fly through not too complex programming logic. Many leading relational database vendors, including Oracle and IBM, have added such utilities to their database products. Additionally, data stored in non-XML based enterprise applications can similarly be extracted in XML form through an API . Increasingly more application systems are building API s for automatic output generation in XML format.
The XML layer can also be made up of XML documents that contain embedded program code for populating the document with data at runtime. These XML documents have a structure for XML content conforming to a DTD, but much of the actual content is represented by the program code that retrieves the data to populate the XML document as the document is referenced. Microsoft's XDR utility creates an XML view of relational database data in this manner.
Data integration at the Business Logic layer conforms to the n-tier architecture concept of separating the data, business logic and presentation layers. Transforming non-XML data from its repository or application source to XML on the fly for the purpose of business logic processing maintains the separation of three layers. Changes to data layer repositories structure for reasons unrelated to the aftermarket catalog, such as system upgrades or consolidation of source applications, will not automatically mean a rewrite of the catalog's business logic programs. Only the extraction program to the XML Layer needs to be rewritten each time this occurs.
Data interchange Aftermarket parts catalogs need to support data interchange as a prerequisite to eCommerce activity. Serving as an eCommerce application, the aftermarket parts catalog must interchange data with related enterprise systems and business partner applications.
Many applications today still accept or receive data as delimited text files. Once data fields are defined, almost any system can map internal processes to send and receive such text files. However, there is little ability to double-check that the correct data is being loaded into the correct fields. The structure and meaning given to data by XML tags makes data interchange using XML formatted data a more reliable task. XML tags can be the basis for checking the correct data is reaching the right destination.
XML Schema The XML Schema recommendation, in particular the Datatypes
is a promising step for defining and specifying datatypes on elements and attributes. XML Schemas would further enhance the automatic data checking abilities of data interchange receiving applications.
Additionally, as XML has emerged as a data transfer standard, most applications are developing
API
s for sending or receiving data as XML. What is left is the mapping of data in the sending or receiving to a mutually agreed or understood XML format with standard names for common XML elements. For example, <PartNo> in the sending application should be resolved with <PartNum> in the receiving application to a commonly agreed naming convention. Synchronization of naming conventions and document structure requires a far humbler technical effort than that of synchronizing between the programming procedures of each of a number of partner applications.
There are two main types of data interchange between an aftermarket parts catalog and related applications:
Aftermarket catalog content is passed to partner systems in order to be integrated into the contents of a remote catalog system. Remote catalog systems include those of web trading exchanges and of buyer procurement systems. The format of the interchanged catalog content is determined based on the relative market strengths of the supplier and buyer of the content.
In order to facilitate XML based catalog content interchange and resolve Supplier-Buyer power plays, XML standard formats have emerged for representing catalog contents of different sorts introduced by Commercial enterprises and independent non-profit organizations. Nevertheless, despite the vying for market segment over the last three or four years, very few, if any, of the standards has gained clear prominence.
RosettaNet xCBL XML standards that currently are showing signs of gaining widespread adoption are xCBL put forward by commercial enterprise Commerce One and the non-profit organization RosettaNet standard.
Below is a Sample Product Catalog in xCBL format:
<ProductCatalog>
<CatalogHeader>
<CatalogID>Acme Laptops Catalog</CatalogID>
<CatalogDate>20000816</CatalogDate>
<CatalogProvider>
<Party>
<PartyID>
<Identifier>
<Agency>
<AgencyCoded>Other</AgencyCoded>
<AgencyCodedOther>CommerceOne</AgencyCodedOther>
</Agency>
<Ident>Acme_Laptops</Ident>
</Identifier>
</PartyID>
</Party>
</CatalogProvider>
<ListOfPartners>
<Partner PartnerID="General_Motors" Relationship="Buyer"/>
<Partner PartnerID="Compaq" Relationship="Manufacturer"/>
<Partner PartnerID="Acme_Laptops" Relationship="Supplier"/>
</ListOfPartners>
<ValidFrom>20000816</ValidFrom>
<ValidUntil>20001231</ValidUntil>
<CatalogVersion>1.0</CatalogVersion>
<DefaultLanguage xml:lang="en"/>
<DefaultCurrency>
<Currency>
<CurrencyCoded>USD</CurrencyCoded>
</Currency>
</DefaultCurrency>
<IsMultiVendor/>
<ShortDescription xml:lang="en">This is Acme Laptops's
catalog of Compaq Laptops, for General Motors.
</ShortDescription>
</CatalogHeader>
The advantage of standards is that each organization can independently subscribe to the format and then be ready for eCommerce data interchange with other companies that have done similarly. The lack of a common standard adopted by both business parties means individual mapping of each sender-receiver application pair. This prove problematic for manufacturers wishing to send catalog content to many procurement or exchange catalog systems.
The second kind of data interchange is that of spare parts order transactions from the parts catalog to order processing systems. The order processing system can be a supply-side order management system or buy-side procurement system. Where an aftermarket catalog is deployed at the equipment manufacturer's site as an internet application accessed by buyers, the parts orders are sent directly to the supply-side order management system. Alternatively, manufacturers may deploy the catalog at large equipment operators' site where the parts orders are sent to the buyer's internal procurement system for further processing.
An example of parts order transaction data is:
<PartsOrder SONumber="12345">
<Customer CustNumber="543">
<CustName>ABC Industries</CustName>
<Street>123 Main St.</Street>
<City>Chicago</City>
<State>IL</State>
<PostCode>60609</PostCode>
</Customer>
<OrderDate>981215</OrderDate>
<Item ItemNumber="1">
<Part PartNumber="123">
<Description>
<p><b>Turkey wrench:</b><br />
Stainless steel, one-piece construction,
lifetime guarantee.</p>
</Description>
<Price>9.95</Price>
</Part>
<Quantity>10</Quantity>
</Item>
<Item ItemNumber="2">
<Part PartNumber="456">
<Description>
<p><b>Stuffing separator:<b><br />
Aluminum, one-year guarantee.</p>
</Description>
<Price>13.27</Price>
</Part>
<Quantity>5</Quantity>
</Item>
</PartsOrder>
XML based standard formats for order transaction data currently compete for adoption with the deeply entrenched EDI standard. Whilst XML offers greater flexibility than EDI and wider usage for activities other than data interchange, EDI has served industry business partners for decades and is expected to take time to phase out.
|
XML Role in Aftermarket Parts Catalog Data Representation, Integration and Interchange |
Advantages of Aftermarket Parts CatalogsXML is the most versatile format for structuring data. XML is able to represent structured, unstructured and graphic data in one common format. It provides an ideal medium for integration of data drawn from disparate sources and for data interchange with associated related enterprise systems.
Business Logic layer Data layer Presentation layer XML has a key role to play in n-tier technology architectures. Its role can be defined for data, business logic and presentation layer respectively. At the data layer, the representation and storage of data as XML is ideally suited for text documents. At the business logic layer, XML is an ideal medium for translating all data into a common format for integration as an XML Layer. The XML layer is an ideal platform from which to send data to the presentation layer. XML can be converted to HTML via XSL transformations or via open-standard programming languages such as Java Server Pages (JSP). The open-standards genealogy of XML coupled with its wide-adoption means that program code for processing XML is widely available and under continuous development.
Mapping dataData interchange between remote systems involves mapping XML names and structures at the sending and receiving systems. A growth of standards for exchanging data in all kinds of industries enhances the adoption of XML as a standard for data interchange.
Disadvantages of Aftermarket Parts CatalogsThere are limitations to use of XML for handling Aftermarket Parts Catalog data. XML is not the ultimate for data storage structure for structured data. Relational databases provide a more suitable structure for storing enterprise parts data. Parts data storage in XML format means depending on XML querying languages for data retrieval. Querying number ranges or comparing dates is still far more easily done on data in a relational database than in an XML repository.
XML suitability for catalog data interchange is impaired by the lack of emergence of dominant XML-based standards for content or transaction data interchange. Without a common standard that trading partners can assume are mutually supported, XML transformations have to occur at the either the sending or receiving end for each of the partner systems due to receive the data. As data interchange is between remote systems, the task of maintaining XML format synchronization becomes more precarious. Despite years of development of XML and XML industry standards for data interchange, XML is still not yet enabling the vast majority of B2B data communications.
Finally, for many data processes, XML transformations are treated too lightly. There are performance issues associated with converting all stored data to XML in runtime applications. EAI technologies have methods for combining data from multiple sources that might provide superior performance. Also, some of the aftermarket parts data could be delivered directly to the presentation layer for combined display with data from other sources, without needing to pass through an XML Layer. The convenience of formatting all catalog data in XML structures may just be too costly in terms of the additional data processing it entails.
Platform solutionThe key to creating an aftermarket sales-driving Parts Catalog lies in creating a platform that delivers integrated content from multiple, disparate sources, and enables communication with related enterprise systems on either side of the firewall.
Each of the layers in the n-tier system architecture can harness XML to varying degrees for the purpose of data storage, integration and interchange. The appropriate use of XML and XML-related technologies in each of these tasks can play a key role in the transformation of the Aftermark Parts Catalog from its traditional hard copy reference-manual role to that of dynamic eCommerce B2B Web application driving sales of spare parts.
Clearly some of the success of XML depends on Industry adoption and the technology developments that accompany it, SVG being a very contemporary example. Furthermore, the adoption of XML standards for processes such as data interchange are dependent as much on business environment factors such as Buyer-Supplier power relations, that are outside of the scope of technology developments, as they are on widespread industry adoption.
[ARM 01] Sell-Side Product Content: The Key to Supplier Empowerment AMR Research , July 2001
[IW 01] E-Catalogs: Long Journey to Rewards , Information Week August 2001
[XMJ 00] XML -- Friend or Foe , XML-Journal Volume 1 Issue 4
[SVG 01] An Introduction to Scalable Vector Graphics , http://www.xml.com/lpt/a/2001/03/21/svg.html, March 2001
[XMB 01] XML and Databases , http://www.rpbourret.com/xml/XMLAndDatabases.htm, June 2001
[XVG 01] Transforming XML into SVG , http://www-106.ibm.com/developerworks/educationxml, March 2001
[XCB 00] xCBL 3.0 Content Documents , Commerce One
[ARM 00] Don't Avoid XML -- It's Essential to E-Business , AMR Research, July 2000
[XM 00] XML for data driven catalog publishing , XML 2000
[XMC 01] Integration by Parts:XSLT, XLink and SVG , http://www.xml.com/lpt/a/2000/03/22/style/index.html, March 2000
| |
Table of contents | Author | City | Company | Country | State/Province | Term | Interchange | |
