SharePoint Designer Considerations

I had this drafted some time ago and never got around to finishing it.

Internally at RDA we had a fantastic discussion on using SharePoint Designer and some best practices around it. First you must understand the primary target audience of SharePoint Designer. It is meant to be a tool for power users who aren't comfortable writing code. If they are not technical and have not resources at who can use Visual Studio, SharePoint Designer is an acceptable choice. However if there are people who know .Net on staff using Visual Studio is more preferable. We have seen a tendency in power users or developers shy away from using Visual Studio because it can become a little complicated to package up and deploy things correctly if you do now know what you are doing. We still recommend that using SharePoint Designer should be kept to a minimum.

A client had some thoughts on SharePoint and was looking for our opinion on it. Below are the questions and paraphrased responses to them.

1) Con: Code stored in database - although there is caching, performance might suffer

Fact is pretty much everything is stored in the SharePoint database, so there really aren't any performance issues. This was a little bit of an issue with SharePoint 2003 but not an issue with SharePoint 2007.

2) Con: No real deployment path with presentation, content, and code mixed together

SharePoint Designer does not facilitate deployment across different environments at all. This is not because the content is all mixed together; it is because SharePoint Designer changes are saved directly to the database. You cannot package things up as a solution or feature and then deploy it to another environment. As well, the changes are not re-useable. Now there are ways of getting around this however they are not supported out of the box and probably not supported by Microsoft.

3) Pro: Good for creative design for styling masterpages

SharePoint Designer is a good tool for making changes to themes/css/master pages and being able to visually see the changes. Remember that the changes to themes/css/master pages can be easily lost when switching between themes or reverting to a definition.

As well, when using SharePoint Designer for master page development you will only be to do this on a site by site basis. Remember that the master page is now customized (unghosted) so the change will have to be applied to each and every site collection which can become painful.

For those who do not know what customizing (unghosting) means, basically there are files that are located on the server where SharePoint server is install (commonly referred to as the 12 hive). Files that can be found there are features, templates, master pages, user controls, etc. When a page is referenced by a user the master page definition on the file server is meshed with content from the database and then displayed. After a master page has been modified by SharePoint Designer, the master page from the 12 hive is copied into the database with the modifications. Then when users reference the SharePoint page, the master page in the database will be meshed with content instead of using the master page on the 12 hive.

It is highly recommended to use Visual Studio for master page development.

4) Pro: Good for prototyping

Yes, SharePoint Designer is a great prototyping tool. It is great for trying to figure out how all the little attributes are working with each other CAML. It is great to use in a development environment.

5) Con: Does not scale well as functional complexity increases

SharePoint Designer does not suffer from scalability challenges; it is just limited in what you can do. It is scoped to doing simple workflows, DataViews, and page layouts, for instance.

6) Pro: Power users can use it

I mentioned this earlier as power users can use this tool to make tactical changes to SharePoint if technical resources are not available to do something in Visual Studio. SharePoint Designer is packaged as part of Office and is the replacement of Microsoft FrontPage.

Conclusion

SharePoint Designer does have its place; however because of the limitations are deployment and re-usability of its solutions, we highly recommend staying with Visual Studio. There are some challenges learning how to deploy web parts from scratch but once you learn the internal workings of how to do these sort of things, you will much better off in the long run.

We also do not recommend giving SharePoint Designer access out to every day users. One of the biggest challenges we have seen with SharePoint migration is heavy Front Page changes which made migration difficult. Do we expect this to be a problem with future SharePoint migrations, hopefully not. However we believe that if you cannot successfully package and deploy something across development, staging and production environments, it should probably not be deployed at all.

Fixing Process Instance XML

A colleague of mine dropped me an email asking about how to resolve a production issues. He has an InfoPath form where a destination user is selected in it. Then when it got to a point in the process where that field needed was used by the destination rule it failed. The reason was because the destination user had left the company and their Active Directory account has been deleted!

He needed to recover the process instance and did not want to tell the business users to start the ticket over again. We considered modifying the process code that was deployed but it was more of a hack. The only other solution was to modify the data in the database. We looked around the database, and were able to find the tables and fields where the XML was stored. However making any sort of changes in this manner would be unsupported by K2 plus we did not want to mess anything up since this is production.

The solution was to write a little snippet of code in a command line application to make a connection out to the server and modify the XML via the API. We went to the Process Overview report, got the process instance number, open the process instance, modified the XML, set it back into the process instance and updated it. The following is Joe Loftus's solution, nice, simple and supported…

