Keller Schroeder is a K2 Partner

If I haven’t mentioned it lately, I wanted to remind you that every business needs SharePoint – some just don’t know it yet. I have said many times that if the only reason you use SharePoint is for document management, then it is still worth it. There are many benefits to classifying and versioning your documents and forms in SharePoint that result in efficiency gained and dollars saved. I often say, however, that document management is just the tip of the SharePoint iceberg. You can multiply efficiency and cost savings by using workflow to automate your business activities.

Unfortunately, as computer processing power has increased exponentially over the past few decades, human beings have not kept up with the pace. In fact, the digital advances have ultimately resulted in more information for a person to process, more responsibilities for a person to manage, and higher expectations set for a person – often making that person more of a bottleneck. Opinions vary widely regarding the number of decisions a person makes in a day – ranging from hundreds to thousands. As an organization, it is critical that the participants in your key business activities make their decisions and perform their duties in a timely manner. “Yes,” you wonder, “but how can SharePoint help with that?”

In addition to storing, versioning, and categorizing your documents, SharePoint provides a framework for workflow to move key documents and information from one person to the next. Information is validated in real time, and routed to the appropriate participants along the way. The information is secure. The activities are logged for auditing purposes. A well-structured workflow will eliminate most of the guess work. There are some useful workflows included with SharePoint, but we have often found that our clients would want us to develop workflows that are unique to their business requirements. As we developed these custom workflows, we began to recognize patterns in what our clients were asking for, and gaps that SharePoint did not fill out of the box. Sometimes the gaps were costly to develop around, so we began to look for a better way. The better way, in our case, came in the form of a partnership with K2.

Before I continue, I want to mention that although I am convinced that every business needs SharePoint, I am also convinced that not every software development project is a great fit for SharePoint. In the same way, not every workflow project is a fit for K2. One advantage to working with an experienced SharePoint partner such as Keller Schroeder is that you can rely on our guidance for which approach is best for your particular situation. You really need to consider both the near term and the long term. The minute you choose to automate a second business activity with SharePoint (or possibly without), you double the importance of evaluating a product like K2.

For now, I wanted to take this opportunity to announce our partnership with K2. We appreciate their great products, and we appreciate just as much their partnering attitude and their quality people. In a coming series of posts, I am going to focus on some use cases for business process automation. I will introduce you to the K2 products. Other members of our team will post some how-to articles with great examples of our K2 and/or SharePoint work. I will kick it all off with a post on the gaps that K2 fills, and the reasons we chose to partner with K2.

SharePoint – Understanding Your Options

As a veteran software consultant (in my 20th year), I take pride in not overusing the phrase "it depends." I realize a client works with us because he or she is looking for a solution, and we try to narrow it down to the best solution possible. Unfortunately, working with SharePoint the last several years, I sometimes have to bite my tongue to avoid saying those words. Arriving at the best solution seems to take a little more diligence than before, simply because there are more choices than before. Having choices is not necessarily a bad thing, but having an abundance of choices can certainly complicate things a bit.

There are numerous ways to address many business challenges in SharePoint. There are so many books, so many blogs, and so many experts. Sometimes, the experts seem to contradict each other on what is a best practice. Sometimes, even the Microsoft product teams seem to contradict each other. I definitely have my preferences, based on good and not-so-good experiences over time. I suggest that “best practice” should be used a little differently than it is often used. For example, someone may ask me to identify the “best practice” for surfacing his or her line of business data in SharePoint. Once I have considered the unique business requirements and environment, I will make a recommendation (the best of many considered), then follow best practices to implement the solution.

Some experts will say that it is a best practice to always use Visual Studio to develop SharePoint solutions. They make good points. Some try to do everything “out of the box,” and others favor power user tools, such as SharePoint Designer. My own experiences tell me that it is best to have isolated development, test, and production environments – and I certainly prefer developing SharePoint features as Visual Studio solutions. However, the reality is that some clients have limited environments, no means for supporting Visual Studio solutions, and a propensity for the power user tools. So we use the tools that are the best fit based on the circumstances. If I am using SharePoint Designer, I follow best practices for developing with SharePoint Designer.

Some of the more popular, and sometimes controversial, blog posts and articles on SharePoint are the ones about "what does it really mean to be a SharePoint developer?" and "what not to do on SharePoint." A recent example from my feed reader was this one. The author makes some good points, but as you can see in the comments, there is some dissention. Personally, I think all three points are valid in certain situations. The dissenters think that some of the points are invalid – probably because their situations were different. What this demonstrates is that the best solution is relative to the circumstances, and the best experts are those who have seen the most situations over the longest period of time. I have yet to find a solution that is “always” the best solution, and I rarely say “never.”

