WO2010149896A1

WO2010149896A1 - Method and device for integrating heterogeneous applications

Info

Publication number: WO2010149896A1
Application number: PCT/FR2010/051208
Authority: WO
Inventors: Brigitte Barberon; Laurent Trompette
Original assignee: Bull Sas
Priority date: 2009-06-24
Filing date: 2010-06-17
Publication date: 2010-12-29
Also published as: FR2947355B1; FR2947355A1

Abstract

The invention relates to the integration of heterogeneous applications. After having received at least one datum of a heterogeneous application in a format specific to said heterogeneous application, said at least one received datum is converted (420) into a predetermined data format separate from the data formats used by said heterogeneous applications. At least one second datum is received from another heterogeneous application for enabling the generation (440, 470, 480) of an object including said at least one received datum converted into said predetermined format, said generation being carried out in accordance with said at least one second received datum, wherein said object can be directly processed by said other heterogeneous application. Said generated object is then transmitted (445) to said other heterogeneous application.

Description

Method and device for integrating heterogeneous applications

The present invention relates to the exchange of data between software applications and more particularly to a method and a device for integrating heterogeneous applications.

While there are vendors of software applications that offer complete suites of enterprise applications, these publishers typically specialize in domains. Thus, for example, there are publishers offering customer relationship management applications, also called CRM (acronym for Customer Relationship Management in English terminology), others offering applications for management of commercial offers and billing or others still offering service activation applications, for example activation of SIM cards (acronym Subscriber Identity Module in English terminology).

While these applications are independent of each other, some data is used by many different applications and some data produced by particular applications is used by others. In the same way, it is possible that certain routines or instructions of an application must be executed after other routines or instructions executed by other applications. Similarly, some rules can be used by multiple applications. Thus, for example, when a customer subscribes to a new telephony service contract, his references are entered into a customer relationship management application. Some of the information entered is then re-entered into an account management and valuation application to manage the customer's account and determine its consumption as well as these rights in order to allow billing. These different applications are often developed on different computer platforms, they are not compatible with each other. In addition, they can be distributed in a network computer science. Thus, when several applications require the same data, it is often necessary to enter them several times.

Data transmission between different applications can be manual. By way of illustration, Figure 1a represents two separate computer systems. The first computer system is here used to implement a customer relationship management application 100 while the second computer system is here used to implement a billing application 105. As illustrated by reference 110, some data is transmitted to each of applications 100 and 105. Such data are, for example, customer data. In the same way, other data are also transmitted to each of the applications 100 and 105 (reference 115). This data may in particular be data relating to contracts offered to customers. Also, as illustrated by the arrow 120, it may be necessary to copy data generated by the customer management application 100 into the billing application 105. These data are, for example, customer references. The use of dashed arrows here indicates manual operations.

To avoid re-keying or double data entry between these applications, it is therefore necessary to provide an interface between these applications.

Simple solutions for interfacing a limited number of heterogeneous applications is to develop a third-party system that transmits data, rules, and / or commands to heterogeneous applications in their particular format. Figure 1b illustrates such an example. According to this example, the computer system 125 is used to enter all the data (reference 130) which is converted into the format specific to the customer relationship management and billing applications 100 'and 105', respectively, so as to be automatically transmitted to them (reference 135). Thus, the data are entered only once. However, such solutions are specific to the heterogeneous applications implemented. Consequently, they are difficult to adapt to other similar situations. In addition, the update of one of the Heterogeneous applications usually require updating the third-party application.

According to another solution, an intermediate layer, also called middleware or middleware in English terminology, is used. The purpose of such a layer is essentially to convert the format of the data to allow their exchange and to manage the calls of the functions of these applications.

On this basis, more advanced solutions can be developed to model the processes implemented and the data exchanges between the applications. Such solutions include EAI (acronym for Enterprise Application Integration in English terminology) and ESB (acronym for Enterprise Service Bus in English terminology).

EAIs are architectures that allow heterogeneous applications to collaborate as part of business integration. In general, an EAI includes connectors used as interfaces with the applications, mapping modules for transforming the received specific data into standardized data and vice versa, and exchange modules for routing the data between the applications.

