U.S. patent application number 15/073696 was filed with the patent office on 2017-09-21 for system and method for configuration and interchanging of business functionality implementations.
The applicant listed for this patent is Interactive Intelligence Group, Inc.. Invention is credited to Robert Adams, Shawn Axsom, Andrew Crowell, Paul L. Melliere, Aydan Yumerefendi.
Application Number | 20170272547 15/073696 |
Document ID | / |
Family ID | 59847954 |
Filed Date | 2017-09-21 |
United States Patent
Application |
20170272547 |
Kind Code |
A1 |
Melliere; Paul L. ; et
al. |
September 21, 2017 |
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.
Inventors: |
Melliere; Paul L.; (Apex,
NC) ; Adams; Robert; (Indianapolis, IN) ;
Yumerefendi; Aydan; (Durham, NC) ; Crowell;
Andrew; (Seattle, WA) ; Axsom; Shawn;
(Indianapolis, IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Interactive Intelligence Group, Inc. |
Indianapolis |
IN |
US |
|
|
Family ID: |
59847954 |
Appl. No.: |
15/073696 |
Filed: |
March 18, 2016 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 67/327 20130101;
H04L 67/02 20130101; H04L 67/20 20130101; H04L 67/42 20130101; H04L
67/32 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; H04L 29/08 20060101 H04L029/08 |
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.
Description
BACKGROUND
[0001] 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
[0002] 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.
[0003] 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.
[0004] 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
[0005] FIG. 1 is a diagram illustrating an embodiment of invoking
an integration action.
[0006] FIG. 2 is a diagram illustrating an embodiment of invoking
an alternate integration action implementation after a
configuration change has occurred.
[0007] FIG. 3 is a diagram illustrating an embodiment of an
integration action configuration.
[0008] FIG. 4 is a diagram illustrating an embodiment of invoking
customer action with a customer relationship management software
service.
[0009] FIG. 5 is a diagram illustrating an embodiment of invoking
customer action with a database implementation.
DETAILED DESCRIPTION
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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).
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
* * * * *