A consultant may architect a development approach with the best intentions. The approach may align with your in-house skills, allow for rapid application development, and produce quality code on a consistent basis over an extended time period. Then, three years later, you may be required to upgrade your SharePoint farm to the latest version, and find that all of that code is going to make the upgrade much more complicated because of the way it was implemented. An architect that has gone through SharePoint migrations before may have steered you in a different direction architecturally.

I was recently privileged to hear Dr. Sheena Iyengar speak at a leadership summit. She made the point that the more choices with which you are presented, the better the chance you will make a bad one. So why does Microsoft give us so many choices when it comes to customizing SharePoint? I may have offered fewer choices myself, but let us attempt to address that question.

I want to reference one of the best articles I have come across for identifying and explaining the various SharePoint development approaches. I will almost assuredly reference it in future blog posts. In addition, I want to mention just a few of the factors that I consider when determining the best development approach for a project or project team:

• Are development, test, and production servers available?
• What are the required skills? Are these skills available in the organization for ongoing support?
• What tools does the development team have available to them? What tools can be available if they do not have them already?
• Is this project a good fit for SharePoint in the first place?
• Will this solution scale to the degree needed?
• Is there a third party solution that would add value to this project?
• What is the budget? What is the return on investment? The most affordable solution is often not the best solution, but a solution may often be phased to offset the cost.

There is definitely an approach to determine the best solution. A good consultant keeps an open mind, but also identifies the potential risks based on his or her experience and on the experiences of others. Setting the proper expectations is critical. In my experience, the end result is typically a positive one. Why? As it turns out, having an abundance of development options is vital to SharePoint’s success. Having a trusted partner that understands the options and can work with you to understand which one is best for you, well that’s priceless.

Make InfoPath Better with Web Services

So you might know I’m a fan of InfoPath and think it is underused, but I also acknowledge that (as with most development tools) it has its limitations. There is only so much you can do with an InfoPath rule to make your forms more dynamic. There are third party products that provide additional rules, but even they fall short of integrating with your line of business systems. Most of the time your only option is to inject custom .NET code. This gives you good flexibility as a developer, but it could potentially require that the Web form be administrator approved and not run as a sandboxed solution. Perhaps a better approach is a service-oriented one.

We recently developed a form that required a button to lookup a customer ID and populate the customer’s address. In this case, a Web service already existed to return the address for valid customers. We added a rule to the lookup button to call the Web service and populate the address from the response. No development required, so the form can be published directly by the form designer.

Another example is for forms that have an email rule. A common requirement is to email a confirmation to the consumer who filled out the form and submitted it. InfoPath makes this easy by allowing you to add an email rule after the submit rule. However, if the mail server is down when the form is submitted, the form data will still be saved into a SharePoint library, but the consumer receives a non-descriptive error from the email rule. As a result, no confirmation email is sent and the consumer thinks the form data was lost, so they resubmit the form. A solution is to develop a Web service to check the state of the mail server, and condition the email rule based on a positive response from the Web service. If the email is not sent, then a property is set within the form to let the form owner know that a manual email needs to be sent later.

The only real caveat in all of this is that the InfoPath data connection that is associated with the Web service must be converted to a data connection file (udcx) and stored in a library on the SharePoint site. Is that a bad thing? Not really. It makes the administrator responsible for which Web services are allowed to be called from forms, and encourages portability for promoting forms from development to staging to production environments. There is a good walk through of connecting a form with a Web service in the MSDN Blogs. Consider making your forms more dynamic by taking this service-oriented approach.

What You Need to Know to Get Started with InfoPath 2010

Before I dive into sample electronic forms solutions with InfoPath 2010, there are some things that you should know.

InfoPath 2010 is a Microsoft Office product. InfoPath 2010 is included with Office 2010 Professional Plus, or it can be purchased as a standalone product. There are two icons included with the program: InfoPath Designer 2010 and InfoPath Filler 2010. Designer is used to create form templates (.xsn files) that can be filled out using Filler, or published to a SharePoint server and filled out online. Filler is used to fill out an InfoPath form on your desktop (similar to filling out an PDF form in Adobe Acrobat Reader). When you fill out a form using Filler or SharePoint’s forms services, the form is saved as an XML document and contains a reference to the template from which it was created.

You do not have to have SharePoint 2010, but it does work better. If you do not have SharePoint, InfoPath forms can be created using the desktop Filler, saved to a network share, emailed, and so forth. If you have SharePoint Foundation 2010 (often referred to as the “free” edition of SharePoint), you can publish your form templates to a form library and save your form data (XML) to a form library. You can also take advantage of SharePoint’s workflows to route the forms, but the forms must be filled out using the desktop Filler. If you have SharePoint 2010 Enterprise Edition, you get all of the same benefits as Foundation, but you may also publish your forms as Web forms – which means that each user in your organization does not need to have the desktop Filler installed to fill out a form. There is an Enterprise CAL license required for each user that will access the SharePoint 2010 Enterprise server. Of course, the license also grants you rights to the other SharePoint Enterprise features, and the cost is offset by the fact that you do not need to purchase the Filler product for every desktop. It is worth mentioning, that some of the Office 365 plans also allow for InfoPath forms to be published as Web forms.

