http://msdn.microsoft.com/en-us/library/ms978507.aspx

Business Protocols: Implementing A Customer Complaint System

2 out of 4 rated this helpful - Rate this topic

 

Ulrich Homann
Marc Levy
Microsoft Corporation

Karl-Heinz Sternemann
University of Karlsruhe

October 2004

Summary: Outlines the application of Service Oriented Architecture (SOA) principles to business interactions by applying a communication service pattern using Microsoft BizTalk Server 2004. (19 printed pages)

Download the source code for this article.

Contents

Introduction
Motivating Example: Customer Complaint in the Packaging Industry
Solution Approach
Conclusion
Appendix A: Implementing the Complaint System with BizTalk Server 2004
Appendix B: Naming Conventions for the Solution

Introduction

This article outlines the application of service-oriented architecture (SOA) principles to business interactions using the unique capabilities of Microsoft BizTalk Server 2004. It is a follow on to the article Agreement and Organization: Protocol Architecture for B2B, which laid out the basic principles behind this approach.

The basic idea is to apply a communication service pattern to structure business interactions. This pattern has been widely applied in network communication. Its two core features are a more effective notion of agreement, and the service encapsulation of interactions. Benefits include better-defined responsibilities for all application components involved, easier customization to support interactions with different partners and, in general, more flexibility to meet the inevitable changes in business.

The example used throughout the paper is a customer complaint scenario in a business-to-business (B2B) setting between partners in a formally established, contractually managed and long-term relationship.

A complete code sample using BizTalk Server 2004 is available from the Microsoft Download Center.

Motivating Example: Customer Complaint in the Packaging Industry

The packaging industry is a heterogeneous group of players in multiple industries including: raw material, packaging material, paper mills, corrugated board, customer packaging, and recycling companies. Figure 1 shows a typical corrugated packaging industry supply chain. Supply chain management (SCM) covers all aspects of integrated planning and flows for: goods and services, optimization of associated information, and finances.

Figure 1. Complete view of a typical supply chain in the packaging industry

The focus is on the specific complaint issues in the relationship between the manufacturer of corrugated packaging boards and its customers—the producer of the final user-specific packaging.

Some Numbers

The corrugated packaging industry produces about 129 billion m2 of corrugated boards (USA 41 billion m2, Asia 39 billion m2, Europe 38 billion m2). The capital value of this production represents roughly 115 billion euros. Germany—the home of our subject company—holds about 20 percent of that market, representing about 3,907,000 tons of product output with an approximate value of 20 billion euros produced by 42 companies totaling 115 plants and 18,000 employees.

Typical Complaint Setup and Issues

At a high level, resolving a complaint situation between manufacturer and customer typically involves:

1. Agreement on the complaint.
2. Quality Management (QM) to handle remedial actions.
3. Compensation ( reimbursement, credit and so forth).

Of course, reality is considerably more complex than this simple overview suggests. In this section we describe some of the complicating factors.

For example, due to the wide variety of customers, the corrugated paper industry uses several different processes to implement QM for customer complaints, and this number is growing. Similar situations exist for the other aspects of complaint management, such as financial reconciliation, which uses five different customer-specific processes to implement essentially the same business functionality.

With respect to QM, global standards like ISO9000:2000, its automotive adaptations (TS16949), or high tech manufacturing quality management formalized in Six Sigma, all require documenting and executing repeatable behavior that is expensive to provide. Also, continuous improvement requires an effective feedback loop to correct the faulty process.

Furthermore, QM is integrated into a number of business functions and can vary by customer and by complaint aspect (goods, information, or finance). This requires the supplier to implement any or all of the QM methods prescribed by their various customers and to deeply understand the impact on their business environment.

To get a further sense of the complexity within the QM arena here is an overview of the main ISO9000:2000 process steps:

1. Analyze the complaint.
2. Derive necessary measures to remedy the complaint situation.
3. Prioritize measures based upon the severity of the situation.
4. Communicate to the customer the results of the analysis and the proposed measures.
5. Make a concrete measure and time plan to:
6. Remedy the current complaint situation.
7. Avoid similar complaint situations in the future.
8. Monitor the measures.
9. Communicate to the customer about the measures and their success.

Similar processes exist for other QM methods. These QM processes must be coordinated with the other complaint activities, such as reimbursement, and the resulting complaint processes in turn integrated with the many other types of B2B interactions.

