Export (0) Print
Expand All
28 out of 31 rated this helpful - Rate this topic

Office Business Applications for Store Operations

 

Moin Moinuddin
Microsoft Corporation

November 2006

Revised: December 2006

Applies to:
   Microsoft BizTalk Server 2006
   Microsoft Business Scorecard Manager
   .NET Framework 3.0 (Windows Communication Foundation)
   Microsoft Office SharePoint Server

Summary: Changing market conditions require agility in business applications. Service orientation answers the challenge by centering on XML and Web services standards that revolutionize how developers compose systems and integrate them over distributed networks. Once integrated, how is the information presented to the decision makers? (36 printed pages)

Get the reference implementation.

Download the Reference Application Pack for Retail. You can use this as an example of building Web services in your own organization, or even use this as a starter kit to jump-start building your own Web-services strategy. Please read the installation document carefully for the product requirements to install and run this sample application. Also, please download and read the EULA before proceeding with downloading the sample application.




Contents

Introduction
Goals of the Sample Application
Scenarios and Components
Office Business Applications
Retail Standards
Interaction of the Components
Information Flow
Technical Decisions
Conclusion

Introduction

Retailers are faced with the enormous challenges of globalization, regulations, growing costs, and demanding customers. In addition to these changing market conditions, there are now multiple channels to reach customers. All of this increases the need for flexibility and agility in business applications. However, at a time when competition is keenly interested in buzzwords like agility and adaptability, businesses are confronted with systems that are seemingly built of steel and cement, developed as though things would never change. These systems become more expensive and cumbersome each time organizations tweak them to fit new business imperatives. Unfortunately, this leads to less materialization of automation, because systems require constant human intervention and IT development. All too often, the alignment of technology with business objectives gets bogged down by integration problems and progresses no further than the white board.

One of the common areas where retailers face huge challenges is the availability of the right information, at the right time, and at the right place—for example, making sales information available in near real time to the store managers, regional managers, and merchandising managers in the corporate headquarters. Another example is the availability of product information to the sales agents. Making information available in near real time requires systems that can generate near real-time data, send the data to the right places, and consume data in near real time.

Service orientation addresses these challenges by centering on rapidly evolving XML and Web services standards that are revolutionizing how developers compose systems and integrate them over distributed networks. No longer are developers forced to make do with rigid and proprietary languages and object models that used to be the norm before service orientation came into play. The emergence of this new methodology is helping to develop new approaches specifically for Web-based distributed computing. This revolution is transforming the business by integrating disparate systems to establish a real-time enterprise.

Making information available where it is needed to simplify merchandising processes requires a methodology that is based on loosely coupled integration between various in-store and back-end applications. This demand makes it critical for an architecture that is based on service orientation for integration between disparate applications. In addition, surfacing information at the right place requires the ability to compose dynamic applications using an array of underlying services. The Office Business Applications platform provides this ability to create composite applications, such as dashboards for the store, regional, and corporate managers.

This sample application is developed by selecting a few common scenarios in retail (such as stock unavailability, loss prevention, customer services, and in-store productivity) to showcase integration using service orientation. The white paper discusses application-to-application connectivity in real time. Data is transmitted from store to enterprise as a business event, and not as a sequence of batches. Data is transmitted between store and line-of-business (LOB) applications in the industry-standard IXRetail format.

This application also shows the best way to achieve agility and integration by way of service orientation. Finally, a sample application is available for download that demonstrates this through a few selected scenarios.

Goals of the Sample Application

The main goals of this sample application are to demonstrate:

  • Integration of disparate applications using Web services.
  • Use of industry standards in achieving interoperability.
  • Ease of building Web services using the Microsoft platform.
  • Transformation and orchestration capabilities of Microsoft BizTalk Server (BTS) 2006.
  • Ease of building manager workbench and dashboards using Microsoft Business Scorecard Manager (BSM) and Microsoft Office SharePoint Services.

Building the Sample Application

To demonstrate the use of service-oriented architecture to automate this scenario, a sample application was built using the IXRetail industry standard for retail enterprise, BizTalk, Windows Communication Foundation (WCF), BSM, and Office SharePoint Server. The approach is as follows:

  1. Build a Visual C#–based sample point-of-service (POS) application.
  2. Use the IXRetail schema to design Web service interface definitions.
  3. Build a sample back-end IXRetail adapter for BizTalk.
  4. Build a sample Web service using WCF that triggers workflows that are based on the alerts and events.
  5. Build a sample supplier service that interacts with the back-end Web service.
  6. Package the application into a set of Web services, Windows applications, metadata (configuration, schema definitions), and a set of applications.
  7. Compose a dashboard using the Web services to surface relevant information to the managers using Office SharePoint Server.

How Does This Benefit Retailers?

This sample application demonstrates many benefits to the retailers. Some of the key characteristics of the sample application that are beneficial in building a real-time connected retail solution are that it:

  • Demonstrates the use of standards to create an extensible solution.
  • Is loosely coupled to enable the benefits of agility, adaptability, and alignment.
  • Is built by using prepackaged technologies, as opposed to creating it from the ground up.
  • Demonstrates composing dashboards easily for managers, based on their roles.

The use of standards, loose coupling, and the use of existing technologies, helps the retailers in incrementally switching to this solution, as opposed to "ripping and replacing" existing solutions. These characteristics also help in selecting the "best of breed," as opposed to being locked down with solutions from a particular vendor. Finally, they also make it possible to extend the solution easily as market conditions change.

Scenarios and Components

This section walks through the reference architecture for building an integrated retailer. As described in the previous sections, retailers face the challenge of integrating their legacy systems within their stores and at the enterprise (or corporate) headquarters. This challenge becomes even more critical due to demanding customers who expect a rich experience both in the store and in other channels.

To achieve the near real-time data availability and to reap the fruits of near real-time data, let us first understand the retail-value chain.

Aa905316.wp_f01(en-us,MSDN.10).gif

Figure 1. The retail-value chain

In a retail-value chain, sales and customer data flows from the stores to the enterprise systems. Based on the forecasting, inventory levels, and sales data, enterprise systems order new products and merchandise from the suppliers. Suppliers fulfill the orders from their warehouses and in turn place orders to the manufacturers when the inventory in the warehouse falls below a certain threshold.

For all of this to function smoothly and avoid customers from experiencing out-of-stock scenarios, retailers need a process that is agile, adaptable, and aligned. This reduces the costs and inefficiencies, while ensuring seamless customer experience. If this process is not set up to have the benefits of agility, adaptability, and alignment, the retail organization is bound to experience the pain points discussed previously.

Retail Scenarios Targeted in This Sample Application

There are many scenarios and use cases in retail. However, to demonstrate the capabilities of the technologies, we have selected a few common scenarios:

  • Item not found. This is a common scenario that occurs in the retail environment. In this scenario, an item arrives at the store and is stacked on the shelf, well before the item is launched through the merchandising system and the pricing information is transmitted to the store. A customer picks up the item and walks up to the checkout counter. When the product is scanned, it cannot be checked out, as the item is not found. Currently, this leads to many manual steps, such as the supervisor being paged and having to walk up to the checkout lane, pick up the product from the cashier, and walk around the store to try to find a price by looking up the price of a similar item. After the price of a similar item is found, the manager overrides the price manually on the POS for the transaction to go through.
  • Item recall. In this scenario, a supplier typically sends a message to the corporate headquarters to recall an item. The merchandise manager updates the merchandise-management system with the item recall and sends a message to the stores. Each store's response is based on the time that the store manager takes to process the message and remove the recalled item from the store shelves. The sample application demonstrates how this scenario can be completely automated by using the latest technology—specifically, Web services.
  • Item out of stock. This is a very common scenario across the retail industry. In this scenario, a customer is looking for an item, does not find it on the shelf, and asks the store employee, who informs the customer that it is out of stock—whereas, in reality, the item is sitting in the back room. This problem occurs due to lack of real-time visibility into store inventory. The sample application demonstrates how the latest technology can overcome this problem and provide a richer customer experience.
  • Real-time promotional-item sales-data transfer. Typically, sales data is transferred to the enterprise systems either on a nightly basis or twice a day. This does not provide adequate visibility to the merchandise-management staff on inventory levels, and specifically on inventory levels of promotional items. So, the sample application demonstrates the transfer of transaction information in real time from the store to the enterprise systems. It also demonstrates the application of certain business rules in transmitting the sales-transaction information in real time. For example, sales information related to high-value items and promotional items is transmitted in real time with the highest priority; other transaction data receives secondary priority in transmitting in real time. The service hosted on the local host collects the simultaneous sales-data updates from multiple POS devices, aggregates them, transforms them, and then transfers the data based on the rules set by the corporate headquarters.
  • Supply chain. Typically, when a transaction is keyed in to the POS system, it does not make it to the enterprise system until later in the day or the next day. This reduces the visibility of the enterprise systems' staff and executives on how stores are doing from inventory and sales points of view. The connected-system sample application demonstrates the complete integration of the supply-chain cycle from store through merchandising system, warehouse system, and finally back to the store. When a transaction is keyed in to the POS, the transaction flows into a store-level inventory function and updates the store on-hand data. When the on-hand quantity falls below a minimum threshold, it triggers an immediate order to the warehouse-management application. The warehouse-management system might interact with a trading partner to satisfy the order. The order is shipped and received at the store, and the store-inventory numbers for the item are appropriately incremented.

