Business Process Modeling Using ebxml: Case Study

Transcription

1 Student Project Business Process Modeling Using ebxml: Case Study Aivaras Pigaga Matr. Nr.: Information and Media Technologies Technical University of Hamburg-Harburg Under the supervision of Prof. Dr. Joachim W. Schmidt Patrick Hupe Hamburg, May 28, 2003

2

3 Table of Content 1. Introduction Objectives Structure of the Work ebxml Concepts and Technologies Why ebxml? Electronic Business Collaboration ebxml Concepts The ebxml Business Process Model The ebxml Business Process Definition ebxml Business Process Specification Schema (BPSS) ebxml Core Components Trading Partner Profiles and Agreements The Collaboration Protocol Profile (CPP) The Collaboration Protocol Agreement (CPA) Registries and Repositories Messaging Service Modeling Requirements and Analysis Processes UML-Based Analysis Putting it All Together into a Meta-Model How Does It All Work Together? Summary of the Chapter A Model to Negotiate, Evaluate, and Execute Electronic Business Processes Four-Layer Electronic Business Process Model Benefit Layer Business Process Negotiation Layer Business Process Layer Message Exchange Layer What Does ebxml Provide? Summary of the Chapter Case Study Initial Case Study Analysis E-Procurement Business Process Description Requesting the Goods Choosing the Supplier Finding Potential Suppliers Negotiating Business Process Definitions Choosing the Business Process Definitions

4 Negotiating Terms and Conditions Choosing the Supplier Purchasing the Goods E-Procurement Business Process Modeling in ebxml Requesting the Goods Finding Potential Suppliers Negotiating Business Process Definitions Negotiating Terms and Conditions Choosing the Supplier Purchasing the Goods Limitations of ebxml Summary of the Chapter Conclusions Summary Outlook

5 Table Of Appendices Appendix A. Generic BPSS UML Class Diagram Appendix B. E-Procurement Business Process Activity Diagrams References

6 6

7 Table of Figures Figure 2.1. Electronic business collaboration [Chiu02] Figure 2.2. ebxml architecture is made up of components [Chiu02] Figure 2.3. Business process is defined as collaborations between parties, which are the groupings of business transactions [Chiu02] Figure 2.4. Basic semantics of the business collaboration [BPSS01] Figure 2.5. Document flows and business signals between two parties [BPSS01] Figure 2.6. Choreography for creating a purchase order [Chiu02] Figure 2.7. Relating core components, and context [CCOv01] Figure 2.8. Business process mapping to core components [Chiu02] Figure 2.9. Overview of collaboration protocol agreement [CPPA02] Figure ebxml message structure [MeSe02] Figure ebxml Business Process Meta-Model [BPOv01] Figure Functional view on ebxml architecture [KoWe02] Figure 3.1. Four-layer electronic business process model Figure 3.2. How does ebxml meet the electronic business requirements? Figure 4.1. E-procurement of indirect materials business process Figure 4.2. Exchange of business process definitions during the negotiation Figure 4.3. Potential suppliers spanning state maintains parameters and intermediate results of a term negotiation Figure A.1. UML class diagram of generic ebxml BPSS [BPSS01] Figure B.1. Overall (high-level) e-procurement process definition Figure B.2. Choosing the supplier Figure B.3. Finding potential suppliers for a given product Figure B.4. Negotiating business process definitions with each potential supplier Figure B.5. Negotiating terms and conditions of a business transaction with each potential supplier Figure B.6. Concurrent negotiation on business transaction terms and conditions Figure B.7. Reverse auction for business transaction terms and conditions Figure B.8. Purchasing the goods requested by the buyer at the chosen supplier

8 8

9 1. Introduction The Internet and the World Wide Web opens many new opportunities for doing business. Business partners in electronic environment share information to improve service and product quality, by improving the business processes inside the companies and outside the companies. With the new opportunities, new difficulties of the new business environment come along. Business conditions change very quickly and require fast response from the companies to adapt to the new conditions. Companies discover that their information systems are intangible assets and are of a strategic importance for maintaining competitive advantages of the companies, since they enable companies to collect and store their knowledge, to manipulate their operational data fast, and to make strategic decisions faster. According to the Boston Consulting Group (BCG) [BCGR00], the electronic procurement between businesses will grow from $1.2 trillion in the year 2000 to $4.8 trillion in From the situation we are witnessing now, in 2003, the weaknesses of economies worldwide and the collapses of many dot-com businesses, we could say that probably we won t reach the value estimated by BCG. However, we suppose everyone would agree that the scale is definitely growing. According to Forrester Research [Forrest03], B2B e-commerce in USA alone in 2004, will reach the value of $2.7 trillion [KoWe02]. The surveys show that the size of the B2B e-commerce market is large and the penetration of it is still rather low, but it is growing. The recognition of electronic data interchange (EDI) [Jilo98] over private networks and its extensions to the Internet proves that, too. For example, Compaq Computers runs weekly an average of $50 million worth business through its combined EDI and Internet systems. [KoWe02] Since the quantity of customers is generally increasing and competition is rather harsh, companies are forced to implement new policies, which significantly increase the volume of business transactions: - A company cannot rely on their own capacity, because of the increasing demand from the customers. It can lower the costs by outsourcing the processes to its suppliers. Moreover, the company has to know many suppliers of the same components to maintain lower prices of the components. As the result business transactions volume is increased 9

10 significantly. For example, a car manufacturer has thousands of secondtier suppliers of the parts and has to track them to enforce the quality control, at the same time keeping inventory levels to the minimum. - PC manufacturers distribute products through thousands of resellers over the web, and the number of resellers is growing. - A web-based travel service aggregates offerings from hundreds or thousands of travel packages suppliers. And we can find many more examples of such an increasing scale of business transactions in business environment of today. The solutions available till now are very expensive and complex. A lot of time, money and human resources are needed to integrate EDI solutions into overall business operations of a company. Furthermore, if a company wants to be able to interchange business data electronically with its business partners, the company and its business partners have to define interchange interfaces between systems. This is very costly and only provides very restricted possibilities to do business electronically. As a result, not only the small and medium businesses have limited chances of implementing a sound EDI solution, but also large businesses have a lot of problems doing it. One can easily see that there is a common need of a technological platform, which would enable easy-to-implement and to operate low-cost B2B collaborations. One of the possibilities could be the ebxml platform. The ebxml concepts and technologies are meeting many of the new requirements that are coming along the changes in the business environment. It supports the automation of business processes and electronic business between industries at a lower cost. The ebxml concepts and technologies look very promising, but we have to investigate to which extent it can be useful in the real business environment. Therefore we will look at the ebxml concepts and technologies and conduct an analysis of a case study in this work Objectives In this work we shall study ebxml concepts and technologies in detail. We shall emphasize on concepts and technologies, which are useful for modeling business processes. We shall establish a general model to negotiate, evaluate, and execute electronic business processes and evaluate ebxml concepts and technologies against the established model. 10

11 We shall also analyze a business process case study. We shall choose a business process scenario and analyze and describe the modeling of the chosen business process scenario using ebxml. During the evaluation against the established electronic business process model and business process scenario, the limitations of ebxml concepts and technologies shall be identified and pointed out. The work results shall be summarized and the outlook on possible further development of ebxml and possible further steps in this work shall be discussed Structure of the Work In chapter 2 ebxml concepts and technologies, namely its business process model, core components, the collaboration protocol profile and agreement, registry and repository, and messaging service, will be presented. Those concepts and technologies, which relate to business process modeling, will be emphasized. This chapter will also describe the business process meta-model and how all ebxml concepts and technologies work together. In chapter 3 a general model to negotiate, evaluate, and execute electronic business processes will be established and ebxml concepts and technologies will be evaluated against the established four-layer electronic business process model. In Chapter 4 the analysis of a case study will be presented. The e-procurement business process scenario will be analyzed in detail. The modeling of the e- procurement business process using ebxml concepts and technologies will be discussed. The limitations of ebxml concepts and technologies will then be pointed out and presented. Chapter 5 will give the summary of the whole work. It also gives the outlook on the development possibilities of ebxml concepts and technologies and possible further steps in this work. 11

12 12