using System;
using System.Collections.Generic;
using System.Text;

using SourceCode.Workflow.Client;
using System.Xml;

namespace FixK2InfoPathData
{
    class Program
    {
        static void Main(string[] args)
        {
      
            //TODO: Replace Constants with command line args
            //TODO: Add third argument which is a path to a repaired xml file to reset the process instance xmlfields value.

            //Set to the correct Server Name
            const string SERVER_NAME = "SERVER NAME";

            //Set to the correct process instance ID
            const int PROCESS_INSTANCE = 7;

            //Create connection using current credentials (the creds must have access to the process)
            Connection cn = new Connection();
            cn.Open(SERVER_NAME);

            //Open Process Instance
            ProcessInstance pi = cn.OpenProcessInstance(PROCESS_INSTANCE);

            //Get InfoPath xml data
            string xoldData = pi.XmlFields[0].Value;

            //fix InfoPath xml data
            XmlDocument doc = new XmlDocument();
            XmlNamespaceManager nsMgr;
                     
            doc.LoadXml(xoldData);

            //configure Namespace manager
            nsMgr = new XmlNamespaceManager(doc.NameTable);
            nsMgr.AddNamespace("my", doc.DocumentElement.GetNamespaceOfPrefix("my"));

            //Fix the offending elements here
            doc.SelectSingleNode(
                "//my:myFields/my:Approvers/my:ITTFinanceApprover1",
                 nsMgr).InnerText = "BlackPearlManager";

            //Set the repaired InfoPath Xml back to the process instance
            pi.XmlFields[0].Value = doc.OuterXml;

            //Update the Process Instance
            pi.Update();

            cn.Close();
        }
    }
}

InfoPath and ASP.NET Development Considerations

This month at the K2 user group we did a presentation on understand the differences between InfoPath and ASP.net. This decision has been a pretty heavily debated thing in my company, even outside the scope of K2. InfoPath 2003 was pretty good but the licensing issues around it being installed on every client machine became challenging given it was part of MS Office Enterprise. Then with InfoPath 2007 they now allow for the forms to be web enabled however there are several limitations around them.

I believe InfoPath is a very strong tool which when used for the right scenario is better than ASP.net. However ASP.net allows for full control and more complex applications. NOTE that I say "applications". InfoPath itself is a "forms" product that when used with product like K2 blackpearl "applications" can be built. Using InfoPath and K2 blackpearl (or K2 blackpoint) now make development of InfoPath bearable. Then next challenge is to understand the user interface requirements and business rules that need to be implemented. Typically if the application is going to require tons of CRUD operations, grids and dynamic user interfaces InfoPath will fall flat. However if the application is just presenting some information, with some light weight CRUD operations using K2 SmartObjects, using SharePoint/InfoPath can make really strong solutions.

Here are the bullets from the presentation.

Selection Criteria:

• Worker skill set
• System integration
• Time to production
• User interface requirements
• Need to integrate with SharePoint
• Business logic & code
• Deployment

InfoPath Pros:

• Improvements over 2003 (browser option, actions are handled outside of the form, multiple form templates & views can be used).
• Quick to develop and deploy, based on XML. When I say quick; we me quick. The level of effort to create InfoPath form is significantly smaller and a wider span of designers can now build them.
• Easy to hook into most Web services.
• Disconnected / Offline use.
• InfoPath does force developers to write pretty decoupled applications in that much of the user interface rules will be captured in InfoPath and all business logic will be pushed to a business/service layer.

K2 InfoPath Pros:

• K2 allows for true business processes to be built around InfoPath instead of embedding the logic in .Net managed code, script or SharePoint server events.
• XML captured becomes part of the process and is accessible through the K2 Object/Context browsers. There is no need to build up functionality to get data and use it within the K2 process. However almost all of that has been alleviated with K2 SmartObjects.
• K2 SmartObject integration with the InfoPath form itself.
• InfoPath forms become part of the K2 project.
• Can be used in server events for XML storage.

InfoPath Cons:

• If using the InfoPath client, it must be installed on every user's computer that will participate in the workflow.
• Browser-based forms, cannot use the full set of controls that are available in the InfoPath client application (InfoPath 2007 features that are unavailable in InfoPath Forms Services and Web browser compatibility in InfoPath Forms Services).
• Browser-based forms require MOSS enterprise licensing. Just trying to use Form Services with WSS is not any cheaper from a cost perspective.
• Browser-based forms are difficult to configure for non-AD authentication (FBA).
• Browser-based forms are hard to control number of postbacks browser-based forms make to server. Things like using AJAX and Flash are not supported.
• Fully-trusted forms, difficult barrier in some environments.
• Debugging and troubleshooting is limited, can be difficult for web enabled forms.
• Hard to control look and feel, and state of controls (enabled / disabled). This is even more challenging with web enabled forms. It is very hard to make it follow corporate branding requirements when published over a public internet site.
• Event model for InfoPath is based on the XML document, not the user interface. This requires a different way of thinking when using custom code.
• Controls bound to secondary data sources can't be easily validated (InfoPath limitation).
• Little support for handling multiple languages via resource files.
• Can only be used with an InfoPath Integrated process -- can't use with a SharePoint integrated process.
• Kerberos issue still not fixed with MOSS SP1 (MS hotfix reference: KB941470 - more detail information).

K2 InfoPath Cons:

• Highly complex browser-enabled forms (lots of data connections, code behind, larger in size) may fail to convert when deployed.
• File attachments can make the form huge and cause the size of the K2 database to grow significantly.
• If you have to go into code you probably should avoid InfoPath unless you're really comfortable – forms with code not officially supported in K2 (read this for help).
• Form file left in SharePoint library (can be changed in Advanced Mode but only for client forms -- browser-enabled forms will always remain in the library).

ASP.NET Pros:

• Flexibility.
• Standard ASP.Net + Workflow.Client and SmartObject.Client namespaces, typically.
• Better control of session state for large forms or attachments.
• No Licensing considerations other than Windows Server.
• Standard debugging.
• Outside of the K2 project.

ASP.NET Cons:

• Longer development cycles.
• Custom code means more complex maintenance and management of projects.
• Outside the scope of K2 project -- must be deployed separately and kept in synch with K2 project.
• Can't be used with SharePoint integrated workflows.

InfoPath Design Considerations

• Do you need managed code? If you have lots of it, use ASP.net.
• Use ASP.NET pages for wider audience and then use InfoPath form back office business processes. It is possible in K2 to have processes that using both InfoPath and ASP.net client events.
• How many views do you need?
• Having lots of fields in a view is not a problem unless every field has a validation and conditional logic rule.
• Store data in the InfoPath form?
• Do not pollute your main data source.
• Working with required fields across views?
• Chaining multiple InfoPath forms into a single process.
• Understand Destination Plans and how XML is managed by K2?

Conclusions

Most of my K2 implementation to date has been successful InfoPath solutions. This all comes down to understanding the scope of the implementation and selecting the right tool. I know I am betraying my app dev roots when I say InfoPath is great because it is hard to get the level of control and customization you want with ASP.NET. The value proposition with InfoPath (with K2 blackpearl) is that it allows for very rapid application development and deployment with a large base of developers. Developers with a good MIS background can do this and do not require a CS background. InfoPath applications require less engineering and have a greater maintainability potential. However InfoPath forms just cannot handle complex business rules or multiple screen CRUD interfaces.

We do not that Microsoft is making a significant investment into InfoPath Forms Server in the next generation of SharePoint and MS Office. Like Excel Services, it is their first release of the technology. I am pretty confident the gap will be closed.

July 8th, 2008 User Group ASP vs InfoPath

Update 4/16/2009 - here is the recorded presentation

I will be supporting a round table discussion with the K2 User Group based in Texas on July 8th. I will be calling in J

If you want to attend in person, please contact Pattie Albright

Here is the information on the session:

Chris Geier & Mike Tally from K2 and Jason Apergis from RDA Corporation
will be doing a round table discussion on the differences, benefits, pros and cons of InfoPath and asp forms, when to use one or the other, and what works with the InfoPath client and what works with InfoPath in form services

Chris Geier will also be demonstrating a new offering from K2. K2 blackpoint is for SharePoint users that want the ability to build workflows and process-driven applications quickly – without code, without complexity.

With an easy-to-use Office-style designer, create powerful and flexible applications that increase the efficiency of your business.

K2 blackpoint, a subset of K2 blackpearl features, provides unparalleled capabilities and affordability. It also offers an upgrade path so that organizations can grow their investment and add complexity over time, if needed.
For more information, go to http://www.blackpoint.k2.com/.