The sample application uses the previous scenarios to demonstrate how they can be completely automated and provide real-time visibility, for employees and executives to make informed and timely decisions.

Key Components of the Sample Application

This section provides the description for understanding the components of the sample application. Figure 2 provides the complete architectural view of how these components integrate and work. This architecture demonstrates the loosely coupled integration between various store and back-end applications. This high-level architecture provides the building blocks that can be further extended or replaced as per the business needs, or can be modeled in a similar way for some other industry vertical.

Aa905316.wp_f02(en-us,MSDN.10).gif

Figure 2. Architectural diagram

Point-of-Sale (POS) (Figure 2, Items 1 and 2)

The sample application has a POS application. This is built as a .NET application (POSSystem, to demonstrate the integration with LOB applications, irrespective of the platform). The POS application can operate in two modes: online and offline. Online signifies a connection to the store server; offline signifies working disconnected to the store server. In offline mode, these terminals store the sales transactions locally in a flat file. After the connection with the store server is established in online mode, the offline transactions are sent across to the store server.

In a real store, offline scenarios happen because of loss of network connectivity or the store server going down. However, in this sample application, offline and online modes are controlled through the configuration file. A parameter in the configuration file of the POS solution controls the mode of operation, as shown here.

<!--This is the POS Id where one can give the name of the POS-->
   <add key="POSID" value="101"/>

<!--This indicates the online/offline status of the application-->
   <add key="Online" value="true"/>

The POS application name is configured in the POSID key, which is passed on with every notification message that is sent to the Store. If the value of the Online key is true, the POS is connected to the store server. In a retail scenario, multiple databases can be present for which every POS should refer to its individual database connection settings. This can also be configured in the Config.xml file, as shown here.

<add key="ConString" value="Data Source=machinename;
Initial Catalog=Databasename;
User Id=test;Password=test123;/>

Every transaction in the online scenario is directed to the store database, and all the transactions are maintained in the sales-master and sales-details tables of the database. An additional file containing the item-master details is also maintained at the system level, the path for which is configured in the Config.xml file, as shown here. (Ensure that the POS application has access to this transaction file.)

<!--This is the path where the WCF Web service writes the details to a 
shared location that will then be accessed by the POS application-->
<add key="FileItemPath" value="//machinename//temp//price.xml"/>

If the value of the Online key is changed to false, the POS application is disconnected from the store database, and all the transactions are completed by using the item-master details Price.xml file that was created in the previous step. An additional transaction log file is also created on the local drive, the path of which is also configurable using the Config.xml file, as shown here. The name of this file is the same as that of the Invoice ID generated. These transactions are then merged into the store database when the POS is either online or if the status of the POS is changed from Offline to Online.

<!--This is the path where the POS application writes the details of 
the transaction to an xml file in the offline mode-->
<add key="FileTransactionPath" value="C:\\"/>

Store Database or Store DB (Figure 2, Item 3)

The Store DB maintains the sales and inventory data of the store. Transaction data from all the POS applications is aggregated into the Store DB for local storage.

All the notifications generated by the POS application and the Store Manager application (explained in the next section) are stored also in the database. The E-R diagram for the database is shown in Figure 3. The main tables in the Store DB are the following:

  • SalesDetails—This table stores the details for each item sold from the POS application.
  • SalesMaster—This table stores orders with the subtotal, tax, and so on.
  • PoSMaster—The POS details for each POS terminal are stored in the database. The Store Manager application refers to this table to find the POS locations for all the applications, to broadcast any events.
  • Employees—This table contains employee details of the store.
  • ProductDetails—This is the product master table, listing the details of each product in the Store.
  • ItemMaster—This is the master table of the store database that contains the transaction data and notification corresponding to each item. This table contains the RecallFlag that indicates recall status of every item.
  • Inventory—This table contains the inventory of items available in either the back room or shelves of the store. This table gets updated whenever any item is sold.
  • LocationMaster—This table stores the location details of the back room and shelf of the store.
  • OutOfStockItemHistory—If an item inventory falls below the threshold, the transaction details for that item are pushed to this table.
  • RecalledItemHistory—If the Store Manager application recalls any item from the store shelf for various reasons, the RecallFlag in ItemMaster for that item is set to true, and the RecalledItemHistory goes into this table.
  • UoMMaster—This table stores the unit-of-measurement details for each item in ItemMaster.
  • Promotions—This table contains the details of items on sale or offered as promotion.

Click here for larger image

Figure 3. The Store DB E-R diagram (Click on the picture for a larger image)

The Store Manager application refers to this database for all necessary operations. Connection to the Store database is made through the DBManager class that is present in the DataAccess component of the sample application. This solution manages all the connections to the database.

Store Manager Application (Figure 2, Item 6)

This .NET application acts as the Store Manager application potentially running on a Tablet PC. All the messages and notifications from the POS are routed to this application. The Store Manager application acts as an interface for all the messages to be sent and received from the store Web service.

The Store Manager application receives notifications from the POS applications and sends them back through the CSTStoreWinService, which is the Windows communication service running in the store. This communication is accomplished through the TCP/IP listener configured on the CSTStoreWinService, whose communication IP (and the port on which it listens) are configured in the Store Manager application. This configuration is done in the App.config file, as shown here.

<!-- IP address of the box that host the Communication Windows Service-->
   <add key="CommunicationIP" value="172.28.41.61"/>
<!-- Port number on the box on which the Communication Windows Service
is listening-->
   <add key="CommunicationPort" value="8000"/>

The Store Manager application communicates by using this socket. The Store Manager application also generates notification XML files for each notification received on the store, either from the POS application or the Enterprise applications. Notification files are configured in the App.config file, as shown here.

<!--XML file name where Item recalled notifications will be stored-->
   <add key="IRCXmlName" value="ircnotify.xml"/>
      
<!--XML file name where Item out of stock (shelf) notifications 
will be stored-->
   <add key="IOOSSXmlName" value="ioossnotify.xml"/>
      
<!--XML file name where Item out of stock (back room) notifications
will be stored-->
   <add key="IOOSBXmlName" value="ioosbnotify.xml"/>
      
<!--XML file name where Item shipment received notifications 
will be stored-->
   <add key="ISHIPMENTXmlName" value="ishipmentnotify.xml"/>

These notification files are created in accordance with the IXRetail schemas for all scenarios. These notification files act as notification messages that are routed by the Store service as notification mails to the back-room staff (on their workstations or terminals) in case of item-recall scenarios, and to the Enterprise applications in case of item-not-found scenarios.

In the item-not-found scenario, e-mail is routed through the Store service to the Enterprise application, so that the worker can set the price for the item that was missing in the store database. The configuration setting for the e-mail to be sent to enterprise is also defined in the configuration file, as shown here.

<!-- headquarters Mail ID-->
<add key="headquartersMailID" value="testmail@microsoft.com"/>