FIG. 1c illustrates a simplified example of the implementation of an EAI platform 140 making it possible to link a client relationship management application 100 and a billing application 105. Data of the application 100 "is transmitted (reference 145) to the platform EAI 140 in the form of messages, more specifically, the data is generally transmitted to a module 150 whose function is to check the message format, according to the a predetermined schema, and extracting the data, the data is then redirected in a first conversion module 155 to be organized according to a structure specific to the EAI (reference 160), called a pivot scheme, allowing a data processing independent of the 100 "and 105" applications The data in accordance with the pivot scheme is then transmitted to a second conversion module 165 to be reorganized according to the structure required by the application 105 ". The conversion step can also understand an enrichment step. The latter is made from data or transformation rules stored in the EAI, for example in the database 170. By way of illustration, when the data relating to a client are transmitted from the application 100 "to the application 105 ", it is generally necessary to convert the data into application-specific parameters functions 105", including parameters related to the quality of the customers (for example, the quality of the customer, individual or professional, may have it has an influence on the contracts proposed to it and on billing.) Finally, before being transmitted as a message (reference 180), the data is formatted in the module 175 according to a predetermined format, linked to the application 105 ", defined by a diagram.

Although such a solution has many advantages, particularly in terms of integration of many applications, it is nevertheless complex and has a cost of implementation which is often very important, particularly related to the needs of business knowledge and knowledge of applications. Moreover, because of the integration of the combination of business knowledge and knowledge of heterogeneous applications, an EAI solution developed for a particular context is difficult to port in another context. BSE, following the philosophy of the EAI, are service-oriented

(Their architecture is called SOA, acronym for Oriented Service! Architecture in English terminology). They are based on web services and message exchange. While these solutions are easier to generalize, they are also complex to implement. There is therefore a need for simple solutions, easy to implement, whose development cost is limited and can be reused to interface a limited number of heterogeneous applications, particularly in the field of contract management telephony, fixed or mobile, and communication network type Internet. The invention solves at least one of the problems discussed above. The invention thus relates to a computer method for integrating heterogeneous applications in a system comprising at least two heterogeneous applications, this method comprising the following steps,

receiving at least a first datum of one of said at least two heterogeneous applications in a format specific to said one of said at least two heterogeneous applications;

converting said at least one data item received according to a predetermined data format distinct from the data formats used by said at least two heterogeneous applications; receiving at least one second data item from the other of said at least two heterogeneous applications;

creation of an object comprising said at least one first piece of data received converted into said predetermined data format, said creation being performed according to said at least one second piece of data received, said item being able to be processed directly by said other of said at least two heterogeneous applications ; and,

transmitting said object created to said other of said at least two heterogeneous applications.

The method according to the invention thus allows the exchange of data between heterogeneous applications without requiring specific data processing rules related to one of the applications. The method according to the invention therefore adapts to the evolution of these applications and processed data. In addition, it can be easily adapted to different heterogeneous applications. The data received by one of the heterogeneous applications can be processed directly, in a standard way.

Advantageously, the method further comprises a step of checking a context based on the comparison of said at least one first data received with at least one other data received from said other of said at least two heterogeneous applications, distinct from said less a second given. The method according to the invention thus makes it possible to carry out verifications before transmitting data to an application, this verification being based on data specific to the application to receive them.

According to a particular embodiment said predetermined format to a recursive structure so that the method is adapted to handle heterogeneous application data when the structure of these data changes. To process such recursive structures, without restriction related thereto, the method preferably comprises at least one iteration.

Still according to a particular embodiment, said step of creating said object comprising said at least one first piece of data received converted into said predetermined data format, said creation being performed according to said at least one second piece of data received, comprises a step of inserting said at least one second data in said object.

Still according to a particular embodiment, the method is accessible to said one of said at least two heterogeneous applications in the form of web services. The method can thus be integrated into a standard environment and be easily accessible.

The method may also access said other of said at least two heterogeneous applications by a specific interface of said other of said at least two heterogeneous applications for transmitting data received and processed in accordance with the invention during the solicitation of the method.

Still according to a particular embodiment, said one of said at least two heterogeneous applications is a customer relationship management application, the other of said at least two heterogeneous applications being a service billing and / or activation application.

The invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer and a device comprising means adapted to the implementation of each step of this process.

