SYSTEM AND METHOD FOR CONFIGURATION AND INTERCHANGING OF BUSINESS FUNCTIONALITY IMPLEMENTATIONS

Abstract

A system and method are presented for invoking integration actions in a unified collaboration system. A client communicates with a bridging web server through a ReST. The bridging web server comprises a cloud service which facilitates communication with integration servers, which may be located on-premises. In an embodiment, the integration server(s) host a number of plugins which are capable of implementing integration actions. The bridging web server decides which action implementation is the best one to service a request. The implementation may be based on prior configuration. Routing decisions on the bridging web server may be automatically selected based on prior configuration.

Description

BACKGROUND

The present invention generally relates to telecommunications systems and methods, as well as unified collaboration systems. More particularly, the present invention pertains to integration actions within the unified collaboration systems.

SUMMARY

A system and method are presented for invoking integration actions in a unified collaboration system. A client communicates with a bridging web server through a ReST. The bridging web server comprises a cloud service which facilitates communication with integration servers, which may be located on-premises. In an embodiment, the integration server(s) host a number of plugins which are capable of implementing integration actions. The bridging web server decides which action implementation is the best one to service a request. The implementation may be based on prior configuration. Routing decisions on the bridging web server may be automatically selected based on prior configuration.

In one embodiment, a method is provided for invoking integration actions in a unified collaboration system, wherein the system comprises at least a client operatively connected to a web server, wherein the web server is operatively connected to an integration server, the method comprising the steps of: establishing communication, by the client, with the web server, wherein the web server comprises a routing decision mechanism; communicating, by the web server, with the integration server, wherein the integration server comprises a plurality of plugins capable of implementing the integration actions; and deciding, by the web server, which integration action to perform wherein the deciding is based at least in part on prior configuration of the web server.

In another embodiment, a method is provided for invoking integration actions in a unified collaboration system, wherein the system comprises at least a client operatively connected to a web server, wherein the web server is operatively connected to an integration server, the method comprising the steps of: establishing communication, by the client, with the web server, wherein the web server comprises a routing decision mechanism; communicating, by the web server, with the integration server, wherein the integration server comprises a plurality of plugins capable of implementing the integration actions; and deciding, by the web server, which integration action to perform wherein the deciding is based at least in part on a failsafe mechanism..

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an embodiment of invoking an integration action.

FIG. 2 is a diagram illustrating an embodiment of invoking an alternate integration action implementation after a configuration change has occurred.

FIG. 3 is a diagram illustrating an embodiment of an integration action configuration.

FIG. 4 is a diagram illustrating an embodiment of invoking customer action with a customer relationship management software service.

FIG. 5 is a diagram illustrating an embodiment of invoking customer action with a database implementation.

DETAILED DESCRIPTION

For the purposes of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Any alterations and further modifications in the described embodiments, and any further applications of the principles of the invention as described herein are contemplated as would normally occur to one skilled in the art to which the invention relates.