E-mail is sent through the SMTP server that is configured in the IIS Server. The configuration settings, such as the SMTP server name and port, are also part of the configuration file.

<!-- IP Of a box that has SMTP (Generally this is Indigo box) -->
   <add key="SMTPIP" value="smtphost"/>

<!-- Port on which SMTP Service is running-->
   <add key="SMTPPort" value="25"/>

Also, the endpoint address of the Store service can be configured in the Config.xml file.

<!-- Indigo Store Service path -->
<add key="EndPointAddress value="http://localhost:2769/StoreService/Service.svc"/>

Store Windows Service (Figure 2, Item 4)

The Store Windows service (CSTStoreWinService) is exposed as a Windows service, and communicates with the Store Manager application by using the notifications raised by the POS. The CSTStoreWinService also manages the communication between the Store Manager application and the Store service, as the Store Web service is hosted in the Windows service.

The Windows service triggers any notification to the Store Manager whenever any high-value items or promotional items are sold beyond their inventory threshold value. This routing of notifications to the Store Manager application is done by configuring the address of the Store Manager in the config file of the CSTStoreWinService.

<!-- IP address of device on which Manager application will run-->
    <add key="MGR" value="172.28.41.61"/>

As soon as the CSTStoreWinService starts, it searches for sales data transmission business rules.

Store Web Service (Figure 2, Item 5)

The Store Web service is hosted as a WCF Web service that is exposed to the Enterprise application. All communication between the Store Manager application and the Enterprise application is routed through this Web service. The endpoints for this Web service are configured in the configuration file. Business logic required on the store is incorporated in the public methods of this Store Web service.

The Store Web service communicates with the Enterprise application through the BizTalk service that acts as an interface on the corporate-headquarters side. The BizTalk service exposes the business rules and sales information methods. The Store Web service communicates with the BizTalk Web service using the IXRetail schemas. It performs the data transformation of store data to IXRetail format. This is achieved by mapping the data from the Store database to the schemas exposed by the BizTalk Web service. More about data transformation is explained later.

The core functions of the Store Web service are listed here:

  • Data aggregation: The sales data and transactions from the POS device are aggregated and pushed to the database using insert DB methods. The database connection settings are done in the Web.config file of the Store Web service, as shown here.
    !-->Db connection string Data Source=<<Database server>>
    Catalog=<<Database name>> -->
    <add key="ConString" value="Data Source=servername;
    Initial Catalog=db name;Integrated Security=True"/>
    
    
  • Data transformation: The Store Web service performs the data transformation of store data to IXRetail format by mapping the data from the Store database to the schemas exposed by the BizTalk Web service. This is demonstrated by the Applying Rules on Real-Time Data Updates scenario.
    • In this sample application, transaction information is transferred in real time from the store to the corporate systems; during this process, certain business rules are applied to select the information to be transferred. For example, sales information related to high-value items or promotional items are transmitted in real time with highest priority. Other transaction data will get secondary priority in transmitting in real time. The service hosted on the local host collects the simultaneous sales-data update from multiple POS devices, aggregates them, transforms them, and then transfers the data based on the rules set by the store manager or the corporate systems.
    • The BizTalk Service exposes the schema based on the IXRetail format and binds it to the orchestration. These orchestrations are then exposed as a Web service, and the business methods are exposed to the store as Web service methods.
      [System.Web.Services.WebMethodAttribute()]
              
      [System.Web.Services.Protocols.SoapDocumentMethodAttribute
      ("http://tempuri.org/BizTalkWS/PriceNotFound",
      Use=System.Web.Services.Description.SoapBindingUse.Literal,
      ParameterStyle=System.Web.Services.Protocols.
      SoapParameterStyle.Default)]
      
      [return:System.Xml.Serialization.XmlElementAttribute
      (Namespace="http://BizTalkWS.PriceNotFound",
      ElementName="PriceNotFound")]
      
      public PriceNotFound
      PriceNotFound([System.Xml.Serialization.XmlElementAttribute(
      Namespace="http://BizTalkWS.PriceNotFound",
      ElementName="PriceNotFound")] PriceNotFound part)
      {
      }
      
      

In the previous Web method, the input parameter should map to the PriceNotFound schema exposed by BizTalk. In the item-not-found scenario, the Store service retrieves the data from Store DB and transforms it into the schema object exposed by BizTalk. So, the transformation is done by mapping the dataset exposed by Store DB to the PriceNotFound schema.

Corporate or Enterprise Web Service (Figure 2, Item B)

Routing of messages, notifications, and sales data from store to corporate systems and back is achieved by the Corporate or Enterprise Web service. The Corporate Web service is exposed as a BizTalk Web service. Data flow happens between the stores and corporate systems using data-transformation techniques. All the retail-business scenario schemas are exposed by the BizTalk Web service. Based on the Retail scenario, the schemas are created for each one of the scenarios. These schemas are then transformed into messages and exposed as orchestrations. The set of orchestrations and receive locations that BizTalk creates are then exposed as a Web service. This Web service is published by using the Web services Publishing Wizard. The Corporate Web service is configured using the Config.xml file that is present in the BizTalk Helper class. The Corporate Web service also logs the events on the corporate side to a log file, the path of which is mentioned in the configuration.

<category name="Common">
   <setting name="LogFilePath" 
value="CSSample applicationLog.txt"></setting>
   <setting name="EventSourceName" 
value="CS Sample application"></setting>
   <setting name="EventSourceLogName" 
value="CSSample applicationLog"></setting>
</category>

The notifications to corporate systems, merchandiser, supplier, and back-room staff are sent using e-mails, the configuration of which is in the configuration file.

<setting name="DBConString" value="Data Source=ibm-indigo;Initial 
Catalog=Test_headquartersDB;Integrated Security=True"></setting>
<setting name="MerchandisersEmail"
value="testemail@test.com"></setting>
<setting name="headquartersEmail" value="testemail@test.com"></setting>
<setting name="BusinessRuleFilePath" 
value="\\ibm-indigo\temp\BusinessRules.xml"></setting>

Supplier Application

The Supplier application is exposed as a Web application, and is hosted on the corporate (or headquarters) side to allow the headquarters manager to recall items from POS applications. The Supplier Web application lets the manager enter the item details to be recalled, and the recall message is routed to the store through the BizTalk Web service.

Aa905316.wp_f04(en-us,MSDN.10).gif

Figure 4. The Supplier application uses this screen to send the item-recall message.

Corporate or Enterprise Database (Figure 2, Item D)

The Enterprise DB maintains the sales and inventory on its side to which the corporate applications are directly connected. All the notifications generated or routed by the BizTalk Web service and corporate Web applications also are stored in the database. The main tables in the corporate database are the following:

  • SalesDetails—This is where the details for each item sold from the POS are stored.
  • SalesMaster—This is the Invoice Master table that stores the invoices generated after each transaction.
  • PoSMaster—The POS details for each POS terminal are stored in the database. The store manager looks into this table to find the POS locations for all the terminals when it broadcasts any event.
  • Employees—The employee details for all the employees working in stores is maintained here.
  • ProductDetails—This is the product master table, listing the details of each product in the Store.
  • ItemMaster—This is the master table of the Store database that contains the transaction data and notification corresponding to each item. This table contains the RecallFlag that states the item-recall status of every item.
  • Inventory—This table contains the inventory of items available in either the back room or shelf of the stores. This table gets updated whenever any item is checked out from the POS.
  • LocationMaster—This table stores the location details of the store back room and shelf.
  • OutOfStockItemHistory—If any item checked out at the POS is unavailable at the store, and the check-out quantity falls below the threshold level in inventory, the transaction details for that item are then pushed to this table.
  • RecalledItemHistory—If the store manager recalls any item from the store shelf due to various reasons, the RecallFlag in ItemMaster for that item is set to true, and the RecalledItemHistory goes into this table.
  • UoMMaster—This table stores the unit-of-measurement details for each item in ItemMaster.
  • Promotions—This table contains the entry for the high-value items that are on sale or promotion.

Corporate or Enterprise Web Application (Figure 2, Item E)