The benefits provided by this computer program and device are similar to those discussed above. Other advantages, aims and features of the present invention will emerge from the detailed description which follows, given by way of non-limiting example, with reference to the accompanying drawings in which:

FIG. 1, comprising FIGS. 1a, 1b and 1c, schematically represents solutions of the prior art for enabling the exchange of data between heterogeneous applications;

FIG. 2 schematically illustrates an exemplary generic structure of the pivot format used in an integration layer according to the invention; - Figure 3 shows the transfer of information, from a functional point of view, between a customer relationship management application and a billing application, according to the invention;

FIG. 4 illustrates an example of an algorithm implemented in the heterogeneous application integration layer to carry out the information transfer illustrated in FIG. 3;

FIG. 5, comprising FIGS. 5a and 5b, illustrates more precisely an example of implementation of the context validation and restructuring functions illustrated in FIG. 4;

FIG. 6 illustrates an exemplary hardware architecture adapted to implement the invention, in particular the algorithms shown in FIGS. 4 and 5.

The invention aims to exchange information between heterogeneous applications. One of its purposes is to establish a correspondence between the data manipulated, reliably and robustly, to introduce necessary data and not provided input and to allow transactions to be made between these applications. Although it can be implemented between many applications, it is here considered, for purposes of illustration, that it is implemented between a customer relationship management application and a billing application. A customer relationship management application aims, in particular, to target customers in order to better understand them in order to adapt and personalize the products and / or services offered to them and individualize relationships. Such an application therefore makes it possible to process all the information relating to the customers such as its identity, its user profile and the consumer profile of products and / or services in the form of a customer knowledge base. The profile includes, for example, the means of payment used and the needs of the customer.

In addition, a billing application must manage certain customer information to enable them to be identified, to know the terms of their contracts as well as their consumption in order to establish an invoice. Thus, as noted above, some data is common to customer relationship management and billing applications. In addition, some data used by one of the applications depends on data managed by the other application. In other words, the integration module is responsible for transforming CRM concepts such as information on contracts and products offered in terms of invoicing such as subscription information, services and valuation charges.

According to a particular embodiment, the invention is implemented in the form of an integration module, called integration layer in English terminology. It can be implemented in a purely software or mixed, software and hardware, for example on a dedicated server.

Still according to a particular embodiment, the integration module is developed in an open type language, for example in Java language conforming to J2EE specifications (Java and J2EE are trademarks). As an illustration, the integration module is here based on the application server JonAS (acronym for Java OpeN Application Server in English terminology).

The integration module can be decomposed into layers, each layer forming an interface with one of the heterogeneous applications to be integrated. Thus, for example, a layer may be intended to receive data from a first application and transform them into a generic format while a second layer receives data from a second application, transforms the stored data in generic form into the format required by the second application by adapting them according to data received from the second application and transmits it to the latter.

Advantageously, several generic formats, also called pivot formats, are defined in the integration module. However, the number of pivot formats is preferably limited. As an illustration, the integration module can use a pivot format to describe the accounts and a pivot format to describe the contracts. The pivot formats are described, for example, using the XML language (acronym for eXtensible Markup Language in English terminology).

Figure 2 schematically illustrates an example of a generic format that can be used in the integration module to manage contract data to which a customer can subscribe. Pivot conversion is an intermediate step of data transport. This format is based on a data model describing a billing account, a customer, a contract, an invoice generation request, a consumption request on an account, a balance of an account and a service activation. proposed on a communication network.

In order for the integration module to be independent of the evolution of the commercial offers managed by the billing and customer relationship management systems, the pivot format is preferably defined recursively.

As illustrated, the structure of the pivot format 200 is hierarchical, it here includes references 205 and 210 to a command and parameters, respectively. The order is, for example, a command to create a customer billing account or a change order for such an account while the parameters may include a particular customer identifier.

The structure further includes references 215 and 220 to a main offer and associated parameters, respectively. A main offer is, as an illustration, a mobile phone subscription, an associated parameter that can be a reference to a package. Tenders or ancillary services may be associated, recursively, with the main offer. Thus, the structure of the pivot format here comprises a reference 225 to an ancillary offer, for example a fixed telephony subscription, a reference 230 to valuation charges to which is associated a reference 235 for the parameters relating to these charges and a reference 245 services ancillary to the main offer, for example SMS type services (short message service acronym in English terminology), which is associated with the reference 250 for the parameters relating to these services. The reference 240, related to the reference 230 of valuation charges, is, for example, to determine the billing rate according to criteria specific to the customer and his subscription.

