1 Introduction

Business process management (BPM) systems provide a broader scope of perspectives to describe, configure and improve business processes to manage information systems as opposed to workflow management (WFM) systems which focus mainly on processes automation for the organizations [1, 2]. In the lifecycle of BPM, business process models play a significant role covering the stages of business processes design and system implementation. For business process management, two problems have attracted more attention of the researchers and practitioners. Firstly, in many cases the process models could not represent all the possible required tasks and related control flows in design stage. Secondly, the process models are not adaptive enough to react to the dynamic environments at runtime. Therefore, it is important to propose methods to refine the business process models by monitoring process execution dynamically and realizing process optimization continuously.

In the BPM life cycle, there are two kinds of business process model refinement methods: these are model based and data based [3]. Model-based methods often use simulation tools such as ARIS to verify the correctness or estimate the performance of the designed business processes before they are executed [4]. However, the accuracy of the simulations usually depends heavily on the simulation environment configurations, which sometimes have deviations from the real environment. Comparatively, data-based methods attracted more research attention because they better reflect the dynamic changes of the business processes at runtime as the event logs are collected and analyzed [5]. In data-based methods, the \(\upalpha \)-series algorithms are designed to trace the business processes from event logs using Petri Nets, and the statistical algorithms are used to diagnose bottlenecks or resource contention during business process execution. Although the data-based methods analyze business processes from multiple viewpoints, such as control flows, data flows and user roles, the weakness of these process mining algorithms is that they are independent from each other and it is hard for users to analyze the performances or the changes of the whole business process synthetically.

This paper studies the methods of scenario generation from process logs perspective for the purpose of SOA system configuration, services governance and business process optimization. Instead of starting from the experiences of business experts of process modeling, we discover scenarios from the running environments (i.e., process instances, service and users) using process mining technology. We consider three types of business elements for scenario construction, which are the roles that carry out tasks in business processes, the tasks which are related to SOA service invocations and finally the business objects which are needed to fulfill the tasks requirements. In other words, we generate business scenarios from the executing environments considering not only the sequences of the tasks, but also the users and the business objects. Based on these elements, we propose a scenarios-based process mining method to construct comprehensive views of business scenarios to help improve the business processes. Furthermore, the scenarios from the executing business processes will help to understand the changes in the business processes more precisely.

The rest of the paper is organized as follows. In Sect. 2, related work is reviewed. The motivation for our work is presented in Sect. 3. In Sect. 4, the detailed approach for mining scenarios from event logs is given. In Sect. 5, we present a case study and a discussion to illustrate the scenario generation method in the area of logistic management. In Sect. 6, the conclusion and future work are described.

2 Related work

With the application of SOA technology in the development of complex enterprise information systems [6, 7], the analysis and modeling of complicated business processes pose challenges to the system analysts and developers. Various efforts have been made to model the operational business processes (e.g., Petri nets, BPMN, UML and EPCs) [1]. In these methods, processes are described in terms of activities. However, due to the increasing complexity of the business models and the demands for the flexibility of enterprise information systems, additional factors, such as enterprise resources consumed by the business processes and the information delivering flow involved in the business processes, need to be considered in business process modeling and monitoring.

Therefore, in order to fully interpret the business processes for SOA system development, researchers have considered other factors to describe the ways business processes are executed and enterprise resources interact with each other (such as roles, business rules, and priorities of resources manipulation) to enrich the business process models. For instance, multi-view models describe a system from multiple perspectives for the different participants involved in the modeling phase to avoid confusion about the business logic, system architecture and implementation [8]. Multi-view methods provide more comprehensive understanding of business processes from different viewpoints, such as organizational structures, functions and data. Although the designers could gain an overall analysis using multi-model method, relationships among the different views have not been fully described in the multi-view models. As a result, the designers find it challenging to optimize enterprise resource utilities during business process modeling or business process running.

Business scenarios provide ways to characterize the uncertainty in decision making as well as in business process requirements analysis [9]. Researchers also use scenarios to reduce uncertainties involved in multi-objective decisions [10]. A scenario-driven approach is also used to capture the requirement of business processes, while UML sequence diagrams may be used to define the scenarios for business process modeling [11].

In order to extract business requirements more precisely, process mining methods are adopted to discover business scenarios from event logs.