The Enterprise application is exposed as a Web application. Hosted on the headquarters side, it performs all headquarters-related operations. This Web application supports various operations, such as sending notifications, merchandiser functionality for filling the stock, stock transfer, shipping inventory as requested by the stores, and generating purchase orders. Its main functions are:

  • Editing of item price.
  • Real-time transfer of price changes to the stores through the store-side WCF service. This is done by using the UpdateItem, which shows up when the application is launched. As soon as the price is updated and submitted, an e-mail is sent to the store manager, and a notification appears on the Store Manager application.
  • Ability to recall items from the store by providing RecallItem functionality. When the Item ID and the reason for recall are entered and sent to the Store Manager application, recalled items in the store are placed on hold.
  • Inventory-management functionality, provided to create and inventory shipment request and send it to the stores. The Store ID is selected from a drop-down list, and the quantity to be transferred is selected for the transfer to complete.
  • Business-rules configuration, provided to create the business rules for transferring sales information from the stores in real time. This information is stored in the SampleBusinessRules.xml file. Business-rules settings are explained here.
  • Priority transmission frequency:
    • Immediate
    • Every <text box> hours
  • Standard transmission frequency:
    • Every <text box> hours
    • Once a day (on shift complete at POS)
  • High-value items:
    • Count UnitPrice of item >= $<text box> as high value
  • Save/Cancel:
    • Save the values to an XML file at path read from Web.config

Store Manager Portal or Dashboard

Office SharePoint is utilized to build the Store Manager application running on a Tablet PC. All the messages and notifications from the POS are surfaced to the dashboard using Office SharePoint Services. The Store Manager application acts as an interface for all the notifications to be sent to—and received from—the Store Web service. In this application, the Store Manager receives the notification from the POS through a call to the database.

The Store Manager dashboard is used to edit the item price, view the sales data, and launch the Windows Store Manger application from the Quick Link launcher.

Office InfoPath Forms: Whenever item-not-found notifications are received by the Store Manager on the Tablet PC, an Office InfoPath form is launched to edit the price of an item. The Office InfoPath form is published on the Office SharePoint Portal Forms library.

Notifications Web Part: A Web Part is developed that displays all the notifications generated by the POS and Store Manager applications. All the messages and notifications from the POS are routed to this application. The Store Manager application acts as an interface for all the messages to be sent to—and received from—the Store Web service.

Sales Data Web Part: A Web Part is developed in Business Scorecard Manager to display the weekly sales information in a pictorial view. The data is read from the Analysis Service CUBE, which aggregates and processes the sales data. The Business Scorecard Manager is used to publish the sales-data information onto the Office SharePoint Portal Library.

Aa905316.wp_f05(en-us,MSDN.10).gif

Figure 5. A sample sales-data Web part

Office Business Applications

A composite application is a collection of software assets that have been assembled to provide a business capability. These assets are artifacts that can be deployed independently, enable composition, and leverage specific platform capabilities. Having an inventory of software assets by itself does not enable the ability to assemble composition applications. This requires a platform with capabilities for composition—that is, a platform that provides the ability to deploy assets separately from one other, and in combination with each other. In other words, these assets must be components, and the platform must provide containers.

The 2007 Microsoft Office System is such a platform for building composite applications, which are called Office Business Applications. At a very high level, some of the technical capabilities of the 2007 Microsoft Office System are summarized in Table 1. Each of these capabilities is a powerful feature, when looked at individually; however, it is the combination of these different technologies into a single integrated platform that makes composition practical. It is the integration of these technologies that enables delivery and deployment of composite applications, without an overwhelming increase in complexity in the overall platform, tooling, and architecture.

CapabilityDescription
Web site and security frameworkA common framework for creating different kinds of sites, for example team-collaboration sites, intranet portals, Internet Web sites.
Open XML file formatsOpen formats to represent business documents that can easily be read, transformed, and visualized. This enables rich server-side processing of documents in ways that were not possible before. With prior versions of Microsoft Office, parsing the document using the object model required an instance of the client application.
Extensible UIServer-side portal that can be extended by users from a catalog of Web parts, and the catalog itself can be extended by solutions providers. Client applications with rich capabilities for extensibility through Microsoft Visual Studio Tools for Office.
Business-Data CatalogA metadata repository to define business entities stored in back-end data stores, to model relationships between entities and define actions permissible on entities.
Enterprise SearchSurface data from various enterprise sources through search.
WorkflowIntegration with Windows Workflow Foundation to host workflows that represent people-to-people interactions, and that link user-interface elements.
Enterprise Content ManagementManage diverse content, with one topology for Web, document, and records management. Support for document life-cycle management.
Business Intelligence (BI)Server-based Office Excel spreadsheets, plus BI components (dashboards, reports, Web Parts) built into the portal and connected to Microsoft SQL Server Analysis Services.
Communication and CollaborationSupport for unified communications integrated into the platform.

Table 1. High-level capabilities provided by the 2007 Microsoft Office System

The first type of container in the presentation tier is the Microsoft Office client application (for example, Office Excel, Office Word, Office InfoPath). These applications are customizable containers that can now more easily surface information and functionality from LOB applications by way of custom task panes, custom ribbons, and custom actions that present users with data and actions in the context of their current activity. The component type that can be hosted within these containers is the Open XML document. This is the new XML representation for Microsoft Office documents and which enables rich server-side processing of information stored within.

The second type of container is a Web portal, as enabled by Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS). WSS v3.0 provides the following hierarchy of containers:

  • Farm—Installation of one or more load-balanced Web servers, and back-end servers, with a configuration database.
  • Web application—Microsoft IIS Web site, extended to use WSS, that can host site collections.
  • Site collection—Container for WSS sites that exists within a specific content database. A site collection contains a top-level site, and optionally child sites, and is the unit of ownership, securability, and recoverability.
  • Site—Container for child sites, pages, and content (for example, lists, document libraries).
  • Page—Container for Web Part zones and Web Parts

A page contained in a WSS site offers a model of Web Parts that is similar to the model in ASP.NET 2.0. Web Parts are components that display content on a page in modular form, and are the primary means for users to customize/personalize pages. Figure 5a shows an example of how a WSS page provides containers for Web Parts, and provides a WebPartManager control. This control creates and initializes Web Part instances inside the context of Web Part zones, and also serializes, stores, and retrieves Web Part customization data. Office SharePoint comes with a Web Part gallery that contains a rich set of Web Parts out-of-the-box—for example, to surface Office Excel spreadsheets and charts, and to view lists and tables. Solution providers can also provide their own custom Web Parts for application-specific or domain-specific functionality, which can then be uploaded into WSS. Information workers can then personalize pages by adding Web Parts from the gallery, removing Web Parts from a page, or rearranging the layout.

Aa905316.rtlsmpappfig05a(en-us,MSDN.10).gif

Figure 5a. Illustration of retail Web Parts manager

The 2007 Microsoft Office system provides a powerful set of capabilities to build composite applications, which are called Office Business Applications (OBAs). Composition is enabled at the presentation, productivity, application, and data tiers. This enables cross-functional solutions that offer a composite user interface that exposes business functions and capabilities across a heterogeneous set of back-end IT assets. These solutions also provide collaborative business capabilities that fill the white space between traditional business applications and personal productivity tools.

Retail Standards

Retail standards are very critical; they help in standardizing the interfaces between devices (for example, a scanner and a point-of-sale terminal) or applications and define standards for interacting with the device. Retail standards also ensure that the messages between sharing applications are in a predictable format, so that applications developed by different people can talk to each other. Standards are beneficial to both application developers and end users. From a developer's point of view, standards reduce the cost of systems design and development, and allow easier migration and specialization in an application area. From a retailer's standpoint, standards allow the integration or interoperability of devices and applications from different vendors, enabling the creation of more cost-effective, customizable, advanced, and powerful systems. Standards also provide the freedom to customers in picking best-of-breed applications that meet their requirements.