13 2. ebxml Concepts and Technologies Business Process Modeling Using ebxml: Case Study In this chapter we will discuss ebxml concepts and technologies. We will explain why ebxml concepts and technologies are promising. We will describe electronic business collaboration in general and how ebxml fits the idea of electronic business collaboration with its specifications, by describing ebxml specifications in detail. Finally we will present an analysis process model for business processes as it is specified by ebxml and we will shortly introduce how ebxml technological platform works and is used by the trading partners Why ebxml? The ebxml concepts and technologies, which will be described in the following sections, are meeting many of new requirements that are coming along the changes in the business environment: - ebxml tends to organize and improve the business processes, which are usually the bottleneck slowing down the business. - It addresses the issue of automating the processes between the trading partners, which can significantly increase the speed of doing business and make the companies more dynamically adapt to changing environments. - It automates some steps of generating trading partner agreements, which is an incentive for the companies to be engaged in new and innovative business relationships. - Since the needed business objects of different industries, such as business processes, core components, and profiles, are stored in public repositories, it makes it easier to conduct businesses between the partners from different industries. Moreover, the cost of doing electronic business is significantly reduced, since the companies do not have to run expensive back-end systems. - Small and medium companies can easily implement and use ebxml, since most of the costly work are done by industry consortiums, e.g. standardization of business processes, and standards do not need to be implemented while industry/domain-specific solutions are provided as offthe-shelf applications. There are not to many applications of the ebxml model to provide the discussed benefits for the business environment. But the interest from the industry side is growing and there is an initiative and many beta-level applications of ebxml 13

14 currently available, which partially embody ebxml solutions. Some of them as an example are given here: - The consortium called OASIS [OASIS03] is the most accepted, which has many initiatives working towards the extension of ebxml specifications. It has already developed open standards for ebxml registry and messaging, and also recently it has submitted collaboration protocol profile and agreement specification to be voted for a standard, and it continues working on ebxml. OASIS also provides some testing-ready implementations of ebxml specifications. - GoXML [Gtech03]. XML Global Technologies provides a Business Integration Framework with plug-n-play components that include data transformation, business process integration, metadata management, ebxml messaging, and Web services interoperability 2.2. Electronic Business Collaboration Electronic business collaboration at a high level of abstraction can be seen as an order of steps as it is depicted in the figure 2.1. These steps fully describe the business collaboration process. Figure 2.1. Electronic business collaboration [Chiu02] Now we will describe these steps. The following description is rather high-level. 1. Process definition. To be able to run any e-business collaboration, first, one needs to define the business process itself. In this stage one needs to define the steps of the process, the deliverables of each step, and the order of the steps of the process. All the 14

15 three issues have to be defined in a way, that it would enable any other party in the business environment to read and interpret them correctly, semantics and syntax must be standardized. 2. Finding a partner. After the process is defined, one has to find the partner in the business environment during the partner discovery stage. The partner has to fit one s requirements in terms of supported business processes and technical details, e.g. communication protocol, etc., to establish a business relationship. If the requirements fit with some other party, then one can start the negotiation on the final set of the requirements for both parties, which would finally become a trading partners agreement after the completion of the partner sign-up stage. The process of finding a partner can be run repetitively if one needs to establish multiple business relationships. 3. Running a particular process. Once the agreement has been reached, the business process can be executed repetitively using the agreement reached in the previous step, but with different terms of business transaction, e.g. different amounts of goods, etc. The terms needed for the process execution are provided during the electronic plug-in stage. After the terms are provided, one can execute this particular process during the process execution stage. All the execution process can be monitored and documented for further analysis, which is done in a process management stage. 4. Process evolution. Upon the information collected in the process management stage during and after every process instance execution, the company is able to adjust the process for the better performance or to avoid some faulty cases. Mentioned adjustments can be done in the process evolution stage, which is again connected with the process definition stage, since the process has to be redefined and the agreement with the partner has to be newly arranged. The process evolution stage only needs to be performed if any relevant problem, such as a bottleneck in some process step, occurred during the process execution. One can see that an electronic business collaboration consist of several loops, such as finding a partner and running a particular process, which can be run continuously after the process definition is made once. Figure 2.2 depicts how ebxml concepts fit the electronic business collaboration model. 15

16 Figure 2.2. ebxml architecture is made up of components [Chiu02] The ebxml technical architecture consists of multiple concepts, which interact with each other. In the section 2.3 we will discuss these in more detail: business process model, core components, messaging services, registry and repository, and collaboration protocol profiles and agreements ebxml Concepts The ebxml Business Process Model As we have seen in figure 2.2, the business process model is one of two essential parts for defining a business process, which can be later used for running actual business transactions. Let us first look at the structure of the business processes in ebxml, then we will discuss the essential parts in more detail, and finally we will introduce the methodology for mapping real business processes to ebxml business processes The ebxml Business Process Definition For defining a business process, ebxml is using two fundamental concepts of collaboration and transaction. The structure of a business process is depicted in figure

17 The collaboration concept here does not match with the one we have been using so far. The collaboration in ebxml business model is defined as an interchange between the trading partners, e.g. the negotiation process between customer and supplier on a purchase of a widget [Chiu02]. A specific collaboration between parties by definition can include one or more business transactions. The transaction here is not a business trading exchange either, it is a technical definition: a transaction is a basic action, or a single information exchange step, between the trading partners. Figure 2.3. Business process is defined as collaborations between parties, which are the groupings of business transactions [Chiu02] If we analyze our example of negotiation on a purchase of a widget, some of the transactions could be defined as follows: - The customer inquires about the details of the product, availability, shipping terms, etc. - The supplier provides the customer with the information required. - The customer accepts the terms or asks for better terms repetitively until the agreement is reached. - The customer submits the purchase order to the supplier on the negotiated details and terms. Within the business transaction trading partners perform a certain role: buyer or seller. Furthermore the transaction can also include document flows, like request document flow for sending a purchase order, and business signals, like receipt acknowledgement signal to confirm the receipt of the purchase request. Looking back to our example, the last transaction has a purchase order sent from the customer to the supplier (document flow) and the receipt acknowledgement sent from supplier to the customer (business signal). When all the transactions are finally defined, the sequence in which they should execute is also defined. It is called choreography. Figure 2.4 depicts the collaboration graphically. 17

18 Finally, a business process instance is created and executed by a software application. The software is referred to as the business service interface (BSI). Figure 2.4. Basic semantics of the business collaboration [BPSS01] ebxml Business Process Specification Schema (BPSS) We know that all XML documents are governed by rules in a DTD or XML schema [XMLS03], which define the naming conventions for elements, attributes, and also the occurrence of elements in relation to other elements. For this purpose, ebxml is using the business process specification schema (BPSS) [BPSS01], which is either defined as a DTD or XML schema. It defines ebxml semantics, which are by definition semantic rules, elements, and properties necessary for collaborations between partners. Within the rules defined by the BPSS, one has a flexibility to specify as many combinations of collaborations and transactions as needed. Business service interface (BSI) uses the specific BPSS as a configuration file to configure the business process-related parameters. (See appendix A for generic ebxml BPSS as a UML class diagram) Collaborations Any interchange between parties using ebxml semantics, which are defined by BPSS, is by definition an ebxml business collaboration. As we already know, the business collaboration includes a set of transactions. There are two categories of 18

19 business collaborations depending on the number of parties involved: binary collaborations and multiparty collaborations. A binary collaboration is the interchange between two parties using ebxml semantics. The parties are assigned so-called authorized roles, since they are authorized to participate in the collaboration. One is always in the initiating role, the other is always in the responding role. The roles are assigned for each activity. Since many data interchanges involve more than one transaction, two parties can be engaged in multiple transactions within collaboration. Every transaction has the sender (from) and the recipient (to) as the authorized roles. One can group transactions into collaborations depending on preferences. There is a possibility to incorporate all of the transactions in a given collaboration or to break them down into groups and to incorporate them into different collaborations over time. A multiparty collaboration is the interchange between multiple parties using ebxml semantics. It can be seen as a combination of several binary collaborations. Multiparty collaboration occurs between three and more parties. Each of the collaboration occurring between any of two parties will be defined as a binary collaboration. The sum of all binary collaborations defined will result in the multiparty collaboration. Based on that, we specify a multiparty collaboration by defining all binary collaborations in which its business partners play different roles. So one business partner can play the initiating role in one of the collaborations and the responding role in the other. Transactions As we already know, the transaction by definition is a single logical step, an atomic unit of work, in an information interchange between two business partners. While collaboration can be understood as conversation or session between trading partners, the transaction is analogous to a single task in a conversation. As we already know there are two roles: sender (from) and receiver (to). A transaction will always result in one of the states: success or failure. If a transaction ends with success, then it might become a legally binding part of the contract, if it is stated so in the transaction definition. If the transaction fails, then the process returns to the state which it had before the transaction was executed. 19

20 The transactions in ebxml are of a high importance, since they support failure recovery. If one important document is lost during the collaboration, the collaboration waits until the document is sent again. Business Document Flows Business document flow is defined as the exchange of business documents between parties within a transaction in ebxml. Optional business signals can be used in the transactions to communicate acknowledgements. Business document flows are depicted in figure 2.5. A request document contained by a document envelope is associated with a requesting activity, e.g. purchase order document. A response document contained by a document envelope is associated with a responding activity, e.g. purchase order acknowledgement document. The requesting activity is an activity sending the request documents. The responding activity is an activity sending response documents. A transaction, in which all these document flows are defined, can be set for one-way notification: the responding activity responds only using business signals. A transaction can be also set for two-way conversation: the responding activity responds not only using business signals, but also with response document flow. Figure 2.5. Document flows and business signals between two parties [BPSS01] So transactions can also be seen as a logical unit of business documents exchanged to ensure the atomicity of a business transaction. 20

