Dynamics 365 and SharePoint Online Integration – Web Api Development
dynamics-365-sharepoint-online-integration-webapi
dynamics-365-sharepoint-online-integration-webapi
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.
Recently I had a requirement to provide cloning capabilities for one of the projects that I was working on. It wasn’t so simple as to just clone an individual record, but also provide the ability to clone the relationships.
In the second part of the installation of configuration of Azure Logic Apps with the On-Premise Data Gateway, we will review the requirements that are need inside of the Azure Portal. This will cover the creation of the Data Gateway resource, the Logic app and the creation of the Trigger and Action inside of the Logic App designer.
I recently had a requirement to configure Logic Apps for use with the Azure On-Premise Data Gateway and connection to an Oracle On-Premise database. Since I did not have access to the Oracle database at that point, I decided to try this out with an On-Premise SQL Server database as the logic should have been similar. I downloaded the Azure On-Premise Data Gateway and installed it on the server, and the configured the Azure environment to connect to the server and post data back to Dynamics 365.
We recently had a requirement that users wanted to hide the Delete icon on the subgrid to prevent users from deleting records. Of course it is possible to remove the Delete privilege on the entity in Security Roles, but the requirement was different. When the status of the parent record was Active, the Delete operation should be allowed, however when the parent record was Inactive, the Delete operation should not be allowed.
In a few of my recent implementation I had the requirement of making modifications to many child records. Some of these processes required the use of an external SSIS package that executed a console application and ran on a schedule, but more recently I had a requirement to simply deactivate multiple child records. This of course can also be done using cascading rules, but it’s a little more complicated once you involve custom filtering.
In this third post of the series, we will review the changes between the properties and methods of the control based on the getControls Collection or the Xrm.Page.getControl method. The tables below will show the base methods of the control, as well as specific method for specific control types.