Retail standards can provide the following benefits to the retail community:

  • Less expensive solution.
  • Richer user experience.
  • Gains in productivity.
  • Reduction in maintenance cost.
  • Choice to select best-of-breed applications.
  • Based on an open language (such as XML) that is vendor-neutral and can be generated and consumed by any application, irrespective of the platform or vendor. The standard defines the data to be exchanged; XML provides an open language to carry the data, and open transport methods—such as Web services—allow applications to exchange that data.
  • Flexibility to the customer to switch between applications with minimal difficulty.

The Association of Retail Technology Standards (ARTS) has standards called IXRetail for POSLog and other sale-related transaction information. The IXRetail POSLog describes the various interfaces that a POS system uses to report the results of its activities to other systems in the retail enterprise. POSLog includes many different kinds of transactions and events. The IXRetail POSLog schema consists of a single XML schema that defines the set of all possible transactions and events that can be sent by a POS to another system.

IXRetail builds on the ARTS Data Model to develop standard XML schemas and message sets, to ease Application-to-Application (A-to-A) integration within a retail enterprise. The sample-application solution is required to comply with the ARTS IXRetail standard XML schemas for interfacing applications within the retail enterprise. The schemas used in the sample application comply with the IXRetail standard and are extracted from the standard set of schemas provided by ARTS. The data flow between the Store and LOB is done by using these schemas.

This reference implementation uses the IXRetail standards pertaining to POSLog, where items are purchased and returned. A sample IXRetail POSLog is shown here.

<?xml version="1.0" encoding="UTF-8" ?>
<!-- UseCase: Item Purchase from shelf -->
<!-- Note: This example includes all optional fields -->
<POSLog
xmlns="http://www.nrf-arts.org/IXRetail/namespace/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.nrf-arts.org/IXRetail/namespace/POSLog.xsd">
<Transaction CancelFlag="false" OfflineFlag="false" TrainingModeFlag="false">
<RetailStoreID>HighStreet</RetailStoreID>
<RevenueCenterID>6333-1221</RevenueCenterID>
<WorkstationID>POS5</WorkstationID>
<TillID>22</TillID>
<SequenceNumber>4294967295</SequenceNumber>
<BusinessDayDate>2001-08-13</BusinessDayDate>
<BeginDateTime>2001-08-13T09:03:00</BeginDateTime>
<EndDateTime>2001-08-13T09:05:00</EndDateTime>
<OperatorID>John</OperatorID>
<CurrencyCode>USD</CurrencyCode>
<RetailTransaction Version="2.1" OutsideSalesFlag="false">
<ManagerApproval>false</ManagerApproval>
<ReceiptDateTime>2001-08-13T09:04:32</ReceiptDateTime>
  <LineItem VoidFlag="false">
  <SequenceNumber>1</SequenceNumber>
  <BeginDateTime>2001-09-16T09:04:00</BeginDateTime>
  <EndDateTime>2001-09-16T09:04:03</EndDateTime>
    <Sale ItemType="Stock">
    <POSIdentity>
      <POSItemID>01234567890123</POSItemID>
    </POSIdentity>
    <ItemID>CA7865</ItemID>
    <MerchandiseHierarchy Level="Department">
Chocolates</MerchandiseHierarchy>
    <ItemNotOnFileFlag>false</ItemNotOnFileFlag>
    <Description>4oz Dark Chocolate</Description>
    <TaxIncludedInPriceFlag>false</TaxIncludedInPriceFlag>
    <UnitCostPrice>1.23</UnitCostPrice>
    <UnitListPrice>1.79</UnitListPrice>
    <RegularSalesUnitPrice>1.63</RegularSalesUnitPrice>
    <InventoryValuePrice>1.23</InventoryValuePrice>
    <ActualSalesUnitPrice>1.63</ActualSalesUnitPrice>
    <ExtendedAmount>4.89</ExtendedAmount>
    <DiscountAmount>0.00</DiscountAmount>
    <ExtendedDiscountAmount>4.89</ExtendedDiscountAmount>
    <Quantity>3</Quantity>
  </Sale>
</LineItem>
<Total TotalType="TransactionGrossAmount">4.89</Total>
  </RetailTransaction>
</Transaction>
</POSLog>

Interaction of the Components

The previous section described the various components that make up the sample application. This section will describe how these components interact and come together to create an agile and near real time decision-making experience in retail.

This sample implementation involved creating reference architecture, sample code to demonstrate the benefits of loose coupling, using standards to achieve interoperability, and the capabilities of the Microsoft platform in achieving this with minimal effort. Also, to show how a retailer is able to move to a more real-time decision-making process in an incremental fashion, as opposed to using a rip-and-replace methodology. Implementation involves using the WCF to create Web services that communicate in near-real time with the enterprise systems for exchanging messages. IXRetail standards are used for exchanging data with the enterprise systems, and a custom IXRetail sample accelerator for BizTalk was implemented for communication with the enterprise systems.

The direction chosen for this reference implementation was to implement the solution using WCF and BizTalk Server, IXRetail message types as interchange and canonical message formats, and messaging over a Web services wire protocol.

Implementation View of Store-Side Architecture

This section provides an overview of the reference architecture for the store side.

Aa905316.wp_f06_ssi(en-us,MSDN.10).gif

Figure 6. Store-services interaction

Figure 6 shows a functional view of a store with POS systems, a local host or store server, manager workstation, and the Store database. POS systems store transaction information in the local database and retrieve price information from the database to complete the sales transactions. The diagram also shows a Web service, which reacts to the information stored in the database or the messages received from the enterprise systems. When a POS system completes a sales transaction, the sales data is picked up by the Web service, transformed into the standard IXRetail format, and transferred to the corporate-headquarters systems. Web services pick up the sales data based on rules that are configured by the store manager and/or the corporate-headquarters systems. For example, a promotional-item sales data supersedes a non-promotional-item sales data for transferring to the corporate-headquarters system.

The outgoing messages go through the steps of aggregation, transformation, and compression before they are transferred to the enterprise systems. This transfer of data in real time from the store to the enterprise systems helps in making real-time decisions at the corporate-headquarters level. It also helps in monitoring real-time key-performance indicators (KPIs), and can trigger workflows at the enterprise level. For example, transfer of information related to inventory levels at the store can trigger workflows to order items from the supplier.

Aa905316.wp_f07_oms(en-us,MSDN.10).gif

Figure 7. Outgoing messages from the stores

Also, as shown in Figure 7, the sales data from the POS systems is aggregated, transformed, and compressed before being transferred to the enterprise systems.

An item-not-found scenario can trigger an in-store workflow, so that the store manager can override a suggested price for the sales transaction to move forward. In an item-not-found scenario, the Web service alerts the manager in real time, who in turn launches the inventory-management application on a workstation or a tablet, to temporarily assign a price for the sales clerk to complete the transaction. At the same time, the Web service alerts the enterprise system about the missing price. When the merchandising manager receives an alert for a missing price, the manager updates the price, and the price information is transferred to all the stores in real time.

The Manager dashboard application surfaces sales information and other KPIs. It also surfaces the real-time alerts related to either item-price-not-found or recalled-item. Office SharePoint Services surfaces the relevant information, and the manager can react to it, either by launching the application from the dashboard or at a later time.

The inbound messages from the enterprise systems also go through similar steps in real time, as shown in Figure 8.

Aa905316.wp_f08_imes(en-us,MSDN.10).gif

Figure 8. Inbound messages from the enterprise systems

Messages such as price updates or item-recall notifications from the enterprise systems go through similar steps. For example, when price-update messages arrive at the store, they are decompressed and transformed before being transferred to the price database. In real time, the price updates are reflected at all the POS systems in the stores.

For example, when an item-recall message is received by the store, it is persisted to the database, and it immediately suspends further the sale of the recalled item. An alerting Web service picks up the message and alerts the store manager to move the on-shelf recalled items to the back room, to prevent further sale of the recalled item. This trigger of workflows in real time prevents the sale of recalled items and reduces the retailer's liabilities.

