Summary :
I have 1 project in Google configured with the Google Action to be "Action SDK" instead of "Dialogflow". (in order to reach my api instead of dialogflow with Google Assistant)
=> When I release my project in Alpha, the Google Action Configuration (fulfilment tool) of the project is reset to "Dialogflow" and ignore my config.
Details :
I've a Chatbot project with the following flow :
Google Assistant sending request to a spring boot app (running as app engine on GCP).
The spring boot app calls dialogflow using grpc to identify the intent and reply to Google Assistant.
I have 2 projects in GAction :
one for dialogflow definition
one for the configuration Action SDK (to reach my app on GCP). This one has the right to reach the dialogflow project (IAM config)
Why 2 projects ? Because when I use 1 project containing Dialogflow intents AND Action SDK configuration, each time I save an intent in Dialogflow, it reset the configuration of the action and set it as Dialogflow Action => ignore the Action SDK.
So, the 2 different projects are my workaround for this issue.
The issue I'm facing now is :
When I release a version of the project containing the configuration on ACTION SDK, when I try to test it, the configuration is reset to ACTION DIALOGFLOW (and so not reaching my api anymore).
How can I make a release that keep configuration set (beeing 'Action SDK') at the moment I push the "release" button ??
Anyone else facing issues with action sdk configuration ?
Related
I am facing one issue. I am not able to find logic app in API management application.
I am 10 different workflows with HTTP trigger. Through Postman, they are working fine.
Both apps (logic app and API management app) are under same subscription and resource group. but when I am searching logic app it is not visible.
In API management ->backend, I am able to find it but not sure how to connect back-end with Front end in this approach.
please help
I've had the same and it took me a while to find out that the Logic App also needs to run under a "consumption plan":
https://learn.microsoft.com/en-us/azure/api-management/import-logic-app-as-api#prerequisites
When creating the Logic App you can chose between a Standard or Consuption plan.
Similar problem. I have a Logic App workflow defined as:
And yet this logic app does not show up when I attempt to import it into API Management:
The Logic App and API Management instances are in the same account and resource group.
I've created lots of Google App Script scripts for Classroom API and the Admin Groups and Drive APIs but I can't seem to get started with AdminReports.
I get the message:
"AdminReports is not defined"
and I can't see it listed in the services that one can add in the scripting environment.
Is it because it's an advanced service? Is there something else that I need to do to get it up and running?
Enable Advanced Google Services:
To use an advanced Google service, follow these instructions:
New Editor:
Configuration
Select Admin SDK API
Select reports_v1 as API Version
(Optional) Replace AdminDirectory with AdminReports
*From https://developers.google.com/admin-sdk/reports/reference/rest?hl=en
Service: admin.googleapis.com
To call this service, we recommend that you use the Google-provided client libraries. If your application needs to use your own libraries to call this service, use the following information when you make the API requests.
Discovery document
A Discovery Document is a machine-readable specification for describing and consuming REST APIs. It is used to build client libraries, IDE plugins, and other tools that interact with Google APIs. One service may provide multiple discovery documents. This service provides the following discovery document:
https://admin.googleapis.com/$discovery/rest?version=reports_v1
Service endpoint
A service endpoint is a base URL that specifies the network address of an API service. One service might have multiple service endpoints. This service has the following service endpoint and all URIs below are relative to this service endpoint:
https://admin.googleapis.com
REST Resource: activities
list: GET /admin/reports/v1/activity/users/{userKey}/applications/{applicationName}
Retrieves a list of activities for a specific customer's account and application such as the Admin console application or the Google Drive application.
watch:
POST /admin/reports/v1/activity/users/{userKey}/applications/{applicationName}/watch
Start receiving notifications for account activities.
REST Resource: customerUsageReports
get: GET /admin/reports/v1/usage/dates/{date}
Retrieves a report which is a collection of properties and statistics for a specific customer's account.
REST Resource: entityUsageReports
get: GET /admin/reports/v1/usage/{entityType}/{entityKey}/dates/{date}
Retrieves a report which is a collection of properties and statistics for entities used by users within the account.
REST Resource: userUsageReport
get: GET /admin/reports/v1/usage/users/{userKey}/dates/{date}
Retrieves a report which is a collection of properties and statistics for a set of users with the account.
Have been working on the integration between Azure DevOps Services and ServiceNow. Our goal is to send Change Requests from ServiceNow to Azure DevOps, where they would become Features or User Stories. Whenever there is some update on Azure DevOps, that update should be sent to ServiceNow, and vice versa.
The idea is to work with REST API.
From our investigation, we have found that it is possible to send updates to other applications through Web Hooks. We are still not sure if this will suite our needs and if we are able to work with this. The problem is that the webhooks only support the HTTP method POST while Service Now requests PATCH to update on it’s side. Is this correct is there any way of creating webhooks with PATCH method?
Other way that we can integrate is to create some software that will send response needed. However, we cannot seem to find a way to automate this response. As I understood, it will generate response only when the script run, not when work item is updated. Is there any way to trigger the sending of a json file with all information within the work item whenever the work item state is updated?
As a workaround, you can try to create a custom service hook. Here is the document you can refer to .
Marketplace provides an extension(Azure DevOps Service Hooks DSL) . This extension framework is designed to ease the development of your own REST Web Hook web site to do this type of integration. It does this by providing a MVC WebAPI endpoint and a collection of helper methods, implemented as an extensible Domain Specific Language (DSL), for common processing steps and API operations such as calling back to the TFS/VSTS server that called the endpoint or accessing SMTP services.
Is there any way to trigger the sending of a json file with all
information within the work item whenever the work item state is
updated?
I am not sure if it is possible to trigger that.
But there is a ServiceNow DevOps extension for the integration between Azure Devops and Snow. You may use that.
I am following the hello world here:
https://developers.google.com/apps-script/guides/rest/quickstart/target-script
Then I update the script with new features and publish it as a new version (v2) with Publish -> Deploy as API executable
With this v2 my execution API client (using (Java)[https://developers.google.com/apps-script/guides/rest/quickstart/java]) fails with an authentification error:
com.google.api.client.googleapis.json.GoogleJsonResponseException: 401 Unauthorized
How can I get my Java client to deal properly with versioned google apps scripts?
The Execution API will use the currently published version of your script if devMode is false or omitted from the request. What I am suspecting is that there was a change of OAuth scopes in your script. The users's OAuth token needs to include all the scopes your project requires.
Open your project's properties and click on the scopes tab. Make sure your java client's OAuth scope request matches what is in the list. You may have extra scopes in your client, but you need to at least include all that are in that list.
Also in the Execution API deployment dialog there is an option limiting access to yourself, your domain, or anyone. Make sure the the user account you are using on the client matches your choice.
In our organization we have an in-house developed web based application that make use of Google Data (GData) APIs(gdata-java-client) API to manage email user accounts, email settings, nickname, profile updates , contact management. This application was built some years back. Recently we planned to enhance some features and had a look at the API and Google API website. Looks like some of the GData APIs are getting deprecated or planning to take down(April 20, 2015). We are using below GData APIs and want to confirm/check which all APIs we need to migrate immediately to new Google APIs Client Library for Java (google-api-java-client) so that the services can function smoothly.
1) Google Apps Provisioning API - V2 (URL used - https://apps-apis.google.com/a/feeds/{ourdomain}/user/2.0)
For Creating User/Update User/Delete User/Nick Name
2) Google Apps Email Settings API - V2 (URL used -https://apps-apis.google.com/a/feeds/emailsettings/2.0/{ourdomain}/{username}/webclip)
For Disabling WebClip
3) Google Apps Profiles Data API - (URL Used - {hostname}/m8/feeds/profiles/domain/{ourdomain}/full/{username})
For Retriving and Updating Profile
4) Google Domain Shared Contacts API - (URL Used - {hostname}/m8/feeds/contacts/{ourdomain}/full)
For CreateContact/DeleteContact / UpdateContact
Jars/Versions of GData Libs that we are using today.
gdata-client-1.0.jar : 1.46.0 / gdata-core-1.0.jar : 1.46.0 / gdata-appsforyourdomain-1.0.jar : 1.3.1 /gdata-contacts-3.0.jar : 3.1.0
Please let us know what all APIs will be taken out of service on April 20,2015 and also please provide the new APIs that we can use for coding the migration. Do we also have any migration guide ? Can we keep gdata-java-client jars and google-api-java-client jars together in the class-path. We would like to migrate the services which are going to brought down by April 20, 2015.
We had completed the migration and thought will update the thread and it might help someone else. Below APIs/components are getting shutdown by April 20, 2015.
1) Google Apps Provisioning API Migrated to ADMIN Directory API
2) Google Apps Profiles Data API --> Migrated to --> ADMIN Directory API
3) ClientLogin --> Migrated to --> OAuth 2.0
Google Apps Email Settings API is still under GDATA API but its placed under ADMIN SDK. No need to migrate this. But we were using ClientLogin Auth model so we need to move to OAuth 2.0
Also for using ADMIN SDK you need to make changes in Google Developer console and Admin console. Details in below links.
https://developers.google.com/admin-sdk/directory/v1/guides/prerequisites
https://developers.google.com/admin-sdk/directory/v1/guides/delegation