It should now be quite clear that it is a non-trivial challenge to carry out complex single interactions such as the ISO 9000:2000 processes, and to also organize the required web of such interactions in a manageable way.

Scenario: The ProWell Case

Our scenario is based on a European-wide company with total revenues of 400 million. The company, ProWell, is a virtual enterprise comprised of small and medium sized enterprises that pooled their capabilities to more effectively compete against their large vertically-integrated competitors. This scenario comes from a broader project to modify their system platform to better focus on communication and collaboration requirements.

Figure 2 details the customer complaint management process before the project start. The required, available, or desirable business functions and their associated processes were complex and non-transparent. It is important to note that the picture only represents a single customer/supplier integration diagram for complaint management without the required integration into the suppliers' (or the customers') associated business functions and systems.

Figure 2. Single supplier/customer complaint interaction before project

Solution Approach

Reviewing the project represented in Figure 2, it becomes very clear that even this single, relatively simple customer complaint scenario presents a complex picture where one is hard pressed to bring the level of transparency required to identify, isolate, and group the various elements involved and the relationships between them.

To address these issues we apply the architecture principles of network protocols. In particular:

1. We first "divided and conquered" the complex interaction into separate but connected conversations.
2. Each interaction is defined with an agreement (or protocol) consisting of data and communication rules. We encapsulate each conversation as a service to abstract details of interactions irrelevant to other parts of the system.

So, for example, the QM interaction is encapsulated in a service. That service provides a stable interface made available, for instance, to the complaint process. The QM service itself is realized using one of several QM processes with an agreement governing the internal interactions between the QM entities. Since these internal interactions are not visible outside of the stable boundaries of the QM services it is possible to substitute one for the other (for instance, to satisfy the requirement of a particular customer) without impacting the rest of the system. Now, it is also possible to construct a higher level interaction between the complaint functions of the customer and the supplier with these insulated from the details of QM. This is summarized in Figure 3 below.

Figure 3. Applying network protocol architecture to B2B interaction

Structuring the Complaint Management System

In this section we discuss some of the analysis that we conducted to better understand the complaint management system and to eventually structure it by applying network protocol architecture.

The key to addressing these issues lies in a two-step approach described in detail in the latter part of this document:

1. Decomposition—Provide an events-based abstraction capturing the business requirements in their entirety. The business functions driving these events became services.
2. Specification—Within the abstraction identify, capture, and organize the stable elements to satisfy the business case(s). These became the service interfaces. To have interchangeabity in isolated layers without repercussions for the rest of the environment, we ordered capabilities in layers utilizing the discipline and principles of network technologies (TCP/IP, for example).

Classifying events

We first set out to classify the various events that make-up the complex interaction diagram of Figure 2. It quickly became clear that some "business critical" events, such as complaint acceptance, are significant milestones in the complaint interaction. Other supporting events, such as receiving a request for additional information to clarify the complaint, corresponded to supporting activities.

Table 1. Events and classifications

Event	Type	Related Events
Initial complaint	Critical	n/a
Complaint acknowledgement (ACK)	Supporting	Initial complaint
Reminder	Supporting	Initial complaint
Request for additional information	Supporting	Initial complaint
Information fulfillment	Supporting	Initial complaint
Acceptance or Refusal message	Critical	Initial complaint
Cancellation of complaint	Critical	Initial complaint
QM measures information	Critical	Acceptance of complaint
QM measures—final results	Critical	Acceptance of complaint
Credit note request	Critical	Acceptance of complaint
Credit note acknowledgement	Supporting	Credit note request
Credit note proposal	Supporting	Credit note request
Credit note confirmation	Critical	Credit note request

Further analysis based on the correlation between events revealed that the supporting events formed three distinct groups:

• Initial processing
• QM issues
• Credit

Figure 4 shows this high-level event taxonomy.

Figure 4. Taxonomy of complaint events

Lifecycles

We next partitioned the events into four different sequences each corresponding to a group in the event taxonomy. What emerged were four distinct but related lifecycles (see Figure 5):

1. An overall lifecycle containing the business critical events.
2. A lifecycle associated with the initial processing of the complaint that starts with the initial complaint and finishes when it is either accepted or rejected.
3. A lifecycle having to do with the quality management aspects of the complaint. This lifecycle begins when and if the complaint is accepted and lasts until the supplier communicates quality improvement measures to the customer.
4. A lifecycle over the events related to credit. This lifecycle also starts when and if the complaint is accepted and ends when the supplier issues credit to the customer or rejects the complaint.