21 During a transaction activity, the binary collaboration roles are assigned to the parties, e.g. the buyer and seller roles are participating in document flows between the requesting and responding activities. The buyer can define many parameters of the transaction, e.g. if the response document will be sent to complete the transaction or to notify on a price change or not. Depending on these parameters, more or fewer document exchanges may be needed to complete the transaction. The seller can use business signals to acknowledge the receipt or acceptance of the documents. Business signals are low-level documents that signal the current state of the transaction. Choreography Business transaction choreography is a predetermined sequence of execution of transactions within a binary collaboration. It ensures that the collaboration is going in the predetermined sequence. The choreography is specified in terms of business process states, business transactions (activities), and transitions between the states and activities. Defined in [Chiu02], there are a number of predefined states for coordinating the execution sequence of business transactions (activities) in a data interchange: - Start the starting state for a binary collaboration. There must be at least one starting activity. If none is defined, then all the activities involved in the data interchange are considered allowable entry points. - Success a successful completion of a binary collaboration as a transition from an activity. - Failure an unsuccessful completion of a binary collaboration as a transition from an activity. - Fork a state with one inbound transition and multiple outbound transitions. All activities pointed to by outbound transitions are assumed being executed concurrently. - Join a state where an activity is waiting for one or more activities to be completed. Join is the point where forked activities join up again. Transitions allow moving from a business process state to a transaction and vice versa. Transitions can be associated with guards. Guards can define many different conditions, based on which a transition should be taken or not. So the choreography defines different paths in a process execution. 21

22 Let us look at the example of choreography for creating a purchase order (see figure 2.6). The create purchase order activity is the entry and the completion point, since the start state points this activity and the end states are pointed by the outbound transitions of this activity. The outcome of the process depends on a guard, which checks if the order has not been rejected. If the order has not been rejected in the process purchase order activity, i.e., if the purchase acknowledgement has been received, the outcome is success and the purchase order will be fulfilled. Else the outcome is failure and the purchase order will not be fulfilled. In the case of failure, the process is run from the start state again. Figure 2.6. Choreography for creating a purchase order [Chiu02] ebxml Core Components A core component is a basic, reusable building block that contains information representing a business concept [CCOv01]. Using core components, we ensure that business vocabulary is common. A core component in ebxml can be used as a building block to create more complex objects. Some examples are: Sales Tax, Total Amount. Core components can be used in many different domains and business processes. In ebxml, core components are building blocks for business process semantics, i.e., business vocabulary. They are reused many times in different business contexts. With this, we enable different businesses to execute business transactions. 22

23 From a very technical point of view, core components are represented as XML elements. Core components are grouped together into documents/messages, which follow the rules of syntax provided by a DTD for each core component. A domain component is specific to a certain area of industry and is used only in that industry. It may be reused in other domains, if it is found appropriate and fitting the industry. Then it becomes a core component. All the core components are context-free. Context is the information describing the specific business environment in which the core component must be used. We can use generic context-free core components and make changes according to the specific business context to adapt to our specific business process at run time. A business information entity (BIE) is a core component defined with a specific business context of a specific business environment. BIE can be used only in the specific business environment, which is defined by the context. For example, if the core component is Total Amount, then one of the possible BIE could be Total Amount Using USD as a Currency. Context, in this case would be - the seller and the buyer are from the U.S. An aggregated component is a component made up from several components. It can aggregate core, domain, or aggregated components. It can be generic or used in a specific industry. It can be reused in a specific business environment by adding a set of specific business context information. An aggregated core component (ACC) is a set of information representing a business concept, e.g. purchase order. An aggregated business information entity (ABIE) is an aggregated core component used in a specific business context. Figure 2.7. Relating core components, and context [CCOv01] 23

24 Figure 2.7 shows the relationship between core component, context, and aggregated components. A business document is in a certain context. To build the document we need certain core components. Several core components can be aggregated into one aggregated component, to which the certain context based on the context of the document is applied. The same core component can define a partner role in many different business contexts. Still all roles defined in different business contexts will maintain a common identifier of the core component by which they were defined. For example, the same core component identifier, e.g. customer, would apply to different persons, e.g. airline passenger, buyer of the book, and guest at the hotel. So in each of the mentioned cases the common identifier is related to its specific industry terminology. Context As we already discussed, context modifies the usage and behavior of the core component. The same core component can be used in multiple business processes. However, the additional context information fulfills the unique requirements of the specific business process. The context allows one or more objects to be associated with any business message or component. There are two types of context from the point of view of an object described in a context: process context type describing process and property context type describing process-independent context. Categorization is a powerful tool to specify the context. The categories are: business process, geopolitical, product, partner and supporting role, official constraints, industry, and system capabilities. We will explain the most complicated context categories. Business process contexts are only of process context type. Business process context specifies how the business process will be conducted. To make a business process interoperable over industries the Catalog of Common Business Processes [CCBP01] is used as a reference. Product contexts provide the information on what goods and services are concerned in the collaboration. Product contexts specify the values for both process-type and 24

25 property-type product contexts. The Core Components Technical Specification recommends the following sources for product classifications: - United Nations Standard Product and Service Code (UNSPSC) [UNSPSC03] - Standard International Trade Classification (SITC) Rev.3 [SITCr3] - The Harmonized Commodity Description and Coding System (HS) [HCDCS03] Partner and supporting role contexts are only of a property-type, since the role context itself identifies the business process. Role context identifies the business partners according to their participation in a business process. So it answers the question: what are the roles to be played by the trading partners in the business process? Official constraints are of both property and process types and describes context for official standards, legal or regulatory requirements, contractual or business agreements, and similar official rules. Industry contexts cover the semantics related to industry or an industry of the trading partners, e.g. product identification schemes used in different industries. The Core Components Technical Specification recommends the following sources for industry classifications: - International Standard Industrial Classification (ISIC) Rev.3.1 [ISICr3] - United Nations Standard Product and Services Code (UNSPSC) [UNSPSC03] Context Rules Context rules transform semantic equivalent information between different formats. These rules help to produce individualized information formats for each partner based on its business environment and data structures. The context rules consist of two parts: a language for assembling and aggregating the component and a language for refining the assembly. In the process of refining the assembly, one adds the business process semantics and restricts or extends the semantic model. So it is a two-step process. First we assemble the component and then refine for actual use. Context rules produce business information entities. It can be also done by applying a conditional rule, e.g. if the geopolitical context has a value of Europe, then take a core component Currency and use the associated rules to provide the correct sign and format for the value. This enables to assemble and modify the core component to produce the appropriate business information entity. 25

26 Using Core Components The core component discovery and analysis technical report [CCDA01] recommends a 4-step process for deploying core components: 1. Find a business process that meets the requirements of the trading partners. 2. Identify the contexts. 3. View and select the core components and associated business information entities in the registry. (Optional) Create new business information entities. 4. Create an XML DTD or schema for the whole business process. 1. In this step the user searches the registry for the business process, which is fitting the requirements. If it is found, it is configured according to trading partner profiles and agreements. If the right business process is not found, it is modeled as core components and published to the registry. 2. Then all related contexts have to be identified. The registry provides information on all specified contexts described in one of the sections above. 3. After the contexts are identified, the registry will provide the matching list of business information entities (BIEs) with the context information. The core component manager software then has to select the right combination of the BIEs for inclusion to the business process. If there are no BIE for some of the requirements, they have to be created. The core component manager software has to search the repository for the appropriate core components and refine them according to the specific context information to fit the business process. The newly created BIEs have to be associated with the business process in the repository. 4. Finally, the complete business process is rendered into the syntax of a message description, which results in DTD or schema representing the BIEs in the repository. The process of mapping business process definitions to core components is depicted in figure 2.8. First the user searches the needed business process definition in the registry. After finding the right definition in the catalog, the user reviews the documentation of the business process definition and decides if the business process definition is the one needed. If it is suitable, the user simply uses the business process definition, which implies that the core component manager software will link all necessary BIEs. If the business process definition is not suitable, the user has to 26

27 decide if it is similar. Similar means, the business process definition just has some variations in some parts. So it makes sense to reuse a large part of it. If it is not even similar, then the user has to document his business process completely, which implies that the user has to create the necessary BIEs, and to publish them in the registry. If the business process definition is similar, then the user has to find out if the context is different. If the context is not different, the user has to document variances of the business process and to publish them in the registry and the suitable parts of the business process definition is reused. If the context is different, then the user has to document the new context and to publish it in the registry, then document variances of the business process and to publish them in the registry as well. During the documentation phase the user has to find all necessary core components and apply the new contexts to create necessary BIEs. Figure 2.8. Business process mapping to core components [Chiu02] Trading Partner Profiles and Agreements For the message interchange to work properly, there is not only a need of a common vocabulary, but also of a common electronic agreement between trading partners. 27

