Integrating enterprise support systems

<u>Background</u>

This application relates to integrating application programs such as enterprise support systems and business support systems (BSSs) and operational support systems (OSSs), and in particular to a method of exchanging information among application programs executed on one or more computers, to a computer system for facilitating the exchange of information among applications, and to machine readable instructions for the same, embodied in a tangible medium or as a propagated signal or both. A BSS typically is a computer application with which users or other computer processes interact to support normal business functions. BSSs are used across a wide variety of industries including telecommunications, energy, pharmaceutical, government and the like. Examples of BSSs include customer relation management (CRM) applications, billing applications, financial applications, and provisioning applications. OSSs on the other hand relate to the framework of computer software and network architecture underlying the operation and execution of the BSSs. An application for monitoring and/or managing the state of a computer network is one example of an OSS.

Typically, a single enterprise (e.g., a telecommunications provider) will maintain several BSSs and OSSs (collectively, enterprise applications) that need to share information or otherwise interact. For example, a telecommunications provider may have a provisioning application for turning on/off switches to control its customers' access to telephone lines or other services, a billing application for automatically generating bills to be sent out to customers, a CRM application for maintaining a database of its customers and for dealing with service calls, complaints and the like, a financial application for handling general accounting functions, and a network management application for managing the underlying network that supports the various enterprise applications.

<figref idref="f0001">Fig. 1</figref> shows a conventional method of integrating multiple enterprise applications. As shown therein, different applications communicate and/or exchange data with one another through specialized point-to-point interfaces (e.g., application program interfaces, or APIs) designed and implemented specifically for certain processes operating within the two applications being connected. Depending on the particular enterprise and the types and number of enterprise applications that it maintains, the number and complexity of point-to-point interfaces that must be designed, implemented and maintained can become significant. For example, the enterprise in <figref idref="f0001">Fig. 1</figref> has eleven different applications that require at least 21 separate point-to-point interfaces between processes. In practice, the number of point-to-point interfaces required can greatly exceed the number of enterprise applications because any two applications may require multiple point-to-point interfaces between them - one for each pair of processes that need to communicate.

In general, implementing and maintaining such specialized point-topoint interfaces is time-consuming and expensive, not only because of the sheer number of point-to-point interfaces that may be required but also due to the complexity and disparity of the applications being connected. For example, different enterprise applications, especially those provided by different manufacturers, may use different programming and/or control languages, may rely on different data models, and generally present several different levels and types of incompatibilities.

Methods for distributed programming applications are known. For example, <nplcit id="ncit0001" npl-type="b"><text>Emmerich W: "An overview of OMG/CORGA", UNIVERSITY COLLEGE, LONDON, 22 October 1997, pages 1-1</text></nplcit>, is an overview of CORBA, a standard for heterogeneous and distributed application integration. In <nplcit id="ncit0002" npl-type="b"><text>Hasselbring W: "A generative communication service for database interoperability", COOPERATIVE INFORMATION SYSTEMS, 1998, PROCEEDINGS, 3RD IFCIS INTERNATIONAL CONFERENCE ON NEW YORK, NY, USA, 20-22 AUG. 1998, LOS ALAMITOS, CA, USA, IEEE COMPUT.SOC.US, 20 August 1998, pages 64-73</text></nplcit>, there is disclosed a method of processing for supporting interoperability of cooperative information systems.

<patcit id="pcit0001" dnum="WO9637817A1"><text>WO 96/37817 A1</text></patcit> describes a data conversion system and method which converts data between different software and hardware platforms. Data from any number of different types or formats from any of various platforms are converted to a single common data standard having a pre-defined generic data type, and the data is then converted from this generic type to a new desired format or type and stored on an existing or new destination platform.

<patcit id="pcit0002" dnum="US5608874A"><text>US 5,608,874</text></patcit> describes a system and a method for automatically receiving, at an intermediate processing location, data from a wide variety of remote sources, identifying the format of the data, translating the data to a common file format, sending the data to a recipient in an intermediate format, then translating the data to the specific format needed by the particular recipient. Error checking features ensure that the transferred data matches the original data although the format is altered, and documentary receipts are sent to each section of the system that sends data, and logical, statistical and mathematical operations may be performed on the data.

<patcit id="pcit0003" dnum="US5119465A"><text>US 5,119,465</text></patcit> describes a data structure format conversion system comprising a front end converter, a back end converter, and a converter executive. The front end converter converts a source data structure in a source format to data in an intermediate format. The back end converter converts the data in the intermediate format to a target data structure in a target format. Finally, a converter executive controls the front end converter and back end converter to effect a conversion from the source data structure in the source format to the target data structure in the target format, through the intermediate format.

<patcit id="pcit0004" dnum="GB2354913A"><text>GB 2 354 913 A</text></patcit> describes a message broker that can receive messages on a given topic from a number of publisher applications. These messages are received at a plurality of publication points, which are data processing nodes at the beginning of specific processing paths through the broker. The messages may be processed by the processing path, for example a transformation, before arriving at a subscription point. From here the message is forwarded to subscribers interested in the subject matter of the message. The system allows the use of a single topic name to identify the subject of the message throughout the system.

<u>Summary</u>

Aspects and embodiments of the invention are set out in the accompanying claims. One aspect can provide a method according to independent claim 1. In other aspects, there may be provided a computer system and machine readable instructions as defined in the further independent claims..

The present inventors recognized that building and maintaining separate point-to-point interfaces between enterprise applications is cost and time inefficient. Consequently, the present inventors developed various systems and techniques for integrating enterprise applications using an underlying framework of components and tools that dramatically reduce the time and effort required. Implementations of these systems and techniques may include various combinations of the following features.