Both clustering and abstracting approaches have been widely used in process mining based on event log analysis from different viewpoints to analyze business processes [12, 13]. Researchers in [14] use a clustering approach to identify both outliers and groups of normal instances to obtain multi-perspective process model. Clustering methods could also be used to learn process variant adaptations during runtime [15]. Abstracting methods deal with the relations between events and activities to mine the control flows and data flows involved in business processes [16, 17]. In [18], a process mining method is used to provide detailed clinical and hospital analysis of the delivery of health care. Some researchers use process mining methods to identify the difference between observed behaviors and pre-modeled behaviors [19]. It is also used to discover service behavior patterns during business process execution in enterprise system [20]. In SOA systems, activities carried out by services are recorded in event logs and business processes could be extracted from event logs. SOA execution logs are used to mine Web service composition patterns, and the gaps between the discovered model and the initial composite model are used to re-engineer the initial Web service composition model [21].

However, more research needs to be done using scenario-driven methods to improve the business process models to adapt to the changes in business environments.

In this paper, scenarios are built through mining event logs from multiple views including control flows, organization structure and data flows for business process optimization and service orchestration. Using the scenarios, we aim to depict business processes in a more detailed way so that the quality of services composition could be improved.

3 Scenario-based business process analysis and improvement in SOA

3.1 Research framework

In SOA-based information systems, Web services are often composed in a loosely coupled style to implement flexible IT infrastructures to support changing business models [22]. In order to improve the correctness and efficiency of services composition in SOA, services orchestration and choreography should not only consider the business functional requirements, but also consider the required resources such as users, data entities and involved control flows in business process execution.

In this paper, an extended scenario-based business process model is adopted to involve the business context in services composition. The business contexts would help the business designers to understand and optimize the business processes more precisely. Meanwhile, business context would provide hints to the services developers to adjust the parameters of the services to meet new business requirements. Therefore, the whole business process lifecycle would cover activities of business process modeling, services development, services composition, information systems deployment and business process optimization based on mining. The proposed framework is shown in Fig. 1.

Fig. 1
figure 1

Research framework

Full size image

In Fig. 1, the proposed framework includes three main components, which are process mining module, scenario generation module and services composition module. In the process mining module, the tools for control flow mining, role-relationship mining and data flow mining are selected to analyze event logs of SOA services invocations. In the scenario generation module, business control flows are synergized with data flow and entity resources to provide business processes designers and services developers with a whole view of business processes containing business contexts.

3.2 Business scenario model

In the scenario-based method of business process analysis and improvement in SOA shown in Fig. 1, scenarios involving run-time contexts are crucial references for improving the business processes. We mine scenarios from event logs recorded in the SOA systems, and then these scenarios are defined as a composition of control flows, related data entities and task performers.

Control flows determine the logical sequences of tasks triggered and accomplished by SOA services invocation. Data entities are abstractions of conceptual and physical business objects related to business processes, such as product orders, manufacturing plans and equipment states, represented by sets of properties [23]. Task performers are not limited to human beings such as customers, suppliers and employees in a company. If some tasks are performed by a software component automatically without the direct interaction of people, such as services in SOA, these services should be regarded as task performers as well [24].

The aim of the design of our proposed business scenario model is to help business process analysts consider more critical business elements during business processes modification and optimization by capturing run-time business process changes reflected in SOA services invoking logs.

The following business elements are involved in the business scenarios.

Definition 1

Event

Events are the activities representing task execution. Events are defined as tuples as follow.

$$\begin{aligned} {Event }= & {} \langle Case\_ID, Event\_ID, Timestamp,\\&Performer, \{BO\}\rangle \end{aligned}$$

The Case_ID is the serial number of the business process instance to be performed. The Event_ID corresponds to the task or the SOA service name. Timestamp records the time the event occurs. Performer is the user carrying out the task. {BO} represents business objects involved in the event.

Definition 2

Execution Instance, Event log

Let E be the set of events and \(E^*\) be the set of all sequences composed of zero or more events from E. Then, \(\sigma \in {E}^*\) denotes the execution instance, while W \(\subseteq \) \(E^*\) denotes an event log.

Definition 3

Business Object (Bo)

As mentioned above, business objects are the abstractions of virtual and physical entities that are involved in the business processes.

$$\begin{aligned} Bo= & {} \langle Bo-\_ID, A\rangle ;\\ A= & {} \{a_1 ,a_2 ,\ldots a_m \}\quad (i = 1,2,\ldots ,\hbox {m}); \end{aligned}$$

