So we currently are creating chatbots using Google DialogFlow. The chatbots that we create are usually decision tree type chatbots that ask a particular question based on the response provided by the user. The client usually sends us flowcharts in pdf which has the decision tree and we then translate it towards creating the said chatbot and adding the relevant modules based on the information provided. Is there a way wherein I can automate some part of the chatbot creation process directly based on the decision tree sent in the PDF? The frequent updates sent by the client is a bit cumbersome so was thinking of automating it.
What I'm thinking currently is somehow converting the PDF file to some JSON format and then using that JSON file, somehow automate the process. I'm a new joiner in the company and they have given me this task to think about.
It’s possible to automate the creation process of your Dialogflow agent, however, you’ll have to create your own implementation for it. As you’ve mentioned, you can convert the PDF file into a JSON object using your own implementation, then you can use the JSON object as a reference to construct the Request Body of the methods stated below.
If you are using Dialogflow ES, then you can use one of Dialogflow ES’s Client libraries or APIs (REST API / RPC API) to create agents programmatically.
You can create ES Agents with the following methods:
REST API: projects.setAgent method
RPC API: SetAgent method
Client libraries: you can look into the documentation of each of the supported languages
After you create an ES agent, you can also add Intents, Entity Types, Contexts, etc. programmatically to manage your agent’s conversation flows.
If you are using Dialogflow CX, then you can use one of Dialogflow CX’s Client libraries or APIs (REST API / RPC API) to create agents programmatically.
You can create CX Agents with the following methods:
REST API: projects.locations.agents.create method
RPC API: CreateAgent method
Client libraries: you can look into the documentation of each of the supported languages
After you create a CX agent, you can also add Intents, Entity Types, Flows, Webhooks etc. programmatically to manage your agent’s conversation flows.
Additionally, note that your JSON Request Body must be formatted correctly based on the Resource that you’re trying to create. For example:
If you’re trying to create an ES Agent, make sure to follow the Request Body format.
If you’re trying to create a CX Agent, make sure to follow the Request Body format.
Related
Case: Google Chat support in node.js using the googleapis library.
I studied the documentation, created a service account and implemented authentication. In first step I used the chat.spaces.list() method and it worked (no error returned).
I want to send a message via chat, so I wanted to create a new space, I found the chat.spaces.create method (https://developers.google.com/chat/api/reference/rest/v1/spaces/create) Unfortunately, this method is not present in "googleapis" for node.js In general, I see that the list of methods in "googleapis" is different than the one in the documentation. Only spaces in the documentation, but spaces and rooms in the library... I'm lost. How to do it? Any tips?
I see that the list of methods in "googleapis" is different than the one in the documentation
I think you are seeing wrong documentation. Your reference link is REST API documentation. The nodejs googleapis client documentation you can see on https://googleapis.dev/nodejs/googleapis/latest/chat/classes/Resource$Spaces.html.
And also based on the REST API documentation, the API that you looking for(create space) is not general available.
† Supports user authentication in Developer Preview. App authentication isn't available.
You need to join Google Workspace Developer Preview Program to access that feature.
So i want to develop a simple web application, which will basically be a basic form which on submission will allow to make an external api request. So are there any application designers that can allow to do that with minimalistic code. Appian for example has an interface/application designer that lets you drag and drop a UI interface and build a workflow, make api calls externally or to a database. So like that are there any other apps that allow to do something similar (make api calls/build ui easily/store in databse)? Any other suggestions are also welcome!
It heavily depends on the API as well as the kind of task you´re trying to achieve.
Here´s just a few examples and considerations. (All the below supposes that we´re talking about Web-Based APIs).
If the API requires authentication of some sort and the user authenticates himself: A simple HTTP file with JavaScript to send the request will do the job
If the API requires authentication but you authenticate for all the users: You will need a backend application that does the API request since you need something secure where you can put your Auth-Details for the API. Classic PHP or NodeJS in combination with a served HTTP file for the form itself would work without any JavaScript (depends on the API definitions)
If the API does not require authentication maybe a simple HTML form would work
If you want to write to a database you can have a look at something like https://directus.io/. They allow building a database with a UI and they automatically generate a Web-API which you can then feed by your forms. If the end-user is known to you Directus actually allows users to log in and fill the database with forms that you can visually design but this is rather for employees entering data into an internal database than customers submitting their contact data to you
From my personal experience, all the UI-Tools that promise to integrate with REST APIs make it really hard to do so since every API is different and there is no real standard for them.
For example: I add a simple response to an intent with Dialogflow interface,
like this.
This response is associated with my intent and my agent, but where is it stored? Is there some google db? Can I access all the agent data stored by dialogflow?
I can't find any hints in the documentation.
Where is it stored? Is there some google db?
There is a data store of some sort, just like most things are stored in a database or data store of some sort. But that doesn't mean that it is a conventional database in the way you may think about it.
It also doesn't mean that you would have access to the database directly.
Can I access all the agent data stored by dialogflow?
Depends what you mean by "all the agent data". Everything that you build using the web interface (the Intents and Entities, for example) is available to you. You can export it as a zip file that contains various JSON files with the configuration. You can also use the Dialogflow API to get various parts of your configuration.
We are integrating a new system with DocuSign. The system is built using C# objects.
My question is, which is the best practice to interface with DocuSign - call the DocuSign Web API methods directly, or include the DocuSign C# client library as a reference to our code, and call that directly?
Thanks!
I recommend using the C# client library. It will save you time and make it very easy to use.
The code for it is also public in github, so if for some reason you want to fork and use it that way - you can do that too.
The DocuSign C# SDK saves you the bother of:
serializing the request objects into a JSON structure
sending the HTTPS request
deserializing the response objects into C# objects.
It also includes helper methods for implementing the OAuth JWT Grant flow.
These are all good reasons to use the SDK.
If you expect that you will be regularly sending documents that are above 20MB in size then you may want to implement the Envelopes::create call yourself. Why? Because the current version of the SDK BASE64 encodes the documents you upload to DocuSign.
If you implement the Envelopes::create call yourself, you can send the documents in binary. This isn't so easy to do but is important if you have very large source documents. An example of how to send in binary mode.
Added
Size limits: 25MB per API call. But document(s) in an API call that are BASE64 encoded have alot of overhead. So in this case, the effective max doc size is around 20 MB.
You can have multiple documents in an envelope. To have multiple large documents, create the envelope as a draft, then upload the additional documents as separate API calls.
See the API Limits document
I am very new to Salesforce and it's API.
I am having a sandbox org and with it I have url, username, password, security token and last but not the least partner.wsdl
My aim was to connect and retrieve/create data.
Technologies at hand was nodejs
So here is how I started.
I searched over the internet and came to know that I need to create a client, SOAP client in order to login, create the connection and use that connection to create and access the Leads data.So I followed this sample where the wsdl was being consumed.
So I was able to connect
I was very happy on this success and then suddenly I wasn't able to identify/find a way where I can get the sObject.I looked hard for this but no luck. So posted a question on SO
Meanwhile I also looked for other node module and found jsforce
I used jsforce starting guide and created a client that was connecting to salesforce however without using the wsdl file.
Again I was happy, even more happy because I was having the sObject with me.
Now, what is the fundamental difference if I login using the local wsdl file and without wsdl file in the language of salesforce. Which one is the correct way of logging in?
Sorry if this question is not according to SO rules or if there is a typo.
I'm the author of jsforce you mentioned.
In that lib we use REST API mostly and SOAP APIs are only used in some specific calls like login or metadata. Even in such calls we don't use WSDLs because there's no good lib to generate client modules from WSDL in JavaScript/Node.js area. Instead we wrote modules for each APIs which generate SOAP XML strings and parse the response XML.
It is enough because these API message schema are static and fiesible in the specific version, unlike SOAP API Enterprise WSDL differs in organizations. So we can hard code the client module directly w/o generate it from WSDL.