Figure 5. Complaint lifecycles

Services

Decomposing the complex interaction diagram into separate lifecycles let us determine the right encapsulation boundaries to factor the system into several services, each responsible for managing a lifecycle within the complaint interaction. Figure 6 shows the high-level view of the service map for the customer complaint scenario:

Figure 6. A high-level view of the customer complaint scenario

We organized the customer complaint system as a service providing complaint resolution between customer and supplier. The customer complaint service is itself a composite of services with overall complaint lifecycle functions managing the complaint through the initial processing, quality management, and financial compensation services. This achieves a better factorization of interactions between the system's components. In this example, the Quality Management service now encapsulates all of the detailed QM interactions and allows them to vary without affecting the rest of the system. For instance you could seamlessly replace an ISO process with a Six Sigma one.

You can also readily recognize in this structure the traditional organization of network communication systems where very complicated interactions are managed as layered services. Analogous to TCP providing reliable stream-based communication to HTTP, the QM service provides quality management to the complaint service without revealing, at that scope, messy and irrelevant details.

It is also instructive to contrast this view on the complaint system with the one in Figure 2 that presented many interactions and actors all at the same level. Here we have introduced the complaint service and its component services that simplify the system by encapsulating much of the interaction complexity.

The Complaint Establishment Service: Interface and Protocol

We now turn to a more detailed description of the complaint establishment service interface and protocol.

The service behaves as a black box exposing messages and the participants' roles through a service interface (see Figure 7).

Figure 7. Complaint establishment service interface (service as a black box)

The protocol refers to the particulars of the interactions between the various agents that make up the service for a particular implementation (see Figure 8). Ideally, different implementation choices and protocols can provide the same service interface—the activity inside the service is opaque to the user. That is, the service could use different ways of establishing the complaint (such as using variations for different partners) but the complaint establishment service interface would remain unchanged.

Figure 8. Complaint establishment protocol

Describing the service interface (service as a black box)

The service interface consists of the roles involved (Table 2), the set of messages (or vocabulary) supported by the service, and the set of rules and constraints that define the service behavior—in essence sequencing and timeliness (Figure 9). For brevity we give an informal description of these aspects of the service but it is possible to provide a formal description using emerging standards such as BPEL4WS.

Table 2. Complaint establishment service interface—roles

Role	Description
Complaint establishment service	The service providing the initial processing of the complaint that eventually results in the complaint being either accepted or rejected.
Complaint initiator	The party submitting the complaint.
Complaint responder	The party receiving the complaint.

   

Figure 9. Complaint establishment service interface—messages and behavior (simplified)

Describing the protocol

In our particular case (see Figure 8), we deployed agents at both the customer (Complaint Establishment (C)) and the supplier (Complaint Establishment (S)) that together form the complaint establishment service. The protocol connecting them can vary depending on the customer and compliance requirements.

Here again we need to describe the roles (Table 3), the messages, and behavior (Figure 10) to define the protocol.

Table 3. Complaint establishment protocol—roles

Role	Description
Complaint Establishment Initiator	The agent that establishes the complaint for the complaint initiator.
Complaint Establishment Responder	The agent that establishes the complaint for the complaint responder.

   

Figure 10. Complaint establishment protocol—messages and behavior (simplified)

To be emphatic, Figure 11 shows the relationship between service, service interface, and protocol.

Figure 11. Relationship between complaint establishment service and protocol

Using the complaint establishment service

We are now in position to better understand the relationship between the functions managing the overall complaint lifecycle and the complaint establishment service.

The customer receiving a delivery of faulty product initiates a new complaint by sending an initial complaint message to ProWell, the corrugated packaging supplier. Figure 10 shows this interaction in the dotted line connecting the complaint management function at the customer (C) with the complaint management function at ProWell (S). While it seems that the complaint management functions at either location are interacting directly, under the hood, the complaint management function at the customer side sends the complaint message to the complaint establishment service and the complaint management function at ProWell receives the complaint message from the complaint establishment service. The complaint management functions are in fact conducting a virtual interaction mediated by the complaint establishment service. Figure 12 summarizes this interaction:

Figure 12. Using the complaint establishment service

Note that since the complaint management functions interact with the complaint establishment service at the interface level they are not exposed to the details of the complaint establishment protocol. That is, they do not need to deal with supporting messages like dunning or requests for additional information. Supporting message interactions are confined within the boundaries of the service mediating the interaction of the higher-level functions. This means that the services themselves are transparent at the interface level—different customers may be handled by different services depending, for example, on compliance regulations.