28 This agreement has to be accepted by both sides before any actual collaboration can take place. A Collaboration protocol profile (CPP) defines the ways that parties can exchange the data. It is stored in a registry and it is the document representing a company as a potential trading partner for the registry user. The CPP actually uses XML extensions such as XLink [XLink01] that reference the precise elements in XML documents representing the business processes. So CPP actually indicates specific capabilities supporting business processes. Since it shows the capabilities of a company in doing business electronically, a CPP serves also as a basis for constructing collaboration protocol agreements (CPA): the intersection between two CPPs of two potential trading partners defines the common ground of the two companies. This provides starting information, on which the companies negotiate a CPA. However, there are only guidelines for negotiating CPAs, there is no standard process for that. So a collaboration protocol agreement (CPA) provides a concrete interaction definition between partners and each side can enforce the execution of them. Business process definitions in CPA are used to configure both sides software. Since the content of the CPA is based on both CPPs, both companies can assure that the contents of CPA and CPPs are current and accurate The Collaboration Protocol Profile (CPP) The collaboration protocol profile describes three main functions of the company s capabilities to conduct electronic data interchange: - Process specifications: specifications of the business processes that are supported by the company. - Document exchange: the services that connects the specification of the business processes with the transport functions for sending and receiving messages, incl. encryption, decryption, and addition of digital signatures. - Transport: the services that supports sending and receiving business messages. Document exchange and transport functions are complementary to each other. Let us look at the example of security functions: encryption, decryption, and digital signatures. They can be realized as functions of either document exchange or transport layer, depending on the implementation of these functions on the company software. 28

29 A CPP is an XML document with the root element CollaborationProtocolProfile required in all instances. It has the following elements: - PartyInfo must appear at least once in a document and it describes the company itself, with the following elements: o PartyId is a unique identifier of the company. This could be a UCC/EAN-assigned company codes. o PartyRef is a reference to more information about the company, e.g. to the ebxml or UDDI registry, or company s website. o CollaborationRole contains the business processes and the role played by the company in those business processes. o Certificate identifies the digital certificates used to authenticate the company. It includes the identifier for each certificate and the description of the certificate as defined by the XML Digital Signature specification [XMLS03]. o DeliveryChannel is used to describe transport and message protocols supported by the company as defined in Transport and DocExchange elements. This element consists of one Transport, one DocExchange, and a Characteristics tag providing security details. o Transport defines all the details about supported transport protocols for sending and receiving messages, a company s URI for receiving messages, and security information for the transport. o DocExchange describes the properties of the messaging service, e.g. message encoding, reliable messaging properties, nonrepudiation, digital envelope, etc. - Packaging is a required element and defines the configuration for the ebxml message headers and payload. - Signature contains the digital signature if such is used. - Comments. Optional element written in a free-text form (human-readable) The Collaboration Protocol Agreement (CPA) Collaboration protocol agreement (CPA) is a document, which describes the agreement between two companies on technical characteristics defining the features, services, and processes in the electronic business relationship between two partners. The creation of a CPA is based on the intersection of the CPPs of both companies and further subsequent negotiations. 29

30 A CPA is an XML document with the root element CollaborationProtocolAgreement, which has a unique identifier (ID) assigned by one of the parties and used by both. It is recommended to use a uniform resource identifier (URI) for this identifier. The root element has the following major elements: - Status provides the information about the state of the development of CPA, which can be proposed, agreed, or signed. The option signed can be realized by adding a digital signature defined by Signature element. - Start and End indicates the date and time the CPA goes into effect and the date and time when it should be renegotiated. The range of time between start and end elements is called the CPA lifetime. It is recommended to renegotiate the CPA earlier before the end time is reached, since the processes can be cut while running, when the end time is reached. - ConversationConstraints. This optional element defines the limits concerning the messages exchanged between parties: o An invocation limit is an upper limit of activities, which can be conducted by the parties. o A concurrent conversations limit defines a limit to the conversations held simultaneously by two partners, which can occur due to limitations in the companies software capabilities. - PartyInfo elements, one required for each company that is a party to the CPA. It is similar to the element described in CPP document. - Signature is also similar to the element described in CPP document. - Comment. Optional element written in a free-text form (human-readable). Figure 2.9. Overview of collaboration protocol agreement [CPPA02] The process of establishing a CPA is shown in the figure 2.9. First the two parties are negotiating the remaining CPA details, which do not result from the CPPs intersection. The negotiation process is running until the CPA has the agreed or 30

31 signed status. After the agreement is reached, both parties are notified and can start conducting business activities based on the agreed terms defined by the CPA Registries and Repositories This section explains one of the basic parts of the ebxml architecture, since it enables the industries represent and publish business process models and objects, and it enables the companies to publish their collaboration protocol profiles. So it is the main point where industries companies get in contact with each other and negotiate agreements using available information. However, since we will be analyzing the capabilities of ebxml to map real business processes, we will not go into greater detail in this section. Any type of data can be stored in the repository including XML data and documents, binary data (such as images, sound files, video data, executable application files, etc.), and any other kind of data. A registry is a way of publishing and looking up metainformation about entries in the repository. Using the registry, this data can be searched and classified. The actual storage of the business models expressed in XML and the profiles associated with the registry are called the corresponding repository content. The registry/repository user connects to the registry and sends the queries to the registry, while the repository provides the requested content. The registry provides an index of the content elements located in a repository as well as the functionality for the access to the repository. The registry can also refer to other registries holding the information of, for example, other industries. Furthermore, it has to have a capability to be updated with new processes, components, and profiles. The interactions with the registry are defined the same way as interactions between trading partners. ebxml specifies the CPA between the party providing the registry and the clients. ebxml also specifies some processes for interactions, messages within the processes, the mechanism of querying the registry and responding to these queries. Moreover ebxml specifies the processes and CPA between registries. Registries are thought to be public facilities. However, specifications recommend implementing appropriate security policies to limit the access to authorized users. 31

32 Messaging Service ebxml Messaging specifications allow the reliable delivery, and security of messages. Talking in a very general way, ebxml messages include security components and allow the exchange of the messages over common Internet protocols: HTTP, SHTTP, or SMTP. We will not go into greater detail in this section either. The Simple Object Access Protocol (SOAP) was adopted by ebxml. The ebxml uses the specific version of SOAP. It allows the use of attachments and is called SOAP with attachments. [SOAP00]. The ebxml message is carried in a package defined by SOAP using MIME message type description format as well as XML documents. MIME also supports many different message formats including encrypted messages [SMIME03]. Figure ebxml message structure [MeSe02] Figure 2.10 depicts the structure of the ebxml message. The communications protocol, such as HTTP or SMTP, provides the outer envelope of the package. Then the outer SOAP envelope uses MIME to specify message length and format. The 32

33 same is done by two main parts of the message, headers and payloads. It also uses the MIME to specify the formatting and length. XML message headers inside the SOAP envelope provide the management information and the payload has the business content of the message. The interesting part in all this message structure is, that the payloads, which can be more than one, reside in an attachment part of the message. The ebxml headers identify the message sender and receiver, provide the timestamps, include digital signatures, list of contents of the payloads in the manifest, and more Modeling Requirements and Analysis Processes The kind of analysis, which we are going to describe in this section, won t need to be performed by every single company. The task of analyzing the business process and generating business models stored in ebxml repositories is a task of industry associations or consortiums, which actually have resources for this type of research. However, since we are at an abstract level going through this process in this work, we will explain how it is conducted UML-Based Analysis The analysis of business processes usually generates several types of UML diagrams [UML03]: - Activity diagrams show the actions taken during the execution of the business processes. - Sequence diagrams depict the interactions between objects within the system and outside the system over time. - Class diagrams, the key element of the analysis, illustrate the classes of business objects participating in the business process and the relationships between them. Moreover, they include not only the definitions of the business objects, but also the operations and functions performed on objects. The class diagram identifies the individual pieces and collections of information needed by each trading partner for the business process to be executed. The class diagrams help to define messages exchanged between trading partners. They also provide the capability later to compare processes at the information level, which is a crucial function for the appropriate processes identification for the usage in different industries. - Collaboration diagrams are similar to sequence diagrams. They are useful, because they show the behavior between object groups rather than 33

34 individual pieces as well as the links between them and by that they help to define the messages and services. - State diagrams show the states of objects as a result of actions in which an object is involved Putting it All Together into a Meta-Model A Business Process Meta-Model is a combination of various notations mainly provided by UML, which allows industries or even single trading partners to document their processes. The Meta-model is used to specify business process definitions and subsequent schemas, elements, and core components (see figure 2.11). Figure ebxml Business Process Meta-Model [BPOv01] After the UML analysis is done, one needs production rules to translate UML diagrams into XML. These production rules specify the XML representation for each UML concept. For example, UML classes become XML elements, UML class attributes become attributes of the elements, and aggregations in UML become parent and child elements in XML. Now let us look at the specification schema in XML. The documentation of these interactions becomes part of the collaboration protocol agreements (CPAs) between the trading partners, and the capabilities of the systems of the companies become part of collaboration protocol profiles (CPPs). 34