This reference architecture shows how, in real time, services can be implemented using the service-oriented architecture concept, where workflows are triggered without much manual intervention. All communication between the stores and enterprise systems is done using standardized XML messages. As described in the previous chapter, a message is an XML document from the store, the enterprise systems, or a supplier. Part of the XML document identifies the type of message, and routing information. Each message is associated with an XML schema that defines the set of valid message formats. In this reference implementation, inbound messages from enterprise systems were delivered in the IXRetail format wherever possible over HTTP. Even though messages could be exchanged in a variety of different patterns, this implementation opted to use the asynchronous two-way messaging.

When a message is received at the store, it is transformed, if needed, and persisted to the database for other services to consume. Other Web services pick up the message and trigger an alert or action.

Implementation View of Corporate-Headquarters Architecture

Figure 9 shows the reference architecture of the corporate-headquarters system. In this case, MSMQ (not implemented in the sample application) can be used as a queuing mechanism; BizTalk is used for aggregation, transformation, and orchestration of messages that arrive at the enterprise. Messages range from store sales data to supplier item-recall messages or confirmation of purchase orders. BizTalk accelerator is used in communicating with the enterprise LOB systems, such as merchandising systems or ERP systems and the data warehouse.

BizTalk is used for transforming the data and orchestrating the inbound messages. This helps in quickly integrating the store systems with the enterprise LOB systems.

Aa905316.wp_f09_hqra(en-us,MSDN.10).gif

Figure 9. Enterprise reference architecture

The enterprise receives messages from the stores, suppliers, and the multichannel sites, such as e-commerce and catalog orders. Messages from stores range from sales-transaction data to inventory-level thresholds and item-price requests. Sales-transaction data is transformed and persisted in the database and the data warehouse in real time. These databases drive real-time KPI monitoring and reporting capability at the enterprise level. E-commerce and catalog orders require real-time inventory checks to complete the fulfillment, as well as to confirm customers' requests to pick up the item at the store. If this is implemented correctly, and an e-commerce or catalog order is accepted with the promise to pick up at the store, it might lead to disappointed customers, as stores might run out of those items. So, it is critical for the order-fulfillment application to check inventory levels at the stores in real time, before accepting the order.

Messages from stores, such as "item not found," generate alerts at the enterprise, requiring the merchandise manager to input a price for an item, which gets downloaded in real time to the stores. When inventory drops below a certain threshold at stores, the enterprise receives a message that triggers a workflow to generate a purchase order (PO) and requires approval by the enterprise merchandise manager. Then the PO is sent to the supplier.

Real-time information flow from the stores to the enterprises helps in real-time decision-making and monitoring of the enterprise.

Figure 10 shows the outgoing messages from the enterprise. Messages such as price updates, inventory checks, and item-recall messages are sent to the stores in real time, which prevents loss and financial liability for the enterprise.

Aa905316.wp_f10_omes(en-us,MSDN.10).gif

Figure 10: Outgoing enterprise messages

Outgoing messages, such as item-recall messages received from the supplier, are transmitted immediately to the stores to suspend further sales of the recalled items. The message from the supplier is received in any format and transformed to an XML format. An inventory lookup is then performed to check which stores carry the recalled item, and the recall message is transmitted to those stores.

Responses to item-not-found requests also follow a similar path. Updated price information is sent only to the stores that carry the particular item.

Information Flow

This section describes how the information flows for each of the scenarios. It shows how various services interact to facilitate real-time decision-making, both at the store and corporate level. Each of the example scenarios is described in detail, along with the steps involved in moving the information to the right place in real time.

Scenario 1: Item Not Found

As described in the earlier section, this is a common scenario that occurs in the retail environment. This scenario requires real-time intervention of the manager, to ensure smooth checkout of items and provide good customer experience.

The steps involved in replicating this scenario using the sample application, along with the resolution, are as follows:

  1. Select an item on the POS application for which the price in the ItemMaster table of the Store DB is zero.
  2. Click Add to check-out the item. A message is displayed as follows: "Price not found for this item. Do you want to convey it to the Store Manager?"
  3. Click Yes. The notification is then sent to the Store Manager.
  4. Click the Notifications tab to see the notification in the Store Manager application.
  5. In the Store Manager application, click the Inventory tab, and select the item for which the price was not found. Edit the price and save it. An e-mail is sent to the merchandising manager at the corporate headquarters, and the price is updated in the Store DB.
  6. Open the Merchandising application at the corporate headquarters by going to the following location: http://localhost/HQSystemsetup/UpdateItem.aspx
  7. Update the price of the item for which the price was not found, and save it.
  8. The final price gets saved in the Store DB and HQ DB, and the message is displayed.
  9. Once again, select the same item on POS. The item can now be checked out with the updated price.

Aa905316.wp_f11_inf(en-us,MSDN.10).gif

Figure 11. Item-not-found scenario

Click here for larger image

Figure 12. Item-not-found scenario-sequence diagram (Click on the picture for a larger image)

Scenario 2: Item Recall

As described in the earlier section, this is a common scenario that occurs in the retail environment. This scenario requires real-time actions by the manager, as well as the staff. The sample application demonstrates how this scenario can be completely automated by using the latest technology—specifically, Web services.

The steps involved in replicating this scenario using the sample application, along with the resolution, are as follows:

  1. Supplier initiates the recall process by launching the Supplier application at the following location: http://localhost/SupplierAppSetUp/SupplierApp.aspx
  2. An item is selected, and the supplier sends the item-recall message to the merchandiser whose Mail ID is configured in the Web.config file of the Supplier application.
  3. Upon receiving the e-mail, the corporate-headquarters application is launched at the following location: http://localhost/HQSystemSetUp/RecallItem.aspx
  4. Clicking Notify Recall button sends a notification to the Store Manager.
  5. Clicking Notifications on the Store Manager application will display the notification.
  6. When an attempt is made to check-out the recalled item, a message is displayed indicating that this is a recalled item and cannot be checked out.
  7. Simultaneously, a notification for item recall is seen at the Store Manager application, in order to alert the manager to remove recalled items from the store shelves.

Aa905316.wp_f13_ir(en-us,MSDN.10).gif

Figure 13. Item-recall scenario

Click here for larger image

Figure 14. Item-recall scenario-sequence diagram (Click on the picture for a larger image)

Scenario 3: Item Out of Stock

As described in the earlier section, this is a very common problem across the retail industry. The sample application demonstrates how the latest technology can overcome this problem and provide a richer customer experience.

The steps involved in replicating this scenario using the sample application, along with the resolution, are as follows:

  1. When an attempt is made to check-out an item, the POS device displays an out-of-stock message.
  2. Immediately, a notification is sent to the store manager to transfer products from the back room to the store shelf.
  3. These same steps are repeated in case the inventory levels of the checked-out item go down below a certain threshold, which is set by the corporate-headquarters staff.
  4. An alert is sent to the store manager, indicating the out-of-stock situation.
  5. Clicking the Notification tab in the Store Manager application opens the alert.
  6. Clicking the Stock Transfer link on the Store Manager application transfers the inventory from the back room to the shelf (provided that the back room has the inventory).
  7. Next, some products can be transferred from the corporate warehouse by opening the corporate-headquarters application at the following location: http://localhost/HQSystemsetup/InventoryShipment.aspx
  8. When you are in the corporate-headquarters application, select the out-of-stock item and the store location from the combo box where the item must be transferred, and click OK.
  9. Items are transferred from the HQ DB inventory table to the Store Manager application where the item stock is pending to be accepted.
  10. Items can be received in the store by clicking the Stock Transfer(In) link on the Store Manager application and accepting the stock that is displayed.
  11. The inventory is updated in the Store DB.

Aa905316.wp_f15_ios(en-us,MSDN.10).gif

Figure 15. Item-out-of-stock scenario

Click here for larger image

Figure 16. Item-out-of-stock scenario-sequence diagram (Click on the picture for a larger image)

Scenario 4: Real-Time Promotional-Item Sales-Data Transfer

As described in the earlier section, transfer of store sales data is done as a batch process, where sales data is accumulated and then transferred to the corporate on a nightly or twice-daily basis. This limits the much-needed visibility at the corporate level about store performance. There is a need to provide sales-transaction data in near real time. So, the sample application demonstrates the transfer of transaction information in real time from the store to the enterprise systems. It demonstrates also the application of certain business rules in transmitting the sales-transaction information in real time. For example, sales information related to high-value items and promotional items are transmitted in real time with the highest priority. Other transaction data receives secondary priority in transmitting in real time. The service hosted on the local host collects the simultaneous sales-data update from multiple POS devices, aggregates it, transforms it, and then transfers the data based on the rules set by the corporate headquarters.