Bo_ID is the unique identification of the business object. A is the set of attributes of the business object.

Definition 4

Business Process (BP)

A business process is defined as the tuple of the unique identifier of the business process BP_ID, a set of scenarios denoted as SceS and their relations are denoted as SceR.

$$\begin{aligned} BP=\langle BP\_ID, SceS, SceR\rangle \end{aligned}$$

Definition 5

Scenario

The main emphasis of business process re-engineering should be put on the scenarios. A scenario is formed from a role, a set of ordered activities and a set of business objects. And the scenario should stipulate the correspondence between activities and the business objects. Thus, the scenario is defined as the following tuple:

$$\begin{aligned} {Scenario}=\langle {Sce}\_{ID}, {AS}, {AR}, \{{BO}\}, {ABo}\rangle \end{aligned}$$

Sce_ID is the unique identifier of the scenario. AS names the activities included in the scenario and can be denoted as the following.

$$\begin{aligned} AS= & {} \{Act_1 ,Act_2 ,Act_3 ,\ldots \}\\ Act_i= & {} \langle ActName \rangle \end{aligned}$$

AR defines the relations between the activities in AS so that the business process topology is defined by AR.

$$\begin{aligned} AR= & {} \{\langle Act_i ,Act_j \rangle |Act_i , Act_j \in AS\hbox { if }\\&\hbox {Act}_{\mathrm{i}}\hbox { is related to }\hbox {Act}_{\mathrm{j}} \} \end{aligned}$$

\(\{BO\}\) are the business objects involved in the scenario.

ABo is a mapping function that maps an activity \({Act}_{i} \) to a set of business objects used by the activity \({Act}_{i} \) in this scenario.

$$\begin{aligned}&ABo: AS\rightarrow 2^{\left| {BS} \right| };\\&\quad ABo(Act_i ) = \{Bo_1 ,Bo_2 ,Bo_3 ,\ldots \}; \end{aligned}$$

Definition 6

Role

Usually in an organization, employees are grouped into roles according to their assigned jobs, as well as the application systems. Different roles will have different allocated tasks and occupy different business objects.

$$\begin{aligned} Role=\langle Role\_ID, AS, \{BS\}, ABo\rangle ; \end{aligned}$$

The AS represents all activities carried on by this role in a business process. {BS} are business objects used by the role, and ABo is the mapping function from one activity \(\hbox {Act}_\mathrm {i} \) to a set of business objects used by the activity.

Based on above definitions, the business scenario model and the business elements in the model are shown in Fig. 2.

Fig. 2
figure 2

Business scenario model for business process mining

Full size image

As shown in Fig. 2, in order to generate the scenarios from the event logs, we use process mining technology from the both organizational structure and the business process perspective. The arrow heads in Fig. 2 represent foreign key relationships. The organizational structure perspective focuses on business objects related to the tasks, such as who perform the tasks and how the task performers are related. The business process perspective focuses on the routines of the business process instances, for example when manufacture orders are fulfilled, what kind of data flows would be involved.

4 Scenario context generation using process mining

4.1 Event logs preprocessing

Currently, information systems such as ERP (enterprise resource planning) systems, PDM (product data management) systems, CRM (customer relation management) systems exist widely in various kinds of enterprises [25]. The event logs of these information systems record data about performed activities in the enterprises including time performed, actors and related business objects, as shown in Table 1.

Table 1 Fragment of event log
Full size table

In SOA-based information systems, business process instances may be carried out by different services offered by different service developers. This brings challenge of understanding and analyzing business processes because event data are often scattered over different data sources and they are hard to be collected.

In order to address the above challenge, we use service invocation event logs as business process mining data sources, instead of using scattered running logs of information system. These SOA services invocation logs could be collected centrally on severs sides by recording the message exchanges [26] (e.g., SOAP messages) and read and write actions [27]. Since service-oriented applications are generally deployed on centralized runtime environments, such as Microsoft Azure Services Platform and Google App Engine, the adoption of such centralized runtime environments monitor the running of distributed services-oriented applications and obtain centralized service invocation event logs. These event logs can be transformed to a standard format, such as MXML (Mining eXtensible Markup Language) for further usage.

According to Definition 1, event log files contain the triggering timestamps of the SOA services, names of the SOA services carrying on the activities, the ids of the business process instances including the activities and the performers who initiate or perform the activities. We use MXML to represent these events logs, as shown in Fig. 3.