35 The ebxml specifications define how the meta-model can be applied in the analysis process. At this point, industries and companies can define their own business processes, core components etc. Then they can publish them in repositories and registries to be accessible to potential trading partners. More details on the analysis process and meta-model can be found in [BPOv01] How Does It All Work Together? The modeling methodology, described in the previous sections, allows us to define and publish business process definitions. Now we will describe how the overall system of discussed standards is actually working together. The relationships and interfaces between different standards can be seen in figure Figure Functional view on ebxml architecture [KoWe02] The registries allow companies to publish the business process models and their profiles in XML. Registry interfaces provide the access to all the stored information: other companies profiles, industry processes, schemas, and other business objects. Once the trading partners are finished with the retrieval, registration, and discovery of the business process definitions, the business service interfaces (BSIs) of the 35

36 companies systems collaborate directly with each other. First they negotiate and exchange the collaboration protocol agreement (CPA), and then they can run the actual process instances, which incorporate the exchange of the payloads of the messages with actual business content. The trading partners are involved in this business collaboration until the expiration of the CPA or the end of collaboration Summary of the Chapter In this chapter we have discussed ebxml concepts and technologies. We have explained why ebxml concepts and technologies are promising. Then we have introduced electronic business collaboration in general and how ebxml fits the idea of electronic business collaboration with its specifications. We have described some of the ebxml specifications in detail, e.g. the business process model, core components, and collaboration protocol profiles and agreements. Other specifications were only mentioned. Finally, we have presented the analysis process and meta-model for business processes as it is specified by ebxml and we have shortly introduced how all standards work together. 36

37 3. A Model to Negotiate, Evaluate, and Execute Electronic Business Processes This chapter is dedicated to analyze electronic business requirements and categorize the results in the manner of a layered model. We will present the four-layer electronic business process model, which we developed after analyzing the requirements to beneficially execute electronic business processes. Then we will arrange ebxml specifications discussed in the chapter before to the developed four-layer model to see how ebxml fits the requirements Four-Layer Electronic Business Process Model To describe electronic business requirements, we have developed the four-layer model, which one can refer to in figure 3.1. The model consists of the following layers: benefit model layer, business process negotiation layer, business process layer and technology layer. Each layer addresses different level of process support: - The benefit model layer (1). The benefits for the company as defined by e.g. business rules and short-term and long-term business goals, which drive and control the negotiations on business processes and rank business processes. - The business process negotiation layer (2) defines rules for negotiations on the business processes, driven by the benefit model. - The business process model layer (3) defines the business processes, which have been negotiated and agreed upon in the layer above. - The fourth layer in the model, referred to as the technology layer defines the technologies, which provide necessary support for the business process definitions and execution. Figure 3.1. Four-layer electronic business process model 37

38 As we can see from this short description, electronic business process model is built in layers, since they use each other s functionality (bottom-up), provide each other with necessary data (top-down), and control the layer below. [MaHu02] Benefit Layer When a company decides to do business with a potential partner, it has to have a clear idea at least of the following: the reasons it is doing the business (why?) and the way one is going to conduct business (how?). These two questions are tightly interrelated. The reasons are primarily related with the results, such as profit. The profit depends on many factors, e.g. costs, taxes, etc. Costs depend on the resources needed to conduct business, e.g. time, human resources, inventory, licenses, etc. Taxes usually depend on an economical region. Many of the factors influencing the profit depend on business processes, which are the way the business transactions could be conducted, running in the company or between the company and its business partner, e.g. time needed to conduct the business, payment schema, human intervention, taxes, etc. Some of these factors can be influenced by non-economical factors, e.g. payment schema (whether the payment has to be done before the goods are sent or the goods have to arrive before the payment is done) can be influenced by trust between business partners. It is obvious, since the business processes are directly determining the degree the goals are met in profit-seeking company, business process negotiation between business partners should be driven by a benefit (1) model defining the tactical goals of the companies for this particular business situation. The companies should be able to examine business processes and decide which processes of which partners are favorable for them and adapt (renegotiate) them to new conditions if needed, according to their benefit models. All process definitions are then ranked according to the level they meet the benefit model Business Process Negotiation Layer We understand business process negotiations as negotiations on the structure of a business process: e.g. potential business partners negotiate on payment schema. In business life business process negotiations like the payment schema example, are taking place all the time. So there is a need to be able to negotiate the business process definitions with a business partner, which ranks high in the benefit model of the company compared to other process definitions. There should be a way of exchanging 38

39 the business processes and a way of finding an agreement on a common process, e.g. by merging of processes, intersecting existing processes, further negotiations, etc. There should be a support of altering a business process when the business conditions change or the agreement expires. The company should be able to define by means of rules, which one of several agreed business processes, according to a certain business transaction, to perform. We need a business process negotiation (2) model to meet business collaboration requirements mentioned in this section Business Process Layer To be able to negotiate processes, one has to have a framework to define the business processes, so both partners have the same understanding of the semantics of business processes. There is a need of business process (3) model to be able to define business processes that partners can understand the same way and it could be used and reused over and between different industries and business domains. In order to have business processes defined the following is needed: human intervention in processes for providing extra data or for regulating the process flow (e.g. terminating) must be supported, control-flow for automatic decision-making, iteration control, and sequencing, common business document definition, two or more business partners participation must be supported, etc Message Exchange Layer And the last but definitely not least, the whole infrastructure of making decisions on business processes, and defining and executing the processes has to be supported by technologies that provide message exchange, integration with partners back-end systems, storage, persistency, availability, exchange, security, authorization, authentication and non-repudiation support. These technologies need to be defined in message exchange (4) layer What Does ebxml Provide? Now we will look at the ebxml specifications and identify the parts out of electronic business process model described above that are supported by these specifications. Let us look at the model again (see figure 3.2), this time taking the bottom-up approach. The ebxml specifications, like messaging service and registry and repository specifications, meet all necessary storage, quality of service, and communication 39

40 requirements of message exchange layer (4) of our model. Registry and repository services are storage and retrieval facilities, which meet the persistency, availability, and security in terms of authorization, authentication, and non-repudiation requirements. Moreover, registry and repository services are scalable and distributed, which implies load balancing. The messaging service provides parties with necessary communication protocols to exchange the messages between each other, whether parties would be trading partners or registries, and repositories. The message exchange layer, as realized in ebxml, is platform independent, since it uses platformindependent technologies, like XML, SOAP, and similar. Figure 3.2. How does ebxml meet the electronic business requirements? Let us look at the business process layer (3) now. The Business Process Specification Schema (BPSS) and the core components specification meet the requirements of the business process layer. Any business process can be defined using BPSS and core components. Because of the concept of core components, any business process or core component can be used and reused in any business situation by adding particular context information. Since the vocabulary used in business processes is defined by the BPSS, the semantics are defined for all participants. The multi-party collaborations are specified in the BPSS and human intervention can be supported by the business service interface (BSI). The control-flow of the transactions within the collaboration is supported by means of choreography and document or message flows are defined in every transaction explicitly. In the business process negotiation layer (2) we can find that many support are lacking. The ebxml provides only so-called collaboration protocol profiles (CPP) and agreements (CPA), which are very restricted. For example, if the business processes fully match, which does not happen very often in the real world, the business process is just accepted as the agreed process and the process negotiation is over. If negotiations are needed, in case of non-matching or partially matching 40

41 processes, it has to be done by human intervention. As we can see, the ebxml specifications support only matching business processes, or the enforcement of the business processes by one party. Agreed business processes can only be altered after the expiration date is reached. But they cannot be altered during execution. However, the existing agreement can, of course, be terminated before the expiration date. Since no process evaluation and comparison against business goals is specified by ebxml, there is no possibility to support business process negotiations upon the goals. We can see that the requirements of the business process negotiation layer are poorly met by specifications of ebxml. And finally, as we already mentioned, there are no specifications defined by ebxml, that would meet the requirements of the benefit layer (1) and, which could be implemented by trading partners software. Instead, human intervention is needed to define benefits for the company and to estimate mapping to process definitions Summary of the Chapter In this chapter we have presented the four-layer electronic business process model, which we have developed after analyzing the requirements of electronic business. The model consists of the following layers: benefit layer, business process negotiation layer, business process layer, and message exchange layer. We have presented how ebxml specifications fit the developed electronic business process model. We have seen, that the existing ebxml specifications fully meet only the requirements of the last two layers, namely message exchange layer and business process layer. The ebxml specifications also meet a tiny area of the requirements of the business process negotiation layer, but many requirements of this layer are not met. And finally we have seen, that there is no specification to define benefit rules for the company, which should drive business process negotiations. 41

