An electronic commerce portal that is used by a special group of users in an intranet supports business-to-employee (B2E) transactions [10]. In this case, business transactions between management and employees, but also business transactions among employees are electronically supported. This requires the use of different software systems (e.g. a legacy system, shop system, web system, internet system, office system). Thus, an electronic commerce portal also acts as an integration platform for heterogeneous software systems [7].

The IPSI (Internet Portal System for Insurances) electronic commerce portal [4] is intended to support insurance agents in their daily work, using the electronic commerce portal in an intranet with the objective of optimal support of B2E transactions. For example, the insurance agents need access to information about their private and incorporated clients. Their work is also supported by a scheduler with reminder function, address book etc. Additionally, the insurance company uses the portal to supply its employees with up-to-date information on the product portfolio, tariffs and legislature. An electronic commerce portal thus has to offer a multitude of functions. The advantage of the portal is the integration of different software systems that provide these functions, so the user can be guided directly to the needed information without having to perform awkward searches or sifting through unwanted information.

The user interface of the IPSI electronic commerce portal can be a WWW or WAP browser. The integrated software systems are termed subsystems. For subsystems that do not have their own data management functionality, a relational database management system is used.

The functionality of the subsystems office, content management, procurement and communication is provided by existing external systems which are integrated into the electronic commerce portal via adaptors (see Figure 1). Through combinations of the subsystems' functionality, new functions of the whole system are created. These are oriented towards the business processes (workflows) of the users: For example, to read an important contract date from the partner database legacy system, write an according note in the scheduler of the office system and initiate the transmission of a reminder message to the user's pager via the communications system, a series of different actions would be required using separated subsystems. Using the electronic commerce portal, however, the insurance agent can accomplish this task in a few steps.

Figure 1. Architecture of the electronic commerce portal.

The business processes search and portal administration are handled by the search and the admin controllers, while all other business processes that involve subsystems are handled by the workflow controller.

Controllers and subsystems communicate by exchanging business objects, i.e. entities that have central significance for the business processes in the electronic commerce portal. "Business objects behave in a manner that is representative of real-world situations, and that makes sense to business experts" [1]. The business objects user, contact, appointment, task, message, shop item, order, order history, search request and search result are therefore known to all controllers and subsystems.

For example, to enter an appointment into the scheduler, the workflow controller creates an appointment object from the data received from the dispatcher and passes it to a method of the office subsystem that inserts the appointment into the calendar of the user. If the user wishes to be reminded of the appointment by e-mail, the workflow controller additionally creates a message object, connects it to a copy of the appointment object and passes it to the communications system, where it is inserted into the queue for e-mail messages and sent at the appropriate time.

< 1. Introduction | 3. Process description >