Using messages to extend CRM functionality

A method of extending the functionality of an API in a CRM program and system to implement the method is disclosed. The method may allow a user to use request and response messages to be communicated with a single interface that may be exposed as a CRM web service module to create new business logic and operations by extending previously defined classes.

This is a non-provisional of U.S. Provisional Application Ser. No. 60/695,958, filed Jul. 1, 2005, the entire disclosure of which is incorporated herein by reference.

BACKGROUND

Typical business applications may have a number of business entities and may be capable of performing various operations on those entities based on business logic. Such applications provide an Application Programming Interface (API) that allows access to and execution of business logic related to those entities. As interoperability is a critical requirement in business applications, Web Service technology may be used to design the APIs. Consumers of the API are dependent on the signature of the API and are impacted when changes are made to the APIs during its life cycle. Also proportionate to the number of business entities that exist in such applications, a similar number of static operations (methods) are defined and made available through the API.

SUMMARY

A method of extending the functionality of an API in a CRM program and system to implement the method is disclosed. The method may allow a user to use request and response messages to be communicated with a CRM web service module to create new business logic and operations by extending previously defined classes and through a single API interface. Target base classes are created by separating the business entities into categories based on the business operations supported by the category and wherein the target class hierarchy can be reviewed to determine what business entities support which operations.

DESCRIPTION

FIG. 1illustrates an example of a suitable computing system environment100on which a system for the steps of the claimed method and apparatus may be implemented. The computing system environment100is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the method of apparatus of the claims. Neither should the computing environment100be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment100.

Typical business applications may have a number of business entities and may be capable of performing various operations on those entities based on business logic. Such applications provide an Application Programming Interface (API) that allows access to and execution of business logic related to those entities. An API may be a set of programs, code libraries, or interfaces used by developers to interact with a hardware device, network, operating system, software library, or application. As interoperability is a critical requirement in business applications, Web Service technology may be used to design the APIs. Consumers of the API are dependent on the signature of the API and are impacted when changes are made to the APIs during its life cycle. Also proportionate to the number of business entities that exist in such applications, a similar number of static operations (methods) are defined and made available through the API. This model is difficult to extend for several reasons:

1. Any change to the API requires a change to all its consumers. Method based extensibility not very versatile and cost effective. In order to extend such APIs, new methods need to be added to the API set;

2. Any change to the type system supported by the API requires a change to the API implementation and all consumers;

3. Ongoing complexity and cost of managing and maintaining a large number of methods;

4. Ongoing cost and complexity of managing the consistency of operations and data across different types of business entities;

5. Longevity of the APIs and its lifetime through a number of different versions of the application;

6. The programming model and development experience could be complex due to the large number of messages and/or types in the API;

7. Often the customizations and the new types (e.g. new Business Entities) that are introduced by the end users require a different programming model compared to the system Business Entities;

8. End users of the API can not easily extend the API functionality; and

9. Work flow and business processes can not be easily integrated with the API.

A Message-Oriented approach creates an extensibility point that addresses all the problems mentioned and provides a framework that allows new business logic to be implemented through new messages. This method accepts arbitrary messages, even messages defined after the implementation, without modification of the API signature or type system. The Message-Oriented approach has the following advantages:

1. Any change to the API may be implemented by addition of a new message without changing the signature of the method or impacting the existing consumers of the method;

2. System types can be extended without breaking the existing consumers;

3. A relatively large number of business entities and business logic can be consolidated in a well organized, browse-able list of messages in the development environment as a way to improve the usability and development experience;

4. Ongoing cost and complexity of managing the consistency of operations and data across different types of business entities can be significantly reduced via a simple message class hierarchy;

5. Longevity of the APIs and its lifetime is improved due to a single extensibility point: messages;

6. The customization and the new types (e.g. new Business Entities) that are introduced by the end users may fit into the message class hierarchy and be consumed with the same programming model compared to the system Business Entities;

7. The API and its functionality can easily be extended by defining new messages; and

8. Work flow and business processes can be easily integrated with the API through a set of newly defined messages that include the workflow recipes and process descriptions.

A message-oriented API may allow the users of the business application to execute business logic and access the business operation and data via messages.FIG. 2may be an illustration of the design of such a system, for example, in a customer relationship management (“CRM”) system. CRM may be a way to maintain having the ability to organize and maintain a connection with clients, customers and service agents with regards to business relationships and customer satisfaction and a CRM application may be an acronym for customer relation management application which are programs by which a customer can be profiled and tracked to assist a sales staff in providing better service for that customer, resulting in improved customer relations overall.