42 42

43 4. Case Study This chapter is dedicated to analyze the e-procurement business process case study. We will present all the case studies that were candidates for the detailed analysis initially. We will then describe the chosen e-procurement business process in detail and will analyze the modeling and implementation aspects of this business process in ebxml. Finally, after the detailed analysis, we will point out and discuss the limitations of ebxml, which are identified during the analysis Initial Case Study Analysis Originally we had several business processes to choose from for the case study: broker/marketplace scenario, supply-chain scenario, and e-procurement of indirect materials scenario. Let us look shortly at all cases. In the first scenario there is a broker/marketplace, where a seller company can register their products for sale. If the product is sold then the broker/marketplace gets the commission, which is specified in the contract between the broker/marketplace and the seller company. On the other side, a customer looking for some product can find it in the broker/marketplace website and buy it. So the broker/marketplace plays a role of a mediator between the seller and the buyer. There are two ways to approach this scenario: from the point of view of the seller company and from the point of view of the broker/marketplace. The seller company has to access and negotiate business processes of different brokers/marketplaces and the broker/marketplace drives different processes depending on different criteria. In the supply-chain scenario there is a buyer, which has many suppliers, which, from the point of view of the buyer, are called primary suppliers. The primary suppliers usually have many suppliers too, which, from the point of view of the buyer, are called secondary suppliers. The supply-chain of the buyer can be as long as it is needed. Main difficulty for the buyer is to enforce quality control on all levels of supply-chain. We can look at this scenario again from two perspectives: the buyer and the supplier. The interest of the buyer is to force the supplier to sell only for this buyer and to convince the supplier to enforce the buyer s quality control policy to all secondary suppliers too. The supplier, on the other hand, is interested in spreading his products to as many buyers as possible. Let us look at the e-procurement of indirect materials. Indirect materials are those, which themselves do not participate in production process, e.g. office goods, like 43

44 pencils, chairs, etc. Unlike the other two, this scenario can be viewed only from the perspective of a procuring company. The procuring company needs to procure indirect materials regularly. The company aims to minimize its indirect costs, which are influenced by the cost of indirect materials. So, most of the time, the company is interested in buying those materials at the lowest price. The procuring company is usually interested in having many potential suppliers for the same indirect material and negotiating business processes and terms and conditions for each business transaction to get lowest prices. After the initial analysis of all scenarios, we have chosen the e-procurement business process, since some phases of this particular business process were of a high interest for the further analysis, e.g. negotiating business processes, negotiating terms and conditions E-Procurement Business Process Description We look at the e-procurement scenario from a very broad point of view. We want to analyze e-procurement from the creation of a purchase request by the employee of the customer company till the receipt of the payment by the supplier. We look at this particular process from the perspective of the customer company, which is a small or medium-size company. The company provides a fixed list of available indirect materials for its employees to choose from. The suppliers for those materials are already known. Still, seeking for better prices and business terms drives the process of negotiating with other suppliers. Moreover, employees can request for indirect materials not available on the list. For those materials, if approved by the management, new suppliers must be found. Our e-procurement business process focuses on two negotiation schemes for negotiating terms and conditions of a business transaction with potential suppliers: reverse auction and concurrent negotiation, which will be discussed in detail later in the chapter. So it is a very flexible and changing way to drive a procurement process, since the suppliers are not fixed and the list of products can be extended on demand. This is complicated to support in non-electronic business environments. Figure 4.1. E-procurement of indirect materials business process 44

45 The chosen e-procurement business process case study is described using UML activity diagrams in appendix B. The phases of this business process are depicted in figure 4.1. There are three phases in this e-procurement business process: requesting the goods, choosing the supplier, and purchasing the goods. Choosing the supplier phase is split into the following three phases: finding potential suppliers, negotiating business process definitions, and negotiating terms and conditions. All phases of the e-procurement business process are described in detail in the following sections Requesting the Goods The e-procurement business process starts with the employee of the customer company (the buyer), who needs a certain good. We are describing the initiation of the e-procurement process, which is depicted in figure B.1. The buyer initiates the e- procurement process by creating and submitting the purchase request for the approval. The purchase is being approved automatically if the wanted item is chosen from the provided list of available items for procurement. In other case, a procurement department employee must approve the purchase before the e-procurement process can be continued. If the purchase is not approved, the buyer is notified immediately Choosing the Supplier For the following steps let us look at figure B.2 in Appendix B Finding Potential Suppliers After the approval of the purchase, the procurement department is searching all potential suppliers from the fixed list of items and from the external sources: Marketplaces, etc (see figure B.3). Companies can register in marketplaces by giving information about their products, so they become publicly visible. To identify potential suppliers, the standard product ID is retrieved [UNSPSC03] [SITCr3] [HCDCS03]. The list of potential suppliers of the certain product is retrieved from the external sources using the standard product ID Negotiating Business Process Definitions The next step is to negotiate business process definitions with each potential supplier from the potential supplier list (see figure B.4). The negotiations are run concurrently with each supplier. The negotiation starts with the retrieval of all business process 45

46 definitions supported by the potential supplier. The retrieved business process definitions are then matched against the ones of the customer company. The business process definitions are ranked according to the level they satisfy the requirements of the customer company. If the highest-ranked business process definitions satisfy the requirements of the customer company well enough, one of these business process definitions will later be chosen for the enactment for this certain potential supplier. In this case the negotiation is completed. If no business process definition is good enough for the customer company, then it can generate a suggestion with a business process definition and send it to the potential supplier. The potential supplier decides to accept or to reject the suggested process definition. If the potential supplier accepts it, he uses the business process definition from the suggestion. If the potential supplier rejects the suggestion, he notifies the customer company about it. In case of rejection, the customer company can generate another suggestion or choose to terminate the negotiation with this supplier and remove the potential supplier from the potential suppliers list. In case of acceptance, the customer company is satisfied, since the new business process definition is good enough to be chosen for the enactment. The negotiation on business process definitions with the potential supplier is completed, if: - One side decides to stop the negotiation and the potential supplier is removed from the list of the potential suppliers. - The agreement between the customer company and the potential supplier is reached and the agreed business process definition is good enough to be chosen for the negotiation of terms and conditions Choosing the Business Process Definitions After the negotiations on the business process definitions are finished with all the potential suppliers, the customer company chooses one business process definition for each potential supplier not removed from the potential supplier list (see figure B.2). At this point, the customer company has to choose the strategy, either one individual business process definition for each potential supplier or a common business process definition for each potential supplier, on which will later depend what negotiation scheme will be used for negotiating terms and conditions of the business transaction. If the customer company decides to choose one individual business process definition for each potential supplier, then it chooses the highest-ranked process definition for each potential supplier. If the customer company decides to choose one common business process definition for all potential suppliers, then the chosen business process definition might not be the highest-ranked for each potential supplier and the potential suppliers not supporting the chosen common process would be removed from the list of potential suppliers. 46

47 Negotiating Terms and Conditions After the business process definition for each potential supplier is set, terms and conditions of the business transaction have to be negotiated to identify the best offer (see figure B.5). The customer company requests then an offer for a quantity of a certain product from the potential supplier. If the potential supplier replies nonavailability of the product, he is removed from the potential suppliers list. If the product is available, then the potential supplier replies with a business transaction terms. At this point, depending whether the customer company has chosen the common business process definition or the individual ones, the one of two negotiation schemes will be chosen: in case of the individual business process definitions the concurrent negotiations scheme and in case of the common business process definition the reverse auction scheme is chosen. The chosen negotiation scheme is enacted concurrently for each potential supplier. Let us look in detail at both negotiation schemes: concurrent negotiation and reverse auction. Concurrent Negotiation The concurrent negotiation scheme is depicted in figure B.6. If the customer company accepts the terms offer, the terms offer is ranked. If the terms offer is not accepted, the customer company replies to the potential supplier with counter-offer terms. The same happens on the potential supplier side. The terms offer can be accepted or not accepted with a notification of the customer company about it or with a reply containing counter-offer terms. The cycle is executed until one of the sides accepts the other party s terms offer, finding an agreement, or does not accept the terms offer and notifies about it the other side. The negotiation can be executed for each potential supplier concurrently. Reverse Auction The reverse auction scheme is depicted in figure B.7. The reverse auction has a precondition the chosen business process definition has to be common for each potential supplier, who will take part in the auction. The reverse auction scenario is executed concurrently for all potential suppliers. Let us look now in detail at this negotiation scheme. The customer company waits a predefined time for offers. After the time is expired, if the customer company has received only one terms offer, the 47

