IT in retail

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 These 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.

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.

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.

<add key="POSID" value="101"/>


<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.)


<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.


<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.

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.


<add key="CommunicationIP" value="172.28.41.61"/>

<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.


<add key="IRCXmlName" value="ircnotify.xml"/>


<add key="IOOSSXmlName" value="ioossnotify.xml"/>


<add key="IOOSBXmlName" value="ioosbnotify.xml"/>


<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.


<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.


<add key="SMTPIP" value="smtphost"/>

<add key="SMTPPort" value="25"/>

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


<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.


<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.
o 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.
o 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-indigotempBusinessRules.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.

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:
o Immediate
o Every <text box> hours
• Standard transmission frequency:
o Every <text box> hours
o Once a day (on shift complete at POS)
• High-value items:
o Count UnitPrice of item >= $<text box> as high value
• Save/Cancel:
o 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.

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.

Capability Description

Web site and A common framework for creating different kinds of sites, for example
security team-collaboration sites, intranet portals, Internet Web sites.
framework

Open XML file Open formats to represent business documents that can easily be
formats 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 UI Server-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 A metadata repository to define business entities stored in back-end
Catalog data stores, to model relationships between entities and define
actions permissible on entities.

Enterprise Search Surface data from various enterprise sources through search.

Workflow Integration with Windows Workflow Foundation to host workflows that
represent people-to-people interactions, and that link user-interface
elements.

Enterprise Manage diverse content, with one topology for Web, document, and
Content records management. Support for document life-cycle management.
Management

Business Server-based Office Excel spreadsheets, plus BI components
Intelligence (BI) (dashboards, reports, Web Parts) built into the portal and connected
to Microsoft SQL Server Analysis Services.

Communication Support for unified communications integrated into the platform.
and Collaboration

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.

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" ?>


<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.

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.

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.

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.

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.

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.

Figure 11. Item-not-found scenario

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.


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.

Figure 13. Item-recall scenario

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.


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.

Figure 15. Item-out-of-stock scenario

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.


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.

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.


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.

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">
<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

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



<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>



<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.

<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.

“New” Retail for a New Decade
Posted on 13. Dec, 2009 by Jon Bird in Brand Strategy, Consumer Trends, Retail
Marketing, Retail Trends, Westfield World Study Tour 2009

Over the last few weeks, I’ve discussed some of the influences that will affect retail in the
coming decade:

• Considered Consumption – consumers thinking more carefully about every
shopping trip and considering not only whether they actually need a particular
item, but also the social and environmental consequences of that purchase (and
the purchase process itself).
• Brand Experiences – manufacturer brands like Nike and Apple raising the bar on
architectural design, fit-out quality, store innovations and service standards, with

increasingly impressive flagship experiences (what Apple call “significant
stores”).
• Constantly Connected Consumers – consumers being able to compare product
and prices, share information and reviews, and buy what they want, wherever and
whenever they want, increasingly direct from their internet-enabled mobile
phones.

There are other retail trends that I could canvas, for example:

• Value Is The New Black – how “true value” has become fundamental and
fashionable, and that it’s not purely price any more, but a combination of price,
quality and other benefits.
• It’s Not About Stuff – retail becoming less about the item itself, and more about
the experience, the service and the visual merchandising surrounding it.

However, I thought I’d finish the year with one of the most revealing and inspiring
observations I encountered in 2009…and hopefully a quote that you will find thought-
provoking as you turn your attention to a new decade.

In May this year, as part of the Westfield World Retail Study Tour, I was fortunate to
hear Mary Portas speak in London. Portas is the UK’s self-proclaimed “Mary Queen of
Shops”. Creative Director of PR and marketing communications company Yellowdoor,
Portas is a retail strategist and commentator credited with helping to turn department
store Harvey Nichols into a powerhouse.

One line particularly struck me in Portas’ presentation on retail trends. She said:

”We are moving from talking, telling and taking to sharing, giving, co-creating and
collaborating.”

In just 14 words, Portas captured the essence of the shift that is taking place from retail
monologue to retail dialogue. “Old” retail was about talking at customers, telling them
what you wanted them to hear, and taking their money. “New” retail is about sharing
information, giving generously without expecting anything in return, co-creating with
third parties, and collaborating with consumers on your essential offer. Some examples of
“new” retail include:

• Japanese supermarket 7 & I printing QR codes on their fresh produce labels that
allow shoppers to instantly find out about the nature and origins of the product
(sharing information)
• US electronics retailer Best Buy and their Twitter-powered “Twelpforce”, giving
consumers a 24-hour a day communications channel to get free advice (sharing
information and giving generously)
• Apple and their free Genius bars in store, where customers can go to get free
technical assistance on Apple products (giving generously)

• Designer Matthew Williamson lending his name to a collection for H&M
worldwide (co-creating)
• Sportsgirl involving their online community in building their offer – including
asking customers to upload photographs of their “look” and send in beauty tips
which are then published, along with suggestions of relevant product
(collaborating with consumers)

Portas points to a partnership-powered future for retailers, where some control is ceded to
consumers and third parties, but in doing so the outcome is richer and more rewarding for
all. At the beginning of a new decade, “new” retail is an exciting prospect.

Decoding retail in new decade

The buzzword in today’s social climate is “mobility” with consumers responding to rise in retail
formats including online retail, which in turn are driving the sea change in the shopping habits
pointing strongly to changes in the retail experience.

As the salary package of skilled professionals touching the new heights, the swelling double
income middle class populace living in isolated nuclear families, have made the jump from ‘zero
spending’ and ‘frugal living’ to one of fancying king size life with enough money to spend on.
“Euphoric shopping” would be the key to reinvent and engage the consumer in today’s
increasingly complex retail environment. In order to grasp this opportunity, the store retailers
need to focus tightly on range of products, quality, and value for money he carries in his store,
apart from creating a memorable shopping experience.

Craze for trendy fashion

“The ability to stay ahead of the curve, to translate trends into products that fit your target
segment and communicate how relevant your product is to your customer will determine footfalls
and sales, and this would be the biggest challenge in the coming times,” says Dilip Kapoor, MD,
Hidesign. Pradeep Hirani, MD, Kimaya Fashions Pvt Ltd further adds, “The emphasis has
changed from price consideration to design, quality and trendiness.”

Organic is the buzz

With “go green” buzz in the air, there is a natural drift in consumers’ purchase pattern showing an
inclination towards eco-friendly products. Organic products across categories like apparels and

beauty products are the latest offerings from the retailers, and consumers are responding well.
Shriti Malhotra, COO, Quest Retail shares, “Indian consumers are accepting modern practices of
personal grooming, making cosmetics and toiletries brands to introduce more sophisticated
products from their international portfolios to India.”

More co-ordinate fashion expected

“More co-ordination buying behaviour would get importance as shoppers are matching their
consumption through lots of mix and match,” says Chetan Daruka, Owner, Vintage Earth.

Accessories ranges are increased in order to give more options to the shoppers. Retailers have
understood the importance of accessories for upselling. Merchandise assortment is done in a
way so that a customer can easily pick up matching accessory for a dress that she chooses to
buy. For example, we notice a sweater is displayed with a cap, muffler and a jacket to give the
complete look.

Increase in portfolios & range sizes

Brands are expanding their portfolio range in order to bring maximum products under one roof to
their target group. Youth and kids’ brand Weekender transformed its new identity into a family
brand; Lilliput is catering to all the needs of kids with the launching of Lilliput World; Blues
Clothing Company (BCC), a vertically integrated fashion and retail company, has recently
diversified into interiors and home furnishings. Brands are making attempt to tap wider target
group. Number of SKUs is growing with more sizes available on the shelves.

Fast fashion comes along

Consumers would look at the stores as the happening place where new products are adding after
every next visit. Daruka comments, “We make sure that we change a part of our products every
three days. This is very important to bring freshness to the merchandise in the stores.”

“The mobility of the inventory would bring lots of happenings in the stores. We would need to
change the merchandise every 2-3 months to make the store look fresh”, says Vijay Kapoor,
Founder & MD, Derby.

Entry of more international brands

There’s a high influx of fashion brands in the Indian market. Varieties will dominate the scene with
escalating competition. The customers will experience the new types of products. Be it Murano
glass jewellery of LuckyClover, outdoor sports lifestyle products from Quicksilver and Roxy, the
Indian consumers are going to experience all of them. This will give a competitive push to the
local brands to improvise on product, pricing, packaging etc.