One or more of the following advantages may be provided. The techniques and methods described here result in an end-to-end solution to pre-integrate CRM, billing, provisioning and other BSS and OSS systems.

The integration hub is able to integrate virtually any type of application, whether pre-packaged, custom-built, legacy or other dissimilar systems.

Accordingly, the integration of disparate systems can be accelerated with corresponding decreases in time, effort, cost and complexity. For example, both the initial development time and costs for integrating systems as well as the expense required for subsequent improvements and modifications can be reduced dramatically. As a result, an enterprise can easily and quickly become fully integrated to have real time visibility and control of the business and customer experience.

Moreover, the integration effort can be accelerated because the tasks are not started from scratch. Rather, a shared object model defines the data entities and the corresponding attributes. As a result, the integration effort is cost effective and the long-term costs associated with maintaining BSS and OSS systems can be reduced accordingly.

The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

<u>Drawing Descriptions</u>

<ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">Fig. 1</figref> is a block diagram showing point-to-point interfaces between enterprise applications.</li><li><figref idref="f0002">Fig. 2</figref> is a block diagram showing an example of how the integration hub may be implemented according to an embodiment of the invention.</li><li><figref idref="f0003">Fig. 2A</figref> shows an example definition and structure of a transformer class according to an embodiment of the invention.</li><li><figref idref="f0004 f0005">Figs. 2B</figref>, <figref idref="f0006 f0007">2C</figref> and <figref idref="f0007">2D</figref> collectively show an example definition and structure of a controller class according to an embodiment of the invention.</li><li><figref idref="f0008 f0009">Fig. 2E</figref> shows an example definition and structure of an acknowledgement class according to an embodiment of the invention.</li><li><figref idref="f0010">Fig. 3</figref> is a block diagram showing additional details of an example integration hub implementation according to an embodiment of the invention.</li><li><figref idref="f0011 f0012">Figs. 3A</figref> and <figref idref="f0012 f0013">3B</figref> collectively show examples of transformer rules according to embodiments of the invention.</li><li><figref idref="f0014">Fig. 4</figref> is a process flow diagram showing an example of a business event being generated and published by one application and subscribed to by another application according to an embodiment of the invention.</li><li><figref idref="f0015 f0027">Figs. 5A-5L</figref> are business event definition tables according to embodiments of the invention.</li><li><figref idref="f0028">Fig. 6</figref> is a block diagram of a channel architecture according to an embodiment of the invention.</li><li><figref idref="f0029">Figs. 7A</figref> and <figref idref="f0030">7B</figref> shows a Channel Architecture Definition table according to an embodiment of the invention.</li></ul>

<u>Detailed Description</u>

The present inventors have developed a framework, referred to as the "integration hub," for integrating BSS and OSS solutions based on an enterprise's particular objectives. The integration hub is built around enterprise application integration (EAI) middleware (specifically, "BusinessWare" v3.1 available from Vitria, Inc. in Sunnyvale, California) that provides an architectural framework, data requirements, and data conversion rules, which collectively facilitate the integration of "best of breed" enterprise applications such as CRM applications (e.g., Siebel eCommunications 2000, Clarify CommCenter v3.1), billing (e.g.. Portal Intranet v6.1, Lucent Arbor/BP V9.1), and provisioning packaged systems (Architel OMS v1.6.2).

<figref idref="f0002">Fig. 2</figref> is a diagram of an example integration hub implementation. As shown therein, the integration hub 200 uses Vitria to provide message translation 204 and facilitate the exchange of state information 202 among various enterprise applications 207-212 (e.g., order entry 207, order management 208, billing 209, provisioning 210, inventory management 211, fulfillment 212) and further facilitates communication and interaction among the enterprise applications 207-212 and various classes of end-users 213-216 (e.g., partners 213, suppliers 214, internal users 215, customers 216). The integration hub 200 communicates with each of the various entities 207-216 using a "connector" - a multi-layered software communication channel tailored to a specific enterprise application.