48 customer company notifies the originator of this terms offer being the highest-ranked. If there were more than one terms offers received, the customer company ranks all terms offers and publishes to all potential suppliers the highest-ranked terms offer. The customer company sets a time-out for the next round and all potential suppliers can provide higher-ranked terms offer. If the potential supplier was the originator of the highest-ranked terms offer, then he just waits for the higher-ranked terms offer to come. If no higher-ranked terms offer comes in predefined time, the customer company notifies this certain supplier about it. If the higher-ranked terms offer is communicated, then the potential supplier either stops participating in the auction or replies with the better terms offer and waits for another round. The customer company receives the terms offer and ranks it. If it is the highest-ranked terms offer, the customer company replies the highest-ranked terms offer to all potential suppliers and starts the countdown of predefined time again from the beginning. The cycle is executed until no better terms offer than the last one comes up in predefined time Choosing the Supplier After the negotiations with all the suppliers on terms are completed, the ranking list of terms offers is completed too. The customer company selects one supplier (see figure B.2), which is highest-ranked in the terms offers list. The selected supplier is notified about it and others are rejected. After the supplier is chosen, the purchase order is created and the last phase of e-procurement process is initiated Purchasing the Goods The possible chosen business process definition is depicted in figure B.8. The procurement department of the customer company sends the purchase order to the supplier. After receiving the purchase order, the supplier delivers the product to the buyer and sends the invoice to the customer company. The employee of the company (the buyer), who initiated the whole e-procurement process, after receiving a copy of the invoice and the product, verifies the invoice. If the product does not satisfy the buyer, he sends it back to the supplier. If the invoice and the product match the purchase request, the buyer notifies the accounts payable about it. The accounts payable then matches the purchase order and the product received notification to the invoice copy they received from the supplier. Finally the accounts payable makes the payment. The e-procurement business process is completed, when the supplier receives the payment. 48

49 4.3. E-Procurement Business Process Modeling in ebxml In the last section we have described our chosen e-procurement business process, which is depicted in appendix B using UML activity diagrams. Let us now look to which extent it can be supported by ebxml. For some phases of the described e-procurement business process, namely requesting the goods, finding potential suppliers, and purchasing the goods, the modeling is not complicated. On the other hand, the two phases left, namely negotiating business process definitions and negotiating terms and conditions, are more complicated. These two phases will have a complex control mechanism on the customer company side and must support complex decision-making. Therefore the both negotiation phases are of a particular interest for the analysis. We will shortly discuss modeling and implementation possibilities of the less complicated phases and go into greater details in modeling of the both negotiation phases Requesting the Goods Let us look at the goods request phase (see figure B.1). The entire phase can be handled by an application on the customer company side with an integrated business service interface (BSI), which uses the specific ebxml business process specification schema (BPSS). The buyer (employee of the customer company) fills in the electronic purchase request form, based on which the purchase request document is generated by the application. BSI must handle the generation of the purchase request document to maintain common syntax and semantics defined by the specific BPSS, since this document will be later published in a registry and used by ebxml business processes. If the purchase request is not approved automatically, the procurement department is notified about it, e.g. by . If the procurement department rejects the request, the application destroys the generated purchase request document and notifies the buyer about the rejection, e.g. by . If the request is approved either automatically or manually, the application moves to the next phase of the e-procurement process, which is choosing the supplier. Choosing the supplier phase starts with finding potential suppliers phase Finding Potential Suppliers In the finding potential suppliers phase (see figure B.3), the application can query marketplaces for companies selling the required product. The query has to be executed using the standardized product ID as a query parameter, which can be 49

50 retrieved from one of standardization organizations [UNSPSC03] [SITCr3] [HCDCS03], depending on which standard is used in this specific marketplace. So the whole phase can be handled by the application on the customer company side with the simple standardized product IDs table and the functionality of querying certain marketplace Negotiating Business Process Definitions Let us look at the negotiating business process definitions phase (see figure B.4). The customer company will be negotiating business process definitions with many potential suppliers. They cannot simply exchange business process definitions by sending XML messages back and forth, since there is no support of common semantics for exchanged business process definitions defined in ebxml. Instead, the ebxml means to define business process semantics inter-organizationally, the repository, must be used. So a space in the public repository has to be allocated by the application on the customer company side for the exchange of business process definitions for each potential supplier. This space in the repository must be accessible only for the application on the potential supplier side, for which it was allocated, and for the application on the customer company side. Having such private spaces ensures that the both applications use the components published in the registry and repository to define the business process definitions for the negotiation, which implies the usage of common syntax and semantics. The most difficult task is to handle the decision-making needed in the negotiating business process definitions phase, e.g. ranking processes, defining a business process, and accepting a business process definition. These decisions require subjective evaluation, since the benefit model (see figure 3.1) of a company making the decision and the profile of a partner involved in the negotiation drives the decision-making, which is not supported by ebxml. So only humans can make those decisions. Initially, the application on the customer company side can retrieve the business process definitions supported by each potential supplier from its collaboration protocol profile (CPP) in the registry. The application retrieves the processes only from those potential suppliers, whose CPP matches the CPP of the customer company in all technical parameters, in order to remove those potential suppliers, with whom the enactment of the business process is technically impossible. The matching of business process definitions of a potential supplier against business process 50

51 definitions of the customer company and the ranking of business process definitions of a potential supplier requires subjective human evaluation. The matching process could still be supported by an application, which would highlight the components of the business process definition of the potential supplier matching the components of the business process definition of the customer company. The application could also provide a rule-based ranking of business process definitions. Human could define the rules. The example of the rule could be: rank business process definitions according to the number of components of each business process definition, which match the business process definition of the customer company. The ranking conducted by the application should be considered only as a suggestion. A human must evaluate subjectively each business process definition based on the benefit model of the customer company and on the profile of the potential supplier and then rank it. The application must also provide the functionality to define new business process using the components available via registry and to publish a new business process definition as a suggestion, which can be read by the potential supplier. The application on the potential supplier side has to provide the functionality to view and to accept or to reject the business process definition suggestion. Figure 4.2 depicts how an exchange of business process definitions can be conducted. The application on the customer company side allocates a part of its space in the repository for the exchange of business process definitions for each potential supplier. These spaces must be allocated only temporarily, until the negotiations are completed and one business process definition has been chosen for each potential supplier. Furthermore, each space must be accessible only for one potential supplier and the customer company, since business process definitions exchanged with one potential supplier must be readable only for this potential supplier and the customer company. Let us look at the exchange between the customer company and one potential supplier in detail. The application on the customer company side creates the suggestion based on the business process defined by human and publishes it in the secured space of the repository allocated for the application on the potential supplier side. The application on the potential supplier side gets notified by the application on the customer company side and reads the suggestion in the secured space. A human must accept or reject this suggestion. If the potential supplier accepts the business process definition suggestion, the application on the potential supplier side publishes the accepted business process definition in the public repository, changes its CPP by adding the reference to the accepted business process definition, publishes the changed CPP, and notifies the application on the customer company side about it. The customer company s application retrieves the new CPP of the potential supplier and ranks the new business process definition. 51

52 After the negotiations are completed and one business process definition has been chosen for each potential supplier, the application on the customer company side changes its CPP, if it is necessary, by adding all necessary business process definitions and publishes the new CPP. Since at least one business process definition in the CPP of the customer company now matches at least one business process definition of each potential supplier, the negotiation of collaboration protocol profiles (CPAs) can be driven by the application on the customer company side with each potential supplier as it is shown in the figure 2.9. Each potential supplier either agrees upon the CPA, which results after intersection of CPPs, or rejects it. If a potential supplier rejects the CPA, the potential supplier is removed from the potential suppliers list. If a supplier agrees upon the CPA, the CPA is generated and published in the registry. It makes sense to generate and publish CPAs at this point. If the product must be bought later from some suppliers, which were participating in this negotiation, there won t be any need to enact this step with them again, since the CPAs with them will already exist. Figure 4.2. Exchange of business process definitions during the negotiation To handle the negotiations with all potential suppliers, one business process definition, as it is depicted in figure B.4, must be modeled as a binary collaboration 52

53 between a customer company and a potential supplier. The business process definition must then be published in the registry and repository. The application on the customer company side must execute concurrently as many instances of this business process definition as there are potential suppliers. The application must track when negotiations with all potential suppliers are completed. After the negotiations are completed, the business process definitions are set, and the CPPs and CPAs are generated and published, the overall e-procurement process moves to the next phase, which is negotiating terms and conditions Negotiating Terms and Conditions Let us look at the negotiating terms and conditions phase (see figures B.5, B.6, and B.7). In this phase the companies can negotiate by simply sending XML messages back and forth. Temporal storage is not needed for the exchange objects, since they are not definitions, but instances of the business documents defined in advance. The decision-making on choosing the supplier has to be done by human, since decisions on ranking terms offers might require a subjective approach as in the previous phase, because the benefit model (see figure 3.1) of a company making the decision and the profile of a partner involved in the negotiation might drive the decision-making. The decision-making could be supported by a rule-based system, as it was also suggested in previous state. Figure 4.3. Potential suppliers spanning state maintains parameters and intermediate results of a term negotiation The application on the customer company side must handle the concurrency, which occurs in both negotiation scenarios used in this phase: concurrent negotiation and reverse auction. The application on the customer company side must maintain a potential suppliers spanning state for all potential supplier (see figure 4.3), where all 53

