MSGraphClient is used to perform REST calls against Microsoft Graph. The Microsoft Graph JavaScript client library is a lightweight wrapper around the Microsoft Graph API. This class allows developers to start making REST calls to MSGraph without needing to initialize the the MSGraph client library.

Note: Microsoft Graph API is replacing the previously released GraphHttpClient, which is now considered to be deprecated.

In this post, I am going to show you a SharePoint Framework WebPart to fetch my User Profile details using Microsoft Graph API. I consider that you have a SharePoint Framework HelloWorldWebPart WebPart, if you don’t, take a look at this article.

Note: API Management can be performed only on first release tenant.

Import the MSGraphClient in the HelloWorldWebPart.ts file as shown below

Write the following code snippet inside the render function.

Open the package-solution.json file and update the Graph API permission

Update the CDN cdnBasePath parameter in write-manifests.json file as per your setup

Execute the gulp bundle and gulp package-solution with ship attribute to prepare the build

Upload the CDN files in the CDN location specified in the write-manifests.json file

Upload the SPPKG file in the app catalog site. As shown below, We have to approve the Microsoft Graph API permission requested by the developer in the package-solution.json.

Click Deploy

Open the New SharePoint Admin Center and click on API Management

Select the permission and approve the request

Install the HelloWorld WebPart in a SharePoint Site and add the same in a page

Verify if HelloWorld WebPart is printing the current user display name and mail in browser console.

Regarding this issue, when I approached some MVPs and Microsoft Windows Development team they replied that it is not possible to map the SharePoint managed properties with the windows explorer search result attributes.

Windows 7 is the first OS with the capability to use external search providers as federated search locations – and yes, this federated location can also be SharePoint! In general, all search providers can be federated if it’s OpenSearch 1.0/1.1 compatible or, in other words, can provide the search results in RSS/Atom format.

So that means if I have to create my own RSS feeding file then my custom code should return the SharePoint search results in RSS/Atom format. So I started exploring what is the best way to get the search results. Then I found a interesting feature in SharePoint 2013 called “SharePoint 2013 Search REST API”. This new REST service is the best way to go in a variety of application scenarios. External Applications to SharePoint that require search functionality can also leverage this service as the endpoint for communication into the Search platform. The old search.asmx SOAP web service is marked as deprecated in SP2013, and the new Search REST service is the replacement.

Using the above mentioned API I am supplying the keyword to the API and getting the XML output. From the XML output I am extracting the necessary XML Node values and populating the output in the format of RSS/Atom using the below code:

We have a SharePoint BCS Profile page (with XSLT customization). In this page we have to load an image in one of the column/cell. There is no problem in loading the image with the IMG tag until the image is not available. If the image is not available in the given URL, it will normally show the cross mark (X) symbol.

The customer requirement is below:

If the image is not available in the given URL location then show an alternative image / text (Preview not Available).

We have a site request SharePoint List. Users will raise request using this list to get a new SharePoint WIKI article. Once the user press the Save button in the OOB SharePoint Designer form (which we customized using SPD 2010), it should redirect to one Status Page and wait there till the workflow creates the new site and configure the permission based on the meta data submitted by the requestor.

Once the workflow is completed we have to check the status of the workflow. If the status of the workflow is “Success” then we have to redirect the page to the newly created site. If the status is “Failed” then we have to show an alert message.

Problem

Basically in SPD forms once the data is submitted, the page will be redirected to the page where you came from.

The problem here is to identify the ID of the newly created item and check the workflow status using that ID since the ID for the new item is unknown before the item has been created

Solution

To solve this we have to follow the below steps explained in the below article :

Now create an intermediate page (GetLastID.aspx) and paste the below code then upload this in any of your document library of your site. All this page does is find the most recent item in the list which was created by the current user and redirect to WIKIStatus.aspx with the ID on the Query String (ParaID).

Now create a new page and name it as “WIKIStatus” and add the below script in a CEWP. All this CEWP page does is check the status of the workflow for the Item Id received from the Query String. If the value of the status column is “Success” then it will redirect the page to the newly created site (which was updated by the workflow behind the scene). If the status is “Failed”, then it will show an alert message.