A Business Transaction Agent architecture Wout Hofman 1 1 TNO, Brassersplein 2, Delft, the Netherlands Abstract. Enterprise Resource Planning systems (ERP) support enterprises in managing inand outflow according economic events like sales and purchasing as specified in the Resource, Events, Agents (REA) model. Many of these ERP systems are not able to deal with real time data to optimize value exchange with customers and service providers. This contribution presents work in progress of the operation of a business transaction agent architecture. The architecture is able to handle real time data. The architecture separates value chain design and coordination with real time data from transaction management in binary collaborations with an agreed choreography. Each agent has a rule set accessing a data layer with public/subscribe functionality. Keywords: business transaction management, rules, agents, interoperability, data sharing, REA 1 INTRODUCTION Networked business models allow companies to conduct business in a more effective way by for instance redistributing tasks between organizations (Legner & Lebreton, 2007). Enterprises are required to quickly set up electronic relationships with their (potential) customers and suppliers for exchanging value like modelled by for instance the Resource, Events, Agent (REA) model (Hruby, 2006). Customer s goals are matched with capabilities (Fensel, Kerrigan, & Zaremba, 2008) and dynamically value chains are composed and orchestrated (Hofman W. J., 2012). Dynamic service composition for technical services has been extensively researched (e.g. (Goncalves da Silva & al., 2009)), but dynamic service composition and process support of business services still requires further research. Some take a business perspective by defining business transactions spanning global supply chains based on multi-actor collaboration (Heuvel & Papazoglou, 2010), but each enterprise operates autonomously in a business network, which leads to value chains that differ from reference models. Under the assumption that enterprises are able to share data electronically, they have to behave according to agreed choreographies, dynamically compose value chains, and, adapt these chains to real time changes. This paper discusses an innovative architecture for real time design and coordination of value chains. Coordination is able to handle exceptions based on binary collaboration according a choreography. This paper does not discuss structures of value chains, but specifies IT functionality for enterprises to deal with a changing environment. A case demonstrating the concepts is given by (Hofman W. J., 2012). It is taken as a running example in this paper and not presented separately. The case considers a forwarder organizing sea transport from a dispatch place to a destination on behalf of his customer, a shipper. First of all, enterprise concepts are briefly presented and applied to logistics. Secondly, a functional decomposition of agents controlling value chains by data sharing for value exchange by business transactions is presented.
2 ENTERPRISE CONCEPTS This section introduces enterprise concepts for binary collaboration, illustrated by transport services. Multi-party collaboration in an organizational network is supported by business process orchestration of each of the actors within that network, thus composing value chains in that network (Spohrer, May 2009). Concepts for binary collaboration are based on event-action theory (see for instance (Bratman, 1999) and (Kim, 1993)), accountancy theory (Hruby, 2006), service science (Spohrer, May 2009), and e-business ontology (Osterwalder & Pigneur, 2002). It results in the following concepts: Business activity: a classification of economic events (Hruby, 2006). Resource: equipment and/or labor. A resource has particular characteristics, e.g. it can be used only once by a business activity (it is consumed and converted into another resource (Hruby, 2006)) or is re-useable but requires maintenance (it is used (Hruby, 2006)), or is produced by conversion of consumed resources utilizing used resources. Business service: an instance of a business activity as provided by an agent. Value proposition (Spohrer, May 2009) is a synonym for business service. Business transaction: actual value exchange (Gordijn & Akkermans, 2003) for a given business activity controlled by business signals according to a predefined business transaction choreography (Schonberger, Wilms, & Wirtz, 2009). A business activity requires input resources (the inflow (Hruby, 2006)) and produces output (the outflow (Hruby, 2006)). The inflow is taken from a place and produced at another one. Place can represent a physical location or a state, e.g. a container is transported from one port to another. Business events or business signals (Hofman W. J., 2012) are used to synchronize value exchange of customer and business service provider. An agreed sequencing of these business signals is modelled as choreography (Object Management Group, 2011). Our proposed choreography consists of four phases (Dietz, 2006), namely a booking phase to agree on conditions for value exchange, execution planning to specify how value exchange will take place, reporting by a service provider on value delivery, and cancellation. A booking phase can result in a framework contract in which more than one business activities can be executed and value is exchange more than once (Hofman W. J., 2012). A business activity has data properties that will have a particular value for each transport service. Properties of a transport activity classifying transport services relate to resources and in- /outflow: Consumed and produced resources with the following properties: o Type of Cargo: classification of resources from a transport perspective e.g. containers, dry bulk, packages, pallets, etc. o Physical characteristics of the cargo: weights (gross weight, net weight, tare weight) and dimensions (length/width/height, volume, over-dimension), both with lower and upper boundaries, e.g. the weight must be within a specific range, and a unit specifier, e.g. 'kg' for weights. o Specifics of the cargo: these refer to stowage and transport conditions, e.g. temperature setting (reefer cargo) and dangerous cargo, and any specifics requiring special handling or related to the value of the cargo. Between: two locations, regions, countries, etc. between which a service is provided. The between property specifies a geo-perspective in which for instance cargo can be transported between cities of one region and another region. A business transaction thus always needs to refer to a physical location in two regions, called place of acceptance and place of delivery respectively. Duration (min-max, average): the estimated duration of a service with minimum (fastest execution of the service) and maximum (slowest execution).
Used resources like trucks, vessels, and labour are normally not specified in a service. Services for packages from the Netherlands to Spain and a container shuttle service between the port of Rotterdam and Germany are examples of transport services. 3. BUSINESS TRANSACTION AGENTS This section specifies a business transaction agent architecture. A business transaction agent coordinates value chains to meet customer goals by business transactions with real time data. First of all, a generic understanding of the operation is given and secondly the individual components are introduced. 3.1 High level process description This section presents a textual description of how the architecture will work, at a later stage it will be specified by for instance activity diagrams. A customer requiring a particular goal initiates the operation of a service provider by submitting a booking. That customer might have selected the service provider from a list of available transport services that have been published by various service providers. Upon reception of a booking, a service provider designs a value chain considering his own transport services and those of other providers. Value chain design results in a set of one or more options, each with characteristics like duration, price, and for instance carbon footprint. These options need to be analysed on their feasibility of execution, e.g. on price and available capacity. Mostly, logistic service providers and carriers publish their services without a price indication or availability of that service. A user selects a value chain for execution and identifies potential bottlenecks in that value chain, e.g. sea or air transport can be considered as a bottleneck in case particular delivery times set by a customer have to be met. These bottlenecks will be booked first. Upon reception of booking confirmation, a user can decide to arrange any remaining parts of the value chain, already initiate the execution of booked parts by issuing instructions, or provide a booking confirmation with a price and cost estimation to the customer. Selecting one of these options leads to different value chain coordination. When composing a value chain, a service provider can also combine goals of different customers or split one goal into two or more sub-goals. A forwarder can for instance decide to split a shipment over two or more containers (FCL: Full Container Load) or combine two or more shipments in one container (LCL: Less than Container Load). When coordinating a value chain, a customer is able to select a transport service based on real time data of capacity availability, e.g. transport to a port can be based on available transport capacity of for instance barges or trains to that port. Once particular parts of a value chain are in execution, a customer can detect exceptions with respect to his expectation and agreed planning, e.g. a traffic jam may cause a truck to be too late at its destination. These exceptions can be detected in two manners, namely a service provider may issue a changed plan adjusting for instance the estimated delivery time or the customer monitors relevant movements of transport means like trucks, vessels or barges for instance based on AIS data and calculates estimated delivery times itself. In both cases, rules are applied to detect if an exception occurs, e.g. too late arrival of a truck at a location may imply that a container cannot be loaded on a vessel whilst it has already sailed to another port. Potential rules that are validated are late or early delivery, under or over quantity delivered, and wrong product deliveries (a complete set of rules is defined by the EU FP7 SEC Cassandra project).
Fig. 2. Visualization of business requirements. Figure 2 visualizes this type of operation. Each business service is represented by a hexagon. These business services compose a network, they are published and can be discovered. The network does not show the enterprises providing the services; one enterprise can provide one or more services in this network. When receiving a goal, a value chain is composed (represented by the blue hexagons) and transactions need to be initiated. The lines connecting two business services in a value chain need transaction coordination. The red hexagon represents a business service that does not perform according plan, i.e. an exception is detected. The figure visualizes the required functionality, e.g. business transaction execution between an customer and service provider, detecting and handling exceptions like too late delivery, and value chain composition resulting in the blue hexagons. An innovative architecture needs to provide this functionality. 3.2 Components of a Business Transaction Agent Conceptually, business requirements are met by a set of components that share data via a shared data store. The assumption made in this paper is that the data store also implements a data management layer that keeps track of data changes. Data changes can be induced by components of a Business Transaction Agent or by physical sensors, e.g. AIS vessel data. Upon data changes, the data management function of the data layer generates events to which components can subscribe. A set of components constituting an agent has particular access rights to the data (Pruksasri, Berg, Hofman, & Deskapan, 2013). The data store contains business services, used, consumed, and produced resources with their location at a particular time, business transactions on these resources, and value chains composed of business transactions. Value chain optimization is by combining (e.g. package, stuff, or load) or splitting (e.g. unpack, strip, or discharge) resources like the loading of containers on a transport means. The structure of the data store is not further given; its Application Programming Interface is specified by the EU FP7 INFSO icargo project (www.i-cargo.eu). This paper provides a high level description of the functionality of three components: the Value Chain Composer, the Value Chain Coordinator, and the Rule Handler. A high level description is given, because a detailed specification of each of these components is a paper on its own. The other components are not described in more detail, since they are either already described elsewhere, e.g. the Performance & Compliance Monitor (Hofman W., 2013), is already developed as prototype, e.g. the Business Service Manager, or can be supported by standard software solutions, e.g. truck and stowage planning are examples of Resource Planner and the
Business Transaction Coordinator by a Business Process Engine that can be configured for the choreography. The Physical Action Evaluator is not discussed here; it is assumed that different algorithms are required to analyse the impact of changes of physical actions on transaction (see for instance impact evaluation of turn around time evaluation). First of all, coordination between components is briefly described and secondly these three components. Fig. 3. System Architecture and components of a business transaction agent. 3.2.1 Internal agent coordination The Rule Handler is the main component of an agent. It coordinates all other components by generating internal events based on data change evaluation. These data changes are triggered the other components of the same or another agents. Communication between two agents is always via the publish/subscribe mechanism of the data store. As soon as an agent is instantiated, it will receive an identification and automatically subscribe to all events with that identification as a recipient. Agent components subscribe to particular events generated by the data store and produce new events that are distributed by the scheduler, e.g. the Resource Planner handles events for planning the so-called used resources (Hruby, 2006) and the Business Transaction Executor handles business signals of the choreography (Hofman W. J., 2012). The following rules apply in processing business signals: The Value Chain Designer subscribes to bookings that initiate a new business transaction and in which the owner of an agent acts as service provider, i.e. it is the recipient of a booking. The Business Transaction Executor subscribes to all other business signals. It concerns business signals like booking confirmation, instruction, planning, report, and cancellation. 3.2.2 Rule Handler This component schedules the execution of all other components of an agent by receiving events, making these events available to others, and generating events. The Rule Handler generates events itself by analysing state changes. The data store generates events representing a state change, which will be called internal events since they are internal to an agent. Generating these internal events requires a set of rules that are evaluated. Two types of rules are distinguished, namely those that are triggered by sensor data and require recalculating physical actions, e.g. a traffic jam requiring resulting in late arrival at a terminal and a recalculation of turn around times for a truck at that terminal, and rules that evaluate the effect of these changes on transactions, e.g. the impact of changed turnaround times on activities of trucks that require informing a customer of later
arrival at his premises. This contribution presents an example of late delivery. Upon having changed the actual location and time for the start and/or end of a service, i.e. the cargo is loaded and/or discharged at a place of acceptance and delivery respectively, the data store generates an internal event that is handled to which the Rule Handler is subscribed. Late delivery is defined as: the actual delivery - or discharge time at the place of delivery is later than the estimated time. In case the service is succeeded by another service and the delivery time is later than the latest loading or pick up time of that other service, that other service needs to be cancelled. If not, the other service receives an update of times. An example is a truck that arrives later at a terminal to deliver a container, but loading of the vessel is already completed. The EU FP7 SEC Cassandra (www.cassandra-project.eu) has identified a number of these rules. The turn around time issue is addressed by the EU FP7 DEMANES project (www.demanes.eu). The rules also need to be formalized in terms of pre-condition, firing rule, and post-condition. 3.2.3 Value Chain Designer The Value Chain Designer produces a set of one or more value chains to reach particular goals. These goals are formulated in terms of business activities and their data properties, e.g. the type of cargo, locations for transport like place of acceptance and delivery, times at which the cargo is available for transport and has to be available after completion of transport (see the previous section). Goals can be combined with others, e.g. stuffing shipments in one container, or split. Once it is decided that goals are combined or split, value chains can be composed based on available business services. Only those business services are discovered that match the goals in terms of consumed or produced resources, and that are able to compose a value chain between the locations mentioned in a goal and meet time requirements of a goal. Business services may overlap in the values for 'between'; the Value Chain Designer needs to calculate a proper set of value chains meeting goals with price, time, and carbon footprint as potential selection criteria. A value chain is modelled by a set of one or more transactions that have a relation in terms of time and place with consumed and produced resources. Each transaction represents a goal in its own. The sets of value chains produced by the Value Chain Designer are suggestions to a user that is able to select, adapt, and execute one of these value chains. For instance a forwarder can select several value chains for outgoing cargo: cargo can be transported from a dispatch place to a stuffing center by road, stuffed with other shipments in a container (LCL), and transported by barge to a port of loading. In case of FCL cargo, a shipper offers a container for transport that can be transported directly to a port of loading. The Value Chain Designer also proposes one or more service providers for each of the selected services in the value chain, thus providing several options for execution. A first prototype of the Value Chain Designer is developed in the EU FP7 INFSO icargo project. 3.2.4 Value Chain Coordinator This component supports a user in coordinating the execution of business transactions for a value chain by selecting, adapting, and executing one of the value chains produced by the Value Chain Designer. Selection is based on various criteria like price, duration, and carbon footprint. Considering these criteria, a user also needs to select one service provider for each service in the chain or can consider other services based on for instance real time data on available capacity. With respect to selection of a value chain or service provider in a value chain, a user is faced with different options. First of all, a user can select to confirm a booking based on past behaviour and price estimations of similar value chains. Without booking any of the services composing a value chain, it is confirmed to the customer. Secondly, a user can select one service provider that is crucial to all other parts or is a bottleneck. For instance, selecting a particular shipping line and vessel for sea transport determines the port of loading and discharge for sea transport. All other services will be organized around the sea transport service. Based on a booking confirmation of
such a determining service, thirdly, a user can decide to confirm the booking, potentially arrange other service around this determining service, and initiate execution after receiving a confirmation of a customer. Selection thus leads to execution and value exchange of one or more services in a value chain. If there exceptions, like late delivery of one of the services in a value chain, occur, the value chain needs adaption. The Rule Handler detects these exceptions. 4 CONCLUSIONS This paper identifies a set of components a business transaction agent based on rules coordinating various activities of for instance planners. A separation is made in value chain design and its implementation that is able to handle exceptions triggered by state changes of data that are either induced by sensor data or by service providers reporting state changes. The components deal with real time data. The structure and functionality of the data store is for further research, but it is assumed that all agents have access to their data based on access rights shared by for instance business signals of transactions. Although accounting and auditing are quite complex, they evaluate data of the data layer to validate if business processes and separation of concerns are properly implemented. This contribution however considers basic functions like value chain design, - coordination, and execution, coordinated by rules leading to real time business process configuration. Thus, separation of concerns for instance cannot be related to particular actions in a business process, but need to be linked to a classification of actions. For instance, a planner can operate the Value Chain Coordinator and customs transactions and their data are handled by another role transport transactions. Further research is required in specifying applicable rules and auditing them by for instance a particular Performance & Compliance Monitor for accounting. ACKNOWLEDGEMENTS The work presented in this paper is funded by the EC FP7 SEC Cassandra project (www.cassandra-project.eu), the EC FP7 INFSO icargo project (i-cargo.eu), and the Dynalog Extended Single Window project. REFERENCES Bratman, M. (1999). Faces of intention. Cambridge University Press. Dietz, J. (2006). Enterprise Ontology, Theory and methodology. Springer-Verlag. Fensel, D., Kerrigan, M., & Zaremba, M. (. (2008). Implementing Web Services - The SESA Framework. Springer-Verlag. Goncalves da Silva, E., & al., e. (2009). Supporting Dynamic Service Composition at Runtime based on End-user requirements. User generated services workshop, International Conference on Service Oriented Computing (ICSOC), (pp. 23-27). Stockholm, Sweden. Gordijn, J., & Akkermans, H. (2003). Value based requirements engineering: exploring innovative e-commerce ideas. Requirements Engineering Journal, 8(2), 114-134. Heuvel, W.-J. v., & Papazoglou, M. P. (2010). Towards Business Transaction Management in Smart Networks. IEEE Computing Society. Hofman, W. (2013). Compliance management by business event mining in supply chain networks. VMBO2013. Delft. Hofman, W. J. (2012). Runtime logistic process orchestration based on business transaction choreography. Business Process Management - Process Aware Logistic Systems workshop. Talinn. Hruby, P. (2006). Model-Driven Design using Business Patterns. Springer-Verlag.
Kim, J. (1993). Supervenience and mind: selected philosophical essays. New-York: Cambridge University Press. Legner, C., & Lebreton, B. (2007). Business Interoperability Research: Present achievements and upcoming challenges. Electronic Markets, 176-186. Object Management Group. (2011). Business Process Modeling notation (BPMn), version 2.0. Object Management Group. Osterwalder, A., & Pigneur, Y. (2002). An ebusiness Model Ontology for Modeling ebusiness. Proceedings of the 15th Beld Electronic Commerce Conference - ereality: constructing the eeconomy, (pp. 75-91). Bled. Pruksasri, P., Berg, J. v., Hofman, W., & Deskapan, S. (2013). Multi-level access control in the data pipeline of the international supply chain system. icets. Macau. Schonberger, A., Wilms, C., & Wirtz, G. (2009). A requirements analysis of Business-to- Business integration. Bamberg: Fakultat Wirschaftsinformatik und angewandte Informatik Otto- Friedrich-Universitat. Spohrer, J. K. (May 2009). Service Science, Management, Engineering, and Design (SSMED) - An emerging discipline - Outline and References. International Journal on Information Systems in the Service Sector.