Appian BPM is a workflow tool that allows you to model Business Processes and execute the in a repeatable fashion. Tools like this have broader tooling and support when compared to the Microsoft-only tools like SharePoint Designer and Workflow Foundation.

Appian currently offers an integration toolkit with SharePoint. I've listed the capabilities and design implications below.

1. Infrastructure
1. The Appian Integration kit creates their own web services to supplement what is offered by Microsoft out of the box. This requires you to install something on the web servers so the Appian-provided web services can use the SharePoint dlls.
2. The integration works with both WSS 3.0 and MOSS 2007.
3. The integration toolkit currently supports Appian 5.7. Appian 6.0 support will be released in the first half of 2010.
4. To support single-sign on between SharePoint and Appian, this approach requires Appian to be installed on a Windows server rather than a Linux server.
2. Workflow
1. The integration toolkit offers canned tasks for working in SharePoint like creating tasks, creating and deleting sites, and customizing permissions. These activities lend themselves to automating parts of your SharePoint governance plan. Appian discusses this use, and I think it provides an excellent solution for managing "site sprawl".
2. Appian does not provide an out of the box feature to start a workflow from content in SharePoint. (eg. starting an Appian workflow from a new document upload). This capability requires a developer to use the Appian webservices from a SharePoint event handler.
3. Appian also provides a web part to see Appian tasks and reports in a SharePoint web part. These webparts link back to the Appian server however, so users will not work only in the SharePoint environment. This approach mirrors what I have seen from other BPM providers as well.
4. Appian provides a document picker if you choose to use SharePoint as a document repository and use Appian as the workflow environment.

I've been building document and form centric web applications lately with SharePoint and InfoPath Forms Services. As you can imagine it's a nice fit, however, one of my requirements has been to strip out all of the SharePoint options for external users, but leave them for internal users who are used to the SharePoint look and feel.

I've been using jQuery to identify areas that need to disappear and making use of the toggle() option. It's quick, I'm not relying on it for security, and it's really nice. I'm going to say that any time you reach for SharePoint Designer, you should use jQuery in a master page or Content Editor Web Part instead.

However, I need to make changes in this daily, and I'm hiding all of the links that would let me edit the page. So I've been relying on the following querystring to jump straight to edit mode. I've trolled through my browser history enough, so now I'm writing it for myself, and for all of you as well.

?PageView=Shared&DisplayMode=Design

I remember the first time I saw Google Suggest, it would run the search in real-time and provide a dropdown with possible queries. One of my teammates always joked about making software with one button that would automatically know what you wanted to do. I showed it to him and suggested that Google was getting closer.

I've been working on my presentation for CapArea.NET about jQuery and SharePoint and I knew I would have to demo this search as you type code. The proof of concept was created by Jan Tielens, and the solution was fleshed out by the team at muhimbi. It overrides the default search box and starts returning results as you type. It's super cool and it's all HTML and JavaScript, it's not a web part, and there are no assemblies. Just add this to your master page, and you get a search upgrade.

While I was testing it I realized one thing. This search is using the keyword search. That's not too helpful since no results get returned until you spell out the entire keyword. I ended up using the LIKE operator against the Name and Description to get a much more helpful search that brings up results while you are still spelling the keywords. It required two changes to the javascript.

1. Changing the query to use the FullText rather than the keyword query.
2. Changing the jQuery selectors as the return values are different for the different query types.

In addition to this I changed the path to jQuery to load from the 12 hive, and I added some protection against SQL injection in the query.

Update 9/26/2011: David Lozzi has extended this code (and code contributed by several others) to create the Search as You Type Project on CodePlex. I would encourage all of you to take advantage of his hard work with this great project.