The steps involved in replicating this scenario using the sample application, along with the resolution, are as follows:

  1. Rules for real-time transfer are set at the corporate headquarters by launching the HQ application at the following location: http://localhost/HQSystemsetup/SalesConfig.aspx
  2. Next, enter the Details and the condition to treat an item as priority, using the corporate-headquarters Web application.
  3. These details are stored in the BusinessRules.xml file whose path is set in the BizTalk application. It will be stored at the shared location mentioned in the config file.
  4. Open the POS application, and select items to check out. Click Proceed. A notification for Check for PRITRANS is displayed.
  5. Select True for the transmitted bit for SalesDetails in the Store DB table for the high-transmission data.
  6. The data automatically moves to the SalesDetails table in HQ DB for the high-transmission data table.
  7. Close the POS. A pop-up window displays "Checking for standard data transmission." All the low-priority data is then transferred to the SalesDetails table of Store DB.

Aa905316.wp_f17_rtpdt(en-us,MSDN.10).gif

Figure 17. Real-time promotional-item sales-data transfer scenario

Scenario 5: Supply Chain

As described in the earlier section, store sales data typically is transferred to the corporate systems as a nightly batch. This results in poor visibility at the corporate level of store-inventory stock levels, and can result in delayed order generation for the suppliers who deliver products at a much later time. In turn, all of this can result in a poor customer experience. The sample application demonstrates how the latest technology can overcome this problem and provide a richer customer experience.

The steps involved in replicating this scenario using the sample application, along with the resolution, are as follows:

  1. An item is checked out at the POS. The inventory level is updated and, if it's below the threshold level, the Store Manager application is sent a notification.
  2. Store manager will move remaining items from back room to the store shelf.
  3. New items must be ordered to keep the supply chain and inventory levels intact. To order new items, open the HQ application by going to the following location: http://localhost/HQSystemsetup/Purchase Order.aspx
  4. Enter Details of the item, and click Send PO to update the inventory at HQ DB.
  5. After the e-mail for the PO confirmation is sent, open the HQ application by going to the following location: http://localhost/HQSystemsetup/InventoryShipment.aspx
  6. Select the item and the store location from the combo box where the item must be transferred, and click OK.
  7. The items are transferred from the HQ DB inventory table to the Store Manager application where the item stock acceptance is pending.
  8. After the manager completes the receiving step by going to the Store Manager application and accepting the inventory transfer, the item can be checked out at the POS.
  9. At the POS application, the item inventory can be checked by clicking Check Availability. This displays the updated quantity from the Store DB.

Aa905316.wp_f18_sc(en-us,MSDN.10).gif

Figure 18. Supply-chain scenario

Technical Decisions

There are many ways to make a retail enterprise agile. However, using a technology that makes it easy to develop and maintain and is flexible for future extensions will reduce the total cost of ownership for a retail enterprise. This section describes the functionality, features of the latest technology, and the benefits associated with using these various technology pieces.

Windows Communication Foundation (WCF)

WCF (formerly code-named "Indigo") is a set of .NET technologies for building and running connected systems. It is a new breed of communications infrastructure that is built around the Web services architecture.

WCF provides Advanced Web services support through secure, reliable, and transacted messaging, along with interoperability. Three things stand out, however, as the most important aspects of WCF: its unification of several existing Microsoft technologies, its support for cross-vendor interoperability, and its explicit service orientation.

Also, one major concern while developing the sample application was that we were joining disconnected systems (POS, LOB, Store) in a real-time application that was hard to achieve. But, because the fundamental communication mechanism of WCF is SOAP, WCF applications can communicate with other software running in a variety of contexts. An application built on WCF can interact with all of the following:

  • WCF applications running in a different process on the same Windows machine.
  • WCF applications running on another Windows machine.
  • Applications built on other technologies, such as application servers based on Java 2 Enterprise Edition (J2EE) that support standard Web services. These applications can be running on Windows machines or on machines with other operating systems, such as Sun Solaris, IBM's z/OS, or Linux.

So, if we want to extend this sample application for non-Microsoft platforms, we can do that quite easily.

To allow more than just basic communication, WCF implements a group of newer Web services technologies collectively referred to as the WS-* specifications. These documents define multivendor ways to add reliable messaging, security, transactions, and more to SOAP-based Web services. The Web services specs supported in the first release of WCF include WS-Addressing, WS-Policy, WS-MetadataExchange, WS-ReliableMessaging, WS-Security, WS-Trust, WS-SecureConversation, WS-Coordination, WS-AtomicTransaction, and the SOAP Message Transmission Optimization Mechanism (MTOM).

Finally, because WCF provides a standard foundation for service-oriented software, it will be the basis for a large portion of Windows communication.

WS-* Implementation on Store Side

WS-*(WS-Security, WS-Reliability) helps enable organizations to build reliable and interoperable Web services applications by defining a standard mechanism for identifying and exchanging Web services messages between multiple endpoints. With a standard way to express where a message should be delivered in a Web services network, developers are able to simplify Web services communication and development, and avoid the need to develop costly, one-off solutions that are often difficult to interoperate across platforms.

WS-* is a key part of the core Web services architecture. In particular, the specification is designed to underlie other specifications, such as WS-ReliableMessaging, WS-Federation, and WS-AtomicTransaction, to provide a protocol-independent, common way to locate Web services in support of features like transactions, security, reliable message delivery, and identity federation.

WS-Security: Windows Authentication

The configuration files in this application set the mode attribute of the Security element in wsHttpBinding to Message and the clientCredentialType attribute to Windows. Other options for clientCredentialType are None, Username, and Certificate. Other options for security mode are Transport and TransportWithMessage.

<bindings>
   <wsHttpBinding>
      <binding name="Binding1">
         <security mode="Message">
               <message clientCredentialType="Windows"
                negotiateServiceCredential="True" />
         </security>
         <reliableSession enabled="true" ordered="true" />
      </binding>
   </wsHttpBinding>
    </bindings>

The client endpoint configuration consists of a configuration name, an absolute address for the service endpoint, the binding, and the contract. The client binding is configured with the appropriate securityMode and authenticationMode. When running in a cross-machine scenario, use the identity and the userPrinicpalName elements.

<system.serviceModel>
   <client>
      <endpoint address="http://mmoin/contoso/Service.svc"
           bindingConfiguration="WSHttpBinding_IStoreService"
           binding="customBinding" contract="IStoreService">
          <identity>
          <servicePrincipalName value="host/mmoin" />
          </identity>
      </endpoint>
   </client>
   <bindings/>
</system.serviceModel>

The service source code has been modified to demonstrate how the CurrentPrincipal can be used to access the identity of the caller. This code requires the inclusion of the System.Security.Principal namespace.

WS-Security: Kerberos

There are several scenarios in which you would use Kerberos authentication, instead of Windows authentication.

Windows SSPI negotiation internally requires several exchanges of information between client and server to arrive at the actual authentication protocol to be used. If performance is critical, multi-leg negotiations might not be acceptable.

The expected message-exchange pattern might dictate that the client be authenticated with the service using Kerberos authentication on every message.

Using WCF, you can create and deploy the client and service with the use of Kerberos required.

The client and service configuration file should be modified to indicate that negotiation should not be used for this binding.

<bindings>
   <wsHttpBinding>
      <binding name="Binding1">
         <security mode="Message">
            <message clientCredentialType="Windows"
            negotiateServiceCredential="False" />
         </security>
   </wsHttpBinding>
</bindings>

If this sample is run cross-machine, a fully qualified machine name should be specified in the endpoint address. Also, the identity should specify the Service Principal Name with the fully qualified machine name. WCF matches the fully qualified host name from the endpoint address with the service principal name. If this check passes, the service is considered to be authenticated by the client.

WS-Security: Anonymous