Fig. 3
figure 3

MXML format for an event entry in log file

Full size image
Fig. 4
figure 4

Control flow of SOA services invocation using WF-net/JPDL

Full size image

4.2 Mining control flow

We use Petri net to represent the control flow of the SOA services invocations. We mine the sequential structure, parallel structure and selective structure of the SOA services invocations using \(\upalpha \) algorithm [28].

Using Petri nets, a SOA services invocation control flow could be defined as \(PM = \langle P, T, S, F\rangle \) where P is the finite set of places. The source place i and sink place o correspond to the start and end points in WF-net (WorkFlow-net). T stands for the finite set of transition in PM. Each transition corresponds to a single task in the business process. S is the set of resources of services used to perform the tasks in PM. We use \(s_{i}\) to denote the resource used to fulfill the ith task. F describes the relations between the places and the transitions denoted as \(F \subseteq (P {}^* T)\cup (T {}^* P)\).

WF-net and JPDL(JBoss jBPM Process Definition Language) are therefore used to display the Petri net result of SOA services invocation control flows mining by \(\upalpha \) algorithm, which is shown in Fig. 4.

A WF-net and its implementation using JPDL are shown in Fig. 4. In JPDL, label \(\langle process \rangle \langle /process\rangle \) stands for an entire process model. Label \(\langle task \rangle \langle /task\rangle \) stands for the transition, e.g., the tasks in the business processes. Its attribute assignee stands for the service resource related to the task. \(\langle start \rangle \langle /start\rangle \) stands for starting a task, while \(\langle end\rangle \langle /end\rangle \) stands for end of a task. \(\langle transition\rangle \langle /transition\rangle \) is the input/output function of the transition.

4.3 Mining the relations between roles

Roles are the actors who perform the tasks in the business processes. Usually, business processes are performed by different roles cooperatively. The relations between the roles often reflect relations between the activities. Therefore, mining the relations between the roles could help to monitor or discover business process changes from the view point of performer relations in addition to the control flows of SOA services invocations. The performers, whether people or software agents, are kinds of enterprise resources; the results of roles mining could help managers to optimize the allocation of human and services resources more efficiently.

In order to establish the role relations of the users, metrics of performer–activity are used to discover the relations between the activities and their performers [18]. As users belonging to the same role often conduct similar activities rather than totally different activities, the frequencies of the performers conducting the activities are counted and used to measure the distance between two performers, as shown in Table 2, where \(X_{i,j}\) represents the frequency of performer i performing activity j.

Table 2 Performer–activity matrix
Full size table

Here, we use Pearson’s correlation coefficient to count the distance between two roles. The formula (1) is as follows.

$$\begin{aligned}&\hbox {PCC}\left( {p}_1 ,{p}_2 \right) \nonumber \\&\quad =\frac{\mathop \sum \nolimits _{j=1}^n \left( \left( \hbox {X}_{1j} -\frac{1}{n} \mathop \sum \nolimits _{j=1}^n \hbox {X}_{1j} \right) *\left( \hbox {X}_{2j} -\frac{1}{n} \mathop \sum \nolimits _{j=1}^n \hbox {X}_{2j} \right) \right) }{\sqrt{\mathop \sum \nolimits _{j=1}^n \left( \hbox {X}_{1j} -\frac{1}{n}\mathop \sum \nolimits _{j=1}^n \hbox {X}_{1j} \right) ^{2}*\mathop \sum \nolimits _{j=1}^n \left( {\hbox {X}_{2j} - \frac{1}{n}\mathop \sum \nolimits _{j=1}^n \hbox {X}_{2j} } \right) ^{2}}}\nonumber \\ \end{aligned}$$
(1)

Using the above formula, the distances of each two roles is calculated to classify them into different work groups. The pseudocode of the algorithm is shown in Fig. 5.

Fig. 5
figure 5

Pseudocode of the roles classification algorithm

Full size image
Fig. 6
figure 6

Role classifitions derived from event logs

Full size image

Using the classification algorithm, the roles shown in Table 2 could be divided into three groups, shown in Fig. 6.

The result shows that P1 can be assigned to Role1, P2, P3 and P4 can be put into the same group Role2, and P5 could be assigned to Role3.

The relations between the work groups are determined by the control flow structures of the activities. We have three types of control flow structures. They are sequential, parallel and selective. If two work groups perform sequential activities, their relations are defined as Hierarchical. If two work groups perform parallel activities, their relations are defined as Cooperative. If two work groups perform selective activities, their relations are defined as Alternative.