The integration hub is implemented as a distributed collection of software components that interact to enable enterprise applications to seamlessly and easily share information in the form of "business events." A business event represents an abstract function or activity that is common to many business systems, for example, create account, create order, cancel order, generate invoice, etc. The integration hub facilitates exchange of business events among disparate enterprise applications, for example, by translating, or transforming, business events from one proprietary format into another, via a common, shared format. There are six primary building blocks used in implementing an integration hub instance: process models, a shared object model (SOM), controller classes, transformer classes, acknowledgement class, and the channel architecture, each of which is described below. <ul id="ul0002" list-style="bullet"><li>Process Model - A process model defines a process of when to send a business event from a first enterprise application (e.g., a provisioning system) to one or more other enterprise applications (e.g., a billing system) and further defines what information is needed for each system. A separate process model is defined for each different type of business event used in the integration hub implementation. For example, depending on the specific enterprise applications involved and the particular objectives of the enterprise, a "cancel service" process model could be defined that upon detecting the creation of a "cancel service" business event in the CRM system will direct that that business event also be transformed and sent to the provisioning system (e.g., to turn off a telephone line) and to the billing system (e.g., to terminate further charges and/or generate a final invoice). A process model typically includes, at a minimum, the following components: a model server, model properties, business event definitions, business process object attribute definitions, and business process states, transitions and actions.</li><li>Shared Object Model (SOM) - The SOM is a central repository that represents enterprise data objects in common format - namely, the Interface Description Language (IDL) format. Business events received from an enterprise application in a proprietary format are transformed into the SOM format, and then when needed by another enterprise application, are transformed from the SOM format into the proprietary format of the requesting application. A SOM typically includes, at a minimum, a list of IDL structures and structure members, a list of arrays (including type and size), a list of application values and IDL values, a mapping of values to IDL fields, a mapping of IDL structures to Business Events, and a mapping of Interface Events to Business Events.</li><li>Transformer Classes (or "transformers") - The transformer classes are Java-language classes that translate data (e.g., business events) from enterprise application format to SOM format, and/or from SOM format to enterprise application format. <figref idref="f0003">Fig. 2A</figref> shows an example of the definition and structure of a transformer class, "SIToVtAddProductTransformer." A separate transformer class exists for each different transformation that may need to be performed. For example, exchanging a business event between a Siebel eCommunications CRM system and a Portal Infranet billing system would require four separate transformer classes: <ol id="ol0001" compact="compact" ol-style=""><li>(1) a transformer class to translate from Siebel eCommunications format to SOM format; (2) a transformer class to translate from SOM format to Siebel eCommunications format; (3) a transformer class to translate from SOM format to Portal Infranet format; (4) a transformer class to translate from Portal Infranet format to SOM format. For example, in the embodiment of <figref idref="f0010">Fig. 3</figref> (which shows an Integration Hub integration of four different enterprise applications), the following transformer classes may be used: <ul id="ul0003" list-style="none" compact="compact"><li>SlToVtAddProductTransformer, SlToVtAddServiceTransformer,</li><li>SlToVtAppAccLvlAdjTransformer,</li><li>SlToVtCancelProductTransformer,</li><li>SlToVtCancelServiceTransformer,</li><li>SlToVtCreateAccountTransformer,</li><li>SlToVtModifyAccountTransformer,</li><li>SlToVtModifyServiceTransformer,</li><li>SlToVtOrderHeaderTransformer,</li><li>SlToVtUpdAccStatusTransformer, SLTransformer,</li><li>VtToSlUpdPrdctStatusTransformer,</li><li>VtToSlUpdSrvcStatusTransformer, PlTransformer,</li><li>VtToPlAcctAdjustmentTransformer,</li><li>VtToPIAddProductTransformer, VtToPlAddServiceTransformer,</li><li>VtToPlCancelProductTransformer,</li><li>VtToPlCancelServiceTransformer,</li><li>VtToPlCreateAccountTransformer,</li><li>VtToPlModifyAccountTransformer,</li><li>VtToPlModifyServiceTransformer,</li><li>VtToPlUpdateAcctStatusTransformer, ABPTransformer,</li><li>VtToABPAddProductTransformer,</li><li>VtToABPAddServiceTransformer,</li><li>VtToABPApplyAcctLvlAdjmntTransformer,</li><li>VtToABPCancelProductTransformer,</li><li>VtToABPCancelServiceTransformer,</li><li>VtToABPCreateAccountTransformer,</li><li>VtToABPModifyAccountTransformer,</li><li>VtToABPModifyServiceTransformer,</li><li>VtToABPUpdateAccountStTransformer, OMSTransformer,</li><li>OMSToVtProvisioningResponseTransformer,</li><li>OMSToVtServiceStatusNotification, and</li><li>VtToOMSRequestBroadbandTransformer.</li></ul></li></ol></li><li>Controller Classes (or "controllers") - The controller classes are Java-language classes that route business events to appropriate transformer classes. For example, if the process model specified that a business event generated at the Siebel eCommunications CRM system needs to be sent to the Portal Infranet billing system, one controller class would route the Siebel eCommunications-formatted business event to the transformer that translates from Siebel eCommunications format to SOM format, and another controller class would route the SOM-formatted business event to the transformer that translates from SOM format to Portal Infranet format. <figref idref="f0004 f0005">Figs. 2B</figref>, <figref idref="f0006 f0007">2C</figref> and <figref idref="f0007">2D</figref> collectively show an example of the definition and structure of a controller class, "PIController." In the embodiment of <figref idref="f0010">Fig. 3</figref>, for example, the following controller classes may be used: SlController, PlController, ABPController, and OMSController.</li><li>Acknowledgement Class - The acknowledgement class is a Java-language class that is used to send status messages from an enterprise application to one or more other enterprise applications and/or for exception handling. For example, each time a business event is received by an enterprise application, the receiving application invokes an acknowledgement class to signal either that the transfer was successful or that a particular error occurred. Upon occurrence of error, the acknowledgement class can trigger an appropriate error-handling procedure. <figref idref="f0008 f0009">Fig. 2E</figref> shows an example of the definition and structure of an acknowledgement class, "SlAcknowledgementTransformer."</li><li>Channel Architecture - The channel architecture defines the communication channels to which business events will be published and the relative priority of those channels. For example, the following channels are used in the integration hub implementation depicted in <figref idref="f0010">Fig. 3</figref>: AccountChannel, ProvisionOrderChannel, ToSiebel, Acknowledgement Channel, ProvisioningRequest, ProvisioningResponse, BillingChannel, ToArbor, and ToPortal. Each of the integration hub business events is assigned a specific channel. Further details on the Channel Architecture are provided below.</li></ul>

<figref idref="f0010">Fig. 3</figref> shows details of an example integration hub implementation. In this example, four different enterprise applications are integrated using the integration hub 300: a Portal Infranet billing application 302, an Architel provisioning application 304, and a Siebel eCommunications CRM application 306 and an Arbor billing application 308. The integration hub 300 is comprised of a shared object model (SOM) 312, a communicator infrastructure 310, a channel architecture 314 and connectors 316, 317. The SOM 312 provides a predefined common logical model of business objects and events specific to a particular industry.