It should be noted here that other offers could be associated with the main offer or an offer or ancillary service, recursively.

Figure 3 shows the transfer of information, from a functional point of view, between a customer relationship management application and a billing application, according to the invention.

Reference 300 here refers to the client relationship management application part, reference 305 refers to the integration module and reference 310 relates to the billing application part.

As illustrated, the data processed according to a data format 315, specific to the customer relationship management application, are converted into a generic format 320 of the integration module. The data stored according to the latter are then converted into a format 330 specific to the billing application. When converting the data stored in the generic format of the integration module into data that can be processed by the billing application, data thereof, stored here in the database 325, are used. The use of billing application data to convert data from the customer relationship management application allows to avoid the coding of specific rules in the integration module which is thus easily portable.

By way of illustration, it can be considered here that the data associated with the data format 315 include in particular information relating to the identity of a client and to a type of subscription to which the customer subscribes. This data is transmitted to the integration module with a command to create a billing account. Upon receipt of this data, the integration module finds, using an integration module enrichment engine, that it lacks information in relation to the generic format defined. It therefore requests the missing information from the billing application by following the rules defined in the enrichment engine. This information is, for example, that to identify valuation services for billing according to the quality of the customer and its type of subscription. Upon receipt of these, they are combined with the information received from the customer relationship management application. All of this information, formatted according to the billing application, is then transmitted to the latter which can then process them directly.

The data modification of the CRM application, impacting the billing application, is processed in a similar manner. However, in this case, the integration module performs an additional step of comparing the data received from the customer relationship management application with the known data of the billing application and a consolidation step of this data. FIG. 4 illustrates an example of an algorithm implemented in the heterogeneous application integration layer for carrying out the data transfer illustrated in FIG. 3.

The references 400, 405 and 410 here apply to the client relationship management application part, the integration module and the billing application part, respectively. The integration module is here called by the customer relationship management application, referred to as CRM, when an account or a customer contract is created or modified (step 415).

The calling function preferably includes the data to be processed. Alternatively, upon receipt of the command, the integration module can send a request to the customer relationship management application to obtain these data.

When received, the data to be processed is converted to the pivot format described above (step 420). If there are several pivot formats in the integration module, it is determined according to the nature of the data received. According to a particularly simple embodiment, this conversion step essentially consists of a rearrangement of the data, an operation known under the name of mapping in English terminology.

A test is then performed to determine if the subject of the call is a contract or an account (step 425).

If it is an account, the context is first validated (step 430). This step consists in comparing the received data with information relating to account templates stored in the billing application, for example in the database 435. If the context is not valid, for example if the information received customer relationship management application is not compatible with the billing application account templates, an indication is sent to the customer relationship management application and the transaction is canceled.

The data stored in the pivot format used, here account type, are then converted to the format used by the billing application (step 440). This conversion step is also called a data restructuring step. This restructuring step here uses data stored in the billing application, in the database 435, including information relating to company or particular account templates. To perform this restructuring step, the integration module relies on its enrichment engine. At the end of the restructuring step, all the data necessary to perform the requested operation are thus collected.

The restructured data is then transmitted to the billing application as an account object (step 445) to allow this application to create or modify an account according to the instructions and information contained therein (step 450).

If the object of the integration module call is a contract (step 425), a second test is performed to determine whether it is a creation or modification request (step 455). If it is a creation step, the context is first validated (step 460) according to information relating to billing account templates, product / service lists and associated parameters, resulting from the billing application, for example from the database 465. This validation step consists in particular in verifying that the data received from the customer relationship management application comply with the account templates and offers managed by the application. billing. Again, if the context is not valid, an indication is sent to the customer relationship management application and the operation is canceled.

The data stored in the pivot format used, here contract type, are then restructured (step 470). This restructuring step here uses data stored in the billing application, in the database 465, including information relating to product and service offers as well as valuation parameters. Thus, at the end of the restructuring step, all the data necessary to perform the requested operation are collected.

