Architecture of a Business-to-Business Store
In the previous chapter, we took a quick look at how a business-to-business store differs from a normal retail site open to the public-at-large. It is now time to analyze in more detail the typical structure of such a site and understand how it works. To do so, we will examine the Microsoft Market (MSMarket) sample that comes with MSCS. MSMarket is a fictitious version of a real Intranet site that Microsoft employees worldwide use to purchase office supplies of any kind, such as books and software.
How Does a Business-to-Business Site Work?As we mentioned earlier, business-to-business electronic commerce has two faces: corporate procurement and supplier-chain integration. The former is used by online stores that are aimed at providing services to an audience composed primarily by employees of a company, in a scenario where the company itself is paying for their purchases. The latter, on the other hand, is used mainly to exchange documents between two systems (one of which can even be a human, as we will see later on in the chapter).
MSMarket incorporates both these concepts, in that it is an online store that can only be accessed by authorized users who do not directly pay for their purchases and provides a set of document exchange rules for accomplishing various tasks, such as authorizing orders that go beyond the individual's purchase limit or delivering a purchase order directly to a supplier.
Let us start by looking at how the corporate process works. First of all, you should keep in mind that, in a typical scenario, the store is not selling anything directly to its customers, but it is rather acting as a middle tier between the company's employees and its suppliers. This means that, generally speaking, the store must be well aware of the requisition procedure that must be followed for each supplier, as well as what the buying power of each employee is-that is, how much money he or she can spend before authorization from his or her supervisor becomes necessary in order to complete the purchase.
As you can see from the diagram, the purchase process for a business-to-business online store is remarkably similar to its retail counterpart, with the exception that, under normal circumstances, users are not allowed to register themselves with the site but must be inserted in the customer database through some alternative method. This happens because, since the customers will be buying on behalf of the company, they should be added to the list of authorized users from the company's own internal employee database. This will also allow whoever is in charge of doing so to set purchase limits for each individual. MSMarket does allow users to register, but only because that is a more practical approach for demonstrating how the store works.
As we'll be going through the store, you will probably notice that MSMarket is much more functional than any other store seen before. In particular, no cross-selling or up-selling is being used-the reason being that the customers who visit this store already know what they are going to buy (and certainly, the company doesn't want to promote more purchases than are strictly necessary!).
The result is a slimmer site, in terms of convenience and speed, that works very well in an Intranet scenario. However, there is also the possibility that a business-to-business store might be configured as an Extranet application; this would be the case, for example, if each supplier were to provide its own dedicated store for the company's employees. Most considerations, such as the procurement paradigm and purchase limits, would still apply, but this time the store would be run by somebody who actually has an interest in enticing customers to buy more-the supplier. In this scenario, you would probably want to take advantage of cross-selling and up-selling functionality even though you're not selling your products to the whole world.
The real differences between business-to-business and business-to-consumer come into play once the customer clicks on the Purchase button: the order request goes through a process that is quite unlike anything we've seen before. Let's discuss each of the steps briefly:
As soon as a purchase is submitted by a customer, its total is calculated and verified against the user's purchase limit. If the total is below the latter, the purchase is automatically sent to the last stage, otherwise an authorization request is sent to the user's supervisor.
Whenever an order's total goes beyond the customer's spending limit, the store sends an authorization request to his or her immediate supervisor. This can happen in one of several ways, and can, for example, be initiated with an e-mail that contains, together with the customer's name and the order's detail, a link to an URL where the supervisor can either authorize or reject the order.
At this stage, the supervisor somehow sends a response back to the store either authorizing or rejecting the purchase. Once again, there are several possibilities as to how this can be done; for example, an e-mail can be sent back to the store with the words "accept" or "reject" in a specific spot, or the approval can be submitted through an HTTP post to the store with the appropriate parameters.
Purchase request submission
If a supervisor rejects an order, the customer is notified (e.g. via e-mail) and the order is generally discarded without further possibility of intervention. If the supervisor authorizes it instead, the store proceeds with sending a purchase request out to the appropriate supplier. As we'll see later on in the chapter, this process is technically similar to the one that we just described for authorizing a purchase, and varies from distributor to distributor.
Setting Up the Site
Before being able to use the MSMarket sample properly, we will have to make some adjustments to its setup. In particular, because the site is largely based on e-mail exchanges, we should make sure that the store knows what SMTP server to use when sending messages out to its users.
To do so, we'll have to enter the store's management site at the following URL:
This will take us to the Manager's home page, from which we can click on Configure Email Processes to access the configuration menu. Once here, clicking on Configuration (maildomain) will let us specify the default domain for all the e-mail messages that our site sends to its users, while selecting Configuration (smtphost) will let us type in the hostname of our SMTP mailserver. Finally, you will also have to enter a return e-mail account to be used by the store when sending e-mail; you can do so by clicking on Configuration (siteaccount).
Once you type in a valid mail domain and SMTP server hostname, be very careful when you create new users for testing purposes within the site. In fact, the store will send out e-mail messages to these accounts and, if they correspond to real people, you run the risk of flooding their mailboxes! As a general rule, you should use your own e-mail account for all the aliases that are requested by the store; this will also let you monitor how the site works more easily.
Navigating the Store
Now that our settings are done, we can proceed with exploring MSMarket and the way it works. The first step on entering the store is either logging in or registering as a new user. Once again, keep in mind that this happens only because this is a sample store-in real-life there wouldn't be a way to register with the site from the front-end. This time, the registration process asks questions that better fit the business model that is currently being used: not a ship-to address anymore, but rather a room and building number or name.
It's interesting to notice that the store is not asking us what department we work for-in many large companies each department has its own budget and keeps track of its expenses separately. As we'll see in a moment, this is done later in the purchase process, when we are asked a cost center code and an account number.
Once we have registered or logged in, we can access the real home page, shown in the next screenshot. As you can see, the page's body only contains generic information about the site and the features it provides. What really interests us, though, is the left-side bar, which contains links to the three main areas of the site (international areas are also available, and are treated as different stores altogether). Each of these areas represents a basic category of items, whose products can belong to one or more suppliers.
Finding products is a straightforward process, very similar to the one that we have seen so far for the other stores. As soon as we want to add something to the basket, however, some new information appears to be in the product page. As you can see from the adjacent screenshot, the store is asking us to choose an account to which the purchase will be charged, and a cost center, which will be responsible for accounting the order. For frequently purchased items, there is also the possibility of specifying an Internal Order code.
Once all the items that we want to purchase are added to our basket, we can proceed with the order fulfillment process. The store asks us for some information regarding the purchase that we are about to make, such as when the merchandise is needed by, or (in the case of catering, for example) when our business or lunch will take place and how many people will be participating.
Continuing with the purchase process causes the store to save our purchase request and, if the order's total exceeds our limit, send an e-mail to our supervisor for approval.
The Approval Process
In our example, it looks like I ordered more food for my event than I can account for. Therefore, my supervisor will receive an e-mail inviting him to review my requisition and either authorize or reject it. In this case, I set myself up as my own supervisor-so that I could better understand what was going on-and I did indeed receive an e-mail from the store, similar to this one:
From: Microsoft Store
To: Marco Tabini
Subject: Requisition # 10005
A requisition is awaiting your approval. To view the details of the requisition click on the link.
Clicking on the link provided by the e-mail brings up the page shown in the next screenshot, which asks me to verify the contents of the order and either approve or reject it.
Clicking on Reject Order causes the requisition to be discarded and the following e-mail message sent back to the requisitioner (myself again):
From: Microsoft Store
To: Marco Tabini
Subject: Requisition # 10005
The requisition has been rejected
If I, on the other hand, decide that my own purchase is worth its money, clicking on Accept Order will initiate the transmission of the necessary purchase orders to the various suppliers (there is only one in this case). In this case, no message will be sent out to the requisitioner.
Could It Have Been Better?
It's a good idea to stop for a moment and reflect on what we have seen so far. The MSMarket sample certainly succeeds at streamlining the requisition and approval process, however there is still room for some improvement. First of all, since the supervisor is going to receive an e-mail message anyway, why not make the most out of it?
For starters, it would have been a good idea if a complete detail of the requisition were included in the message; this would have allowed the supervisor to understand what the requisition was about and how urgent it was without having to start his or her browser and go to the store pages. In addition, the process of authorizing the requisition could have been further improved by providing two different links, one to be used by the supervisor when accepting a requisition and another for rejecting it.
How Do Requisitions Work?
We have seen an example of document exchange in the approval process, in which there was the need to generate and transfer documents between the store and the supervisor. A more typical example can be found to pick up right where the process shown in the diagram in the earlier section on the Site Structure of MSMarket left off.
In fact, once a purchase has been definitively approved, the store must proceed to somehow open a communication channel with each supplier's line-of-business system and send purchase orders to it. Ideally, the system should also be able to receive information back from the suppliers-so that it would be able, for example, to track the status of an order or to receive shipment confirmations.
There are three fundamental stages in the submission process, although their exact nature depends on the medium that is being chosen for the transmission of data:
As part of the first step, the data must be prepared for being sent out. This includes calculating or generating all the appropriate fields, and making sure that all the necessary information is available.
Data will then have to be formatted in such a way that the recipient can understand it. This step varies widely depending on the submission medium that is being used, and can consist of generating a flat text file, or creating an e-mail message, and so on.
Finally, data is sent over to the recipient using the appropriate method. This can include just about anything, from a printout of a purchase order to more advanced methods, such as EDI (which we'll discuss below), e-mail or other Internet protocols.
At the other end of the submission, a line-of-business system must receive the data and perform the same steps in reverse order. This will allow it to "take apart" the document, map the data it contains to the system's internal storage banks and check its validity.
As you have probably noticed, much of the success of this operation depends on the ability of sender and recipient to agree on a common format for the document and on a medium that is available to both systems. There is, in fact, a standard for the exchange of business-to-business transactions; its name is Electronic Data Interchange (EDI).
EDI is an open-ended standard, in that it only defines rules according to which the data must be formatted and sent to the recipient. There are two sub-standards of EDI: one called X12, maintained by the American National Standard Institute (ANSI) and used mostly in North America; the other called UN/EDIFACT (which stands for Electronic Data Interchange for Administration, Commerce and Transport), managed by the United Nations and primarily used outside North America.
EDI, born before the Internet became a widely available communication medium, has been designed to be sent across a number of different media (primarily telex and other private networks). As a result, it uses an extremely narrow character set (in fact, a subset of the ISO 7-bit set), which becomes even narrower if the medium chosen is telex (unable to transmit letters!).
The core of an EDI communication is called interchange, and represents the exchange between two parties of one or more messages. Messages, in turn, can be grouped in functional groups and can be composed of one or more data segments.
Even though (or perhaps, because) it's a generic standard, EDI is very complex and costly to implement, both from a development point of view and from a maintenance standpoint. In fact, mostly for legacy issues, companies that wish to implement it must generally resort to using private (and expensive) networks for the exchange of data. As a result, while many (albeit not all) larger companies are EDI-compliant, almost all the smaller fish are not and resort to more primitive interchange methods (most of the wholesale retail documentation is still done by hand).
How does Site Server support EDI? Well, it doesn't-not directly, at least. MSCS includes a complete interchange system that focuses on the Commerce Interchange Pipeline (CIP), which, similar to the Order Processing Pipeline, offers an ordered approach to exchanging documents between two partners. The CIP doesn't favor any exchange protocol in particular, but rather provides a common framework for any format, including EDI.
The good news, therefore, is that if you want to develop a store able to communicate with an EDI-compliant system, you'll be able to do so. The bad news is that EDI remains a rather obscure topic for the uninitiated, and you will most likely have to take advantage of the services offered by a third-party consultant that specializes in traditional interchanges.
If, on the other hand, you are looking at creating a new interchange system, you'll be happy to know that the CIP is not only fully contained, but also designed to work across the Internet-representing a powerful, and yet significantly less expensive, alternative to EDI. As a matter of fact, once you have established your own document guidelines (i.e. the format for a purchase order, a response, and so on) you will be able to exchange information via e-mail or even HTTP posts.
Remember to Close the Loops
The important thing to remember when designing a business-to-business system is remembering that you should provide a notification system through which the recipient of a message can acknowledge its arrival to the sender. This is particularly important if the correct delivery of the message is vital to the successful completion of a transaction (i.e. if your store sends a purchase order that never arrives, then the order will never be completed!).
It's also a good idea to take full advantage of the concept of interchange and implement a two-way communication system. EDI, for example, provides support not only for messages that go from the store to the line-of-business system (therefore from the requisitioner to the supplier), but that also travel in the opposite direction. This becomes useful, for example, when you want to inform your customers that the merchandise they have ordered has been shipped; in this case, your supplier will send you a notification message, which you can use to set the appropriate fields in your order database.
MSMarket's Store Manager Interface
What does the management interface of a business-to-business store look like? As you can see from the following screenshot, it's a little different from that of a normal retail store. In particular, you will notice that, although many concepts are the same, the terms used are unlike anything we have seen so far.
The set of functions on the left side are designed to provide a means to configure several aspects of the store, such as all the e-mail settings, the various locations where employees can be found (including conversion rates for charging customers from foreign countries in their own currency), and the details of the accounts and cost centers that can be used by the users. Each cost center can be assigned to one or more accounts, indicating who can be held accountable for each transaction.
On the right side of the screen, on the other hand, we have access to information about the products that are sold by the store, its customers and a list of requisitions that have been made so far. Products-or Parts-are organized in Part Classes, which in turn are grouped in Requisition Classes, which represent the highest-level departments. Requisition classes are linked to account numbers, so that the right account is used to pay for specific products (i.e. the Office Stationery account is used to buy office supplies, but not catering).
It's important to understand that, unlike any other store that we have seen so far, MSMarket is designed to work without any human interaction. Users could be entered automatically from the company's employee database, while the store could be retrofitted to interface (through an interchange) with the company's own accounting system in order to provide complete feedback on the requisitions that are made. Finally, even the product database can be automatically updated from each supplier's line-of-business system-using another interchange, of course!