Blogs SharePoint

I have been working in the Government space for a few years now, and most implementations of the Dynamics and Azure tenants and environments are hosted in the Government Cloud. This means that there are a lot of restrictions that we have to deal with, not only from Microsoft but also from the internal IT policies.

Last Friday, while working with one of our clients on an integration issue between Dynamics and the Microsoft Exchange global address book, he asked me if there was a way for them to have automated creation of events (calendar items) in their Microsoft Outlook calendar where the source of the data was an Excel spreadsheet in OneDrive. This is a short post, but might help someone out who needs to implement this.

One of the features in Microsoft Dynamics 365 (and some of the previous versions has been document templates). I wanted to validate some of the logic, if we can automate the creation of a document and sending it as an email using Microsoft Flow, and of course Flow did not fail to perform.

In order to implement this logic, the first thing was to create the actual document in Microsoft Word. This document will be the template that we create, and will convert it to an Adobe PDF and finally Send it in an email message using Office 365. This process is based on a requirement to generate a license and send it as an email to the user when a new license is generated (or updated).

Ever since Microsoft purchased AdxStudios and replaced the product with Dynamics Portals, one of the biggest pains was the removal of SharePoint documents. The interim solution of course was available using Azure blobs with the Dynamics Labs solution which provided document uploads, but using the Out of the Box SharePoint Documents was a miss by a lot of Portal Developers.

For the final part of the series, I am going to demonstrate and explain the portions that resides inside Dynamics CRM (or can possibly be built inside other applications). The solution includes an HTML web resource that contains a subgrid (using JQWidgets, but can be replaced with any third party jquery grid or bootstrap table). The subgrid contains a list of documents that are contained in SharePoint, and provides the functionality to upload or download additional documents.

Now that we have configured our SharePoint and Azure environments to allow us to create an API that will be called from CRM and process SharePoint requests, we will dive into the actual API.

The next part of this solution is to configure Microsoft Azure. If you do not have an Azure account, you can create a Trial account of Pay as you go account. If you are a partner or have a BizSpark subscription you get a certain amount of credits per month, which should be more than enough for the type of implementation that needs to be done using Azure.

The easiest part of this solution is to configure SharePoint. There is no custom development involved, but just the creation of the document library, the folders, custom lists and the attributes that we want to use for the solution. We will need to start with the creation of the custom lists as they will be used for the creation of the lookup attributes.

Over the past few years we have encountered multiple scenarios where the Out of the Box SharePoint Integration component, did not fulfill the requirements of our clients using Dynamics 365 and SharePoint. Some of these had to do with capturing additional attributes in SharePoint, and sharing similar data across different entities in SharePoint.

There are many times that we create a SharePoint web part in which we have to pass query string parameters to it from the main page, or possibly use an aspx page. If the web part that we create resides inside a Page Viewer Control, we are unable to use the Request.QueryString method in order to retrieve those values.

In such case, we would have to use the Request.UrlReferrer property in order to retrieve the Query String of the parent page and manipulate the data using a Custom "Get Query String" method that we create.