Do we have webhooks/Push notification available for successfactor? - sap-successfactors

Do we have webhook available for SAP successfactor?
Do we have any webhook available where I can get the notification if any operation happened in the entity like any object is inserted in the entity then I will get notification?

Yes, it is an inplace functionality called Intelligent Services (can be found in Successfactors within transaction "Intelligent Service Center (ISC)".
There you can subscribe to different events (only the one's provided in the standard, no custom hooks possible). The subscription results in an integration center flow, where data can be passed via different protocolls to a webservice of your choice.
You can also configure a "business rule" with an intelligent service as a starting point.

Related

Callout from trigger without using Future annotation

At this moment I'm calling a #future method X from the Account_after_update trigger. I have to use #future annotation because X makes an external site call (just to notify account is updated). It's working fine.
But for some reasons (please don't ask why) I have to remove #future annotation.
And of course it will be impossible to make HTTP request from the X method (Salesforce restriction).
Is there a way how to notify external site about account updating (and send an account ID) without using of #furure annotation? Or even without a trigger? Probably something like subscription to account_updated event.
You can use outbound messages which can send a soap request to an endpoint using workflow, or you can use the streaming api where you can create push topics to send push notifications to subscribers. Of the two options outbound messages is simplest if your endpoint supports soap.
You can try creating background jobs to do the work for you. hope you find the solution here

How to create a custom webhook URL per address via API

We are creating a custom payment service that uses Coinbase as a Bitcoin backbone. I managed to set up Bitcoin address creation (wallets) and the checkout process is actually finished (Bitcoin address is being created).
However, I did not find a way to attach a custom callback URL to an address I've created. The address should "listen" to incoming transactions and trigger the webhook URL.
We cannot use any of the predigested merchant solutions from Coinbase (button / page / iframe) because the payment flow should be deeply integrated into our existing processes, look and feel. Instead the system is just creating a new Bitcoin address and should be notified on incoming transaction events, but without using a merchant solution.
When creating an address using the Coinbase API v2, you get an object that includes the callback_url property. However, it is empty and in the documentation there is no hint on how to specify that.
I thought about polling the addresses, but that could easily exceed the 10,000 requests per hour rate limit. Any clues how to specify the callback_url on address creation (https://api.coinbase.com/v2/accounts/:account_id/addresses)?
I’d recommend a third-party for this - I’ve personally used https://blockchainwebhooks.com and https://www.blockcypher.com - both have been reliable and offer free plans. Blockchain WebHooks is significantly more affordable, that’s what we still used today.

Differentiating message event type while catching payload on facebook webhook

I am creating a facebook chatbot and i can get different kinds of JSON format for persistent menu, quick replies and simple messages. Is there any way that i can differentiate what functionality (i.e. either persistent menu, quick reply, button template) is triggering the webhook call?
Here is the list of actions, that can trigger webhook by the date 10th Sept 2017. You can differentiate the calls by parsing JSON format. Each one has its own structure encapsulated with a general structure.
Message
Message Delivered
Message Read
Message Echo
Postback
Plugin Opt-in
Referral
Payment (beta)
Checkout Update (beta)
Pre-Checkout (beta)
Account Linking Event
Policy Enforcement Event
App Roles (beta)
Standby (beta)
Pass Thread Control (beta)
Take Thread Control (beta)
To find out more check out the related dev docs:
https://developers.facebook.com/docs/messenger-platform/webhook-reference

Notifications on changes in SmartSheet

The API only seems to describe how to get other programs to control smartsheets, how do I get smartsheet to control other apps?
It seems to be possible, the zapier integration mentions that you can make an event "on new row".
In particular, it would be nice to get notifications on new rows and changes in dates.
Cine, you are correct - the explicit objective of the Smartsheet API (as is with most APIs) is to provide access to and facilitate management of Smartsheet data and properties. The API has no knowledge of other products and services - nor it should.
The Smartsheet connectors for Zapier, Azuqua, itduzzit and other similar "API orchestration" services allow users to create triggers on various Smartsheet events, like new rows or row updates... or take an action based on another event (e.g., create a new row or update an existing row).
In addition, we are in the process of developing webhooks (see https://en.wikipedia.org/wiki/Webhook and http://resthooks.org/) and plan to make these available later this year. Through webhooks you will be able to subscribe to notifications on Smartsheet events, like new rows, sheets, discussions, etc.

rest api design -> email notification

Is it bad practice to do automatic notification (email/sms/etc) as part of an api call? Or should that be separated from the core functionality.
Say I update a project status and want to send notification to all users watching the project.
Can I do that from the update call or should I break it out into some other notification mechanism? Any thoughts? If doing it from the call I guess each relevant method would need an option of skipping sending notifications.
I would add to a response by Rafael Mueller that there is a difference between RESTful interface and implementation mechanics.
As far as RESTful interface is concerned here are my thoughts. Let's say you update a project status with "PUT /project/123/status". Whether email is going to be send or not it's up to a value proposition of your app. May be that's how you want to differentiate yourself from your competitors.
Let's say you support sending of emails but you want to give control to a client on a call-by-call basis. I would go with an optional HTTP Header or an optional attribute of the request body be it JSON or XML or anything else.
Once you allowed variability in emailing project status, I would advice to design a designated end-point to trigger email update on demand. Something like "POST /project/123/status/send-email". This way your client won't shoot itself in a foot: if they forgot to send email during a project status update, or simply changed their mind, they can always call "send-email".
I would rise an event, ProjectUpdated, you can add it to your messaging system (a database could solve, or rabbitmq, msmq...) and the consumer of this event, will send the email.