The SOM 312 is an IDL representation (defined using the Vitria software developers' kit (SDK)) of common business entities in Vitria BusinessWare. These business entities include account, customer, contact, order, payment, and billing information. The integration hub IDL defines the data format, modules, and structures of common business entities such as account, product, service, order, customer, payment, and contact. Enterprise applications generate functions that are translated into business events within Vitria. Vitria encapsulates the business data for these events, e.g. Create Customer, Add Product, Cancel Service, in an IDL format that the integration hub defines as the shared object model (SOM).

The SOM 312 is used by the transformation classes, which as described above are a set of java-language classes that use transformation rules 313 to translate data from enterprise application format to SOM format or vice versa. In effect, the transformation rules 313 are business rules that translate from the specific APIs (application program interfaces) used by the enterprise applications into the common SOM format and vice versa. More particularly, the event transformation rules 313 are defined in the transformer classes. These java transformer classes load enterprise application data into Vitria business event objects. The transformers also extract data from business event objects and load them into enterprise application databases or APIs. The transformer classes operate by applying formatting and translation logic to the data before loading them into an application or business event. These translation rules include changing numeric fields to alpha numeric, changing status values to enumerator or Boolean values, and copying string or numeric fields to target string or numeric fields. The transformers include exception handling and acknowledgement classes that capture errors and publish them to an acknowledgement channel or error log.

The communicator infrastructure 310 provides transactional synchronous and/or asynchronous message structure for communicating between the integration hub 300 and the enterprise applications. It reliably transports information in a consistent format between systems by employing an event-driven publish-subscribe methodology via communications channels. The communicator 310 includes a number of channels to which an application can publish an event and to which another application can subscribe to receive the event. The communicator infrastructure used in this embodiment was developed by, and is available from, Vitria, Inc. of Sunnyvale, California. Further details on the communicator infrastructure can be found in documentation available from Vitria and in information at Vitria's website: <ul id="ul0004" list-style="none" compact="compact"><li>http://www.vitria.com/products/businessware/eai.html</li></ul>

The channel architecture 314 defines how messaging will be partitioned for high-performance communications. The channel architecture defines the communication channels that business events will be published to. These channels include New Order, Account, and Product. Each of the integration hub business events is assigned a specific channel. The integration hub channels are prioritized (using the priority scheme developed by Vitria) to ensure that business events are sent to enterprise applications in the correct order; e.g. Create Customer is sent to billing before Add Product. Detailed documentation on the priority scheme is available directly from Vitria for customers and integration partners.

The connectors 316, 317 are part of the communicator 310 and represent the channels for communicating between the integration hub 300 and the enterprise applications. The communicator has two different types of connectors to communicate with each separate application: a publisher connector 317, which publishes a business event from a publishing application to a channel in the communicator 310, and a subscribing connector 316 which receives a business event from the communicator 310 (pushed by a publisher connector 317) into the subscribing application connector.

Each business event represents a logical business function. Sample business events include account creation, product creation, service modification, and product cancellation. The Create Customer business event, for example, originates in the CRM application, e.g. Siebel or Clarify. The CRM application invokes an API or changes database tables that the integration hub monitors. The integration hub uses its connector architecture, which includes controllers and transformers, to translate the enterprise data into a SOM format within a business event. The integration hub publishes the business event onto the appropriate channel. Subscribers of the event - e.g., billing, provisioning, process automation - subscribe to the business event from the channel and into their respective connectors. The connectors translate the SOM data into the target enterprise application's data format; e.g. Portal Infranet, Architel OMS. The connector invokes an application-specific API to load the data into the target enterprise application. The target enterprise application generates an Acknowledgement business event in the integration hub that includes the success/failure status and result data of the target enterprise application's API. This Acknowledgement business event is published to the Acknowledgement channel for transmission to another enterprise application or a log file.

Each Vitria connector 316, 317 is comprised of three different components: a publisher / subscriber module 318 (depending on whether the connector is a publisher connector 317 or a subscriber connector 316), a transformer 320 and a driver 322. The Vitria publisher / subscriber modules 318 send / retrieve business events to / from the communicator infrastructure 310. The Vitria drivers 322 provide pre-built interfaces to packaged applications. As with the communicator infrastructure 310, the Vitria drivers 322 and the Vitria subscriber / publisher modules 318 used in this embodiment were developed by and available from Vitria, Inc., although in other embodiments they could be custom-developed if desired. Further details on the publisher / subscriber module 318 and the driver 322 are provided in documentation available from Vitria.

The transformer component 320 of each connector 316, 317 provides the execution environment for the event transformation rules 313. More particularly, each transformer 320 is a separate Java-language class that, when invoked, performs a translation function on data (e.g., a business event) using methods defined by the transformation rules. A transformer rule is an algorithm that converts between the message formats to disparate applications. A transformation rule lists the fields of the related messages of the applications and describes how each field is related to another. <figref idref="f0011 f0012">Figs. 3A</figref> and <figref idref="f0012 f0013">3B</figref> collectively show an example of the transformation rules used for the CRM, Billing, and middleware applications.

In general, the integration hub provides a framework that enables a first application, upon having a business event created or otherwise occur locally (such as the creation of a new customer account by a human user), to publish the event to an appropriate channel in the communicator infrastructure, and concurrently have the event converted to a common format (i.e., the SOM format). At that point, any other enterprise application connected to the integration hub can subscribe to the channel of interest and retrieve the newly created event. As part of the retrieval process, the event is converted from the common SOM format into the APIs and fields used by the subscribing application. The subscribing application then can use the APIs and fields to undertake its own local action responsive to, or otherwise appropriate for, the business event generated by the first application.

<figref idref="f0014">Fig. 4</figref> shows an example of data flow during a typical sequence using the integration hub architecture to exchange business events between two applications - in this example, a Siebel eCommunications CRM application and a Portal Infranet billing application. Assume, for example, that a human operator creates a new customer account and a service order for that account in the Siebel eCommunications CRM application running on node 400. Following the submission of the service order, the CRM Application causes the new account information to be sent in Step 1 to the server 402 which hosts the application's database engine. The Siebel Workflow Manager (a component of the Siebel application) is what performs this send. It is invoked to send customer information to the Integration Hub. Upon submission of the service order, the Siebel Workflow Manager determines that a new account has been created and needs to be sent to the Integration Hub. The Siebel Workflow Manager then goes to the Siebel database and retrieves an instance of a pre-defined Siebel integration object called "Vitria Account". The integration object tells the workflow manager what data to get and where to get it from, for that particular business event. Within Siebel eCommunications, the customer data, which comprises the integration object instance, is transformed into XML (extensible markup language) format and sent over an HTTP (hypertext transfer protocol) protocol to Vitria servlet 403. The Siebel source connector model 407 is a publisher to the Vitria servlet.

Next, in Step 3, the Siebel source connector model 407 converts the XML data into an IDL format and then a transformer translates the Siebel IDL format into a shared object model format. The source connector 407 in Step 4 creates a "Create Customer" event (in the SOM format) and publishes it onto the channel 409, which receives Create Customer business events that billing applications subscribe to. The integration hub channels are prioritized using Vitria's configuration tools to ensure business events are received in the correct order; e.g. a Create Customer business event is processed before a Add Product business event.

Next, in Step 5, the Portal Infranet target connector 410 executing on node 414 subscribes to the channel 409. Next, in Step 6, a transformer transforms the "Create Customer" event from the SOM format into appropriate APIs and field lists for the Portal Infranet application. In Step 7, a Vitria target driver sends the APIs and field lists to the connection manager component 413 of the Portal Infranet application. Finally, in Step 8, Portal Infranet creates a new customer account within its local Account table in its database 415.

The integration hub's shared object model has defined, and uses, a set of core business events to pass customer, product and service data among the various enterprises applications. The number and types of business events used for a given integration depend on the applications being integrated and the objectives of the enterprise and its users. Often, the business event definitions are industry-specific, for example, specific to the telecommunications industry, because companies in a given industry often use the same or similar enterprise applications in furthering their commercial endeavors.

For the example of <figref idref="f0015 f0016 f0017 f0018 f0019 f0020 f0021 f0022 f0023 f0024 f0025 f0026 f0027">Fig. 5</figref>, in which a CRM system and a billing system are integrated to share information with each other, the following ten core business events were defined and used: <ul id="ul0005" list-style="bullet" compact="compact"><li>Create Order - starts the provisioning and billing process of an order within the process models</li><li>Add Product - add a new product to an account or service from CRM into provisioning and billing</li><li>Add Service Instance - add a new service instance, service location, login, and password to an account from CRM into provisioning and billing</li><li>Apply Account Level Adjustment - apply account-level adjustments (credits and debits) from CRM into billing</li><li>Cancel Product - cancel an existing product from an account or service from CRM into provisioning and billing</li><li>Cancel Service Instance - cancel an existing service instance from an account from CRM into provisioning and billing</li><li>Create Customer - submission of billing, payment, and contact information for a new account from CRM into billing</li><li>Maintain Account - submission of changed billing, payment, and contact info for an existing account from CRM into billing</li><li>Maintain Service Instance - make corrections to an existing service's location and password from CRM into provisioning and billing</li><li>Update Account Status - transfer changes to account status (active, suspend, closed) from CRM to billing</li><li>Update Product Status - as provisioning system (OMS) passes through its processes, the product status will be updated automatically in Siebel the billing system to the CRM system</li></ul>

In effect, these 10 business events define a common language for communicating between the Siebel eCommunications 2000 CRM , Portal Infranet v6.1 billing, Lucent Arbor/BP v9.1 billing, and Architel OMS provisioning. The integration hub effectively acts as the intermediary and interpreter to facilitate communication between these systems. Integrating additional applications into the enterprise would generally require the definition and use of different or additional business events specific to the applications under consideration. However, by defining business events that have general applicability to several different types of applications (e.g., Create Customer), business events can be re-used thus reducing the integration effort, expense and complexity. In general, other embodiments could use additional or different business events, depending on the applications being integrated as well as the objectives of the enterprise and its users.

<figref idref="f0015 f0027">Figs. 5A-5L</figref> are examples of business event definition tables. These particular business events were defined for integrating a Siebel CRM system with two different billing systems: Portal Infranet and Arbor. The set of 12 business events defined below and in <figref idref="f0015 f0027">Figs. 5A-5L</figref> are sufficient to enable the Siebel CRM system, the Portal Infranet billing system and the Arbor billing system to exchange information that implements the integration objectives of the enterprise. The integration hub defines process models within Vitria that subscribe to the Create Customer, Modify Customer, Update Account Status, Add Product, Add Service, Modify Service, Cancel Service, and Cancel Product business events. The order management process models created in the integration hub define the process management of accounts, orders and services. These process models define the process of when to send business events to the provisioning and billing systems and define what information is needed for each system. As an example, the Add Service Instance and Add Product business events for ordering a telecom service (e.g., a digital subscriber line (DSL)) must first be sent to Architel OMS for provisioning and then to Infranet or Arbor for billing after it has been provisioned. The Add Product for a DSL modem can be sent directly to Infranet or Arbor for billing. For both examples, the process model is a subscriber and publisher of the Add Product business event. The process model subscribes to the Add Product business event after it is published by the CRM, e.g. Siebel, Clarify. As discussed below, the process model, in turn, publishes the Add Product business event to the ProvisioningRequest channel in <figref idref="f0028">Fig. 6</figref> and/or the Billing channel in <figref idref="f0028">Fig. 6</figref> based on the product type.

<figref idref="f0015">Fig. 5A</figref> shows the definition table for the "Acknowledgement" business event, further details of which are set forth below. <tables id="tabl0001" num="0001"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="37mm" /><colspec colnum="2" colname="col2" colwidth="54mm" /><tbody><row><entry>File Name:</entry><entry>Acknowledgment Event</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>Billing (Arbor, Portal)</entry></row><row><entry /><entry>CRM (Siebel)</entry></row><row><entry>Subscriber(s):</entry><entry>Install Service Process Model</entry></row><row><entry /><entry>Modify Service Process Model</entry></row><row><entry /><entry>Disconnect Service Process Model</entry></row><row><entry /><entry>AcknowledgementToFile</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents.idl</entry></row><row><entry>Business Event Name:</entry><entry>Acknowledgment</entry></row></tbody></tgroup></table></tables>

Description: An acknowledgement event can be created in two main ways: <ol id="ol0002" ol-style=""><li>1. If the translation or the transformation fails in the Arbor, Portal and Siebel connectors an error message is written to the acknowledgement log file.</li><li>2. As Arbor, Portal and Siebel target connectors' process each Business Event, an acknowledgement event will be created from the response returned from the application. This acknowledgement will act as a confirmation to the Vitria process models that Arbor, Portal or Siebel has successfully processed each business event.</li></ol>

<figref idref="f0016 f0017">Fig. 5B</figref> shows the definition table for the "Add Product" business event, further details of which are set forth below. <tables id="tabl0002" num="0002"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="36mm" /><colspec colnum="2" colname="col2" colwidth="54mm" /><tbody><row><entry>File Name:</entry><entry>Add Product Event</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel)</entry></row><row><entry /><entry>Install Service Process Model</entry></row><row><entry /><entry>Modify Service Process Model</entry></row><row><entry /><entry>Disconnect Service Process Model</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Portal, Arbor)</entry></row><row><entry /><entry>Order Pre-Processor Model</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Add Product</entry></row></tbody></tgroup></table></tables>