The CRM web service200may be the interface that users of the business application use. The interface exposes the new messages (extension) that have been added to the CRM system after customization as well as the original messages that initially were included in the system through the same interface. The same interface and programming model that is used for the system original business Entities is used for custom Business Entities providing a seamless programming experience. This web service200has a well defined web service description provided for in Web Service Definition Language (WSDL) and may be defined in any other desired definition language. WSDL may be an XML-based contract language for describing the network services offered by a Web service provider via UDDI. UDDI stands for Universal Description, Discovery, and Integration and may be an XML and SOAP-based lookup service for Web service consumers to locate Web Services and programmable resources available on a network. WSDL may describe a Web service to Web service consumers by its public methods, data types of all parameters, return value, and bindings. SOAP stands for Simple Object Access Protocol which may be a lightweight, XML-based messaging protocol used to encode the information in Web service request and response messages before sending them over a network. SOAP messages may be independent of any operating system or protocol, and may be transported using a variety of Internet protocols, including SMTP, MIME, and HTTP. The WSDL is dynamically generated for the users of the system and enables them to access the web service and program against it.

The system may have a single web service method, called Execute. An example may look like:

The same method and interface may be used to work with various business entities and business operations and data in the system. The Execute method may take Request messages210and return Response messages220. Request messages may be instantiated and built by a client of the CRM web service230. The caller may send the message to the CRM platform by calling the Execute method on the Web service230. The message may be serialized into a SOAP packet by the client240before being sent to the CRM web service200and then deserialized back to the message object on the CRM Web platform. The message may then be sent to the server250and processed there. The result of message processing may be returned to the caller of the Execute web method via a response message220. Both request and response message content may be strongly typed allowing the caller to use a better development environment support when working with types. It also should be noted that SOAP is one of the available protocols for exchanging structured information in a decentralized, distributed environment, but that any appropriate protocol may be used.

FIG. 3may be a class diagram that illustrates the class hierarchy of Request and Response messages that are used in conjunction with the Execute method. There will be several classes derived from the Request message to represent different business operations that are supported by the CRM system. Each Request derived class has a corresponding Response derived class. For example CreateRequest class is derived from the Request class and corresponds to CreateResponse class that is derived from the Response class. As a general rule, the parameters on a typical web method may be mapped into members of the Request messages310and return parameters of a typical web method may be mapped to the members of the Response message320. All the supported business operations and business logic may be exposed via subclasses of Request messages330and may be postfixed with the Request and Response keywords. The messages may all start with the Operation name where Operation is a supported business operation in CRM platform. Both of these naming conventions enables easy browsing of the messages in the development environment and improved the API usability.

FIG. 4may illustrate a method of using messages to extend functionality of an application programming interface in a CRM system. At block405, the method may select an operation where the operation is a CRM operation. As the message-oriented design is process centric, the programming experience may start by the developer choosing the desired business operation (Create an Account, Merge an Account, Send an Email) through selecting a concrete Request message.

At block405, the method may communicate a request message based on the selected operation. The communication may occur over any wired or wireless channel using a communication protocol appropriate for the channel chosen. As explained previously, the method may take Request messages and return Response messages. Request messages may be instantiated and built by a client of the CRM web service. The caller may send the message to the CRM platform by calling the Execute method on the web service. The message may be sent via any transport protocol, such as SOAP for example, to the CRM server and gets processed there.

At block415, if the request message has a business entity type name as part of the request messages, this will indicate to the user that the message is only valid for that specific Business Entity, then the user may instantiate the request message; filling the request message parameters at block420; and then sending the request message to the CRM server for processing at block425.

At block430, if the request message is a common request message without any business type name in the request message name, then a user may instantiate the request message. At block435, the user may discover supported target business entities by looking at the target class type and instantiate the target base class. At block440, the user may fill in the target class parameters to the request message. This approach ensures that the user can only execute supported operation on a given Business Entity, at design time.

At block445, the method may add the target class to the request message and at block425, the method may execute the request message. The result of the execution may be returned to the caller of the Execute web method via a response message. Both request and response message content may be strongly typed allowing the caller to use a better development environment support when working with types. Of course, this is just one way of executing the method and other ways are possible.

At block450a user may instantiate a request message that has no references to any business entity, neither in the request message name nor in the request message class. This type of message is business entity agnostic and may be used to execute generic operations that do not necessarily require any reference to a business entity. At block455, the method may fill in the request message parameters; and then the request message may be sent to the CRM server for processing at block425.

