 |
|
|
Abstract
The European openXchange project started last year, and progress has been on several related ebXML topics. The openXchange reference architecture consists of a modelling, profiling, agreement and transaction phase, based on ebXML. The main ebXML documents are outputs from each phase. The BPSS is the output of the modelling phase, CPP is the output of the profiling phase, and finally before the transactions can take place the CPA is the result of the agreement phase. Each phase is further decomposed in the reference architecture. Some of the components that are needed and currently not available will be developed by the software partners within the openXchange consortium. These software components will be used in the pilot user sites.
Within Germany as well as in the Netherlands two pilot sites will be used to test the software components, to evaluate the openXchange framework, but also to validate the ebXML concepts. The first pilot site in the Netherlands is between NUON (an utility supplier, and also a large demander of temporary staffing) and Manpower (supplier of temporary staffing) and will be used for dealing with the timesheets and invoices based on ebXML messaging. The second pilot is in the Building & Construction industry between Stoel van Klaveren (supplier of building materials) and Slokker (customer) and aims to automate the process of ordering materials within a framework contract. Although both pilots are between two companies, they want to use standards for reusing the components in a later stage to do automated business with other partners as well.
One of the remaining issues in ebXML is that of automatic matching of profiles (CPP) and BPSS files. Creating a cpa from two cpp files is not a trivial process. One of the main problems is comparing the referenced bpss files. Current research, done by openXchange in combination with the University of Twente, includes matching difference in sequence of activities, the use of pre and post conditions and the contents of messages (based on core components). The difference in sequence usually originates from the use of parallelism that can be tackled by using Birkhoff’s duality theory. The first steps to create an algorithm for matching business activities will be visualized.
Table of Contents
The EU-funded openXchange project (IST-2000-28548) started February 2002, and is undertaken by a European consortium consisting of TNO, Berenschot, and Fraunhofer amongst others. The openXchange project aims on the development of a reference architecture for software applications that support the automation of inter-organisational business processes, based on ebXML. In pilot user sites in as well Germany as the Netherlands, the applications will be implemented and evaluated. This paper will address three openXchange topics:
1. The openXchange reference architecture
2. The openXchange pilots in the Netherlands
3. Process Matching
This paper will not explain ebXML in detail, as there are many other papers[LB02] related to that topic. However to define a reference architecture that is based on ebXML, a basic understanding is necessary. Four main activities are identified for doing business the ebXML way [LB02]:
1. Standardising of messaging and processes
2. Recording of company profiles
3. Arranging an e-business agreement
4. Run-time of e-business process
These four activities are transformed into phases in the openXchange reference architecture, with some simplified naming as shown inFigure 1. The following sections contain a description and an introduction of the related openXchange architecture for these four different phases of business process integration. However, this information will be quite compact and for more information the author can be contacted.
The modelling time specifies the business process for a certain industry or domain. Due to the fact that a general standardisation of business processes is hardly possible to achieve and, moreover, not desirable, openXchange specifies sectoral sets of business process components. One sector, for example, is ‘Temporary Staffing’ as it is used for procurement of temporary workers companies independent of their size, industry or location.
The sets of business processes are identified and specified for each domain within the user requirement analysis of the openXchange project. The result is then modelled in UML. The only component necessary for the Modelling Time is a business process modelling tool. Within the openXchange the BindStudio tool is used for modelling the business content and the creation of ebXML output. The modelling time provides harmonised business process components that serve as input for the following Profiling Time. The main output of the modelling time is the Business Process Specification Schema (BPSS).
The real e-business transactions take place in the transaction time. The instantiation of a business process starts by means of a trigger (for example from an ERP system). Business documents are then exchanged according to the business process, and technical restrictions specified in the Collaboration Protocol Agreement (CPA) with a reference to the common ‘enhanced’ BPSS.
At Transaction Time the architecture consists of six main openXchange components (see Figure 2):
'Business Document Service' to validate single documents against specified restrictions.
'Business Process Service' to log and control the process execution.
'Messaging Service' to send and receive openXchange compliant messages.
'Cartridge Service' to provide the connection to existing information systems (e.g. ERP systems).
'Specification Access Services' to provide access to the relevant XML documents.
'Administration Service' to allow administration of the environment.
These components are explained by the following example.
The business process instance is triggered by the event of the receipt of a purchase order in a specified XML based format, by the openXchange Messaging Service. After receipt the openXchange Document Service checks the transmitted information on feasibility and also checks whether the receipt of a purchase order is in line with the commonly agreed process. If so, the data gets posted into the underlying ERP system, which creates a response using the openXchange Cartridge Service again. The response is then formatted according to the specified formats and sent out to the business partner where the business process is continued.
Within the Netherlands the focus is on the temporary staffing industry and building & construction industry. For both domains some UMM based business process modelling has taken place, resulting in an ebXML compliant business process model (BPSS). The guidance in this phase from UMM, was not as expected. Especially the use of the “worksheets” was sometimes vague, and at first-glance redundant. A simplified UMM is being developed, which addresses many of our issues, but still an UMM with more guidance and more efficient to use would be really welcome.
After finalising the process models, for each domain one pilot is initiated. For the temporary staffing this is the pilot between NUON (buyer of temporary staffers) and MANPOWER (supplier). The landscape of the pilot is shown in Figure 3
Both companies are aiming for a business case, to assess possible future implementations of ebXML. Therefor a very simplistic scenario has been chosen, that of sending a timecard from NUON to MANPOWER. This means that the business process consist of only one collaboration with one business transaction with one business document. The creation of the BPSS should not be that difficult. On the other hand the creation of the timecard business document will be more time consuming. The timecard specifications of the hrXML/SIDES projects will be the fundament of the timecard business document, but still needs to be adapted to the Dutch situation and specific for an ebXML environment. But both companies do want a “standardised” timecard business document as they want to use it in communications with other companies as well. Within the Modelling phase of the openXchange reference architecture this is within the pilot the only point of interest. The Profiling and Agreement phase will be done by hand, by creation of the Collaboration Protocol Profile (CPP) files and CPA file. No registry or automatic matching within this pilot.
The Transaction time is more exciting as we are dealing with a complex system landscape within NUON and MANPOWER. The drawing in figure 3, is very simplified related to the system landscape. The NUON system landscape is SAP based, although not all SAP systems are linked. Central will be the SAP HR system for sending the timecard. The openXchange Cartridge Service will convert the Timecard data into an ebXML message. When needed information from the BPSS can be used within this Cartridge. The openXchange Business Process Service can be seen as the process monitor. The openXchange Messaging Service is the sender and the receiver of the ebXML messages. In here the message will be send from the NUON to the MANPOWER domain. Again the openXchange Cartridge Service will do the translation to the MANPOWER internal systems.
Within several weeks it should be possible to exchange timecards between NUON and Manpower the ebXML way, and then decisions can be made based on the business case. If successful, continuation seems obvious but then for a broader business process including for instance invoices.
Although ebXML offers a complete framework for doing e-business, there are still some gaps to fill. Once a company’s cpp is published, business partners have to be found to do business with. Finding a suitable business partner includes comparing business profiles and business processes. Currently, the ebXML framework does not support a way for doing this in an automated way.
Creating a cpa from two cpp files is not a trivial process. One of the main problems is comparing the referenced bpss files. In the ideal case a branch organization published the necessary files and the companies in question only reference these files. If both companies reference the same bpss and both take a different role, we speak of a trivial match. This doesn’t necessary have to be the case. Two companies may still be able to do business even though they reference different bpss files. In order to determine this, the different bpss files have to be compared.
A bpss file can describe both binary and multiparty collaboration. When referencing a bpss, a company can participate in several binary collaborations, but necessary all of them. If a company wants to do business, it has to find business partners for all the relevant binary collaborations it participates in. If a candidate partner is found, the companies binary collaborations has to be matched with that of the possible partner in order to check whether they are compatible.
Before developing an algorithm that can compare two binary collaborations, the definition of compatible has to be clear. Since a binary collaboration specifies the possible business scenarios a company supports, intuitively two binary collaborations are compatible if a business collaboration scenario exists that is supported by both binary collaborations. Since binary collaborations are modeled as activity diagrams, this comes to comparing the two sets of possible traces of both activity diagrams. This brings us to the following preliminary definition: “Two binary collaborations are compatible if the intersection of the sets of traces contains at least one trace that leads to success”.
The definition may look all right at first glance, but there are some problems. In the preliminary definition, the assumption is made that both binary collaborations use the same activities. Apart from the problem of determining whether two activities are the same, two companies may still be able to do business even though their binary collaborations describe different activities. One case in which this can happen is if one of the companies spreads a certain amount of work over two activities while the other models it as one activity. This can occur because an activity is not atomic in nature but can be refined by describing the documents. The same problem can occur at document level.
Documents consist of core components and one company may split a document in two separate documents. Since the (semantic) consequences of splitting up a document have not been researched yet, this possibility is not taken into consideration. Documents are matched on similarity by comparing the Business Information Entities that form the documents. This leads to a refined definition of compatible: “Two binary collaborations are compatible if the intersection of the sets of possible traces of exchanging similar documents contains a trace that leads to success.”
The second problem has a mathematical background. According to the definition, the set of all possible traces of both binary collaborations has to be determined. But if the collaboration contains a cycle, this number is infinite and cannot be determined. In graph theory the proper way of solving these kinds of problems is called (bi)simulation. If simulation is to be used, a third collaboration must be created (in a automated way) that is simulated by both. The problem with this approach is that simulation is defined for graphs, and graphs can’t express parallelism. Since activity diagrams support parallelism, standard simulation cannot be used.
According to [PRA91], a model using true parallelism (like activity diagrams) can be transformed into a model describing branching time (or interleaving) parallelism by using Birkhoff’s duality theory. This transformation can only take place though if the states (here activities) are atomic in nature. The activities used in ebXML are not, so in order to apply the transformation, a refinement has to take place. The arrival of documents (or signals) in ebXML is atomic, so if the binary collaboration can be refined in such a way that each document arrival represents an activity, this transformation can be made.
After the refinement has been made, the collaboration diagrams can be transformed into reachability graphs. Standard reachability graphs do not completely satisfy the demands. Consider the following scenario, using activity diagram A in Figure 4(the used fork is a ‘AND forks’). After the run A,B the reachability graph should contain a node (CD) since both C and D are reachable. After the occurrence of C, only activity D is reachable. Another run that leads to the node (CD) is A,B,D,E. After the occurrence of C, both D and F are reachable. Obviously node (CD) in the first case is different from (CD) in the second. To make a distinction between these two occurrences, trace history is added to the graphs.
After adding the concept of trace history to the reachability graphs, activity diagrams A and B can be transformed into graphs A and B. A simple set of rules can be used to compare both graphs. The result of the comparison is a reachability graph C Figure 6that is simulated by both graph A and B. According to the earlier mentioned definition, activity diagram A and B are compatible. Graph C can be transformed in activity diagram C. If activity diagrams A and B represented binary collaborations where two companies both toke a different role, binary collaboration C is the “agreement” between both business processes and should be referenced by the CPA.
This paper is an introduction to some topics from the openXchange project: the reference architecture, the pilots and process matching. The architecture is finalized and used for the pilots and the creation of openXchange software. The pilot project in the temporary staffing domain is running smoothly, and the first ebXML messages should be running soon now. Both NUON and MANPOWER believe in the wins that can be created by using ebXML, and now the situation will be created to show off some of the possible wins for the future.
A first step is made in automated business process matching. In order to come to a fully automated agreement time, certain aspects of ebXML have to be included in the algorithm. Document assembly will have priority since this is needed in order to determine whether two activities are compatible. Other aspects like pre and post conditions should first be formalized in the ebXML specification before they can be used in the matching algorithm. Work on these topics is still in progress.
  |
Design & Development by deepX Ltd. |