Globalisation would bring the demand of more skilled designers. Experimentation activities would
intensify in the buying space across all categories. Continuous thinking to make better
merchandise would be a challenge and fusing fashion will become the trend setter.

Entry of new brands has also created better and systematic way of working, merchandise and
advertisements. Demand for cleaner cuts, sophisticated merchandise and solution based
products with an extra edge on aesthetics would rise.

Store preparations

Front-end staff would also play imperative role and would be the vital link along consumers,
brands and shopping experience. Kapoor of Derby elaborates, “Good command on language and
physical fitness is what the fashion ahead would demand. Trendy audience would prefer the
stores which have well-groomed staff and can elaborate on the products and its benefits to strike
the minds.”

Building experiential relationship with the clientele is what actually would drive and strengthen the
loyalty, and retailers need to understand the matrix of customer satisfaction and its importance.

The way to increase sales

• Continuous thinking process-VM, store interiors, lighting, etc
• Spacious stores: allow the shoppers to decide on their own
• Need to change merchandise approximated every 2-3 months
• Continuous budgets assigned for R&D, shop interiors, staff grooming

Luxury goes Mainstream

“In the coming times fashion won’t come cheap. It will be priced high in order to stand out of the
crowd. Also, consumer will consume the product even with bit of odd features attached to it,”
views Kapoor. Luxury brands too are sensing the potential of the Indian consumers and joining
the mainstream retail with aggressive expansion plans pan India. They are shedding off their
secluded image with marketing strategies that connect with common people. Non-core products
of a super premium brands at lower ticket sizes are gradually adorning the retail shelves and this
will happen through licensing.

More QSR and organic food

Cash rich, time poor consumers will demand for more quick service restaurants. The segment is
growing at a rate of 40 per cent per annum and there is immense potential of these destinations
in the tier II and III cities too. Also new trends, such as organic food, are emerging in the Indian
market also. The changing lifestyle of middle class is creating a huge demand for better
packaging and quality retail infrastructure. The below traits will be predominant in the market:

• More quick service meals
• Introduction of innovative & new products options- (seasonal products available all
through the year)
• Processed food items, ready to eat products, organic food items
• Energy drinks & better packaging products

In-store experience & special demos

Gourmet retailing has created a new set of customers with its unique quality products. Customers
love shopping there. “Our staff is formally trained in hospitality, donning the role of a friend and
advisor that help our consumers to pick the right products, pair ingredients, etc. Be it in-store
sampling, shelf talkers, on ground food consultants or even social media, GNB identifies and taps
each of these channels to make shopping in our stores a unique experience,” says Mohit Khattar,
MD , Godrej Nature’s Basket.

Entry of Private labels

“The private labels could be the next big thing for retailers that are looking to create a strong food
and beverage category. Being closer to customers, retailers are in the position to utilise their
understanding to work on the consumer insight and provide them with best solutions,” says Lalit
Agarwal, Founder, V Mart.

Changing traits in CDIT market

The consumer durable has shown a noticeable shift in the buying behaviour over the recent
years. The CDIT market (including mobile phones) is INR 65,000 crore and above as per industry
data and is growing at 15-20 per cent, and the same pace is also expected in the next two years.

Domestic consumer sentiments have turned buoyant due to changing demographics and
preference for technologically upgraded products. Overall, the industry grew in double digits in
2010. Industry watchers and analysts note that while the premium category will continue to drive
growth in the urban markets, there is remarkable upward market waiting to explode in semi-urban
and rural India.

Big is Beautiful

The rage this year is ‘Big is beautiful’ for almost all consumer durables and electronics brands,
with LCD, plasma and LED television screens getting bigger; refrigerators increasing in size and
features; and washing machine capacities giving competition for every next model launch.

From offering garish utilitarian devices with zero aesthetics, the sector has moved on to become
high on the purchase wish-list of consumers, waiting to splurge their newly-earned money on
stylish gizmos and gadgets. Sunil Mehta, CEO, Next Retail India says, “Consumers come with
very clear positioning of brand and product in his mind. He is also looking for value-add in terms
of features or related products, and value for money and this aspect is going to increase in the
coming time ahead.”

Widen the product lines

IT in retail

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Similaire à IT in retail

Similaire à IT in retail (20)

Dernier

Dernier (20)

IT in retail