Can I publish an agent version and manage environments on Dialogflow V2 API? - google-cloud-platform

Can I publish an agent version on an environment using the Dialogflow V2 API?
I can't find any documentation on how to do that.
The doc about versions and environments only mentions doing this using the console (https://cloud.google.com/dialogflow/docs/agents-versions).
And the API doc of the agent environments resource only contains a list method (https://cloud.google.com/dialogflow/docs/reference/rest/v2/projects.agent.environments).
Does it mean that every change done using the API is automatically reflected in production?
Or does it mean that every change done by API is staged, and can only go to production by manually accessing the console and publishing the new version?
Both options seems terrible by the way.

Currently, it's not possible to manage agent versions through the Dialogflow API, it seems that this feature is already being contemplated to be integrated to Dialogflow; however, there is no an ETA for its implementation. You can follow up this request here.

Related

Is there a way we can add new projects to existing GCP monitoring workspace via a API?

I have multiple GCP projects, And I want to setup a multi-projects monitoring workspace for my environment. I would like to add all un-monitored projects to the workspace that I have already created, but via an API so that this job is automated.
Via console I know that it's possible using this link's setup (https://cloud.google.com/monitoring/workspaces/create#add-monitored-project) But how can I achieve this via an API?
Please can someone provide any inputs here.
You can manage Dashboard via API, and list services in the workspace, but API does not support adding projects to a workspace.
You can find list of all API methods here.
If you think that functionality should be supported, you can file a Feature Request.

Is there a way to track Facebook Campaign Ad Installs with Expo managed workflow?

Stack: Expo React Native, expo-branch
I am searching for a way to track Facebook Campaign Ad Installs with Expo in the managed workflow. I have integrated expo-branch (link below) and set up the integration between Facebook Ad Manager and Branch. As it stands, Branch is not getting the IDFA, which I suspect is the reason I am getting no analytics on Facebook through any ad campaigns. It looks like Expo has restricted access to the IDFA and I'm wondering if anybody has found a viable workaround (without detaching from Expo).
References:
https://docs.expo.io/versions/latest/sdk/branch/
https://forums.expo.io/t/latest-expo-branch-excluding-the-idfa-code/44357
A Branchster here:
For SAN(self attributing networks) like Google and Facebook, it is necessary that the Branch SDK correctly captures the device identifiers for the SAN integration to work and you be able to see attributed Installs and downstream events. Since there is not much support for Expo in the managed workflow, we would suggest using Bare workflow. Alternatively, you can reference our complete SDK support here.

WsO2 ESB development thru Tooling Vs Management Console

Why does the management console provide features to develop a service or customize a component of WSO2 ESB?
What's the purpose of one Vs other?
Doesn't the development stops after handover of CAR files/artifacts to DevOps team?
My understanding with Management Console is to deploy, manage(start-stop) & monitor ESB services/integration flows.
Is there an overlap on these two ? The documentation itself provides two ways to do the same thing. I mean why?
TIA,
--M
All these features are available in Management console for users to try out easily. For example, when they want to see what are available feature etc, quickly.
When you're using ESB in real development, you should use toolings instead.

WSO2 ESB, REST Apis Versioning strategy

I have PizzaV1.0.0 API, which strategy does it use to generate a new V2.0.0 version and keep both in ESB.
If version the CAR, the duplicity of APIs and Sequences.
I have not found a way to version the APIs in eclipse, I need to version the API and some sequences that have changed.
In API Manager I created a new version, now I have two versions published.
What versioning strategy do you use in ESB to stay in sync with API Manager?
Maybe this post can help you
http://nandikajayawardana.blogspot.com.br/2014/02/proxy-service-version-management-with.html
I do what they describe and it is working great.

WSO2 APIM - api file deployment

deploying the WSO2 APIM 2.1.0 using puppet, we consider to deploy the API itself with the CICD as well.
In theory - I could copy (template) the synapse files (proxy, api) and the api is available for the call, however - the API is not visible in the store. I assume there's more data in the database than just a synapse config file.
Is there a way to define / deploy API (including to the store) using the configuration files or it needs to be done manually?
Edit:
I thought there's a way to deploy API using the API Admin Services. But when calling addAPI with the metadata XML, looks ok. But trying to see the API in the publisher throws an exception
ERROR - index:jag org.wso2.carbon.apimgt.api.APIManagementException: Unable to find the API: admin-myapi-v1.0.0 in the database
Thank you for any hint
g.
Based on your requirements it looks like you can use one of the following options.
Migrate APIs - You can export APIs from one environment and import those APIs to the new environment. When you import APIs in the new environment, those APIs will be in created state. You need to manually publish those APIs. May be using the jaggery API or REST API you will be able to publish the APIs.
REST API
Jaggery API - This is deprecated at the moment and discourage for using this.
Once you create the APIs, APIs related details will be saved in the database. Additionally, synapse configuration can be found in the file system. If you point the previous database to the new deployment and deploy the synapse artifacts, APIs will work. But then again API creation/publishing and entire flow will not be tested. For CICD, you need to consider above mentioned options. In the future releases, there is more focus towards the REST API and it will be more useful for the CICD.