The Anonymous sample demonstrates how to implement a WCF application that uses WS-Security with no client authentication, but requires server authentication using the server's X.509v3 certificate. All application messages between the client and server are signed and encrypted.

Client Configuration

<security mode="Message">
   <message clientCredentialType="None" />
</security>

<!--Service Configuration-->

<security mode="Message">
   <message clientCredentialType="Certificate" />
</security>

WS-Security: Certificate

To configure WS-Security with X.509v3 certificate authentication for the client requires server authentication using the server's X.509v3 certificate.

The server certificate has to contain the same value for the SubjectName as the findValue in the serviceCredentials.

<serviceCredentials>
   <serviceCertificate findValue="localhost"
           storeLocation="LocalMachine" storeName="My"
           x509FindType="FindBySubjectName" />
</serviceCredentials>

<!--Client & service both should be configured for clientCredentialType
as certificate.-->

<security mode="Message">
   <message clientCredentialType="Certificate" />
</security>

WS-Security: User name

To implement an application that uses WS-Security with user-name authentication, all application messages between the client and server are signed and encrypted. By default, the user name and password supplied by the client are used to log on to a valid Windows NT account.

<security mode="Message">
   <message clientCredentialType=" UserName " />
</security>

Client call will use user name and password.

proxy.ClientCredentials.UserNamePassword.UserName = username;
proxy.ClientCredentials.UserNamePassword.Password = password;

WS-Reliability

Service will be configured as follows.

<reliableSession enabled="true" ordered="true" />

BizTalk Server 2006

BizTalk Server 2006 is a business-process management (BPM) server that enables companies to automate and optimize business processes. This includes powerful, familiar tools to design, develop, deploy, and manage those processes. So, to manage the business flow from Store to Enterprise and vice versa, and to manage the workflow, BizTalk Server 2006 was chosen.

Moreover, BizTalk Server 2006 created XML messages from IXRetail schemas that were used for communication between the store and its headquarters.

BizTalk Server 2006 provides support to effectively exchange messages between stores and headquarters situated at different machines. Given the diversity of communication styles that exist, the BizTalk Server 2006 engine must support a variety of protocols and message formats like the IXRetail.

BizTalk Server 2006 also provides adapters for different products like Microsoft SQL Server to integrate with it. So, in the sample application to integrate with Store service and SQL Server, Web service adapter and SQL adapter were used.

The business logic for the various retail scenarios was implemented using the orchestration engine of BizTalk Server 2006, which made it a common middle layer to host the business logic.

BizTalk Server 2006 also provides an Enterprise Single Sign-on facility, providing the ability to map authentication information between Windows and non-Windows systems. So, interoperability across heterogeneous platforms can be achieved.

To summarize, the goal of BizTalk Server 2006 was to help the sample application meet the challenges of creating automated business processes that rely on diverse systems and to use the product's foundation, the BizTalk Server 2006 engine, which provides core messaging and orchestration capabilities.

BizTalk Server will add support for WCF as a communication option, sometime following the release of BizTalk Server 2006.

Office SharePoint Services

Office SharePoint provides a common framework for creating a wide range of Web sites, such as team-collaboration sites, dashboards, and intranet team sites. This is tightly integrated into the Active Directory directory services system, to provide authentication and role-based authorization, as well as to enable federated trust relationships. Office SharePoint provides a Web portal that can be used to host server-side Web applications that are composed from a library of building blocks called Web Parts. This library is packaged with a number of Web Parts out-of-the-box, and can be extended by solutions providers for particular business processes. In addition, users can also personalize and extend applications after they have been deployed into Office SharePoint.

In this sample application, Office SharePoint 2003 server is used, so some of the capabilities—such as Open XML file formats and Business Data Catalog (BDC)—were not available. However, the Management Dashboard uses the Business Scorecard Manager (BSM) to create the cubes. The capabilities of BSM are explained in the following subsection.

Business Scorecard Manager

The Management Dashboard is an application created in the sample application for the managers to view the sales, inventory levels, and alerts at a common Web location, enabling them to manage the stock and resources amply in the stores.

The Management Dashboard enhances the power of a manager by providing a Web-based reporting portal that allows managers to access and view only the most important and most pertinent information. Several reports can be viewed simultaneously that highlight key issues in the store data. They can then be drilled down to the underlying detailed reports. This was achieved using Business Scorecard Manager (BSM) 2005.

A dashboard enhances the sample application by fully using the computer desktop in combination with other relevant information: unstructured data, collaborative tools, charts, and graphs, as well as other scorecards. The dashboard provides a comprehensive view for data communication and analysis, displaying trends in the form of graphs, as well as providing the user with additional contextual information for decision-making.

BSM is a comprehensive scorecard and dashboard application that provides you with deep contextual insight into business drivers. BSM provides an intuitive and friendly design to allow anyone across the organization the ability to build, monitor, and manage key-performance indicators (KPIs) that are individually meaningful to them.

Using BSM, the sample application provided the sales, inventory, and promotional-data KPIs in the Management Dashboard for store managers to analyze relationships between KPIs and tangible business objectives.

From a business point of view, by tracking the critical performance and financial data in BSM, the sample application greatly enhances visibility and accelerates reporting, consequently making it more alert to material changes in the retail business, and compliant with disclosure and filing requirements.

Also, using balanced scorecarding goes beyond financial data to link corporate strategy with LOB action. This is because scorecards typically report on organizational performance in both financial and non-financial terms, according to KPIs. Corporate strategy tends to encompass efforts from across the entire organization, from finance to sales to operations, so scorecards and their constituent KPIs must also span that distance.

BSM was used in the sample implementation to:

  • Employ a clear graphical interface for unambiguous interpretation of data.
  • Be fully Web-enabled, which results in instant relay of the same message to multiple remote locations using a universal medium, offering real-time visibility into key business trends. This is how the BSM sales and inventory levels get updated in real time in the sample application, which was one of the key requirements in choosing BSM for dashboard management.
  • Introduce flexibility by encouraging individual definition of objectives, as well as measurement, monitoring, and management of sales performance.
  • Map and link sales information to the strategic objectives of the organization; create a strategy-focused operation and encourage the use of information to measure and optimize the sales engine; or drive new initiatives.
  • Provide personalized and timely information across different stores for individual store managers.
  • Reconnect information with the business processes that create it to help run them more effectively and efficiently.
  • Enable different views of data and reports and deep, easily executable analysis, to provide a highly customized business tool with measurable value.
  • Present structured data, as well as documents, spreadsheets, links, and other unstructured data, which promotes a balanced and informed decision-making process.
  • Layer over traditional sales LOB applications, to protect financial and training investment and leverage existing data.

Conclusion

Disruptive technologies—such as RFID, contact-less payments, mobile payments, biometric payments, Wi-Fi, and so on—bring challenges and opportunities for retailers. Those retailers who adopt these technologies in a timely fashion and use them to reach more customers and discover new markets will see their revenue continue to grow, whereas those retailers who shy away from adopting these technologies will find it difficult to survive in this highly competitive marketplace.

As availability of broadband and RFID grows in the marketplace, customers expect better experience from retailers. This requires not only adopting these technologies in-house, but also changing existing systems to consume new data that gets generated. This additional data can help with real-time decision-making, if used properly; or it can overwhelm and kill a business, if not. So, real-time decision-making is extremely critical in the retail business. As the customers become increasingly demanding and the competitive pressure increases, the need for agility grows. Attaining agility requires availability of the right information, at the right time, and at the right place.

Retailers work with very thin margins, meaning that they are always looking for ways to cut costs. The legacy applications are inhibitors to growth, and IT then dictates business growth as opposed to supporting it. For IT to support changing business needs, they must have agile and adaptable solutions that are built on technologies that can support growth. Service orientation is the new architectural paradigm that has the potential to help IT become agile and keep up with these business demands.

Acknowledgements

I would like to thank Nick Lewis, Tim Gruver, and Michael Graber of Microsoft Corporation; Avadh Jain, Anurag Katre, and Ramesh Lanka of Tata Consultancy Services; and Jon Tobey of Ideastream, for their help in the completion of this work.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.