Integration of Yammer REST APIs with SPFx react webpart

Yammer REST APIs can be consumed by using SharePoint Framework React webpart. The SPFx webpart contains wrapper around the Yammer JavaScript SDK that can be extended for fluent typescript api experience. One good use may be when we would like to have Yammer and SharePoint interaction in one webpart hosted on modern site page.

Calling the Yammer Search REST APIs


This article is about recent sample that I created for the SharePoint Patterns and Practices community, a very simple SharePoint Framework client-side web part built using React that authenticates against the Yammer REST services and then consumes the Yammer search REST endpoint.

Velin Georgiev blog image

A short demo is available in this video:


Why should I use it?


Based on the stakeholder needs we had to bring unified user experience in one webpart where we have news article that is stored in a SharePoint list, but the social features for the article like `likes` button and `follow` button stored in Yammer. The likes are stored in a Yammer Thread created along with the news article in SharePoint. So unified look is always important for the client and they wanted us to do custom code to met their branding expectations. Another use case is where you'd like to have more control over the Yammer APIs or to use REST endpoints that are not available with the OOTB Yammer components in SharePoint.

Prerequisites, before we can test sample


- Office 365 subscription with SharePoint Online and Yammer.
- SharePoint Framework development environment already set up (detailed guide link).
- Yammer app already registered. Here is a link on how to register an app with Yammer guide.

How to run the SharePoint Framework Yammer sample


- Clone the Github repository from this link.
- In the Yammer corresponding to your Office 365 tenant, register a new Yammer App. Here is a how to register an app with Yammer guide.
- Do not forget to paste your Office 365 tenant url in the Javascript Origins upon Yammer app registration e.g Javascript Origins: https://<your_tenant>.sharepoint.com.
- Add Yammer app redirect URI e.g. https://<your_tenant>.sharepoint.com/SitePages/Home.aspx.
- Make sure the Yammer app is enabled

Velin Georgiev blog image

- Copy the Yammer app client Id and redirect uri.
- Go to the SPFx webpart folder and find src/webparts/reactYammerApi/yammer/ProdConfiguration.ts.
- Replace the config client id and redirect uri with the copied from the yammer registered app values.
import { IConfiguration } from './IConfiguration';

/**
* Webpart production configuration.
*/
export class ProdConfiguration implements IConfiguration {
    public readonly clientId: string = "<YOUR_YAMMER_APP_CLIENT_ID>";
    public readonly redirectUri: string = "<YOUR_YAMMER_APP_REDIRECT_URI>";
}
- Open the command line, navigate to the web part folder and execute:
    - npm i
    - gulp test (optional)
    - gulp serve --nobrowser
- Navigate to the hosted version of the SharePoint workbench (https://<your_tenant>.sharepoint.com/sites/<your_site>/_layouts/15/workbench.aspx).
- Add the React Yammer API web part.

Yammer Smart Authentication, if Yammer Enforce Office 365 identity is enabled


If Yammer Office 365 Identity Enforcement is enabled, the webpart will 'smart' authenticate Office 365 user when in SharePoint Online environment i.e. a user should allow the app (consent popup) once in a lifetime. After, the user will be logged in all the time. Smart because if you do not have the yammer auth cookies, you would not have to re-authenticate with login button and popups. To enable Office 365 Identity Enforcement on Office 365 Enterprise E3 Trial tenant, go to the Office 365 admin -> Admin centers -> Yammer -> Security Settings -> Enforce Office 365 identity. Unfortunately, this setting should be enabled by tenant admin and a decision about this should be made on an enterprise architectural level. The good news is that this is an extra security setting so maybe your enterprise has already enabled it.

Summary


Using the Yammer APIs has some good sides like more control over the components and better user experience, but also brings some downsides like time in development effort and some request limitations listed on this link. I would still go with the above approach because for me seems that I can met the stakeholder requirements and not end up with a very complex multi-tier solution to that, but just a webpart.

Thanks to Joseph King for his help on the sample.

Available on Github

Comments