Meeting Agenda: US Central Time
11-11:15 Networking/Refreshments
11:15-11:30 Announcements/Intros of New people
11:30-11:45 Tips & Tricks
11:45-12:45 Technical Presentation
12:45-1:00 Meeting Wrapup

For Virtual Attendees:

Note: please keep your phone on mute until you are ready to speak.

Audio Information

Telephone conferencing
Choose one of the following:

• Start Live Meeting client, and then in Voice & Video pane under Join Audio options, click Call Me. The conferencing service will call you at the number you specify. (Recommended)
  
• Use the information below to connect:
  Toll-free: +1 (888) 296-6500
  

  Toll: +1 (913) 227-1219
  

  Participant code: 224648
  

First Time Users:

To save time before the meeting, check your system to make sure it is ready to use Microsoft Office Live Meeting.
Troubleshooting
Unable to join the meeting? Follow these steps:

1. Copy this address and paste it into your web browser:
   https://www.livemeeting.com/cc/scna/join?id=4FM7QS&role=attend&pw=t%3A%3D2P%3BW
   
2. Copy and paste the required information:
   Meeting ID: 4FM7QS
   
   Entry Code: t:=2P;W
   
   Location: https://www119.livemeeting.com/cc/scna
   

BDC Crawl Missing Security Identifier

SOLUTION - We rebuild the SSP

Error: I ran across the interesting little error with the BDC which I did not expect. You may know that in the Share Service Provider (SSP) you need to give user permissions to the BDC. Well you may come across this error when you index a content source that is using the BDC:

The parameter is incorrect. (Could not create a security identifier for the identity 'XXX\YYY'. This identity may have been deleted.)

Symptoms: If you view the BDC content source crawl log there will be no errors however this error will be listed as an error in the Crawl Settings for search itself. This error will be created for every record that was indexed.

Cause: Well I found out that the user account in question had been deleted from Active Directory.

Resolution: To resolve the issue I had to remove the user account from the Business Data Catalog permissions as well as from all the BDC applications and entities permissions. Once I did that, run a full index, and everything will work.

Background: The first question I had was why are there no errors on the BDC content source? Knowing what I know about the BDC I suspect this is what occurred. First, there are connection errors to the BDC data source (SQL Server in this case); for instance there were no access issues to the database or the database objects that were being used in the Application Definition File (ADF). Second, knowing this I can only assume there is an error with the way the index is being built. Basically the error is in reference to the validation of Active Directory account that has permissions to the BDC application and its entities.

Deeper Dive: Digging a little deeper the following is the root of the issue. Many developers create an ADF using a tool or by hand and may not add an AccessControlList node. These nodes get added to the ADF when permissions are added in Central Administration. The AccessControlList can be added to both the LobSystem and Entity nodes.

The AccessControlList nodes must be added to the ADF prior to it being crawled. This is why if an administrator goes to Central Administration and gives a user or a group permission to the BDC, they must do a new full index of the BDC content source.

The following is an example the AccessControlList. In this example, account XXX\YYYY is being given full rights. This XML can be added to both the LobSystem and Entity node.

<AccessControlList>
  <AccessControlEntry Principal="XXX\YYYY">
    <Right BdcRight="Edit" />
    <Right BdcRight="Execute" />
    <Right BdcRight="SetPermissions" />
    <Right BdcRight="SelectableInClients" />
  </AccessControlEntry>
</AccessControlList>

Avoiding this Error: The error is occurring because the account XXX\YYYY does not exist in Active Directory account. It is recommend that permissions through a Active Directory group to minimize the occurrence of this error.

K2 blackpoint Questions and Answers

Here are some common questions that you may ask about K2 blackpoint.

Q: We already have blackpearl does blackpoint fit into the picture?

A: All the functionality in blackpoint will be rolled into blackpearl. Blackpoint is targeted toward organizations that want workflow beyond what SharePoint workflow can provide but may not need all the capabilities, such as Visual Studio and SmartObjects that blackpearl includes.

Q: Can I use blackpoint with WSS, Microsoft Forms Server and MOSS?

A: K2 blackpoint can be used with either Windows SharePoint Services v3 or Microsoft Office SharePoint Server. Microsoft Office Forms Server to provided for web-enabled InfoPath forms.

Q: Can I use SharePoint 2003?

A: SharePoint 2003 is not supported.

Q: Can I use blackpoint on a load balanced SharePoint farm?