The validation and restructuring stages are based on the enrichment engine that associates the types and values of the data sent by the CRM to actions to be performed. These actions will, among other things, extract certain data from the billing application and allow the validation of CRM data or the addition of information completing the request.

The restructured data is then transmitted to the billing application as a contract object (step 445) to enable this application to create a contract according to the information contained in this object (step 450).

If the object of the call to the integration module is a contract (step

425) and if it is a request for modification (step 455), the context is first validated (step 475) according to information relating to the product and service offerings as well as to the valuation parameters from the billing application, for example from the database 465.

The data stored in the pivot format used, here contract type, are then restructured (step 480). This restructuring step again uses data stored in the billing application in the database 465, including information on product and service offerings and valuation parameters. As illustrated, steps 475 and 480 are repeated several times, according to each of the modifications to be made. Once again, the validation and restructuring steps are based on the enrichment engine.

The restructured data is then transmitted to the billing application as a contract object (step 445) to allow this application to create a contract according to the information contained in this object (step 450).

The constitution and maintenance of a billing account are thus automated. Similarly, the combination of a valuation element, which allows billing, for example containing a telephone number, to a product subscribed by the customer, for example a mobile telephone line, is automatic, as is the validation and the formation of subscribed or modified customer contracts.

In addition, the integration module is sufficiently generic to accommodate most types of offers, present and future, including offers combining fixed and mobile telephony, Internet access and television reception via the Internet. network, in order to be able to manage billing system offers that can evolve regularly. In addition, the integration module does not contain configuration elements specific to the offers, types of contracts or customers that an operator may have. Thus, the integration module is able to adapt to operator environments by searching for specific information in the billing system itself, using its enrichment engine based on the format structure. pivots.

The enrichment engine includes a list of business-type rules to apply when validating and restructuring. Alternatively, the enrichment engine includes means enabling it to access such rules. These rules are prioritized to allow, if necessary, a sequential execution.

Each enhancement engine rule associates an action with an attribute of the recursive structure of the pivot format of the request.

This attribute is determined in particular by the type of the element pointed by this attribute, for example a command, service, access or parameter type, the operation requested on this element, for example a creation, a modification or a deletion, the value attribute as well as the number of iterations in the hierarchical structure of the pivot format to reach it.

The possible actions linked to this pointed element are, among other things, an extraction of information in an external application, combined or not with an insertion of an element in the structure of the final request, a deletion of information or a validation of certain information. .

Each rule and each action is preferably associated with a description of the elements to be extracted in the external application, for example valuation elements, billing cycle, account or payment skeleton by type of customer, offer or service. Thus, the search engine can determine the element of the external application processed during a validation or a restructuring.

The rules implemented in the enrichment engine make it possible to obtain here the following elements,

- elements to define which service contains the load that will be valued and its type; - the elements allowing to know the services and the parameters of the services valid at the moment of the subscription by consulting the historical information of the offers and services; and,

- Billing account template elements to define billing attributes, especially billing cycle frequency and payment time information, depending on the type of customer.

FIG. 5, comprising FIGS. 5a and 5b, illustrates more precisely an example of implementation of the context validation and restructuring functions, illustrated in FIG. 4, executed when the integration module receives a creation command from contract.

At the beginning of each commit and restructure operation, the enrichment engine is responsible for listing, or identifying, all the business rules to be applied based on the pivot format type and the transaction type (step 500 ). As indicated above, this is, in the example illustrated in FIG. 5, a creation of a contract. The rules are applied one after the other in a predetermined order.

By way of illustration, the rules associated with the contract type pivot format and the creation operation may be validation rules of the billing, subscription and service account as well as valuation rules.

When a rule is not validated, an error indication is sent to the CRM application and the operation is suspended.

For context validation operations, the integration module compares the data received from the customer relationship management application with information stored in the billing application, according to the rules defined in the enrichment engine. (step

505). The integration module constructs a request to obtain the element informed by the rule and sends a request to the application, here the billing application.

Thus, when the billing application receives a request for information relating to a billing account, it recovers these information and transmits to the integration module (step 510) which can then check the billing account according to the information received from the customer relationship management application (step 515).

