Dialogflow/APIGEE Integration for CCAI
Google’s Contact Center AI solution offers natural interactions based on AI-powered conversation. By using the Contact Center AI, you can automate the interactions between your customers and your backend support agents. The Contact Center AI frees human agents to focus on more complex and specialised calls, providing them with real-time information, workflows, and turn-by-turn guidance.
Though the Contact Center AI has many components but one of the components is Dialogflow which lets you create advanced Virtual Agents within a short time. These Virtual Agents can seamlessly switch between topics, handle supplemental questions, and operate across multiple channels 24/7 to minimize live agent interventions.
When your customer is interacting with a Dialogflow virtual agent, the agent might access your backend services to gather information. Also, the agent might send information that you want to store in your backend systems. Dialogflow defines the format of the response data. So, a Dialogflow agent accepts the response data from your backend services only in the specified format. Similarly, your backend services might require the request data in a specific format. As a backend service integrator, you have to ensure seamless communication between your Dialogflow agent and your backend services.
Developing APIs for CCAI fulfillment is not a straightforward task. There can be many challenges associated with it, including:
Complexity: You may need to access APIs that are not exposed externally, which can require significant collaboration and rules to enable access to existing data and systems. This can easily lead to technical debt and more inefficiency without an API Gateway that can translate the complexities of data systems in real time and forward them to a customer.
Increased customer frustration: Contact centers often act as one of the primary drivers of customer experience. Improving the speed of response can enhance experiences, but any friction or delays can be magnified. Caching and prefetching data are some commonly used flows to enable faster virtual agent responses.
API Orchestration: APIs generally require more than just exposing an endpoint as they need to change often in response to customer needs. This flexibility can require API orchestration, where APIs are decoupled from rigid services and integrated into an interface tailored to the expected consumption patterns and security requirements of interacting with Dialogflow CX.
Without an API platform, translating complexities of data systems in realtime and forwarding to the caller is not efficient.
This is where Apigee plays a major role. Apigee can reduce time to value, uplevel the call center conversation, and simplify/secure common integration patterns. The Apigee platform helps accelerate the development of CCAI-compatible APIs to fulfill agent
actions by providing pre-constructed APIs and connectors. It provides an interface tailored to the expected patterns and security requirements of talking to CCAI. Furthermore, it helps integrations with your hybrid architectures across your contact centers and also eases the
complexity of integration with legacy systems to fulfill the virtual agent actions.
APIGEE support in Dialogflow
You can use Apigee to manage the interactions between Dialogflow and your backend services. Apigiee’s ParseDialogflowRequest and SetDialogflowResponse policies enable easier integration with Dialogflow. By using these policies, you can easily plug-in your backend services to handle fulfillment requests from Dialogflow.
The ParseDialogflowRequest policy processes the WebhookRequest from a Dialogflow virtual agent before sending the request data to your backend services. The policy extracts data from the WebhookRequest into the flow variables, which your backend services can use.
The SetDialogflowResponse policy processes and formats the response data from your backend services as a WebhookResponse to the Dialogflow virtual agent. The policy constructs a WebhookResponse in the required format for a Dialogflow agent.
Get more out of Contact Center AI API development with Apigee
The following are several best practices for Apigee API development for Dialogflow CX API fulfillments:
1. Create a single common Apigee API proxy
Let’s assume we have a Dialogflow CX virtual agent that needs three fulfillment APIs that will be fronted by Apigee:
a) get list of items
b) add items to cart
c) order items in cart
Technically, you can create a separate Dialogflow CX webhook for each of these APIs, which can point to three separate API proxies.
However, because Dialogflow has a proprietary request and response format, creating three separate API proxies for those fulfillment APIs results in three non-RESTful proxies that are difficult to consume for any clients other than Dialogflow CX virtual agents.
Instead, we recommend creating a common Apigee API proxy that is responsible for handling all the fulfillment APIs required by the agent. Dialogflow CX will have just one webhook that is configured to send requests to the common Apigee API proxy. Each webhook call is sent with a webhook tag that uniquely identifies the correct fulfillment API.
2. Leverage Dialogflow policies as much as possible
Apigee provides two Dialogflow-specific policies: ParseDialogflowRequest and SetDialogflowResponse. It is highly recommended to use these policies whenever possible.
Doing so not only adheres to the general best practice of choosing built-in policies first over custom code, but also ensures that parsing and setting of Dialogflow request and response is standardised, hardened, and performant.
3. Use conditional flows for each webhook tag
Conditional flows should be used to separate the logic for different fulfillment APIs. The easiest way to implement this is by placing a ParseDialogflowRequest policy in the PreFlow. Once that policy has been added, the flow variable google.dialogflow.<optional-prefix>.fulfillment.tag will be populated with the value of the webhook tag. This variable can then be used to define the conditions in which a request enters a particular conditional flow.
4. Consider utilizing proxy chaining
Dialogflow CX webhooks have their own request and response format instead of following RESTful conventions such as GET for reads, POST for creates, PUT for updates, etc. This makes it difficult for conventional clients to easily consume an API Proxy created for DIalogflow CX.
Hence we recommend using proxy chaining. With proxy chaining you can separate API proxies into two categories: Dialogflow proxies and resource proxies.
Dialogflow proxies can be lightweight proxies limited to actions specific to the Dialogflow client. These might include:
Authenticating requests
Translating a Dialogflow CX request into a RESTful format
Sending a RESTful request to the resource proxy
Translating the response back from the resource proxy into the Dialogflow format
And any tasks that involve connecting to the backend and exchanging data should fall to your resource proxies. You should create resource proxies just like any other Apigee API proxy, without considerations for Dialogflow in mind. The focus should be on providing an eloquent, RESTful interface for all types of clients to easily consume.
Proxy chaining provides a way to reuse proxies. However, it can incur some additional overhead as the call moves from one proxy to another.
5. Improve performance with cache prefetching
When creating a chatbot or any other natural language understanding-enhanced application, response latency is an important metric — the time it takes for a bot to respond back to the user. Minimising this latency helps retain user attention and avoids scenarios where the user is left wondering whether the bot is broken.
If a backend API that a Dialogflow virtual agent relies on has a long response time, it may be useful to prefetch the data and store it in Apigee’s cache to improve performance. You can include tokens and other meta-information, which can directly impact the time elapsed between customer input and a return prompt from Dialogflow. The Apigee cache is programmable, which can enable greater flexibility and thus a better conversation experience. You can implement prefetching and caching data using Response Cache (or Populate Cache) combined with Service Callout policy.
6. Prefer responding with a single complex parameter instead of multiple scalar parameters
When responding to a virtual agent with the SetDialogflowResponse policy, one can return multiple values at once via the <Parameters> element. This element accepts one or more children <Parameter> elements. If possible, it’s generally more effective to return a single parameter as a JSON object instead of breaking up the response as multiple parameters, each containing a single string or number. You can leverage this strategy via <JSONPath>.
This approach is recommended because:
Parameters will be logically grouped.
Dialogflow CX can still easily access the composite parameters using dot notation.
The agent can use a null value for a single parameter to erase previous response parameters and delete the entire JSON object instead of having to specify a null value for many different individual parameters
Conclusion
Apigee’s built-in policies, nuanced approach to security, shared flows, and caching mechanism can provide a smoother way to implement effective virtual agents that deliver speedy responses to your end customers. By applying these best practices, your Dialogflow engineers can have more time to innovate and focus on building better conversation experiences rather than integrating backend systems.
