I have a requirement to call external REST API from custom postprocess event handler in OracleIdentityManager?
If anyone have idea,please post here.
There is no OIM Rest API for the invoking Event Handler as of now. In future there might be development for it.
Related
I'm a student who's newbie to the world of APIs and I'm working on an assignment where I have to create a NodeJs rest API that would call a SOAP service, transfer the XML response into a JSON object and return it to my angular project that calls this API.
I have looked around and found very little information about this, so is there a good place for me to start (Tutorial, courses, etc..) ?
looking forward to receiving answers because my passing grade is on the line :( </3
You need to break up this problem into multiple steps.
How do we make a rest-api in nodejs?
See a link like: https://www.codementor.io/#olatundegaruba/nodejs-restful-apis-in-10-minutes-q0sgsfhbd
OR How to best create a RESTful API in Node.js
How do we call a soap service from nodejs?
See e.g. SOAP Request using nodejs
How do we call our rest-api from angular?
https://angular.io/guide/http OR
Call Rest API From Angular Application
So break the problem up into steps, find the tutorials that help you implement that part, and put it all together.
Also use console.log and JSON.Stringify to debug your objects. E.g. see: https://levelup.gitconnected.com/5-ways-to-log-an-object-to-the-console-in-javascript-7b995c56af5a
I have created azure functions with "HTTP trigger" and "generic Webhooks" with Visual studio 2017.The only difference I found that both "triggers" can be triggered by HTTP request.
both functions have "HttpTrigger" as parameter.
so I am confused when should we use one over the other as both triggers allows us to run small piece of code in cloud.
How Is it different from one another ?
An HttpTriggered function can respond to any HTTP verb you configure. However, a webhook only responds to POST and expects the payload to be JSON.
Source: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook#responding-to-webhooks
This restricts requests to only those using HTTP POST and with the
application/json content type.
A 'Webhook' is a user defined callback that can be registered on a website in case you want to react to certain events.
For example something that is often done is responding to events in a gtihub repository, like when someone does a check-in or an issue is added. Typically you would want to trigger a build when a check-in happens. You can register a callback/webhook on github which points to a url provided by you that reacts to the HTTP POST called by github.
Azure function can be configured to be triggered by a normal HTTP request or it can be setup as a webhook i.e. it will be called whenever a specific event on some website has occurred. Functions configured as webhooks will respond only to a HTTP POST. There are already built in values to set up an Azure Function as a github or Slack webhook.
If you are not reacting to an external event or cannot register a webhook in the event source just go with the HttpTrigger and explicitly invoke your function.
As per the documentation, the webhooks only work with 1.x version of Azure functions runtime while if you are working with the newer runtime 2.x - it is recommended to use the HttpTrigger instead.
From the documentation,
In version 1.x, webhook templates provide additional validation for
webhook payloads. In version 2.x, the base HTTP trigger still works
and is the recommended approach for webhooks.
I have been using the asynchronous abilities of Node.js from quite some time now. But I am stuck on an interesting problem. Basically I have 2 API's that I need to call one after the other. Due to the asynchronous nature of Node.js I cannot retrieve the response of the first API request till it has finished and the respective callback function is called.
What I want to do is that I want to pass the response from the first API as request payload to the second API on the fly and not wait till the first API gets fully completed.
As a possible alternative, should I switch from building rest API to stream APIs?
Any pointers on how to do this?
Thanks
Yes, converting REST API'S to stream API is a better option. Node.js is known for its asynchronous behaviour. Because of the same all REST api's function in the same manner as you described earlier. As someone has previously pointed you could look at the Twitter Stream API for reference.
For more understanding you can check out this link - How to create a streaming API with NodeJS
Question
A NodeJS server is called by a client. This causes a further call to be made to a 3rd party API. The API then asynchronously calls-back to the NodeJS server. How do I make the client aware that the asynchronous callback has completed?
Details
I have an NodeJS server with these two routes (code is coffeescript):
app.get '/security/login/application/authorise', ->
applicationService.authorise()
app.get '/security/login/application/callback', (req, res) ->
applicationService.login req, res
The first route is called by my AngularJS client. Its purpose is to authorise the client and allow it to start-up (users will sign in later). The authorisation process involves making a call to a third party security API.
The security API does its thing and then calls-back to the NodeJS server via the /callback route shown above. The information passed to the callback allows a further call to be made to the API that determines if the original authorisation request will pass or failed.
The problem is that call to the first call to the /authorise route is, of course, asynchronous and so returns to the client right away. The client is then left in limbo, not sure if the NodeJS server has authorised it or not.
Please note that I cannot just nest these calls (imo) because the first call to the API simply returns 200 OK regardless. The process only continues when, sometime in the future, the third party API starts a new conversation by calling back into the NodeJS server via the /callback route.
Options
It seems I have a number of unpalatable options:
Stay Asynchronous. Return control to the client and then have the client poll the server, presumably with some unique, temporary 'callback-id', to determine if the callback has been completed.
Go Synchronous. Block the return with a hacky loop of some sort. Maybe promises can clean this up a bit somehow.
Go Bidirectional. Use sockets to allow a push notification from the server (but what about old browsers like IE8, which I have to support).
I think I have probably over-cooked this problem and the solution is most likely easier than I imagine. Your help would be gratefully received.
If i have a function in a thread that is processing some data, then it calls a callback function to update the status in the UI.
If the UI takes time to process the callback function then it is not so much usefull.
Instead of just handling the update in the callback function, should it send some kind of message to the UI that way it doesnt block?
I mean when in the processing function and i call the update status function, this should return immediately to the procesing function, then in the update it can wait all it wants for the UI update to finish.
Or do I need a 3rd thread to handle the sending update data to the UI ?
Usually there's a way of posting the callback to the UI thread without blocking.
For instance:
On Win32 there's PostMessage
In .NET Windows Forms there's Control.BeginInvoke (which implements ISynchronizeInvoke.BeginInvoke)
In Java there's EventQueue.invokeLater
I'm sure if you look at the docs for the UI toolkit you're using, you'll find something similar.
In .NET (WinForms, WPF, Silverlight) you just need to use the Dispatcher object on the Thread of the UI to call the update method for the User Interface.
Dispatchers can be called either synchronously (using Invoke) either async (using BeginInvoke/EndInvoke). Please note that in .NET there is a requirement to call EndInvoke for each BeginInvoke (becuase .NET doesn't gives you the warranty that the async handles will be freed), so Fire and Forget isn't an option by default (unless you implement your own FireAndForget)
Mapad posted a link to on UI and threads here which you may find useful. You didn't mention which UI toolkit and which language so I can't give you any specifics.