Conclusion

We used the following approach to design the complaint system:

1. Decomposition into services:
   • We analyzed the events processed in the course of the interaction, classifying them with respect to business importance (critical, supporting) and correlation criteria (related events). This analysis yielded several groups of events.
   • We constructed lifecycles of these events using the interaction sequencing information and the event groupings. This lead to component services each responsible for the processing associated with each lifecycle.
2. Individual service specification:
   • Based on the common elements, we specified the service interface (that is treating the service as a black box) describing roles, messages, and behavior offered by the service. This way the user is unaware of which of several possible services is fulfilling a particular function.

We specified protocols describing the distributed agents implementing the service and the interaction between them. This includes a description of roles, messages, and communication rules.

Appendix A: Implementing the Complaint System with BizTalk Server 2004

Accompanying Sample

The following section describes a BizTalk server sample that illustrates the concepts discussed in the paper. The sample is available for download from the Microsoft Download Center. We describe the technical requirements and how those map to the functionality offered by BizTalk server. We also discuss the logical architecture of a business protocol complaint system designed for BizTalk Server and the various BizTalk artifacts that make up the solution.

Note   The sample is meant for illustrative purposes only. It focuses primarily on the protocol architecture of the complaint system as discussed in the paper. It does not cover other aspects such as error handling, partner management, realistic message formats, more robust protocols, and so forth.

Logical Architecture

In order to implement the kind of system that we have been describing we specifically need support for:

1. Managing many services.
2. Message-based interaction between services.
3. A configurable and dynamic binding model so that depending on different factors, messages are routed to the appropriate service (specifically to support the per-partner customization of interactions such as QM).
4. Easy definition of protocols and the runtime environment required to support them.
5. Support for standards where they exist.
6. A partner management system.

This, of course, is in addition to the many other functions required to round out an application environment. Because of our focus on B2B interaction we should also mention functions required to support aspects that we have omitted for brevity, such as enterprise application integration (EAI) to integrate the complaint system with line-of-business (LOB) applications. BizTalk 2004 offers these functions. Most germane to our concern are:

• An environment to manage multiple services and their composition around a message-based publish/subscribe system.
• A standards-based orchestration feature that makes it easier to define and run services that implement long-running message-based agreements.
• A partner management subsystem.
• Rich EAI functionality.
• Many supporting functions such as Business Activity Monitoring to report on the system activities at both technical and business levels.

Example: implementing the customer's complaint establishment service

In this section we give an overview of the BizTalk 2004 implementation of the complaint establishment service on the customer side.

That service is implemented as a BizTalk orchestration. The role of that orchestration is:

• To implement the complaint establishment protocol that it carries out with its peer at the supplier.
• To provide the complaint establishment service interface functionality (for use by the complaint management service).
• To integrate the complaint establishment with the relevant LOB functions. For brevity we omitted this element in our discussion but obviously a system deployed in a real-world business environment needs to account for this requirement.

Figure 13 summarizes the structure.

Figure 13. Complaint establishment orchestration structure

The orchestration's interfaces are partitioned into three groups of ports: the service interface, the protocol interface, and the line-of-business (LOB) interface. For simplification we omitted a discussion of LOB integration but a complete implementation has to include it. Each port corresponds to one of the major types of interaction that the orchestration participates in. In addition to providing a sensible organization, this also facilitates binding these interfaces with BizTalk partner management.

Overall structure of the customer's complaint system

All of the other services are implemented in the way we outlined for the complaint establishment. They are connected together to assemble the entire system using the BizTalk Server engine. There are of course many details that we will not cover here, but we briefly note the use of EAI and B2B BizTalk features to support all of the many low-level details that need to be accounted for. Figure 14 shows the resulting system. Note that this could also be the structure of the complaint system at the supplier (and that is the way it is in the accompanying sample) but this is not required. All that the supplier has to do is obey the agreements that govern the various interactions!

Figure 14. Customer's complaint system

Physical Architecture: Mapping to Implementation

The solution in this specific customer case identified four subsystems:

• Application—Represents systems external to the modeled business interaction between partners, enterprise resource planning (ERP) systems, databases, mainframe applications, and so on.
• Commitment—Encapsulates the services that process the business critical events—events that commit both companies to a certain course of action. For example, the acceptance of a complaint by the supplier, leads to quality management and financial repercussions. Without this commitment, no such repercussions will happen. This subsystem includes the overall lifecycle complaint management services.
• Clerk—Encapsulates the services that handle details or optional steps available between partners to move towards a commitment. In the case of the complaint management interaction, all interactions—like various escalation levels or requests for additional information (photos of the damaged goods, for example)—that enable the buyer or the seller to commit or reject the complaint are bundled into this layer. This layer is generally where variations between process types (such as Six Sigma or ISO9000:2000) or partner agreements occur. This subsystem includes the complaint establishment, quality management, and credit services.
• Supporting Service/Utility—Encapsulates supporting business functions and components. An example commonly required in business interactions is a time control function based on a business calendar. This is used to control time-sensitive operations taking into account work days, exempt holidays, weekends and days where the factory or company might be closed and so forth.

Appendix B: Naming Conventions for the Solution

The BizTalk Server artifacts are organized as outlined in the overview of the layered solution (Figure 15). In order to keep a clear overview of the various layers and associations, the implementation uses a naming convention scheme.

Orchestrations

The file names of the orchestrations (.odx) have a prefix that determines the association to a specific layer:

1. CL represents the clerk layer.
2. UL represents the utility layer;
3. SL represents the services layer.
4. Since the commitment layer in the example contains only one orchestration per partner, we decided against a prefix; the orchestration name is the same as the layer name. For example, CoL.odx.
5. As the implementation is an illustrative sample focusing on the protocol architecture, the application layer is not implemented.

The final file name of the orchestration follows the general outline <shortcut of the solution layer>_XXXX.odx. Orchestrations that only receive and route messages have a postfix indicating their function. For example CL_XXRec.odx for the receiving function as part of the clerk layer.

Figure 15. Orchestration file names of the responders

Drop Folders

The example uses drop folders to simulate receiving and sending of messages between partners. The drop folders for initiator and responder follow the format <abbreviated name for the message>_From_<abbreviated name of the source orchestration>_To_<abbreviated name of the target orchestration>.For example, the folder <CC_From_CoL_To_CCP> represents the folder that sends the customer complaints from the commitment layer (CoL.odx).

The drop folders simulating the partner-to-partner communication use the message name For example, CC is a shortcut for the customer complaint message and CCA represents the customer complaint acceptance message.

Figure 16. Drop folders of the initiator

Orchestration Ports

The names of the send ports follow the format "Send<abbreviation of the message name>To<Target>_Port". <Target> either represents the name of an orchestration or "partner" (if the target of the message is the business partner). For example, port "SendCCAToCoL_Port" sends the customer complaint accept message to the commitment layer. The port "SendCCCToPartner_Port" sends the customer complaint cancellation to the partner.

Figure 17. Send port example

The receive ports replace the "Send<…>To<Target>_Port" with "Receive<…>From<Source>_Port". Otherwise, it is a complete mirror of the send port conventions.

Orchestrations Shapes

Orchestration shapes follow the same formula as the orchestration ports; however, the source or target is the appropriate layer of the solution. Receive shapes that activate an orchestration are marked with "Activate," replacing the "Receive" at the beginning of the label.

Send Ports, Receive Ports and Receive Locations

The send port structure is <name of the solution><business partner name>_<message name>_From_<source>_To_<target>. <Solution name> is "complaint"; <business partner name> is either "initiator" or "responder"; <source> is the orchestration that sends the <message name>. <Target> is either an orchestration or a partner receiving said message.

Figure 18. Send ports

The receive ports and their associated receive locations follow the same structure. However, the <source> can be either an orchestration or a partner, and <target> is an orchestration.

Figure 19. Receive ports and locations

 

About the authors

For the past five years Marc Levy has been working on business process automation. As an architect on the BizTalk team, he was one of the principals for the orchestration features. Before BizTalk, Marc was responsible for COM+ security (contributing author to "Designing Secure Web-Based Applications for Microsoft Windows 2000"). Marc's passion with distributed systems is the unifying theme of this work started in the early nineties at the Open Software Foundation (OSF) with the Distributed Computing Environment (DCE).

As a solutions architect, Ulrich Homann is responsible for the design and architecture of Web services and integration of the .NET platform with providers and consumers of business applications. Previously, Uli was program manager in the Enterprise Program Management team and responsible for the development relationship with key partners, mainly SAP AG. Uli also served as part of Microsoft Consulting Services, where he was responsible for several key distributed database application projects in Germany. Prior to joining Microsoft in 1991, Uli worked for several small consulting companies, where he designed and developed distributed systems.