The API may be extended via new messages. As all the new messages are derived from the base Request and Response messages adding new messages does not require changing of the method signature. For example, one version of CRM can have the ability to send an email by exposing the SendEmailRequest message and the later on add a new functionality to send a fax via a telephone line by simply adding a new message called SendFaxRequest. Both messages are derived from the base Request class and therefore do not require a change in the Execute method. Also the existence of class hierarchy may allow the serialization and deserialization of the messages to happen properly on both the client and server.

Polymorphism on the request message hierarchy may mean that the same interface can be used for multiple business entity types without the need of creating a new and separate interface for each business entity. For example a CreateRequest can be used to create new instances of different types of business entities via the same message and the same Execute method. This is one of advantages of message oriented approach.

Different types of messages may be defined in the system to satisfy different types of business operations that are provided in a business application. Some messages represent common operations and apply to most of the business entities in the system while some other messages are more targeted towards a specific set of business entities. A developer that uses a business application API may need to discover what business entities are supported on what business operation in the design environment and without making reference to documentation. The disclosed system may be addressed via Target classes and business entity Categories. Target classes may enable a developer to identify what messages are supported for which business entities. The business entities may be grouped under different categories based on the business operation that are supported by the category and for each group a Target base class is created.

FIG. 5may illustrate the Target class hierarchy for two examples. TargetMerge510and TargetQuantify520each represent a business entity category that may support a number of operations. Each business entity that belongs to the category has a Target class derived from these classes. For example in TargetMerge case, TargetMergeAccount class is a derived class that shows the Account business entity is a member of TragetMerge category. With this class hierarchy, the user of the API may be enabled to programmatically or by using tools in their development environment browse the Target class hierarchy and discover all the supported configurations without need of documentation.

Sample code to execute the merge operation may be as follows:

//1) Create a Merge Request

//2) The type of Target field of MergeRequest is TargetMerge so the derived classes

//are named as TargetMerge<Business Entity Name>. Create an instance of a class derived from TargetMerge that corresponds to a selected Business Entity.

//3) Set the Target on the Request message

//4) Execute the Merge Request, type of Response message will be MergeResponse.

The customization integration with the programming model may be seamless and consistent with the rest of the programming model. The CRM system may allow the users to add new business entities to the system. The addition of business entities to the system may automatically trigger generation of new types and messages in the service definition of the CRM web service and extends the hierarchy of messages. This may allow the developers to work with both original and customized strongly typed business entity classes and messages that accept these classes and enable execution of business logic and operation on them.

Another example of code to create and instance of a new business entity that already added as part of customization follows:

//User company FAB has created a custom business Entity in the system named //fab_Vendor. The user gets the same experience as working with system entities

//Business Operation is Update

myVendor.fab_description=“A trusted vendor that provides safety equipment for Bikes”;

FIG. 6may illustrate a class diagram for DynamicEntity610, a new business entity, and its members. This class may be a peer to rest of the CRM Business Entities that are also derived from BusinessEntity620. DynamicEntity610may be a new class derived from BusinessEntity620that allows an entity instance to be programmed against without having the full definition of the entity in the description of CRM web service available in WSDL language. DynamicEntity610may have an array of strongly typed properties (Properties)630that represent the entity attributes and a name (Name)640that represent the logical name of the entity. As the DynamicEntity610class is exposed in the WSDL as a class with an array of properties, a user of the API may create instances of this class and set the name of it to any desired business entity (system or custom, included or not included in the WSDL) and add any desired properties (included or not included in the WSDL) to the array without getting any compile/design time errors. At runtime, the content of the properties array will be evaluated and if the entity name does not exist or the properties named in the array is not recognized a runtime exception may be thrown.

Code to define DynamicEntity may be as follows:

The DynamicEntity class610may extend the API beyond the strongly typed classes and may provide a generic and extensible way to work with business entities and execute their business logic. A user may decide to use the strongly typed business entities classes DynamicEntity610format. A user also may decide to receive the results of the business operations execution in strongly typed BusinessEntities620objects or DynamicEntity610format. The benefit of DynamicEntity610is that at the design time, the user does not need to have fully described web service definition of the specific business entity type and can develop code that dynamically and at runtime discovers various defined business entities in a targeted CRM implementation and work with those entities (execute operations) without having their definitions at design/compile time.

Thus, many modifications and variations may be made in the techniques and structures described and illustrated herein without departing from the spirit and scope of the present claims. Accordingly, it should be understood that the methods and apparatus described herein are illustrative only and are not limiting upon the scope of the claims.