Description: When a new service order containing products that are purchased by a customer, an Add Product event is kicked off. This event passes the deal (i.e. component or bundle) name stored in the CRM as well as the name of the account that it should be added to. This information is sent to the provisioning system if the product requires provisioning. Once provisioning has been completed, the add product event will be sent to the billing system and the product is added to the appropriate account.

<figref idref="f0018">Fig. 5C</figref> shows the definition table for the "Add Service" business event, further details of which are set forth below. <tables id="tabl0003" num="0003"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="36mm" /><colspec colnum="2" colname="col2" colwidth="54mm" /><tbody><row><entry>File Name:</entry><entry>Add Service Event</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel)</entry></row><row><entry /><entry>Install Service Process Model</entry></row><row><entry /><entry>Modify Service Process Model</entry></row><row><entry /><entry>Disconnect Service Process Model</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Arbor, Portal)</entry></row><row><entry /><entry>Order Pre-Processor Model</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Add Service</entry></row></tbody></tgroup></table></tables>

Description: The Add Service event occurs when a new service is ordered. When a new service is ordered, the CRM application passes the details to the billing application i.e. account number, service type, service instance id, password, effective date, and service location via Vitria IOM. Vitria IOM will utilize the service information to create a provisioningRequest event to provision the products associated with the given addService event. Once a product underneath the specific servicelnstance is complete, IOM will then send the addService event to the billing application and create a service instance under the appropriate billing account.