54 parameters and intermediate results of the negotiation must be maintained, e.g. current time-out value, the ranking list of terms offers, etc. The business process definitions of concurrent negotiation and reverse auction, which guide the negotiation, must be modeled and published in the registry and repository. Both business process definitions must be modeled as a binary collaboration between a customer company and a potential supplier. The business process definitions must then be published in the registry and repository. The application on the customer company side must execute concurrently as many instances of the chosen business process definition as there are potential suppliers. The application must track when negotiations with all potential suppliers are completed. It can be done, by tracking the state of negotiation with each potential supplier parameters of the potential suppliers spanning state. Let us look at each scenario. Concurrent Negotiation The concurrent negotiation process is depicted in figure B.6. The potential suppliers spanning state has to maintain the following parameters in this process: - The ranking list of the terms offers of all suppliers. - The state of the negotiation with each potential supplier, e.g. in progress, finished. The negotiation on terms is completed when all concurrent negotiations with all potential suppliers are completed. One negotiation is completed when one of the negotiation partners (the customer company or the supplier) decides not to reply with counter-offer terms and notifies the other side about it or when one of the partners accepts the current terms offer of the other party and then the customer company ranks the terms offer with the terms offers of other potential suppliers. Reverse Auction The reverse auction process is depicted in figure B.7. The potential suppliers spanning state has to maintain the following parameters in this process: - The ranking list of the terms offers. - The current value of the predefined time-out of the reverse auction round. - The state of the negotiation with each potential supplier, e.g. in progress, finished. 54

55 The application on the customer company side must track the current value of the timeout. If no better terms offer than the previous one is communicated in the predefined time, the reverse auction is over and the terms offers ranking list is completed. If the higher-ranked terms offer is communicated by one of the potential suppliers participating in the reverse auction, the application must publish the highestranked terms offer to all the potential suppliers and the time-out value of this reverse auction is reset to the predefined time value Choosing the Supplier After the negotiations are completed either using the concurrent negotiation scenario or the reverse auction, the application moves to the next phase of the e-procurement process, which is choosing the supplier (see figure B.2). The application on customer company side must set up a ranking list of terms offers and then the decision on choosing the supplier must be made by a human, since many subjective factors must be taken into account, e.g. the profiles of the potential suppliers. After the supplier has been chosen by a human and notified about it by the application on the customer company side, the purchase order is created from the purchase order definition in registry and repository and using the terms and conditions that were negotiated with this particular supplier during the negotiating terms and conditions phase. The application moves then to the next phase of the e-procurement process, which is purchasing the goods Purchasing the Goods After all complicated negotiation processes are completed, the business service interface (BSI) of the customer company initiates the purchasing of the goods phase. BSI enacts the business process definition, which was negotiated with the chosen supplier during the negotiation business process definition phase. It could be defined as in figure B.8. During the execution of the chosen business process, BSIs of the both sides, customer and supplier, collaborate by exchanging business documents and business signals, defined by the chosen and published business process definition, and using the terms and conditions, negotiated in the earlier phases of the e-procurement business process. Human intervention can be handled by the applications on both sides. 55

56 4.4. Limitations of ebxml There are several very important limitations of ebxml that were identified, while analyzing the case study. The limitations are the following: - No support for negotiation on business process definitions, - No support for human decision-making, - No benefit model support to drive the negotiations on business process definitions and terms and conditions, - No support of concurrent collaboration executions. Let us discuss the mentioned limitations. The existing collaboration protocol profile and agreement (CPP and CPA) specification is very limited and does not support the negotiation on business process definitions. The negotiation on CPA is limited to intersecting the CPPs of two companies and then the necessary negotiations have to be handled outside of ebxml. The support for negotiation on business process definitions for generating a CPA must be specified as a part of ebxml. There is no specification in ebxml, which supports a human decision-making. Most of the decisions during the negotiation on business process definitions and terms and conditions have to be made by human. Therefore, such a model must be specified as a part of ebxml. Negotiations on business process definitions have to be driven by a benefit model, in order to identify the best business process definitions for certain business environment and partner. However, to support such a model by the electronic business means is extremely complicated, since it is highly subjective and depends on certain business environment and partners. Therefore, recommendations for building specific benefit models could be provided by the ebxml initiative, since a benefit model specification wouldn t be effective. The most disappointing limitation of ebxml is the lack of concurrency support on the business collaboration level. It is the limitation of the business process specification schema (BPSS) (see figure A.1). While defining the collaboration, there is no means to specify that this particular collaboration can be executed concurrently. Whereas defining the transaction, the business transaction activity can be defined as executed concurrently. The support of concurrent collaboration executions is 56

57 necessary, since the concurrency, which occurred in our case study, could be then handled fully by the business process definition and not by the application Summary of the Chapter In this chapter we have analyzed the e-procurement business process case study. We have described all the case studies that were initially candidates for the detailed analysis, namely broker/marketplace scenario, supply-chain scenario, and e- procurement of indirect materials scenario. We have also described the chosen e- procurement business process in detail and have analyzed the modeling and implementation aspects of this business process in ebxml. Several limitations of ebxml have occurred during the analysis: no support for negotiation on business process definitions, no support for human decision-making, no support for benefit model to drive the negotiations on business process definitions and terms and conditions, and no support of concurrent collaboration executions. 57

58 58

59 5. Conclusions 5.1. Summary In this work we have described how ebxml concepts and technologies relate to a general view on electronic business collaboration. We have studied ebxml concepts and technologies, namely the business process model, core components, collaboration protocol profile and agreement, registry and repository, and messaging service. We have described how one can model business processes in ebxml using business process meta-model and how all concepts and technologies work together. We have established the four-layer electronic business process model. We have identified and described four layers of electronic business process model, namely benefit layer, business process negotiation layer, business process layer, and message exchange layer. This model enabled us to evaluate ebxml concepts and technologies from the point of view of electronic business requirements. The evaluation showed that ebxml satisfies the requirements of the message exchange layer and business process layer. However, ebxml does not provide support for business process negotiation layer and benefit layer. We have also analyzed the e-procurement business process case study. We have described the chosen e-procurement business process in detail. After initial analysis we identified the most interesting phases of the e-procurement business process for the deeper analysis, namely negotiating business process definitions and negotiating terms and conditions. We have analyzed and described the modeling of the chosen e- procurement business process using ebxml concepts and technologies, emphasizing on negotiating business process definitions and negotiation terms and conditions phases. During the analysis of the case study, several limitations of ebxml were identified: no support for negotiation on business process definitions, no support for human decision-making, no support for benefit model to drive the negotiations on business process definitions and terms and conditions, and no support of concurrent collaboration executions. This work has shown that ebxml concepts and technologies are supported by main electronic business-related initiatives and consortiums and useful for modeling, implementing and executing business processes between companies. However, there is still lack of some very important concepts and functionality, which must be still specified by the ebxml initiative, in order to fulfill all electronic business requirements. 59

60 5.2. Outlook Most of the ebxml concepts and technologies are still in an early stage and they must be extended. The absence of the support for concurrent collaboration executions is very disappointing. In many cases it is necessary to execute collaborations concurrently. Therefore, the support for concurrent collaboration executions must be provided by the ebxml initiative. The process of negotiating business process definitions at least with the support of rule-based ranking system should be specified by the ebxml initiative. Instead of rule-based support, where a human must define the rules, ebxml could provide casebased reasoning support, where a machine could support needed decision-making. In both cases, we would suggest to leave the final decision for a human, since business decisions always incorporate some amount of a risk and responsibility. Rule-based or case-based decision-making support system should be also provided for negotiating terms and conditions of a business transaction. The ebxml initiative should provide recommendations how to specify a benefit model for companies in different business domains. Using the benefit model, a company could easily define rules for the decision-making needed during the process of negotiating business process definitions and terms and conditions. The benefit model could also be used in case-based reasoning systems. As for the following steps regarding this work, we suggest to implement the case study to be able to evaluate implemented ebxml concepts and technologies. 60

61 Appendix A. Generic BPSS UML Class Diagram Figure A.1. UML class diagram of generic ebxml BPSS [BPSS01] 61

62 62

63 6. Appendix B. E-Procurement Business Process Activity Diagrams Figure B.1. Overall (high-level) e-procurement process definition 63

64 Figure B.2. Choosing the supplier 64

65 Figure B.3. Finding potential suppliers for a given product 65

66 Figure B.4. Negotiating business process definitions with each potential supplier 66

67 Figure B.5. Negotiating terms and conditions of a business transaction with each potential supplier 67

68 Figure B.6. Concurrent negotiation on business transaction terms and conditions 68

69 Figure B.7. Reverse auction for business transaction terms and conditions 69

70 Figure B.8. Purchasing the goods requested by the buyer at the chosen supplier 70