Can the namespace preferences and program preferences be set via REST API calls? If yes, what is the syntax for it?
Generally in Cloud Data Fusion, when we intend to perform the action on GCP side, like create/delete/restart etc. instance, it's feasible to use domestic Google Cloud API, giving the opportunity to interact with a service endpoint via JSON/HTTP calls interface as described in Google Cloud API design document.
Dedicated to Data Fusion you can follow the Cloud Data Fusion REST API reference document, nicely explaining the methods for composing REST API HTTP calls to manage Data Fusion instances, moreover every method description from the documentation contains Google API Explorer sub-panel, to get handy experience building JSON request on a live data.
Said above, I assume your initial question is related more to CDAP REST API, as it includes the methods for pure CDAP instance metadata/namespaces/application configuration.
From the user perspective your workflow might be the following:
Identify the CDAP API endpoint as explained in this guideline;
Compose an HTTP PUT/GET request relevant to Data Fusion
Namespace/Metadata/Preferences/Configuration
object via CDAP RESTful API.
Yes of course! You have two methods.
The first method is creating it from the platform. Follow the steps below:
Open your data fusion instance
Go to System Admin => Configuration => Make HTTP calls
To create a namespace, submit an HTTP PUT request:
PUT /v3/namespaces/<namespace-id>
Link of CDAP: CDAP
The second method is using terraform.
Related
I find tons of articles explaining how to call rest apis from APEX - but I'm accessing salesforce from an integration system using the Salesforce REST API, and want to it the other way around.
ie -
I've found functionality (record merging) - that is not available from the rest API, but IS available from apex. Is there any way to run an apex statement or script from the rest API?
NOTE: I'm aware that the functionality also available from the SOAP api, but we really don't want to go near that for various reasons.
you want to REST API endpoints in APEX, so that you can call this endpoint from anywhere, Right? if so then you need to check this article.
After reading above article, you are able to create GET, POST, DELETE endpoint in your Salesforce Org and you can use this endpoints.
We have an application developed with react and NodeJs and already implemented an MYOB cloud ERP integration to import data. Now we are planning to add a new ERP integration for Acumatica, in the developer document it was mentioned that the rest API is available but I can't find the cloud instance URL, everywhere it was mentioned as localhost only. So can anyone please help me to understand how to connect the Acumatica cloud to fetch details?
Note: I understand the authorization flow like Authorization Code but I'm confused with which URL to use for and I hope it should be a fixed one as it is a cloud URL
The Integration end points is a rather large topic. I am in the process of writing a blog post on it which is more or less a getting started blog on automating stuff and getting info via ReST. The blog itself is in the context of using these services via PowerShell but if you are able to follow along and get to the point of establishing postman examples of what you need to do you should be able to get to the same end result in any language.
You will want to explore The Web Services Endpoint screen in the integration module as this is where all the Contract Based Soap/ReST definitions are managed. You can even set up custom endpoint if you need.
Do you have access to the Acumatica Portal? The best way to get started is with some of the course work there.
Stand by and ill forward some information for you to get started.
Robert
The URL for the RestAPI is whatever is the site URL of your Acumatica instance. For example if your Acumatica is hosted in www.ManiMaran.com. To login to your API :
http://ManiMaran.com/entity/auth/login.
I have an external REST based API that I need to create a connection to in order to retrieve data on a regularly scheduled basis (for BI purposes). This API is fairly robust, and supports around 60 distinct endpoints. Also, this same API is used to access information across multiple client sub-domains (e.g. client1.apisource.com, client2.apisource.com, client3.apisource.com, etc.). In other words, the API endpoints are the same for each client subdomain.
So what I'm trying to figure out is whether it's possible to create a single ADF that contains a complete set of pipeline actions for each endpoint THAT uses a "dynamic" URL based on the client subdomains? In other words...what I'm trying to see if its possible to create a single ADF that can manage a dynamic list of base URLs.
I tried to parameterize the HTTP and REST connections, but this doesn't appear to Is this possible yet. Any thoughts? Thanks!
Here is an example of a Web Activity to call a REST API using parameters and expressions. The URL can be an expression like:
#concat('https://management.azure.com/subscriptions/',pipeline().parameters.SubscriptionID,'/resourceGroups/',pipeline().parameters.ResourceGroup,'/providers/Microsoft.Sql/servers/',pipeline().parameters.Server,'/databases/',pipeline().parameters.DW,'?api-version=2014-04-01')
I do have some data stored in my Real-Time Firebase database. I am willing to expose some of this data via a REST API to my B2B customers.
I know that Firebase is itself a REST API but its authentication mechanisms don't fit my needs. I am willing my customers to access the API with a simple API Key passed in the HTTP request headers.
To summarize, I need an API layer sitting on top of my Firebase real-time database with the following properties:
Basic Authentication via an API key passed in the HTTP request headers
Some custom logic that makes sure customers respect the API limits (maximum requests per day for example)
The only thing I can think of is implementing this layer in AWS lambda but that also sounds a bit off. From the lambda, I would have to access my Firebase database and serve that data. That seems too many network requests; something native to Firebase would be great.
Thanks,
Guven.
Why not have a simple API which provides them an Oauth token for the original firebase REST API if they have the correct Api Key
It'll be more secure as only you'll be able to make the tokens as only you'll have the service account private key. Also saves you the headache of making a whole REST API. Also the Oauth tokens expire relatively quickly so it's less of a risk than a normal key that you furnish
I personally have created my own Servlets where a user posts their data if they are authenticated using an id pass combo.
In the Servlets i use the default REST API provided by Firebase with the Oauth generated in my servlet. This way, i can have the DB security rules set to false for all writes from any client api. And the REST API and their admin sdk on my server ignore the security rules by default.
After some research, I have decided that AWS is the best platform such API related features.
Gateway API lets you setup your API interface in a matter of seconds
DynamoDB stores your API data; you can easily populate the data here
AWS Lambda lets you write the integration code between Gateway API and DynamoDB
On top of these, the platform offers these features out of the box:
Creation & handling and verification of API keys for authentication
Usage plans to make sure that API consumers don't exceed your API usage limits
Most of what I was looking for is offered in these AWS services.
I need to make an API call from post trigger of Azure DocumentDB.
I tried calling external APIs - but found that such calls are blocked in DocumentDB. If I host an API on Azure's same account will that API is allowed to be called from the post trigger ? If not what can be the alternatives.
Server-side code runs in a sandboxed environment and cannot make external calls. You can, instead, make the same call from your client after your request is acknowledged by the service (indicating your post-trigger succeeded/failed).
DocumentDB now supports a private preview of server side change feed. Using this model you can pull down all the changes from a DocumentDB collection and execute custom logic to perform desired post processing like invoking web services.
Please email askdocdb at Microsoft dot com if you want to learn more about this pattern.
In server-side scripts you can use all JavaScript functionality and CRUD/Query API for DocumentDB. Other "hosting" API is not exposed. For instance, JavaScript by itself doesn't have built-in support for file system or web API, functionality like needs to be provided by host (IE, cscript, etc). DocumentDB doesn't provide additional API other than CRUD/Query API.