4.4 Mining data flow

Data flows are transmission sequences of data between activities in business processes. They reflect the logical relations of the business activities performed by different roles. In many situations, the values of the parameters transmitted in the data flow determine the directions of the business process control and govern the choices of certain cases taking particular business paths [19]. For example, if an order is accepted, the customer should get a notification message sent automatically. These decisions could be made depending on the values assigned to business objects. Therefore, we can analyze the event logs to identify the possible data constraints affecting the structures of business processes, and obtain business rules used for further control of business processes.

We use the Daikon system proposed in [29] to detect the relations between the variables and the assigned values to deduce data constraints affecting the structures of the business processes. These data flows are helpful for the services developers to analyze or re-engineer the business processes.

4.5 Scenario generation

According to control flows, role relations and data flows, scenarios are generated automatically from log data. The scenario could be generated using the algorithm, shown in Fig. 7.

Fig. 7
figure 7

Scenario generation

Full size image
Fig. 8
figure 8

Architecture of the cloud logistic management platform

Full size image

Figure 7 shows that the generation of the scenarios starts by focusing on one of the roles in the scenarios. Then, activities performed by this role are pulled into the same scenarios. After that, related activities according to the control flows are pulled into the scenarios to expand the range of the business processes. The algorithm will recur till all the users are pulled in.

5 Case study and discussion

5.1 Case study

In this section, we use a prototype to illustrate our approach of scenario generation based on process mining.

Fig. 9
figure 9

Control flow of intra-provincial logistics process

Full size image

It is believed that cloud computing technologies could improve the efficiency and the performance of resources allocation and many SOA applications are deployed on the cloud computing platforms nowadays [30–32]. The prototype is part of a SOA-based logistics management platform developed for the transportation bureau in one of the provinces in China. In the transportation bureau, logistics companies are registered to convey varieties of logistics transportations. In order to efficiently use the computational resources, the transportation bureau puts forward the project to build a cloud platform so that logistic companies could tenant SOA services from the platform to deploy their logistic management systems.

The architecture of the cloud logistic management platform is shown in Fig. 8.

As shown in Fig. 8, in the cloud side, the logistic companies use the business modeling tools provided by the platform to construct their business process models. On service side, SOA services could be selected to choreograph corresponding logistic information systems for the tenants according to the business process models. During the execution of the logistics information systems, event logs are collected on the service side. In this prototype system, the process-mining-based scenario generation method is used to analyze the event logs generated by the tenant companies. It could be seen in Fig. 8 that the mined scenarios may help SOA service providers to build SOA governance strategies. Also the scenarios could be references to business process designers.

In the prototype, an open-source tool ProM is used to analyze the event logs [33] as shown in the following steps.

Step 1:

Control flow mining.

We choose a plug-in \(\alpha \) algorithm of ProM to discover the control flow of the SOA services calling as shown in Fig. 9.

In Fig. 9, the control flow of the business process of intra-provincial logistics is displayed.

Step 2:

Role relations mining

Users involved in the business processes are classified and divided into different roles according to the performer–activity metrics.

In this step, we use plug-in called social network tool in ProM to calculate the distances between two performers. It could be seen in Fig. 10 that in this case study, the performers could be divided into three types of roles, named drivers, delivers and logistics assistants, belonging to two work groups, named intra-provincial work group and extra-provincial work group.

Fig. 10
figure 10

Generated work groups

Full size image

Because the logistics company in this case study has two types of customers running intra-provincial and extra-provincial business separately, the users are divided into two work groups. It could be seen that in this case study, the mining results are consistent with the real situation of the analyzed company. Therefore, the mining results could help the business process designers better understand the business processes of the companies.

Step 3:

Data flow mining

In data flows, the constrain conditions which trigger the activities could be obtained by counting the values of the business objects involved in the business processes. In this case study, we use decision-tree algorithm implemented in ProM [19] to calculate the values of the business objects, and the results show that two business objects TransportPlan and ShippingOrder are critical in this business process, as demonstrated in Fig. 11. They are the attributes related to shipping activities in the logistics process. The result shows that the task “check shipping order” will check the shipping destination and current location recorded in TransportPlan and ShippingOrder , respectively. If TransportPlan.Destination != ShippingOrder.CurrentLocation, “transit shipment” will be carried out, otherwise, “make transportation plan” will be carried out.