<figref idref="f0019">Fig. 5D</figref> shows the definition table for the "Apply Account Level Adjustment" business event, further details of which are set forth below. <tables id="tabl0004" num="0004"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="37mm" /><colspec colnum="2" colname="col2" colwidth="57mm" /><tbody><row><entry>File Name:</entry><entry>Apply Account Level Adjustment</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel), Account Process Model</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Portal, Arbor)</entry></row><row><entry /><entry>Account Process Model</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Apply Account Level Adjustment</entry></row></tbody></tgroup></table></tables>

Description: When an adjustment is applied to an account, the adjustment information will be sent from CRM to Billing. Account number, adjustment amount, and reason description will be passed from CRM to Vitria into Billing.

<figref idref="f0020">Fig. 5E</figref> shows the definition table for the "Cancel Product" business event, further details of which are set forth below. <tables id="tabl0005" num="0005"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="36mm" /><colspec colnum="2" colname="col2" colwidth="45mm" /><tbody><row><entry>File Name:</entry><entry>Cancel Product (Version 1.0)</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel)</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Portal, Arbor)</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Cancel Product</entry></row></tbody></tgroup></table></tables>

Description: This event removes product from an account or service object. This event passes the information such as, deal or component name, product instance id, account number, and optionally, service type, service id (Portal login), and service password from the CRM to Billing through the Vitria connectors and Vitria IOM component. This information is sent to the billing system and a confirmation of delivery is then sent to an acknowledgement log file.

<figref idref="f0021">Fig. 5F</figref> shows the definition table for the "Cancel Service" business event, further details of which are set forth below. <tables id="tabl0006" num="0006"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="38mm" /><colspec colnum="2" colname="col2" colwidth="54mm" /><tbody><row><entry>File Name:</entry><entry>Cancel Service (Version 1.0)</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel)</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Portal, Arbor), Provisioning</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Cancel Service</entry></row></tbody></tgroup></table></tables>

Description: The Cancel Service event cancels a service by changing its status from active to closed. The CRM sends the Cancel Service event (Including account number, service type, service ID, effective date, and status) to the Vitria connector after the service has been cancelled in the CRM.