There are two types of forms on SharePoint 2010 Enterprise Edition. Form Library Forms allow for one or many related forms to be served from and stored in a single document library on SharePoint. These forms are often used in conjunction with SharePoint workflows for routing and approval. List Forms, new to SharePoint 2010 Enterprise Edition, allow an InfoPath designer to customize the look and behavior of the data entry forms of any SharePoint list. Using InfoPath to brush up these forms allows a non-developer to do more creative and robust things that were previously only possible for developers.

That is enough background to get us started. I will provide more helpful tips as we work through some of the solutions. I will introduce the first form solution in my next post.

A Focus on InfoPath

Thirty-three months ago I first covered SharePoint on our blog. Since then I have presented InfoPath 2007 and 2010 sessions at a few regional technical conferences. Yesterday, I presented InfoPath to around seventy local professionals at an invitation-only event. As the product has evolved, so has the interest, so has the local user base, and so has the number and variety of our projects. InfoPath is one of the driving forces behind SharePoint’s unprecedented growth.

InfoPath brings to the table:

• Rapid development of electronic forms for non-developers
• Rules based business process automation
• The ability to extend the forms using .NET programming if required
• The inherent ability to gather data to SharePoint for detailed analysis

There are definitely some caveats to keep in mind when implementing InfoPath forms. For your run-of-the-mill, rules-based forms for automating internal business processes, you will find InfoPath is a great fit and a piece of cake. For programmer-enhanced forms, you will need to manage trust levels and get an administrator’s help with publishing the form. And anonymous forms, well, they present numerous challenges that I will guide you through in upcoming posts. What if you want to create a form that gathers data to two separate SharePoint lists? InfoPath does not do that out of the box, but it is possible.

Because of the growing demand for InfoPath, and because of the new InfoPath 2010 capabilities in SharePoint 2010 Enterprise and Office365, I am going to spend some time focusing on InfoPath solutions for SharePoint. I personally believe that this is one of the more valuable, but often overlooked features of SharePoint. My goal with this upcoming series of posts is to hear you say “I wish I had known that sooner!”

A Big Week for SharePoint

Earlier this week, Microsoft announced the release of SharePoint 2010 Service Pack 1. Visit the Update Center on TechNet to learn more about this update and to keep up with updates for other Microsoft products. If you have SharePoint 2010 Foundation, you will want to install SP1 for SharePoint 2010 Foundation, then SP1 for SharePoint 2010 Foundation Language Pack if applicable.  If you have SharePoint 2010 Server (Standard or Enterprise), you will want to install SP1 for SharePoint 2010 Foundation, the SP1 for SharePoint 2010 Foundation Language Pack (if applicable), SP1 for SharePoint 2010 Server, and SP1 for SharePoint 2010 Server Language Pack (if applicable).  After you install SP1, you should also Install the June 2011 Cumulative Updates. (Also see http://blogs.technet.com/b/office_sustained_engineering/archive/2011/06/29/sharepoint-2010-sp1-and-the-june-cumulative-update-for-sharepoint-2010.aspx)

As usual, the Office 2010 updates were released in conjunction with the SharePoint 2010 updates. It’s a great idea to update Office, too, especially if you use the SharePoint 2010 desktop products that are contained in the Office 2010 suites.

Last Friday (June 24), our Evansville SharePoint Users Group co-sponsored a Windows 7 Phone “Hackathon.”  It was a great time and there were some interesting app ideas.  I bring it up, because it was great to see the integration included with SharePoint, Office, Dynamics CRM, and Office 365 in the upcoming Windows Phone 7 update code-named “Mango.”

Speaking of Office 365, it was officially launched to the public this week! It is not a bad deal for individuals and companies of all sizes. It is all written on SharePoint, so you can customize it using familiar SharePoint tools. Take a look at Office 365.  What a week!

SharePoint 2010 Service Pack 1 Coming in June

Microsoft's SharePoint Team has announced the release date of Service Pack 1 for SharePoint 2010. Look for the release in late June of 2011. A couple of my favorite features: Site Recycle Bin and the return of StorMan.aspx. With Site Recycle Bin, administrators will be able to recover sites and site collections that were accidentally deleted by authorized users much like the way documents and lists are recovered. StorMan.aspx (Storage Space Allocation) will allow you to see which large documents and document libraries are consuming your disk space. You can read more about the service pack on the SharePoint team's blog at http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=973.