Fig. 11
figure 11

Data flow mining

Full size image
Fig. 12
figure 12

Scenario generation

Full size image
Step 4:

Scenario generation

According to the results obtained in steps 2 and 3, the control flow shown in Fig. 9 could be divided into several scenarios based on the algorithm shown in Fig. 6. Scenarios for the extra-provincial businesses are synthesized into one comprehensive business processes, as shown in Fig. 12.

In Fig. 12, three scenarios are generated; each scenario corresponds to one type of roles, which are driver, delivery man and clerk, respectively. In these scenarios, business objects, tasks and roles are closely related to show the business processes more clearly to the business processes designers and SOA services developers.

In this case study, it could be seen that business processes are traced in the event logs of SOA service invocations. In our method, we use \(\upalpha \) algorithm to mine the control flow of the business activities. After that, role relation and data flow mining algorithms are used sequentially at each point of activities along the generated control flow to obtain information about the required human resources and data entities during business process performing. These detailed business contexts may help designers to monitor and optimize the business process more clearly.

5.2 Discussion

In the above case study, the prototype of the cloud logistics management platform was developed according to the real requirements of the logistic companies. We have simulated the running of the platform in the laboratory and generated an extra-provincial business scenario using event logs to show the effectiveness and applicability of our proposed method. We compare the scenario-based business process modeling method with multi-view business modeling methods such as ARIS [34] and Artifact [35]. Our comparison is based on provision of various functionalities in the proposed method rather than on comparison of logs collected as a result of running platform.

Table 3 Comparison between business process modeling methods
Full size table

Table 3 demonstrates that the scenario-based business process model has the following advantages.

  1. 1.

    More flexible for business modeling. Since the scenarios could be regarded as a process-centric artifact, the scenario could be easily encapsulated as business model and transformed for different disposing purposes. Business process management systems may be achieved by the scenarios conveniently and modified through recombining these scenarios or adding new scenarios. For instance, if the business process in the case study should have a new part of asking help from external experts having existed in the scenario repository, it could be directly inserted into the process in accordance with the requirements.

  2. 2.

    A comprehensive view for process optimization or refinement. Since the scenarios contain not only process model but also data objects and roles, we could refine the business processes based on more detailed contexts of run time. This could increase the efficiency of business process modeling.

6 Conclusion and future work

In this paper, we emphasize three factors in business process analysis: the roles which invoke the SOA services, the business objects required in the business processes and the control flows of the activities. We adopt the concept of business scenario to analyze and optimize the business process models based on the data of event logs. Two main contributions are summarized as follows:

  1. 1.

    A method for scenario discovery using three perspectives of process mining is proposed to construct comprehensive business process models. In this scenario generation method, roles are centric. The users are classified into roles and work groups according to their distances calculated on the metrics of performer–activity. Activities related to the users are added into the scenarios to expand the covering range of the business process. The control flow structures are used to determine the relations between the roles. The scenarios are enriched by the constrain conditions calculated from the data flows.

  2. 2.

    The scenario model is proposed for analysis and improvement in business process modeling, which is highlighted by its flexible composition and overall comprehensibility for technical or non-technical people. And the usability of scenario-based process improvement is discussed, including the scenario reconstruction and modification.

Although scenario-based technologies used in our research have shown advantages in capturing users’ requirements for SOA systems development, the proposed method of scenario generation has limitations. The services invoked in the SOA systems should be well defined and the running traces should be recorded in the log files so that elements such as roles, activities and control flows could be extracted from the log data. In addition, the accuracy of the business process models built on the scenarios in our approach varies depending on the choices of the process mining algorithms.

Our future research will focus on following issues.

  1. 1.

    Algorithms need to be designed for mining more complex relations among the users involved in the business processes. Only simple relations such as clusters and rough hierarchical relations could be discovered in this paper. Algorithms need to be proposed to obtain more accurate sequential and hierarchical relations widely existed in the organization structure from the log files of SOA systems.

  2. 2.

    Methods of merging distributed scenarios need to be studied in future. In cloud computing, services are deployed in distributed environment. In this paper, we use SOA services invoking logs centralized on service sides to analyze the business scenarios. The scattered scenarios are merged according to the control flows mined from the centralized event logs of SOA service invoking. Further research is needed to deal with the situation where event logs are scattered.