Upon receipt of the Cancel Service event, Vitria IOM sends a Provisioning Request event (CreateOrder.Request - OMS System Event) to Provisioning and awaits a Provisioning Response event (CreateOrder.Response -OMS System Event). Once provisioning is complete, Vitria IOM sends a Cancel Service event to billing.

Billing receives the account number through the Vitria connector and it uses the account number to find the account. The service POID is found in Portal and the service status is changed by invoking the ChangeStatus opcode. Within Arbor, the service instance id is used to call the cease function on the specific instance of the Service Instance object that needs to be cancelled. Only the service instance id (external_id) and effective date will need to be passed in order to cancel service within Arbor.

<figref idref="f0022">Fig. 5G</figref> shows the definition table for the "Create Customer" business event, further details of which are set forth below. <tables id="tabl0007" num="0007"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="37mm" /><colspec colnum="2" colname="col2" colwidth="54mm" /><tbody><row><entry>File Name:</entry><entry>Create Customer Event Definition</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel)</entry></row><row><entry /><entry>Install Service Process Model</entry></row><row><entry /><entry>Modify Service Process Model</entry></row><row><entry /><entry>Disconnect Service Process Model</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Portal, Arbor)</entry></row><row><entry /><entry>Account Process Model</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Create Customer</entry></row></tbody></tgroup></table></tables>

Description: The Create Customer event occurs when an order for a new customer is submitted. When the first order for a new customer is submitted, the CRM application passes the createAccount event into Vitria and to the Account Process Model. The Account Process Model will then send the createAccount event containing contact, payment, and billing information into the Billing Application. The Billing Application takes this information and creates an account. All optional fields that were not passed from CRM application will have default values in the Billing application. The Billing application will send to Vitria a confirmation indicator message stating whether the Billing application has successfully created the customer or not.

<figref idref="f0023">Fig. 5H</figref> shows the definition table for the "Modify Account" business event, further details of which are set forth below. <tables id="tabl0008" num="0008"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="36mm" /><colspec colnum="2" colname="col2" colwidth="54mm" /><tbody><row><entry>File Name:</entry><entry>Modify Account</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel)</entry></row><row><entry /><entry>Install Service Process Model</entry></row><row><entry /><entry>Modify Service Process Model</entry></row><row><entry /><entry>Disconnect Service Process Model</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Portal, Arbor)</entry></row><row><entry /><entry>Account Process Model</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Modify Account</entry></row></tbody></tgroup></table></tables>

Description: The Modify Account event occurs when a customer's attributes change. Account modifications include changes to an account's billing address, contact information, bill payment method, and bill cycle date. When an account's attributes change, the CRM tool passes the billing system information regarding changes to the customer account. The billing system takes the information and updates the customer's attributes. The billing application will send Vitria an acknowledgement message when the billing system has successfully updated the customer's information. Examples of account attribute changes are changes to: the account's name, the account's address, the account's contact information, the billing cycle, the billing currency, the bill payment type, and the account close day of month. Note that the currency cannot be changed for any account. The bill frequency, bill type, and bill cycle day can only be modified for non-subordinate accounts.

<figref idref="f0027">Fig. 5l</figref> shows the definition table for the "Modify Service" business event, further details of which are set forth below. <tables id="tabl0009" num="0009"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="36mm" /><colspec colnum="2" colname="col2" colwidth="54mm" /><tbody><row><entry>File Name:</entry><entry>Modify Service</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel)</entry></row><row><entry /><entry>Install Service Process Model</entry></row><row><entry /><entry>Modify Service Process Model</entry></row><row><entry /><entry>Disconnect Service Process Model</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Portal, Arbor)</entry></row><row><entry /><entry>Order Pre-Processor Model</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Modify Service</entry></row></tbody></tgroup></table></tables>

Description: The Modify Service event will take place in the CRM when any service information is modified.

The information regarding the change will be sent to the Billing Application. There are three alternate scenarios that result in a modifyService event. <ol id="ol0003" compact="compact" ol-style=""><li>1. A new product is added to an existing Service.</li><li>2. A product is cancelled from an existing Service, however there are still other active products remaining under the same service.</li><li>3. A product is added and a product is cancelled under an existing service.</li></ol>

<figref idref="f0025">Fig. 5J</figref> shows the definition table for the "Service Status Notification Error" business event, further details of which are set forth below. <tables id="tabl0010" num="0010"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="36mm" /><colspec colnum="2" colname="col2" colwidth="53mm" /><tbody><row><entry>File Name:</entry><entry>Service Status Notification</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>Provisioning (OMS)</entry></row><row><entry /><entry>Product Service Model</entry></row><row><entry>Subscriber(s):</entry><entry>Install Service Process Model</entry></row><row><entry /><entry>Modify Service Process Model</entry></row><row><entry /><entry>Disconnect Service Process Model</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Service Status Notification</entry></row></tbody></tgroup></table></tables>

Description: The purpose of this event is to send provisioning status information from OMS to the Vitria IOM.

When a new service or product request is made (Provisioning Request Event), it is sent to OMS via the OMS Target Connector. A response (Provisioning Response Event) is sent by OMS to Vitria IOM via the OMS Target Connector. The OMS Source Connector will monitor the OMS database to see if there is any change in the status of a service or product. If there is a change in the status of a service or product, a Service Status Notification Event is created with the required parameters. The OMS server is accessed to obtain additional information. The Service Status Notification Event is then sent to Vitria IOM. The Vitria IOM will create and send the Update Product Status Business Event to Siebel (where the CRM information will be updated). Once provisioning is complete, the automator will then trigger the billing events to Portal/Arbor (where the BILLING information will be updated).

