watsonx Assistant

With the introductions of Actions and Integrations, there are now 3 main methods to connect to backend APIs.  I am trying to work out all the pros and cons of the different methods and why someone would use one method over another.

1) Method 1: Webhooks
This is a cut down version of the older Classic Assistant webhook.  No pre-message webhook unless you are using the Classic Assistant, so you can only make the webhook call now once the users message has been received and processed by Watson.
There is only one webhook per dialog skill, so the API called by the webhook effectively does any orchestration required to call various external APIs, aggregate data, etc. 
8 second timeout on webhook call.
State/Context needs to be passed to the API if it is needed.

2) Method 2: Actions/Integrations
Actions can use Integrations to call backend services.
Multiple Integrations can be configured with multiple operations with request and response parameters defined. Max 100 Integrations per Assistant
State/Context needs to be passed to the Integration as request parameters if it is needed.

3) Method 3: Custom "Orchestration" Application
According to the documentation this is a "client application that communicates with an assistant at run time, use the new v2 API. By using this API, you can develop a user-facing client that can be deployed for production use, an application that brokers communication between an assistant and another service (such as a chat service or back-end system)"
Option to use automatic state management (manual/stateless state management also available)
Full control over all aspects of integration and orchestration of conversation flow.
Could be more prone to being left behind as Watson Assistant develops (eg. the move from V1 to V2 API calls in the past) as all actions are manually orchestrated by the code. (I am thinking that Method 1 and 2 only call externally for additional information and rely on the core WA capability to manage flow, state and context)

I've got a new project that will need to call on multiple backend services via API's, integrate with a web front end as well as a mobile app and possibly voice, and I'm trying to determine the best approach for this project. 

I'd be interested in any comments, feedback, expansion, correction on the above.


------------------------------
Graham Walker
------------------------------

#WatsonAssistant

I would like to add something to your option #3: you actually have a choice of connecting with Watson using the v1 API or the v2 API. You'd prefer the v1 API if you happen to create several skills for your custom orchestration engine (by using the classic experience) and you might want to switch between them either during development or even at runtime -although I haven't done this one myself-, as otherwise you'd only be able to connect to a unique skill via the assistant (if using v2). Another reason you might prefer the v1 API is that it lets you edit your skill/dialog via API (which I don't think v2 supports yet - although IBM promised a long time ago that v2 was eventually going to achieve parity with v1 on this, it's not clear that it's still in their roadmap - I heard no updates in a long time). ​

------------------------------
Patricia Goldweic
------------------------------

Original Message:
Sent: Tue August 16, 2022 02:03 AM
From: Graham Walker
Subject: Pros and Cons on Backend Connectivity

With the introductions of Actions and Integrations, there are now 3 main methods to connect to backend APIs.  I am trying to work out all the pros and cons of the different methods and why someone would use one method over another.

1) Method 1: Webhooks
This is a cut down version of the older Classic Assistant webhook.  No pre-message webhook unless you are using the Classic Assistant, so you can only make the webhook call now once the users message has been received and processed by Watson.
There is only one webhook per dialog skill, so the API called by the webhook effectively does any orchestration required to call various external APIs, aggregate data, etc. 
8 second timeout on webhook call.
State/Context needs to be passed to the API if it is needed.

2) Method 2: Actions/Integrations
Actions can use Integrations to call backend services.
Multiple Integrations can be configured with multiple operations with request and response parameters defined. Max 100 Integrations per Assistant
State/Context needs to be passed to the Integration as request parameters if it is needed.

3) Method 3: Custom "Orchestration" Application
According to the documentation this is a "client application that communicates with an assistant at run time, use the new v2 API. By using this API, you can develop a user-facing client that can be deployed for production use, an application that brokers communication between an assistant and another service (such as a chat service or back-end system)"
Option to use automatic state management (manual/stateless state management also available)
Full control over all aspects of integration and orchestration of conversation flow.
Could be more prone to being left behind as Watson Assistant develops (eg. the move from V1 to V2 API calls in the past) as all actions are manually orchestrated by the code. (I am thinking that Method 1 and 2 only call externally for additional information and rely on the core WA capability to manage flow, state and context)

I've got a new project that will need to call on multiple backend services via API's, integrate with a web front end as well as a mobile app and possibly voice, and I'm trying to determine the best approach for this project. 

I'd be interested in any comments, feedback, expansion, correction on the above.


------------------------------
Graham Walker
------------------------------

#WatsonAssistant