Integration actions may be used in contact center applications for interaction flow construction or scripts. A bridge might refer to system of integration which allows integration (or bridging) of a platform with third party applications. Without integration actions, these types of systems would have to contain connection details and other technical information necessary to perform a business function (such as finding a user in a database by looking up the user's phone or contact number). Connection information and other details behind how to retrieve that user data are contained in the integration action. In an embodiment, the application needs to only know what the inputs are (e.g., the phone number), what the outputs will be (e.g., a user record), and the URL to invoke the action. Applications know which business functions they want to perform, but they don't know how to perform that operation. Integration actions provide the mechanics to performing an operation and can be altered without updates to the application itself. Without integration actions, the mechanics would have to be installed prior to disbursement. Updates would be required to the application whenever the mechanics are out of date, such as when credentials are updated or a new Customer Relationship Management (CRM) system is deployed.

Integration actions provide individuals without software development knowledge the ability to change implementations (and hence the behavior) behind a ReST request without needing to write code and without notifications or changes to the clients invoking the action. Thus, a source of where a specific piece of data is obtained may be changed without the client needing to be aware that a change was even made. Integration server plugin developers may be provided a .NET API through which they are able to expose an action implementation, making it available to the customer to configure as an action endpoint. An action may have a constant URL and schema for inputs and outputs; however, the specific bridge plugin instance that provides the implementation is allowed to change at a customer's request.

A single action may thus be implemented by plugins such as a CRM (e.g., Salesforce) plugin, a workforce management system plugin, and a database plugin (e.g. Oracle, Microsoft SQL). A customer is able to change their action configuration to change between these implementations as dictated by business needs, without requiring any changes to clients consuming this action.

In an embodiment, integration actions comprise a layer between clients consuming a ReST API and plugins, which provide some implementation for that action. FIG. 1 is a diagram illustrating an embodiment of invoking an integration action, indicated generally at 100. Components might comprise a Client 105, a Bridging Web Server 115, and an Integration Server 125 which further comprises at least one Plugin 120.

The client 105 might comprise a unified collaboration service or a UI component which requires a business function that an action provides, such as applications for constructing call flows by a flow author, to name a non-limiting example. In an embodiment, because integration actions are exposed via HTTP communications, the client 105 should be capable of communicating HTTP and handling JSON bodies.

The client 105 communicates with the bridging web server 115 via a Representational State Transfer (ReST) 110. The bridging web server 115 communicates with the integration server 125, also via ReST. The integration server 125 may host a number of plugins 130 which are capable of implementing integration actions. The bridging web server 115 comprises a cloud service (such as a cluster of machines running in AWS) that facilitates communication with integration servers 125. The routing decision mechanism 120 on the bridging web server 115 is selected based on the configuration by a customer. When an integration action is invoked, the bridging web server 115 decides which integration action implementation is the best one to fulfill the action request based on customer configuration. Integration actions may be created or edited by a customer, or selected from a list of available plugins to decide which one will fulfill the integration action request. Integration servers 125 exist on a customer's premises and the bridging web server(s) 115 provide a communication channel to the integration servers 125 for invoking methods on plugins 130a and 130b. Plugins 130 define one or more integration action implementations. There is no practical limit to the number of plugins that can be created or the number of integration action implementations that a single plugin can implement. In this example, two are shown (130a and 130b) as a non-limiting example for simplicity.

FIG. 2 is a diagram illustrating an embodiment of invoking alternate integration action implementation after a configuration change has occurred, indicated generally at 200. Similar to the embodiment illustrated in FIG. 1, the routing decision mechanism 220 on the bridging web server 115 is selected based on the configuration by a customer. When an integration action is invoked, the bridging web server 115 decides which action implementation is the best one to fulfill the action request based on customer configuration. Integration actions may be created or edited by a customer or selected from a list of available plugins to decide which one will fulfill the action request. Integration servers 125 exist on a customer's premises and the bridging web server(s) provide a communication channel to the integration servers 125 for invoking methods on plugins 130. Plugins 130 may define one or more integration action implementations. In embodiment non-limiting example, the routing decision mechanism communicates with the plugin 130b via the integration server125 which delegates to the plugin 130b.

FIG. 3 is a diagram illustrating an embodiment of an integration action configuration, indicated generally at 300. Once a plugin has been deployed to an integration server, the integration action implementations that are defined in that plugin become available for selection in the configuration UI 300 for integration actions, and subsequently available for the integration web server to use when fulfilling an integration action invocation. Prior to use, an integration action may be setup by defining information such as an action name 305, a plugin group 310, a request schema definition 315, a response schema definition 320, a plug-in action 325, and plug-in information 330. The action name 305 may comprise a description of the integration action. In FIG. 3, the action name 305 is “TestActionCall Details”, for example. In an embodiment, schema may be defined in JSON schema. The plugin group 310 represents a cluster of plugin instances that are available to fulfill an action request. In an embodiment, it is a failover mechanism and can act as a replacement in the event another plugin failure. A request schema definition 315 defines the inputs to the action including the property names and any constraints on the property values. The response schema definition 320 comprises the outputs that the action will provide, including the property names and any constraints on the property values. Implementation of an integration action may comprise a .NET method defined as part of a plugin. The method might have an input parameter corresponding to the integration action request schema and a return value corresponding to the integration action response schema. By installing and configuring an integration server plugin, the bridge platform may be made aware of what integration action implementations the integration server plugin has. The bridging platform may then present the implementation for selection in the integration action configuration. In the diagram 300, the plug-in action 325 selected is “GetContactByPhoneNumber”. Other information 330 may also be listed in the UI, such as the plugin type 330a (Salesforce) and other system information 330b (supporting platform and version).

After being configured, the integration action may be invoked by contacting a ReST endpoint, with the HTTP request path containing the name of the action to be invoked. The bridging platform then determines which integration action implementation has been configured to fulfill the requested action. The bridging platform may then translate the request body from JSON to a .NET object, and call the .NET method. The bridging platform may then wait for the method to return, translate the returned .NET object into JSON, and return the HTTP response to the client. FIG. 4 is a diagram illustrating an embodiment of invoking customer action with a customer relationship management software service, indicated generally at 400.

Integration actions may hide implementation details about how a customer-specific business function is performed. The actions may be used to provide a single entry point to a service that is capable of providing a specific business function in a number of ways, without the client having to know which code is being used to provide that functionality. In an embodiment, a common use may be abstracting away the implementation behind looking up a caller's identity information given their phone number. An integration action may be created that provides a contract which accepts a phone number in the request and returns the customer's name, address and account number. Multiple integration action implementations would be created for this, perhaps one that retrieves the information from a database 415, such as Oracle, and one that retrieves the information from a CRM 410, such as Salesforce.com. A customer would then be able to choose which implementation is the right one for their business and even swap out these implementations at will via the integration action configuration, without the client ever knowing something has changed. In FIG. 4, information is retrieved 405 from Salesforce.com 410 via an integration action. Alternatively, FIG. 5 is a diagram illustrating an embodiment of invoking customer action with a database implementation, indicated generally at 500. In FIG. 5, information is retrieved 505 from a database associated with Oracle 415.

While the invention has been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive in character, it being understood that only the preferred embodiment has been shown and described and that all equivalents, changes, and modifications that come within the spirit of the invention as described herein and/or by the following claims are desired to be protected.

Hence, the proper scope of the present invention should be determined only by the broadest interpretation of the appended claims so as to encompass all such modifications as well as all relationships equivalent to those illustrated in the drawings and described in the specification.

Claims

1. A method for invoking integration actions in a unified collaboration system, wherein the system comprises at least a client operatively connected to a web server, wherein the web server is operatively connected to an integration server, the method comprising the steps of:

a. establishing communication, by the client, with the web server, wherein the web server comprises a routing decision mechanism;

b. communicating, by the web server, with the integration server, wherein the integration server comprises a plurality of plugins capable of implementing the integration actions; and

c. deciding, by the web server, which integration action to perform wherein the deciding is based at least in part on prior configuration of the web server.

2. The method of claim 1, wherein the communication of step (a) is established via ReST.

3. The method of claim 1, wherein the web server comprises a cloud service which is capable of facilitating communication with the integration server.

4. The method of claim 1, wherein the integration server is capable of integration of the client with one or more third party applications.

5. The method of claim 1, wherein the client comprises one of: a unified collaboration service or a UI component, wherein the UI component requires a business function.

6. The method of claim 5, wherein the client is capable of communication via HTTP and handling JSON bodies.

7. The method of claim 1, wherein the integration server is located on-premises.

8. The method of claim 7, wherein the integration server is capable of communicating via a WebSocket protocol.

9. The method of claim 1, wherein the plugins define one or more integration action implementations.

10. The method of claim 1, wherein the prior configuration comprises a manual configuration or an automatic configuration.

11. The method of claim 1, wherein the integration action configuration is capable of alteration at any time in the process without disruption of the system.

12. The method of claim 1, further comprising the step of:

d. connecting, by the integration server, the unified collaboration system with a third party application.

13. The method of claim 12, wherein the third party application comprises one or more of: a customer relationship management system, a database, and a workforce management system.

14. The method of claim 1, wherein the integration actions have been manually configured to include one or more of: defined inputs to the integration action; defined outputs that the integration action provides; an identifier wherein the identifier is used by the client to specify which business function to perform; and a plugin grouping.

15. The method of claim 14, wherein the defined inputs comprise property names and constraints on the property values and the defined outputs comprise property names and constraints on the property values.

16. The method of claim 14, wherein the plugin grouping comprises a cluster of plugin instances that are available to fulfill a request of the integration action.

17. A method for invoking integration actions in a unified collaboration system, wherein the system comprises at least a client operatively connected to a web server, wherein the web server is operatively connected to an integration server, the method comprising the steps of:

a. establishing communication, by the client, with the web server, wherein the web server comprises a routing decision mechanism;

b. communicating, by the web server, with the integration server, wherein the integration server comprises a plurality of plugins capable of implementing the integration actions; and

c. deciding, by the web server, which integration action to perform wherein the deciding is based at least in part on a failsafe mechanism.

18. The method of claim 17, wherein the communication of step (a) is established via ReST.

19. The method of claim 17, wherein the web server comprises a cloud service which is capable of facilitating communication with the integration server.

20. The method of claim 17, wherein the integration server is capable of integration of the client with one or more third party applications.

21. The method of claim 17, wherein the client comprises one of: a unified collaboration service or a UI component, wherein the UI component a business function.

22. The method of claim 21, wherein the client is capable of communication via HTTP and handling JSON bodies.

23. The method of claim 17, wherein the integration server is located on-premises.

24. The method of claim 23, wherein the integration server is capable of communicating via a WebSocket protocol.

25. The method of claim 17, wherein the plugins define one or more integration action implementations.

26. The method of claim 17, wherein the integration action configuration is capable of alteration at any time in the process without disruption of the system.

27. The method of claim 17, further comprising the step of:

d. connecting, by the integration server, the unified collaboration system with a third party application.

28. The method of claim 27, wherein the third party application comprises one or more of: a customer relationship management system, a database, and a workforce management system.

29. The method of claim 17, wherein the integration actions have been manually configured to include one or more of: defined inputs to the integration action; defined outputs that the integration action provides; an identifier wherein the identifier is used by the client to specify which business function to perform; and a plugin grouping.

30. The method of claim 29, wherein the defined inputs comprise property names and constraints on the property values and the defined outputs comprise property names and constraints on the property values.

31. The method of claim 29, wherein the plugin grouping comprises a cluster of plugin instances that are available to fulfill a request of the integration action.

32. The method of claim 17, wherein the failsafe mechanism has been configured to utilize an alternative plugin if a desired plugin is unavailable.