If the applied rule is not a validation rule (step 505) or after validation of the billing account parameters, information about the offers and services are accessed.

Thus, when the billing application receives a request to obtain offers, services and / or associated parameters, on the date of the subscription of a contract, it extracts this information from its databases and transmits to the integration module (step 520). Parent offer (215), offer (225) and / or service (245) offerings, such as subscription codes or dates, are used to extract the reference elements from the billing application. .

If the rule applied is a service validation rule (step 525), the integration module, via the enrichment engine, checks the subscription data received from the customer relationship management application with the information received. previously of the billing application (step 530). This step is preferably performed for each subscription, that is to say for the main subscription and all the subscriptions that depend on it.

Similarly, if the applied rule is a service parameter validation rule (step 535), the integration module checks the parameters of the services offered in the subscription, received from the customer relationship management application, with the information previously received from the billing application (step 540).

If billing account information is wrong

(step 515) or if the subscription data (step 530) and / or the service parameters received are not in accordance with the offer (step 540), an error indication is transmitted to the management application of the customer relationship and the transaction is suspended (steps not shown).

The enrichment engine preferably contains rules concerning the recovery charges and their types. When the rule applied is a valuation rule (step 545), the valuation charge information in the offer is then searched for in the data received from the billing application (step 550) and is associated with the subscription data received from the billing application (step 550) and is associated with the subscription data received from the billing application (step 550). customer relationship management application. A valuation charge of a given type is identified through an Enrichment Engine rule by its attribute and its value in the pivot format (230). When the valuation charge is identified in the bid, the valuation identifier (240) is assigned to that charge based on its type.

This valuation information is then added to the subscription data received from the customer relationship management application (step 555) to form the object that will allow the billing application to create the contract corresponding to the subscription.

A test is then performed to determine if all services corresponding to the subscription under treatment have been processed (step 560). If not, the next service is processed (steps 535 to 555).

If all the services corresponding to the subscription under treatment have been processed (step 560), another test is performed to determine whether all subscriptions dependent on the main subscription have been processed (step 565). If not, the next dependent subscription is processed (steps 520 to 560). Finally, if all the services corresponding to the subscription being processed and all subscriptions dependent on the main subscription have been processed, a test is performed to determine whether all the rules identified have been applied. If not, the following rule is applied (steps 505 to 565). It should be noted that depending on the type of operation, for example the modification of a contract or the creation of an account, the verification and insertion of information steps may be different from those described with reference to FIG. Similarly, the insertion step may be replaced or include a selection step in which some data received from the billing application is used to select other data received from the billing application or data received from the billing application. 'application of customer relationship management, to form the object to be transmitted to the billing application, and vice versa.

According to a particular embodiment, the integration module comprises a web services type interface, commonly called web services, allowing the customer relationship management application to directly access the services offered by this module. Access to these services may comply with the http / SOAP standard (acronym for HyperText Transfer Protocol and Simple Object Access Protocol in English terminology). By way of illustration, the services proposed may be the following: - sending an operation for creating or modifying the customer data on a pivot format "Customer";

- sending an operation to create or modify the billing account data on a pivot format "Account";

- sending an operation to create or modify the contract data on a pivot format "Order";

- sending a quotation request operation on a pivot format "Order";

- sending an activation operation on the network of subscribed services on a pivot format "Activation"; - sending an invoice generation request transaction on a "Invoice" pivot format; and,

- sending a balance request operation to the billing account on a pivot format "Balance".

According to a standard service management scheme, the requests received from the customer relationship management application are stored in a queue and processed according to their order of arrival. Alternatively, queries can be processed synchronously.

Still according to a particular embodiment, the billing application is accessible via an API (abbreviation of Application Programming Interface in English terminology) specific.

To improve the availability of the integration module, it can be doubled, in a purely software or software and hardware, according to a redundancy mechanism. Thus, if the integration module fails, the redundant module can take over. The queuing queue is advantageously copied from the failed module to the redundant module. The failure is detectable by the customer relationship management application only if there is at least one request being processed in the integration module. In this case, the application will detect an error and may resubmit the request.

FIG. 6 illustrates an exemplary hardware architecture adapted to implement the invention, in particular the algorithms shown in FIGS. 4 and 5. The device 600 here comprises a communication bus 605 to which are connected:

a central processing unit or microprocessor 610 (CPU, acronym for Central Processing Unit in English terminology);

- A read-only memory 615 (ROM, acronym for Read OnIy Memory in English terminology) may include the programs necessary for the implementation of the invention;

a random access memory or cache memory 620 (RAM, acronym for Random Access Memory in English terminology) comprising registers adapted to record variables and parameters created and modified during the execution of the aforementioned programs; and

a communication interface 650 adapted to transmit and receive data, in particular to and from devices on which the heterogeneous applications are executed.

The device 600 also preferably has the following elements:

a screen 625 making it possible to display data and which can serve as a graphical interface with the user who can interact with the programs according to the invention, using a keyboard and a mouse 630 or another pointing device such as a touch screen or a remote control; a hard disk 635 that may include the aforementioned programs and data processed or to be processed according to the invention; and a memory card reader 640 adapted to receive a memory card 645 and to read or write to it data processed or to be processed according to the invention.

The communication bus allows communication and interoperability between the various elements included in the device 600 or connected to it. The representation of the bus is not limiting and, in particular, the central unit is able to communicate instructions to any element of the device 600 directly or via another element of the device 600. The executable code of each program enabling the programmable device to implement the processes according to the invention can be stored, for example, in the hard disk 635 or in the read-only memory 615.

According to one variant, the memory card 645 may contain data, in particular a correspondence table between the detected events and the commands that can be requested, as well as the executable code of the aforementioned programs which, once read by the device 600, is stored in the hard disk 635.

According to another variant, the executable code of the programs may be received, at least partially, via the interface 650, to be stored in a manner identical to that described above.

More generally, the program or programs may be loaded into one of the storage means of the device 600 before being executed.

The central unit 610 will control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, instructions which are stored in the hard disk 635 or in the read-only memory 615 or else in the other elements of aforementioned storage.

When powering on, the program or programs that are stored in a non-volatile memory, for example the hard disk 635 or the read-only memory 615, are transferred into the random access memory 620 which then contains the executable code of the program or programs according to the invention, as well as registers for memorize the variables and parameters necessary for the implementation of the invention.

Naturally, to meet specific needs, a person skilled in the field of the invention may apply modifications in the foregoing description.

Claims

A computer method for integrating heterogeneous applications in a system comprising at least two heterogeneous applications, said method being characterized in that it comprises the following steps,

converting (420) said at least one data item received according to a predetermined data format distinct from the data formats used by said at least two heterogeneous applications;

receiving at least one second data item from the other of said at least two heterogeneous applications;

creation (440, 470, 480) of an object comprising said at least one first received data item converted into said predetermined data format, said creation being performed according to said at least one second piece of data received, said item being able to be processed directly by said other of said at least two heterogeneous applications; and,

transmitting (445) said created object to said other of said at least two heterogeneous applications.

The method of claim 1 further comprising a step of verifying (430, 460, 475) a context based on comparing said at least one first received data with at least one other data received from said other of said at least one received data. two heterogeneous applications, distinct from said at least one second datum.

3. Method according to claim 1 or claim 2 characterized in that said predetermined format to a recursive structure.

4. The method of claim 3 wherein said creating step comprises at least one iteration related to the recursivity of said format. predetermined for use in converting said at least one first datum.

5. Method according to any one of the preceding claims, wherein said step of creating said object comprising said at least one first piece of data received converted into said predetermined data format, said creation being performed according to said at least one second piece of data received, comprises a step of inserting said at least one second datum into said object.

6. Method according to any one of the preceding claims wherein the method is accessible to said one of said at least two heterogeneous applications in the form of web services.

7. Method according to any one of the preceding claims, wherein said method accesses said other of said at least two heterogeneous applications by a specific interface of said other of said at least two heterogeneous applications.

The method according to any one of the preceding claims wherein said one of said at least two heterogeneous applications is a customer relationship management application, the other of said at least two heterogeneous applications being a billing application and / or activation of services.

9. Computer program comprising instructions adapted to the implementation of each of the steps of the method according to any one of the preceding claims when said program is executed on a computer.

10. Device comprising means adapted to the implementation of each of the steps of the method according to any one of claims 1 to 8.