Integrating with REST APIs + OAuth when no native Snap is available
Hi, I’m looking into some API integrations with some services that are not supported by native snaps, but do offer a rich REST API and support OAuth. The wiki docs on the REST Snap have some details but its a quite daunting process to try and blindly hook up the OAuth2 steps and get the account working in a pipeline. Maybe I’m being lazy, but arent there any walkthrus or has someone done this before and willing to share how to set up integration with: Domo Microsoft Graph API (for Azure AD) Maybe even ElasticSearch Thanks, Mike4.1KViews1like3CommentsProblems with the Snaplogic "Import a Project" API
I exported a project as a zip file and saved it locally, but I’m having trouble getting the Snaplogic Import a Project API to work. I’ve tried to get this API to work on Postman and as a Python script, but I keep getting a 400 - BAD REQUEST response and the error “Expecting body argument for endpoint import_project: file_handle”. So I assume something is wrong with how I’m trying to send the file, but I can’t figure out what. Here is an example of a Python script I’ve tried: import requests from requests.auth import HTTPBasicAuth import os pod_path = 'elastic.snaplogic.com' import_path = 'Partners/Company/x_Imported' url = f'https://{pod_path}/api/1/rest/public/project/import/{import_path}' params = {'duplicate_check': 'true'} headers = {'Content-Type': 'multipart/form-data'} dirname = os.path.dirname(__file__) filename = os.path.join(dirname, 'project_files/xImport.zip') file_obj = open(filename, "rb") files = {'file': ('xImport.zip', file_obj, 'application/zip')} r = requests.post(url, auth=HTTPBasicAuth( <username>, <password>), headers=headers, params=params, files=files) Any ideas about what’s wrong with this script?2.6KViews1like1CommentCreating APIs with SnapLogic Pipelines and Ultra Tasks
Overview API (Application Program Interface) is an old concept repurposed to mean a modern web service based on the REST protocol and increasingly using the JSON data format. These modern APIs have become the franca lingua of the digital economy, by facilitating lightweight, performant communication between applications across an enterprise or across the internet. Typically RESTful APIs perform operations on “resources” (Customers, Orders, People, etc). By convention, the type of operation is identified using the most common HTTP verbs such as POST (create), GET (read), PUT (update), DELETE SnapLogic provides Ultra Tasks as the means by which a Pipeline can be exposed as a secure, high-availability, low-latency, sub-second request/response API. For example, the following is a Pipeline that embodies a Customer API exposed using an Ultra Task: Once the Ultra Task is enabled, the associated Pipeline stays resident in memory on the Snaplex node(s) it was configured to execute on. The number or Instances can be configured to accomodate the expected concurrent API request volume. The API can then be called securely from an external application (Postman REST client in this case): This is an example of an API GET (read) request for a specific Customer identified by the ID “1001” Designing the Pipeline Ultra Tasks deliver the components of the HTTP request message to its associated Pipeline as fields in the JSON document: content: The request body for POST or PUT requests headers: For example, the ‘User-Agent’ HTTP header can be referenced in the input document as $[‘user-agent’] uri: The original URI of the request. method: The HTTP request method. query: The parsed version of the query string. The value of this field will be an object whose fields correspond to query string parameters and a list of all the values for that parameter. For example, the following query string: foo=bar&foo=baz&one=1 Will result in a query object that looks like: { "foo" : ["bar", "baz"], "one": ["1"] } task_name: The name of the Ultra task. path_info: The part of the path after the Ultra task URL. server_ip: The IP address of the feed-master that received the request. server_port: The TCP port of the feed-master that received the request. client_ip: The IP address of the client that sent the request. client_port: The TCP port of the client that sent the request. In the above Customer API example: A Mapper Snap is used to parse the ID from the portion of the URL after the base path provided by the Ultra Task (demo-fm.snaplogic.io/api/1/rest/feed-master/queue/MyOrg/MyProjectSpace/API/Customers)… In this case “/1001”: A Router Snap is used to conditionally direct execution to the appropriate subflows designed in accordance with the RESTful CRUD operations described above: Additional Reference https://en.wikipedia.org/wiki/Representational_state_transfer http://doc.snaplogic.com/ultra-tasks13KViews1like5CommentsREST Get Slow
Hey guys, I have built a simple REST Get process to grab some data from an API. There are about 100 URLs to call but it is taking ages. 100 URLs takes about 7 mins whereas in another software application the 100 calls takes about 25s! I have tried using the REST Get snap in a child pipeline and increasing the pool size but I’m still not getting anywhere the speed I would expect. Any suggestions?1.6KViews1like0CommentsAPI responses not working
Hello, So I created an API specification with these error responses. ‘400’: description: Bad request. ID must be an integer ‘401’: description: Authorization information is missing or invalid headers: {} content: {} ‘404’: description: Not found ‘500’: description: Interal server error (500) When I uploaded the spec into snaplogic and changed the pipeline I want it to fetch data from SQL server select with given ID. I want to reroute the error when the ID is not found. But when I do that I still get on the API call the Server error 500 form the snap itself of snaplogic and not from the reroute or from the specification defined error response Does someone know why it does not reroute the error to my custom error view or the response code from my api specificationSolved3.7KViews1like4Comments