This is basically a collection of changes to be made to web.config files that can be stored and then applied to all web front-end servers in a farm. This class is available with SharePoint 2010 and 2013. Unfortunately, the class is poorly documented so I had some trouble figuring out how to use it. You could write a console application to use the SPWebConfigModification class or you could use a feature receiver, but I found that the easiest approach was to just use it with PowerShell. After some trial and error, I came up with the following four PowerShell scripts that can be reused to read, add, remove, and completely clear the SPWebConfigModifications on the server. Read More…
In our example project there are actually two workflows, SectionDocumentApprovalState (SDAS) and MasterDocumentApproval (MDA). The MDA checks if the various SDAS-related sections have been merged and finalized, then notifies specific users for approval of the final document. An instance of SDAS is created for each section, created from the Master Document that monitors the editing and approval of the specific section. We’ll focus on just the SDAS workflow. In the previous post, I referred to the workflows as being part of the Presentation Layer and the custom code called into the Business Layer. Both of these layers will change in a SharePoint 2013 workflow solution.
Creating SharePoint Sites From a Dynamics CRM Plugin
With more and more companies adopting both Dynamics CRM and SharePoint into their corporate technology stacks, I’ve found myself integrating the two technologies more often than ever before. It’s quite cool. These are two extremely powerful systems and they both do what they are designed to do very well. I’m not going to go in-depth about what the differences are between these products…they are in totally different software “genres.” Apples and oranges. However, I want to point out one thing SharePoint gives you that many clients ask for again and again: Subsites.
Subsites are SharePoint sites that belong to a root SharePoint Site Collection. An example of this would be a corporate intranet SharePoint Site Collection (https://intranet) with SharePoint Subsites for each division in the corporation, e.g. Marketing (https://intranet/sites/marketing), Accounting (https://intranet/sites/accounting), etc. There are pros and cons to breaking these Subsites out into their own Site Collections (so they can have their own content database), but quite often you see this hierarchical approach.
Another very common use of SharePoint Subsites is for things like item level management, for instance a project. You may have a SharePoint Site Collection named Projects (https://projects), and you may require a new SharePoint Team Site for any new projects that come online so as to provide an environment where a team can collaborate on said project, and maintain any data or documents about the project in a central location. This can best be described with URLs —https://projects/sites/Project1, https://projects/sites/Project2 and so on.
So how does Dynamics CRM play into my scenario? What if you’d like to leverage this same functionality for things like Accounts, Contacts or Leads? Pick an Entity from CRM — for the purposes of this blog the Entity is somewhat arbitrary, but we’ll use the Account Entity so we have something to focus on. Every new Account I create may or may not require an environment where teams can collaborate and store data and documents for this new Account. Dynamics CRM gives us SharePoint Document Management out of the box. But what if I need more? What if my company maintains a site ‘template’ that can be used to create a new, standardized website (SharePoint Subsite) for any new Accounts that come online? A place where a team can collaborate and have the freedom to deal with unstructured data and content in a central location?
In this blog I’ll show you how to leverage the SharePoint Client Object Model in a Dynamics CRM Plugin to create a SharePoint Team Site for new Accounts that come online.
Automated workflow and integration of development tools were immediate needs. It wasn’t until 2007 that we felt we had enough features to address our client’s needs to automate paper-based workflows. You can view the whitepaper we published on January 30, 2007 (the very day SharePoint 2007 was released) on our YouTube channel. We published an updated version on the day of the 2010 release, which was a major release in terms of features and performance that also marked the expansion of Search features.
READ MORE: SharePoint App Dev Platform: The Journey So Far & the Road Ahead
Over the years we have built countless large-scale, human-to-human (and human-to-system) workflow solutions. Some support tens of thousands of users, hundreds of thousands of workflows, and hundreds of millions of documents and records. We’ve built task, event, investigation, legal matter, and assessment management systems (just to name a few) across DoD and the military, many Intel agencies and some civilian agencies in the public sector. In the commercial sector our clients range from the largest law firms, international NGOs with far-flung offices, health plans, wealth and financial management, among many others.
Today, SharePoint 2013 has fully matured. It finally contains all the features we need for a fully-featured application development platform. We now have enumerable building blocks which allow us to write less code and deliver solutions for a fraction of the cost of other solutions. Read More…
$rp = Get-FASTSearchMetadataRankProfile -name default
Executing the above commands in my environment produces this:
The impact of this configuration is often undesired in custom SharePoint solutions, where content types derived from Item (0x01) typically contain crucial information, or provide links to other related items. In these scenarios, some types of list items should appear at the top of search results. Fortunately, FAST Search for SharePoint offers a means of accomplishing this goal. Read More…
SPLimitedWebPartManagercan be a cause of memory leaks. Why? Turns out that
SPLimitedWebPartManagerinstances instantiate their own
SPWebobject, but don’t properly dispose of them: a bug in the SharePoint 2010 SDK. It seems that one of the only ways to discover this ghost memory leak is in production. Or a little utility, built by Microsoft, called SPDisposeCheck.
You can run SPDisposeCheck in the command line, but I thought it would be nice to integrate it into a project. These are the steps to integrate SPDisposeCheck into a build: Read More…
The long-time AIS client is a top law firm with household name clients in the technology, financial, healthcare and retail industries. They staff more than 1,000 lawyers and offices in 12 cities in the United States, Europe and Asia. This client offers comprehensive legal capabilities for intellectual property, tax issues, real estate, bankruptcy, environmental, corporate law and more.
AIS was initially brought in to build the firm’s global intranet. The project, a SharePoint intranet application, was very successful and user adoption exceeded expectations. Around the same time, the firm hired another company to build a resource application for its main legal practice areas. But because of poor user feedback and bad performance, the application never made it to production. After nearly three years of time and money spent, the firm turned to AIS for help.
Turns out we had installed SQL 2012 but not SQL 2012 SP1. Power View gets a number of important upgrades in SP1, including much-needed filtering that’s missing from the earlier version, as well as my eagerly anticipated Map chart type. Read More…
We decided to implement a custom claim provider that would query the CRM system at login for customer claims based on the user ID. On upload (based on the customer that was assigned to the document), we used the content organizer to route the document to the correct site, library and folder based on the organization and security rules that we had. Each library had a claim for the customer assigned to it so only users with that claim could view the documents in the library. We would use search for the UI so that the users had a single place to find and view the documents. Sounds simple, right?
It should’ve been.
Unfortunately, the implementation was anything but simple. From the beginning, we hit the core limits of SharePoint 2010, FAST and Claims. Now that we’ve made it to the end, I want to talk about the limits we ran into and steps you can take in your design to avoid them. Read More…
Strangely, we started noticing that the names of the metrics (which were also being written to a SharePoint list) were displaying some incorrect results…names like “ShowAllItemsOpened” were instead “showAllMenuItem_Click.” What’s that you say? Clearly that’s the name of an event handler! Well, you’d be right! But it worked before! What changed in testing? First, some background information …