A: Yes, K2 blackpoint can be used to provide workflow capabilities for any number of SharePoint web front-ends in a SharePoint farm.

Q: What servers in my SharePoint farm do I have to install this on?

A: The K2 blackpoint server components can be installed on a non-SharePoint server or on any of the SharePoint servers depending on how the farm is being scaled. On each SharePoint server, a set of web services is installed to facilitate communication between the SharePoint server and the K2 blackpoint server.

Q: Will I need administrative rights to install?

A: Yes, the install requires a user with local administrator rights on the server.

Q: Will this install anything on my SharePoint central administration site?

A: Yes, the K2 blackpoint install adds a tab to the Central administration site that provides access to administrative pages and tasks for managing the integration between K2 and SharePoint.

Q: Do you do solution or feature deployment?

A: Components such as our K2 web parts are deployed via solution deployment. Other components, such as our SmartObject creation capability are deployed as features and can be activated on a per site collection basis. K2 blackpoint processes are deployed to the K2 blackpoint server and do not reside directly on the SharePoint server.

Q: Can I extend the templates in K2 Studio?

A: No, existing templates in K2 Studio cannot be extended, but custom templates can be built and surfaced within the K2 Studio environment.

Q: Can I get to the code in K2 Studio?

A: No, code-level access is not available in K2 Studio.

Q: Do I have to use a process portal to manage my process?

A: Yes, K2 blackpoint makes use of Process Portals to provide access to all administrative and management tasks related to processes

Q: Microsoft says SharePoint has workflow, what does this do that it does not?

A: K2 blackpoint extends on the out-of-the-box SharePoint workflow capabilities by including a drag-and-drop Office-style process designer, functionality to manage all aspects of your SharePoint environment including lists, libraries and sites, a more in-depth set of reporting capabilities and improved task management capabilities such as delegation and redirection.

Q: Why wouldn't I just want to use built-in workflow in SharePoint?

A: SharePoint workflow provides basic process capabilities for managing documents and list items in SharePoint. However, more complex tasks, such as complex routing rules, escalations or managing lists, libraries and sites in SharePoint can be very difficult and in most cases requires a developer to write code to provide the functionality. K2 blackpoint provides all of these capabilities and more out of the box, without the need to write any code.

Q: Can't I do all this in SharePoint Designer?

A: No, many more complex tasks require a developer to write code to provide the same functionality that is included out of the box in K2 blackpoint. The K2 blackpoint comparison document compares features that are available in SharePoint Designer compared to K2 blackpoint.

Q: How does K2 blackpoint scale?

A: K2 blackpoint can be scaled to support multiple SharePoint servers. K2 blackpoint does not have to be installed no every SharePoint web front end of the farm, it is server unto itself. They can be clustered on their own dedicated resources, load-balanced, and be a highly available workflow environment.

Q: Can I upgrade to K2 blackpearl later?

A: Yes, when your workflow needs become more complex over time K2 provides the ability to easily upgrade to K2 blackpearl.

June K2 blackpoint Community Webcasts

K2 is providing some community web casts on K2 blackpoint. It is open to anyone. If you want to see it in action and ask some questions here is a place you can do it in. No upfront information needs to be provided. Just attend and check it out!

Tuesday June 17, 2008 11:00am-12:00PM CST (GMT-06)

Subject: blackpoint Webcast
Start Time: Tuesday, Jun 17, 2008 9:00 AM PDT
End Time: Tuesday, Jun 17, 2008 10:00 AM PDT
Attendee URL: https://www.livemeeting.com/cc/scna1/join?id=7CND7W&role=attend&pw=w%3B26H9%26Pd
Meeting ID: 7CND7W
Attendee Entry Code: w;26H9&Pd
Location: Live Meeting
Toll free: +1 (888) 233-7876
Toll: +1 (719) 234-7876
Participant code: 733479

June 19th meeting from 6pm – 7pm Central Time. (GMT -06)

Subject: blackpoint Webcast
Start Time: Thursday, Jun 19, 2008 4:00 PM PDT
End Time: Thursday, Jun 19, 2008 5:00 PM PDT
Attendee URL: https://www.livemeeting.com/cc/scna1/join?id=CK67B6&role=attend&pw=w%3B26H9%26Pd
Meeting ID: CK67B6
Attendee Entry Code: w;26H9&Pd
Location: Live Meeting
Toll free: +1 (888) 233-4650
Toll: +1 (719) 234-7876
Participant code: 733479