Concepts of Flexibility for Efficient Integration of B2B Processes Jelena Zdravkovic Department of Computer and Systems Sciences University of Gävle and Royal Institute of Technology Kungsbäcksvägen 47, 80176 Gävle, Sweden
[email protected]
Abstract. Business-to-Business (B2B) e-commerce is emerging as trading parties are attempting to integrate electronically, to automate exchange of their services. To be able to collaborate, enterprise processes must expose compatible public behavior. It is a common need for a company to collaborate a business with many partners. A problem is that, even agreeing on information to be exchanged, the partners usually expose different requirements for protocol and logic of interactions. Therefore, it becomes necessary for companies to redesign process models to accommodate to a new partner. As the result, the company must engage considerable resources for designing and verifying new process specifications, as well as for maintaining them. In this paper, we propose a framework for flexible modeling of enterprise processes, to support a larger scale of B2B integrations. The proposal is based on a set of concepts of flexibility that enable partial process specifications, depicting thus a wider scope of business scenarios that a company is willing to conform in a B2B context. The complete process specification is made after B2B parties agree on a strict public protocol and enforced by runtime transformations. The proposed framework for flexible process modeling is aimed to speed up integration of partner processes as it increases ability for process matching without requiring changes in their design.
1 Introduction The rapidly growing interest in e-business has emphasized the need for technologies able to support automated integration among enterprises. Except for the simplest forms of integrations, Business-To-Business (B2B) scenarios require for business logic to be executed during interactions. The business logic is expressed in form of processes. To be able to collaborate, enterprise processes must expose compatible business behavior. It is a common need for companies to collaborate business with many parties. However, in many scenarios, involved parties cannot directly integrate even when they agree on information to be exchanged, as their processes are completely predefined and cannot adjust to a new protocol. As an example, it means that a company, modeling a strictly predefined order and selection of a group of activities, cannot directly
integrate with enterprises having different orders and selections, even the company is willing to conform to those orders. It also means that an enterprise sending and receiving information disposed in a set of messages and activities, cannot match with another enterprise that exchanges same information in a dissimilar aggregate of messages or/and activities. These examples illustrate that too prescriptive process specifications force enterprises to redefine them almost every time a new B2B agreement is made. As the result, companies must engage considerable resources for designing and verifying new process specifications, as well as for maintaining them. Moreover, there is no possibility to have a unique process view over a particular business context. A solution to the problem is to model enterprise processes in a flexible manner to support a larger scope of B2B protocols that companies may conform to, without necessity for model redesign. The need for flexibility in workflows is well recognized in the research community ([1], [2], [3] [4], [5]). Our work differs in two aspects. First, we discuss the concept of flexibility related to B2B integrations, i.e. the flexibilities in structures of modeled enterprise processes, needed for relaxation of matching requirements. Second, in our study, we do not concentrate only on flexibilities in composition of activities, but we evenly consider other aspects of process definitions. Our approach for modeling partial process specifications with addition of flexible elements is similar to the proposal given in [5]; the works differ, however, in structuring notion and scope of the proposed flexible elements. There are several significant studies on relaxation for equivalence requirements between enterprise processes and public protocols ([6], [7]) through the concept of process inheritance. Our study coincides with them in the way we suggest more generic modeling of enterprise processes, for obtaining a larger scale of B2B matches. The contribution of the paper lies in a comprehensive approach to flexible modeling of enterprise processes, to enable broad B2B integrations without requirements for process redesign. Process flexibility may be achieved in different ways. It may be modeled in the process specification, through the common control-flow constructs. For a company having many B2B partners, this could result in highly complex models with many alternative paths at all flexible points. Another way to achieve flexibility is to specify a separate process template for each particular B2B partner (i.e. contract). However, for a company with high number of template processes, it would become almost impossible to choose a right template for a new contract, as well as to reflect occurring business changes in all of template specifications. In our approach, a process is partially specified with both predefined and flexible elements, while the full specification is defined at contract time. Thus, a single, generic process model is obtained, encompassing whole range of B2B scenarios in a particular business context. The rest of the paper is structured as follows. In Section 2, we define a framework that we utilize to classify different aspects of flexibilities in B2B processes. In Section 3 we describe our approach for flexible modeling of enterprise processes. In Section 4 we discuss implementation aspects of our approach. In Section 5, we conclude the paper with the discussion of the presented results.
2 Modeling Aspects of B2B Processes In this section we introduce a conceptual framework, to classify different aspects that constitutes enterprise process specifications. The framework is based on modelling aspects of workflow processes, as proposed by Jablonski in [8] and Rausch-Scott in [9]. In our study, we concentrate on B2B integrations, i.e. on external (public) behaviour of enterprise processes. We, therefore, describe the modelling aspects identified by Jablonski and Rausch-Scott, as following: − The functional aspect defines intention of an interaction, i.e. its goal. An interaction is a basic exchange of messages between partners, having a certain affect. The functionality of an interaction is determined by names and types (send/receive SR, receive/send RS, solicit send S, and solicit receive R) of activities of collaborating processes. − The behavioral aspect depicts the flow protocol of message exchanges between B2B processes. This is determined by specifying the control flow of a process, i.e. when an activity is to be executed in relation to others. − The informational aspect refers to the messages exchanged during B2B interactions. Messages are defined in partners’ process activities, specifying documents to be included. − The transactional aspect concerns consistent execution and recovery of a set of interactions. The design of the transactional aspect includes defining what to be considered as consistent states, depicting thus particular transactional boundaries (scopes) of collaborating processes. In case of errors in interactions caused by failures in process activities, the transactional mechanisms are used to perform adequate recovery procedures by compensation of already completed activities [10]. By the models of Jablonski and Rausch-Scott, the organizational aspect addresses the roles of businesses involved in a particular business scenario. Thus, this aspect is not a subject of change (i.e. flexibility), because in our study we consider integration of partners with already recognized business roles. In the next section, we introduce our approach for modeling flexible B2B processes, by defining forms of flexibilities for each of described process aspects.
3 Flexible Modeling of B2B Processes In this section we describe our approach for flexible modeling of enterprise processes. We first define flexible B2B processes. Then, we define notion and the structure of the flexible element, used to depict choices in process specifications. Based on the conceptual framework described in the previous section, we then define the classes of flexible elements.
3.1 Flexible B2B Processes Flexibility is one of the most revenant issues in the context of process management. In this paper we consider flexibilities of the process structure. In addition, by following the classification given in [2], we concentrate on flexibility by selection. It means design of different choices in a process specification, such that a number of alternative execution paths may derive from. Based on the described concept, we define flexibility in the B2B context as the ability for flexible modeling of the parts of a private process, to allow for alternatives in constitution of public protocols (i.e. public processes). The flexible model constitutes a partial process specification, comprising two parts: − The predefined part, consisting of the common process elements - control-flow constructs, activities, messages (documents) and transactions. − The flexible part, constituted of flexible process fragments containing sets of process elements and depicting alternatives in full specification of those sets. The complete specification is made at the time of contracting, i.e. when the public process is created. In the works related to flexible process modeling, flexibility by selection is associated with the number of instance types1 that can be generated from a process model. In our study context, flexibility by selection indicates the number of public process specifications that an enterprise process may conform to. 3.2 Modeling Processes with Flexible Elements Current process-based languages (such as BPEL4WS[11], YAWL[12], BPML[13]) support a certain degree of flexibility, with the common control-flow constructs such as sequence, iteration, AND/OR splits and joins ([3]). Creating more reach forms of flexibility using those constructs, leads to design of all alternative paths at all relevant points. This may drastically increase complexity of a process specification and, accordingly, decrease its readability. Another problem is that process-based languages cannot model some forms of flexibility, because they are related to implementations of activities, provided as services of background systems. To enlarge extent of flexibility in process specifications, while keeping the model readability, we use flexible elements. A flexible element consists of one or more process elements and represents alternatives in the public part of the process specification that can be selected depending on the requirements at contract time. In the process model a flexible element is depicted in the form as shown in Figure 1. As it may be seen in the figure, the flexible element construct consists of three parts: – Type, which labels the form of applied flexibility (each of the four process aspects defined in Section 2 supports various forms of flexibility, as it will be seen later). – Elements, denoting one or more process elements belonging to a flexible element. – Constraints, which is a logical expression that describes what to include or exclude from a flexible element type. The expression consists of a number of expression 1
An instance type is a set of process instances that follow the same execution path [5].
elements connected with AND, OR, or NOT. An expression element may represent a process element (i.e. an activity, a document or a transaction) or a set of process elements (sequenced activities, for example) belonging to a flexible element. FE type e1
e2
en
elements constraints
Fig. 1. Flexible element construct
The concept of flexible elements is thus used to model the fragments of a B2B process specification that are not completely defined, due to allowed alternatives in business collaboration protocol and logic. For illustration of defined flexible elements we will consider business of a company (such as Sandvik2, for example) that supplies its products to many worldwide partners. The company collaborates business by integrating its business process with a partner process and following agreed business protocol and logic. As it will be seen, requirements for protocol and logics of exchanged business documents may vary significantly. We will show how abilities for matching between partner processes considerably increase, when the processes are flexible modeled using the approach we suggest. Behavioral Aspect Following the definition in Section 2, the behavioural aspect depicts when an activity is to be executed in relation to others. This means that in B2B interactions, there could be differences in requirements for selection of activities to be executed, as well as in ordering of activities. To enable modelling of such differences, we identify two types of flexible elements – selection and ordering (with the subtype sequencing). Selection This flexible element depicts that activities from a process segment may be considered in B2B integration, or omitted. The elements part consists of one or more activities, which are optional. The constraint part is used to depict exceptions, if such exists. For instance, if activities a1, a2 and a3 are optional in the way that any one is optional, while two others must be in the specification, then the constraint is defined as (a1, a2) OR (a1, a3) OR (a2, a3); if, however, the activities would be optional in the way that at least one should be executed, then the constraint would be NOT(). In the described product supply example, before sending an invoice, the company may send the price list (activity a), information on delivery terms (b), as well as a product offer (c). For the company, all three activities are optional, without restrictions. For partners, however, it could be different: some partners, for example, require to get all three documents; most of international partners ask for delivery terms; for some, a product offer suffices, while old partners often do not require any of the documents. Figure 2 depicts the differences in modeling the flexibility with BPMN (a promising notion for graphical modeling of business processes [14]) and the flexible element: 2
Sandvik is a global industrial materials engineering company with offices in 130 countries.
c
FE selection
b a
a
b
b
c
c
a.
b.
Fig. 2. Selective execution of a group of activities that exchange pre-sales documents a. BPMN model b. Model with the flexible element.
Ordering This flexible element allows for execution of activities in arbitrary order, sequential and/or parallel. The element is used to model alternative orders for a segment of the public part of a B2B process. The elements part includes two or more activities. The constraint part depicts exceptions from the rule, if such exist. As an example, if activities a1, a2 and a3 may be arbitrary ordered, except the activity a3 may not go in parallel with a2, and the activity a2 cannot precede the activity a1, then the constraint would be defined as NOT(a3||a2) AND NOT(a2-..a1)), where the symbol || is used to denote the parallel order, the symbol “-“ is used to denote the sequence order and the symbol “-..” is used to denote the preceding ordering. In the described B2B scenario, depending on a partner, the company may allow for activities “receive payment” (activity a) and “send delivery information” (activity b) to execute in diverse orders. For instance, for an old partner, the company allows delivery before payment; for some other partners, those activities may execute concurrently, while for others payment must be done before products are delivered. In Figure 3, we depict the differences in modeling the “ordering” flexibility with BPMN and with the flexible element: b FE ordering
a b
a
a
b
a.
a
b
b.
Fig. 3. Free ordering of payment and delivery information activities a. BPMN model b. Model with the flexible element.
Ordering/Sequencing This element is the special case of the flexible element ordering. It is used to model allowed alternatives in sequential order of a set of activities. As an example, if activities a1, a2, a3 and a4 may be sequenced in arbitrary way, with the exception of the sequence a4, a3, a2, a1, then the constraint is defined as NOT(a4a3-a2-a1); as another examples, if the activities may be arbitrary sequenced except that the activity a4 cannot be executed before the activities a1 and a2, then, the constraint is specified as NOT(a4-..a1, a2), In the study example, we can consider situation when the company must send information on results on three kinds of product testing (activities a, b and c) to its partners. As for different partners importance of performed
tests may vary, the company may allow for flexibility in tests ordering, except the test c cannot be performed before the test a. In Figure 4, we illustrate the differences in modeling this flexibility, with BPMN and with the free sequencing element:
a.
b.
Fig. 4. Flexible sequencing of product testing activities a. BPMN model; b. Model with the flexible element.
Functional Aspects As described in Section 2, the functionality of B2B interactions is determined by names and types of activities of collaborating processes. In the concept of matching two processes, an activity in one process must be compatible with a corresponding activity in the other process. As an example, this means that if an enterprise sends a purchase order and receives the confirmation as one single activity, it cannot match with another enterprise that receives the order and sends the confirmation as two separate activities. In [15] the authors define a process compatibility concept that allows for differences in activity structures (i.e. types), as long as processes match semantically, i.e. in the communicated information and in the control flow of message exchanges. Based on that concept, to improve capability for functional matching between B2B processes, we define the following flexible element: (De)Flattening The flexible element is used to model flexibility in interaction patterns. The elements part includes either one activity (of type SR or RS) or two subsequent activities (of types S and R). The constraint part is not used. As an example, if an activity a is of type SR, it may be presented as two subsequent activities a1(S) and a2(R); as another example, two subsequent activities a1(R) and a2(S) may be presented as a single activity a of type RS. It does not mean, however, that these transformations may be applied for any activity in a process specification. Due to limitations of information systems it could be, for example, impossible to represent a SR activity as two separate activities (of S and R type), because a system is not capable of doing other operations before completing this activity. In the study example, the company sends delivery notification (a) and receive acknowledge (b) as two separate activities; however, it allows matching with partners that exchange these information in a single activity. Figure 5 depicts the corresponding flexible element: FE (de)flattening a
b
Fig. 5. Flexible element depicting composition of subsequent activities a (type S) and b (type R) into a single activity (type SR).
This flexibility cannot be presented by a BPMN model, because it is related to the implementations of the activities a and b, which are part of underlying applications. Informational Aspects The informational aspect refers to the documents included in messages exchanged during B2B interactions. A problem in B2B integrations is that business partners usually expose different requirements regarding exchanged documents and their structures. Thus, for efficient integrations, it would be beneficial for a company to be able to specify allowed alternatives in the exchanged information content and structure. Following this, we define two type of flexible elements – omitting and (de)composition. Omitting This flexible element allows for omitting input or output message (i.e. document) from a RS or SR activity. The elements part contains the document that is optional; the constraints part is not used. In the studied example, the company sends offer and receive acknowledge of the reception as a single activity a. However, the company is willing, even, to participate in collaborations with partners that do not send the confirmation of order reception. Figure 6 illustrates the corresponding flexible element: FE (de)composition a
Fig. 6. Optional receive of the “confirmation of order” document.
b
Fig. 7. Composition of documents “order rejection” and “counter offer” from activities a and b into a single document.
(De)Composition The flexible element allows for restructuring of information provided by messages (documents) within activities. If a document is to be decomposed to a number of smaller documents, the elements part contains that document; the constraints part depicts allowed decompositions. As an example, if a document d may be decomposed to documents d1 and d2, then the constraint is (d1, d2). At contrast, if documents from several subsequent activities are to be sent (or received) integrally, then the elements part depicts those activities; the constraints part is not used. In the example case, if the company, after sending a product offer, receives the rejection and a counter offer as two messages (i.e. as two receive activities a and b), it may comply with partners that send those documents within a single activity. Figure 7 depicts the corresponding flexible element. Described flexibilities cannot be presented by alternative paths in BPMN models, because they are related to differences in implementation of selected activities. Transactional Aspects In B2B domain, support for transactional message exchange is important to enable consistent recovery of process states in exceptional circumstances. This means that
partners have to expose similar scopes for corresponding transactions, as well as compatible recovery behavior. Companies aiming to enlarge number of B2B partners are often willing to conform to different transactional requirements, but underlying process models are too prescriptive to support that. To enhance flexibility in transactional integration of B2B processes we define, accordingly, two types of flexible elements – scope and compensation. Scope This flexible element allows for participation of different activities within a transaction. The element is intended to model alternative transaction scopes. The elements part is a single transaction; constraint part depicts activities that may be excluded from the transaction. For instance, if a transaction T encompasses activities a1, a2,.., an whereas activities a1 and a2 may be excepted from it, then the constraint is defined as (a1, a2). In the studied case, the company encompasses activities “receive order” (a), “send invoice” (b), “receive payment” (c) and “send delivery information” (d) within a transaction, to facilitate correct payment cancellation. However, the company may exclude the first activity (a) from the transaction if some collaboration requires so (i.e. when partner does not send order cancellation). In Figure 8, we illustrate the differences in modeling the “scope” flexibility with BPMN and with the flexible element: a
b
c
FE scope
d
a a
b
c
b
d
c
d
(a)
a.
b.
Fig. 8. Flexible scope of product ordering transaction a. BPMN model b. Model with the flexible element.
Compensation The flexible element allows for optional compensation of an activity engaged in a B2B interaction. The elements part contains one or more activities (as an activity may be compensated by a set of activities); constraint part is not used. b
c
d
e
b
c
d FE
compensation
e b
c
d
a.
b.
Fig. 9. Flexible compensation of “send invoice” activity a. BPMN model b. Model with the flexible element.
In the described example, if after payment (activity c) the transaction is aborted (by a partner initiative, for example), then the company returns payment, but does not re-
quire to receive an “official” invoice cancellation document. Figure 9 illustrates the differences in modeling the flexibility with BPMN and with the flexible element. The above discussion reveals that, in our approach, the flexible element is a fundamental object for modeling alternatives in execution of B2B processes. By following the four main aspects of process modeling (Section 2), we identified a class of flexible forms. We modeled all forms with the proposed generic structure of the flexible element. The structure is fairly simple and compact; even more important, it is very simple for change (i.e. when new constraints are to be set, or new elements, etc.). In addition, the structure is open for extensions. First, new types of flexibilities may be introduced. Second, the constraints part logic could be further extended to describe new dimensions of rules; for instance, the elements depicting optional compensation and possible omit of documents could involve time restrictions. Finally, it is important to appoint that different forms of flexibilities may be nested within each other. In the next section we discuss abilities for implementation of our approach, as well as integration of flexible modeled enterprise processes to complete specifications according to public protocol requirements.
4
Implementation Considerations
The flexible element construct is integrated in a process specification as a separate process fragment. In the previous section, we presented the flexible element object using a graphical notion. Even we argued for readability of process models, it is clear that it decreases as the number of flexible elements grows. This is directly related to the fact that, in general, process models have to depict various logics, such as composition, choices, transactions, events, errors, compensations, etc. One solution to this problem is to use layers of process view, as suggested in [16]. The graphical notion of the flexible element, as we defined it, could be easily translated to the form of a scripted tag with the corresponding structure (Figure 10 depicts a BPEL4WS segment enwrapped with the flexible element “sequencing”).