<figref idref="f0026">Fig. 5K</figref> shows the definition table for the "Update Account Status" business event, further details of which are set forth below. <tables id="tabl0011" num="0011"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="36mm" /><colspec colnum="2" colname="col2" colwidth="53mm" /><tbody><row><entry>File Name:</entry><entry>Update Account Status</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>CRM (Siebel)</entry></row><row><entry /><entry>Install Service Process Model</entry></row><row><entry /><entry>Modify Service Process Model</entry></row><row><entry /><entry>Disconnect Service Process Model</entry></row><row><entry>Subscriber(s):</entry><entry>Billing (Portal, Arbor)</entry></row><row><entry /><entry>Account Process Model</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Update Account Status</entry></row></tbody></tgroup></table></tables>

Description: The purpose of this event is to send information from the CRM to the Billing application when an account is suspended, re-activated or closed. The CRM sends the account ID and status to Billing through the Vitria connectors and the Account Process Model. When an account status is changed to "Suspended", "Active" or "Closed", the child account's status must be changed to correspond to the same status. The CRM application will change the child services or products to the "Suspended", "Active", or "Closed" status before the account status is changed. This is a user training issues, and must be incorporated in the training plan.

<figref idref="f0027">Fig. 5L</figref> shows the definition table for the "Update Product Status" business event, further details of which are set forth below. <tables id="tabl0012" num="0012"><table frame="none"><tgroup cols="2" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="37mm" /><colspec colnum="2" colname="col2" colwidth="50mm" /><tbody><row><entry>File Name:</entry><entry>Update Product Status</entry></row><row><entry>Type:</entry><entry>Business Event Definition</entry></row><row><entry>Publisher(s):</entry><entry>Provisioning (Architel), Vitria IOM</entry></row><row><entry>Subscriber(s):</entry><entry>Vitria IOM, CRM (Siebel)</entry></row><row><entry>IDL File Name:</entry><entry>ihBusinessEvents</entry></row><row><entry>Business Event Name:</entry><entry>Update Product Status</entry></row></tbody></tgroup></table></tables>

Description: When a product event is triggered it will be sent from Siebel to the Service Level Model. The Service Level Model will then send a provisioning request to the provisioning system (OMS). When the provisioning system receives the request a response will be sent back to the Service Level Model indicating that the request has been received. Siebel will then be notified in order to update the product status. Upon the completion of provisioning all the products OMS will send a Service Status Notification back to the Service Level Model. This will then be passed onto Siebel and the status of the product will be changed to complete or cancelled depending on the event that triggers this process.

<figref idref="f0028">Fig. 6</figref> is a block diagram of the integration hub's channel architecture 600. To aid in understanding the data flow involved in <figref idref="f0028">Fig. 6</figref>, an explanation for each component in this figure is provided. The Siebel application 602 is the CRM application where customer data originates. There are specific data fields required by the downstream billing systems, Portal Infranet 604 and Arbor 606. A "channel" is a key organizational concept in the publish/subscribe model in that it accepts incoming events from publishing applications and communicates these events to subscribers of that channel. <figref idref="f0029 f0030">Fig. 7</figref> is a Channel Architecture Definition table that includes a description of each channel and the associated publisher / subscriber information.

The Automator Process Model 608 is a Vitria graphical model that specifies application integration logic. Specifically, the automator 608 is the business automation component that controls the flow of data between systems, and ensures the timely delivery of accurate data. The OMS application 610 is used for provisioning purposes. The Acknowledgement channel 612 handles the exception logic by recording processing errors and success messages in a text file (Acknowledgement.txt). The error information may include the name of the failed event, the name of the application for which the connector belongs, the error message, and a flag to denote a success or failure. This information is packaged within an event that is sent to the Acknowledgement channel 612. Business Events, as described above, are represented in <figref idref="f0028">Fig. 6</figref> at the point of each event flow.

The following example represents an example of data flow that may take place in the architecture 600 when a new customer orders a DSL product. The Required information will be entered into the Siebel system 602 and once the 'Submit' button is pushed by an operator, all four events are sent to Vitria: one createAccount event, one orderHeader event, one DSL addService event, and one DSL addProduct event. The events will be processed by the Order Processor Model and finally the Service Process Model. These models handle the interaction between the OMS provisioning system 610 and billing systems 604, 606. A provisioningRequest event is generated from this order as well. The provisioningRequest event is then sent to the OMS provisioning system 610.

Upon receiving the request, the provisioning system 610 will send back a provisioningResponses for confirmation. As a result of the response event, Vitria will send an updateProductStatus event to the Siebel CRM 602 in order to set the status of the product to 'Pending.'

Once provisioning is complete, the OMS provisioning system 610 will send two serviceStatusNotification events to Vitria denoting the DSL service and it's product is now 'Active.' Vitria will then send a serviceStatusNotification event to the Siebel CRM 602 denoting that the DSL service is active. Vitria will also send an updateProductStatus event to the Siebel CRM 602 to change the status of the DSL product to 'Active.' At the same time, the addservice event and addproduct event will be sent to one or more of the billing systems 604, 606. The orderHeader event is internal to Vitria and will not be sent to billing.

The channel architecture 600 described above is a configuration of Vitria's native channel architecture. The integration hub has defined an account, product, new order, and billing channels to which business events are published. The account, product, and new order channels are routed to the composite billing channel. The account, product, and new order channels are prioritized to ensure that business events are sent to billing and provisioning in the correct order.

Various implementations of the systems and techniques described here may be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), in computer hardware, firmware, software, or combinations thereof, or in other types of machines.

A number of embodiments of the present invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the scope of the invention.

Accordingly, other embodiments are within the cope of the following claims.