Hi Patricia,
Yes, you are quite right about being able to use V1 and V2 API's.  I didn't mention V1 as I keep waiting for IBM to end of life V1 on me and so I was thinking it might be better to start any new project with V2 (if I don't need the edit options) :-). 
I remember talking with others some time ago about the concept of a "concierge" style virtual assistant.  This would use a skill to do high level triage across a number of specialist areas and would then "hand off" the conversation to the appropriate specialist skill.  This was always talked about in regard to using skills and V1 rather than V2 and assistants.  Although I vaguely remember talking to the IBM product manager at the time and there was an idea of having assistants that could have multiple skills under a single assistant and this could facilitate this type of concierge idea.
In regard to having an orchestration component manage the various "skills", I suppose you could set up a number of assistants with associated skill per assistant and then just set up multiple connections to the various assistants in your code.  You could then use your primary assistant as the first "cab off the rank" to determine the subject area and then, based on the response, direct further queries to the other assistants in the code as required.

------------------------------
Graham Walker
------------------------------

Original Message:
Sent: Mon August 22, 2022 11:17 AM
From: Patricia Goldweic
Subject: Pros and Cons on Backend Connectivity

I would like to add something to your option #3: you actually have a choice of connecting with Watson using the v1 API or the v2 API. You'd prefer the v1 API if you happen to create several skills for your custom orchestration engine (by using the classic experience) and you might want to switch between them either during development or even at runtime -although I haven't done this one myself-, as otherwise you'd only be able to connect to a unique skill via the assistant (if using v2). Another reason you might prefer the v1 API is that it lets you edit your skill/dialog via API (which I don't think v2 supports yet - although IBM promised a long time ago that v2 was eventually going to achieve parity with v1 on this, it's not clear that it's still in their roadmap - I heard no updates in a long time). ​

------------------------------
Patricia Goldweic

Original Message:
Sent: Tue August 16, 2022 02:03 AM
From: Graham Walker
Subject: Pros and Cons on Backend Connectivity

With the introductions of Actions and Integrations, there are now 3 main methods to connect to backend APIs.  I am trying to work out all the pros and cons of the different methods and why someone would use one method over another.

1) Method 1: Webhooks
This is a cut down version of the older Classic Assistant webhook.  No pre-message webhook unless you are using the Classic Assistant, so you can only make the webhook call now once the users message has been received and processed by Watson.
There is only one webhook per dialog skill, so the API called by the webhook effectively does any orchestration required to call various external APIs, aggregate data, etc. 
8 second timeout on webhook call.
State/Context needs to be passed to the API if it is needed.

2) Method 2: Actions/Integrations
Actions can use Integrations to call backend services.
Multiple Integrations can be configured with multiple operations with request and response parameters defined. Max 100 Integrations per Assistant
State/Context needs to be passed to the Integration as request parameters if it is needed.

3) Method 3: Custom "Orchestration" Application
According to the documentation this is a "client application that communicates with an assistant at run time, use the new v2 API. By using this API, you can develop a user-facing client that can be deployed for production use, an application that brokers communication between an assistant and another service (such as a chat service or back-end system)"
Option to use automatic state management (manual/stateless state management also available)
Full control over all aspects of integration and orchestration of conversation flow.
Could be more prone to being left behind as Watson Assistant develops (eg. the move from V1 to V2 API calls in the past) as all actions are manually orchestrated by the code. (I am thinking that Method 1 and 2 only call externally for additional information and rely on the core WA capability to manage flow, state and context)

I've got a new project that will need to call on multiple backend services via API's, integrate with a web front end as well as a mobile app and possibly voice, and I'm trying to determine the best approach for this project. 

I'd be interested in any comments, feedback, expansion, correction on the above.


------------------------------
Graham Walker
------------------------------

#WatsonAssistant

Each of the 3 options have a very specific usage. We have developed a Customer Care Platform applying all 3 forms of integration:

1) Pre-hook is called when the message comes in, before Watson processes it, so we can pre-process various situations and inject context or configurations (like changing the voice) before Watson gets to respond; then the Post-hook processes the Watson response before sending to the user and again we can handle some other situations that Watson wasn´t able to do; We also use Pre/Post-hooks to save the payloads in Cloudant for post-process and analytics

2.1) Actions: We just started to use it for very straight forward situations to avoid bad user behavior;

2.2) Integrations: By the integrations we managed to get a full functional multichannel environment;

3) This is the core for our platform, and this is also responsible to let us achieve LiveAgent Transfere in all channels, including APIs, WhatsApp, Telegram, Phone, Web, etc

There are a few Columbus-Eggs behind each tool!


------------------------------
Marcos Lohmann
------------------------------

Original Message:
Sent: Tue August 16, 2022 02:03 AM
From: Graham Walker
Subject: Pros and Cons on Backend Connectivity

With the introductions of Actions and Integrations, there are now 3 main methods to connect to backend APIs.  I am trying to work out all the pros and cons of the different methods and why someone would use one method over another.

1) Method 1: Webhooks
This is a cut down version of the older Classic Assistant webhook.  No pre-message webhook unless you are using the Classic Assistant, so you can only make the webhook call now once the users message has been received and processed by Watson.
There is only one webhook per dialog skill, so the API called by the webhook effectively does any orchestration required to call various external APIs, aggregate data, etc. 
8 second timeout on webhook call.
State/Context needs to be passed to the API if it is needed.

2) Method 2: Actions/Integrations
Actions can use Integrations to call backend services.
Multiple Integrations can be configured with multiple operations with request and response parameters defined. Max 100 Integrations per Assistant
State/Context needs to be passed to the Integration as request parameters if it is needed.

3) Method 3: Custom "Orchestration" Application
According to the documentation this is a "client application that communicates with an assistant at run time, use the new v2 API. By using this API, you can develop a user-facing client that can be deployed for production use, an application that brokers communication between an assistant and another service (such as a chat service or back-end system)"
Option to use automatic state management (manual/stateless state management also available)
Full control over all aspects of integration and orchestration of conversation flow.
Could be more prone to being left behind as Watson Assistant develops (eg. the move from V1 to V2 API calls in the past) as all actions are manually orchestrated by the code. (I am thinking that Method 1 and 2 only call externally for additional information and rely on the core WA capability to manage flow, state and context)

I've got a new project that will need to call on multiple backend services via API's, integrate with a web front end as well as a mobile app and possibly voice, and I'm trying to determine the best approach for this project. 

I'd be interested in any comments, feedback, expansion, correction on the above.


------------------------------
Graham Walker
------------------------------

#WatsonAssistant