I recently needed to make several web.config changes to our production SharePoint 2010 web farm. Making all of these modifications manually would have been tedious and would have left a lot of room for error. After doing some research to find a better way, I discovered the SPWebConfigModification class in the Microsoft.SharePoint.Administration namespace.
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…
Workflow in SharePoint 2013 has undergone quite the architectural change from its SharePoint 2010 ancestor. I documented many of the major changes in a previous blog post, “What Changed in SharePoint 2013 Workflow? Pretty Much Everything.” While SharePoint 2013 is backwards-compatible with SharePoint 2010 workflows, you may decide that the benefits of the new design are needed. The purpose of this post is to illustrate the new considerations you’ll need to keep in mind when targeting SharePoint 2013 workflows. The SharePoint 2010 project we’ll use for this example is the one from my very first AIS blog post, “Developing Multi-Tiered Solutions for SharePoint.”
Figure 1 - Sample WebAPI methods for Section Document Merge and Post-Merge Actions.
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.
It was more than 10 years ago when AIS first began to explore and envision the idea of using SharePoint as an application development platform. Although Office was a great product to author content, it did not provide a means to manage that content. From the moment we heard that Microsoft was going to provide a centralized, managed repository for Office and other forms, documents and records we immediately started to envision solutions for our clients, along with a laundry list of new features.
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…
The standard configuration of FAST Search for SharePoint does not always yield the most relevant results. This is often the case when developing SharePoint applications composed of custom content types and documents. The FAST Search for SharePoint 2010 default rank profile applies a -4000 point boost (or 4000 point penalty) to list items, thus drastically reducing their relevance in search. One can verify this by executing the following commands from a FAST PowerShell console:
$rp = Get-FASTSearchMetadataRankProfile -name default
Executing the above commands in my environment produces this:
Default Rank Profile Managed Property Boosts
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…
Have you ever worked on a project that seemed to eat any memory available? If so, chances are you have encountered a memory leak. Memory leaks in SharePoint are very common. For example, using instances of
SPLimitedWebPartManager can be a cause of memory leaks. Why? Turns out that
SPLimitedWebPartManager instances instantiate their own
SPWeb object, 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…
A global law firm gained a planning and billed-hours edge with a new custom SharePoint application, incorporating an intelligent data dashboard, developed by the experienced team at AIS. This custom-developed solution continues a rich history of success, as the firm views AIS as their IT project partner and a long-term extension of their team.
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.
Click here to read the full case study.
After watching demos on Power View I was excited to begin using the tool, as we recently configured SQL 2012 SSRS and PowerPivot with SharePoint 2010 for an internationally-focused client. But after playing around with my PowerPivot model in Power View, I realized the Map chart type that I had been so looking forward to using…was not available.
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…
I recently completed a large document management system on SharePoint 2010 that used FAST Search and claims-based authentication. The client wanted to secure and limit access to customer-specific documents based on data coming from their CRM system.
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…
I have a Windows Presentation Foundation (WPF) app currently in testing and this week it came back with some weird issues. The app uses the Client Object Model to consume SharePoint 2010 lists and UX is a factor in the design, so we’ve decided to do some metrics recording to see how people interact with the app. We want to know what features people use and which efforts were wasted.
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 …