I’ve recently been involved in a project whose the purpose was to extend the Corporate Intranet with the social capabilities of Yammer. No matter what you do, you have different options when it comes to integrate with Yammer. Here is a list of options with pros & cons of each:
1) Yammer Client SDK
This guy is great but in the context of a Corporate Intranet, there is something end users don’t like to see : the consent prompt. Indeed, in order to use the Yammer Client SDK, one must first register an App in Yammer (easily done from the client_applications page) and allow CORS requests from the consumer, being in this case your Intranet. Once done, you can start using the SDK but in order for the SDK to interact on behalf of the user, they need to login and to consent (once). This is not user-friendly when your users are used to SSO like features. So, depending on your scenario, if you can afford such drawbacks, you could chose this SDK, else, go see the next option :).
2) Yammer Embed
Yammer Embed is great as it greatly facilitates the integration of Yammer. In only a few lines of code, you can get it bound to a group, an opengraph object, a feed…Tip : if you want to link it to a page, just chose the opengraph type of integration and specify the URL of your page (which should automatically be unique). The first person that will interact with that page will create the thread.
However, Yammer Embed also comes with some challenges : 1) it’s not super mobile friendly as it’s using an iframe behind the scenes 2) Users also have to login…as the Yammer Login button shows up by default. 3) the look & feel might not match your Corporate Intranet’s.
Regarding the SSO, a useful tip consists in injecting a hidden iframe into the page that makes use of SmartLinks in order to tell 365 the target domain you’re trying to reach. In you have a federation, this hidden iframe will cause the browser to be (silently) redirected to your ADFS server and you will have a transparent login. If you perform the embed config after this iframe has finished loading, you won’t need to log into Yammer.
3) Yammer Apps – Server Side, the Yammer way
Tip 1 : if you create such a server-side component, host it in Azure as it will decouple your Yammer integration from the on-prem platform and will be consumable by both on-prem and Cloud hosted services.
Tip 2 : make sure to use caching to prevent Yammer throttling.
4) Azure AD Apps
As you probably know, it is possible to create Azure Active Directory Applications in order to consume the Yammer Service but this has some shortcomings at the time of writing : 1) there is no application-only permissions 2) it is not yet compatible with ADALJS as the Yammer Service isn’t CORS enabled for Azure AD Apps.
Given the advantages and shortcomings of each option, we ended up with a combination of options 1 and 3. We hosted a proxy component in the Cloud and secured via Azure AD. Indeed, if you’d like to retrieve the groups of a given user, some generic information etc., the proxy approach can be useful as you can easily impersonate them. For any direct interaction, Yammer Embed sounds to be the most logical component to use as it natively supports both display & contribute capabilities.