PowerPivot Attack!

•February 3, 2010 • 2 Comments

There is considerable interest in implementing BI solutions between multiple OLAP providers – SQL Server Analysis Services & Oracle Cubes for example.  In order to demonstrate the tremendous integration advantages of Microsoft BI, I recently took SharePoint 2010 and PowerPivot from install-to-PowerPivot Gallery!  Here are some interesting facts and the walkthroughs:

Excel 2010 Add-In

  • Think of PowerPivot as two separate installs/environment add-ins:  Excel 2010 & SharePoint 2010
  • PowerPivot is a FREE FREE FREE Add-on to Office!  Potential cost savings are INCREDIBLE (and very uncharacteristic of Mr. Softy!)
  • Excel 2010 Add-in allows you to pull data from multiple sources (SQL Server, Excel, Data Feeds, Access, OLAP) and create relationships between them utilizing PowerPivot.
  • Pulling data from SQL Server Reporting Services is just slick!  We scheduled SharePoint 2010 to produce a data feed off of an existing SSRS report.  Then we setup PowerPivot to consume the feed.  PowerPivot basically allows you to re-mash the data sources within a report and with other reports/data sources.  Extremely powerful!
  • Excel 2010 is required for the PowerPivot POWER users but no Excel client is necessary to view and utilize PowerPivot through SharePoint 2010
  • PowerPivot OLAP integration is something to watch.  Building relationships between say SAP-Oracle and SQL Server Analysis Services could be very powerful – good article.  While you’re waiting, use the SSRS data feed.  SSRS has tons of hookins to various data sources – our most recent experiment was with SAP XMLA.
  • With Excel 2010 Vertipaq compression technology, you can manipulate 100’s of MiLlIoNs of rows of data in your puny pc RAM
  • Go to powerpivot.com and you can see quite a few well made demos and tutorials for using the Excel Add-in

SharePoint PowerPivot Service Application

  • SharePoint 2010 allows you to view the Excel Workbooks and DYNAMICALLY refresh the data
  • PowerPivot for SharePoint 2010 requires an SEPARATE SQL Server Analysis Services + SharePoint install for every PowerPivot server you wish to create
  • AGAIN, no Excel client is necessary to view and utilize PowerPivot through SharePoint 2010
  • PowerPivot Gallery is tricked out document library that utilizes Silverlight to thumbnail preview workbooks
  • In Central Admin, Report Center allows you monitor PowerPivot usage
  • There’s also a PowerPivot Site that sets up the PowerPivot gallery and other features (similar to Document Center)

Setup

  1. Download and install SQL Server 2008 R2 on an existing SharePoint 2010 WFE.  Use this PowerPivotGeek article for setup.  These technet articles are also great for background and HIGHLY recommended.
  2. Download and install the BI data set provided by Microsoft.  These are GREAT for demoing a tremendous amount of data (millions of rows for the famous Contoso).
  3. Download and install the PowerPivot Add-in for Excel 2010. 
  4. Watch this cheesy but very informative demo of PowerPivot to get a good overview of the capabilities.
  5. BUG:  At the time of this writing, PowerPivot there is a bug that is characterized by “could not load embedded data“.  Basically after closing your workbook, you will not be able to reopen it or refresh the data in SharePoint.  As a work around, refresh your data sources often, especially after a relationship is created/modified.  I’m in the habit of doing it before every save.  It’s smoooooth sailing from there.

 As a final thought, I would like to find out if PowerPivot utilizes the standard Excel data source import or if it has it’s own proprietary import.  If it utilizes Excels, perhaps ANY multidimensional data source can be related.  Obviously, you would have to install the OLAP provider on the SharePoint server.  Sounds like fun – especially with bEtA owt!

Update:  Installed Office Web Apps and PowerPivot does not appear to be compatible with Excel Web App at this time.

MASHUP: SharePoint 2010 BCS + WCF + SAP

•January 22, 2010 • 3 Comments

Recently went through the process of pulling data from SAP into SharePoint 2010 via BCS and WCF.  Very powerful stuff but ooooh, the pain, THE PAIN!  So I thought I’d share my experience to mitigate the unpleasantries you may experience.  To sum up the basic steps and design:

  • Develop the .NET-to-BAPI RFC using the SAP Connector 2.0 in VS 2003/XP VM
  • Migrate the entire project to VS 2010 in Windows Server 2008 R2
  • Add logic (DataTable) and wrap in WCF Service
  • Deploy WCF to IIS 7.0
  • In SharePoint Designer 2010, configure an External Content Type to consume the WCF service
  • Configure content type in a SharePoint 2010 BCS List

Admittingly, the SAP process was the most difficult (and sinister!)  Lots of help was available in the SharePoint community however.  Enjoy!

1.  Setup the XP VM

  • Required because VS2003 installs failed in Windows Server 2008
  • Install VS 2003
  • Install SAP .NET Connector 2.0 – this is the real culprit.  This connector provides the BAPI explorer ONLY in VS2003.  SAP is FINALLY working on the 3.0 connector which will hopefully integrate into a VS2010. 

By the way, you can opt to use the BizTalk Adapter Pack and forgo the VS2003/XP steps.  The adapter pack is designed to be used with WCF.  However, at the time of this writing, Microsoft recommends a suggested retail price of $5000+ per CPU.  Another cheaper alternative is ERPConnect by Theobald Software.  ERPConnect integrates at the assembly level – therefore it can be integrated into any .NET platform – ASP.NET, WinForms and not just WCF.

2.  Setup VS2003 – follow this example for developing a BAPI interface.  Stuff you’ll need from your SAP gurus.

  • System Number 
  • SystemID 
  • Client
  • App Server host  
  • Username
  • Pass

3.  VS 2010 Setup (Separate VM)

  1. Recommend NOT using XP 32bit for VS2010.  Problems with GUI in MY VM.
  2. After setting up the BAPI function calls in VS2003, copy the entire project to VS2010.
  3. If in a separate VM, install SAP GUI to ensure dlls are available for the connector.
  4. Create a VS2010 WCF Library Project – Choose .NET 3.5!!
  5. Import the VS2003 project as an existing project.  Perform the upgrade conversion.
  6. Add a reference to the WCF Library project for the:
  • SAP.Connector.dll
  • SAP.Connector.Rfc.dll
  • Your custom developed SAP dll from the new converted VS2003 project.
  • System.Web.Services 

7.  Follow this blog for setting up/developing/deploying your WCF to IIS.

  • Using Process Explorer, I determined librfc32.dll needs to be in the environment variable PATH.  You can get this from SAP GUI or if you’re brave, the SAP Market Place (developer purgatory).  I only mention it because I’m sure you don’t want to install SAP GUI on a production server.  Also, for development in 64bit environments, you should install the 64bit librfc32.dll in the Windows\System32 folder and the 32bit librfc32.dll in the Windows\SysWow64 folder.  Here’s a good link on finding the librfc32.dll in SAP Market Place.
  • Install SAP.Connector.dll and SAP.Connector.Rfc.dll in the GAC.
  • Enable 32 bit Web App compatibility on the WCF App Pool (located under Advanced Settings).
  • Ensure the 32 bit Web App compatibility is DISABLED for ALL SharePoint 2010 web apps
  • Ensure the .NET 4.0 ISAPI filter is removed from all of your existing SharePoint 2010 web apps.  

8.  Follow this blog for setting up and connecting to your BCS via an External Content Type in SharePoint Designer 2010.

  • PAY ATTENTION to your base address in your web.config.  It needs to match the URL you use in when connecting via SD.
  • PAY ATTENTION to connection option of using METADATA EXCHANGE.  Remember the “/mex” and to choose “Metadata Exchange” for the Metadata Connection Mode.  
  • URL WEIRDNESS:  Did I already mention to pay attention to your base address??  In the web.config on my PRODUCTION server, I specified http://myservername:8888 for the base address.  However, SharePoint Designer could not find the end point until I used a fully qualified domain name:  http://myservername.mydomain.com:8888.  Note that I did NOT have to use the FQDN in my local VM for testing!
  • Also, I noticed the BCS Data List does have paging built in.  HOWEVER, it does a full pull from the source for each page.  That could get EXPENSIVE if you have a lot of data.

WCF Considerations

1.  Read article comparing WCF to old way of doing Web Services.

  • It’s DataContractSerializer is 10% faster using the XMLSerializer
  • Versioning tolerance (DataContractSerializer only)
                 – Missing members (deserializes defaults – null, 0 and etc)
                 – Adding fields does not break interface
  • Seemless support for other bindings:  MSMQ, TCP, Named Pipes, Dual HTTP and etc
  • Asynchronous call (or callback) support
  • Takes advantage of Windows Activation Services

2.  Microsoft provides a great tutorial here.
 
3.  Use VS2010 “WCF Library” projects to enable portability
 
4.  Use a separate App Pool for WCF Services
 
5.  Use a separate virtual directory OUTSIDE of SharePoint
              – web.config modifications
              – patching of SharePoint

6.  Also a good article on deployment best practices

7.  WCF supports WS-I Basic Profile 1.1 via the BasicHttpBinding class.

Workflow Automation with PowerShell

•January 5, 2010 • 2 Comments

Workflow upgrades can become a HUGE pain.  Often, the larger the number of running workflows, the larger the pain.  Manual restarts or custom code may be the only solution, both of which are prone to human error and can become expensive. 

From my last post, I prescribed two painkilling design principles that will allow you to automate workflow upgrades:

  • Make your workflows disaster recoverable
  • For every change/upgrade, restart the workflows

Now we can use PowerShell to:

  • Find all workflows running on a given list
  • Stop the existing workflows
  • Start the latest version
  • Report any errored workflows

I’ve included the steps I used to achieve this below for nooobs.  Devs and Infra-dweebs may find PowerShell very refreshing.  It really tends to empower shell-scripting, task automation and development skills you’ve acquired.  For Devs, the hard part will be thinking in terms of AUTOMATING TASKS.  For infra-dweebs, the challenge will be in becoming familiar with the SharePoint Object Model.  Hopefully, the references below will assist both:

1. POWERSHELL INSTALL:  Do nothing yet, just read and install.  Seriously, this is a time saver.

  • Great Getting Started article. 
  • You will need to install Windows Management Framework.  It will require a server reboot.  Don’t forget to set the “Execution Policy”. 
  • PowerShell 2.0 is out at the time of this blogging.  It will still use the 1.0 directory so don’t get confused.  You can check the version here.
  • Other good commands:  Get-Host, Get-Help

2. EDITOR INSTALL:  Use PowerGUI – I couldn’t find anything worthwhile for VS2008 and PowerShell.

  • Install PowerGUI
  • Watch the entire intro video (just kick-arse)
  • If you have time (and patience), watch this video from Mr. Softy.  The speaker is way inefficient but provides a cool introduction using grep and sed.  I’ve listed both examples below incase you skip the 90 MINUTE presentation. 
  • GREP:  cat data.txt | where { $_ -match “Mary” }
  • SED:  cat data.txt | %{$_ -replace “Mary”, “Susan”}

3.  DEVELOPMENT:  Using the tips below, you can literally cut & paste from Visual Studio SharePoint Object Model code. 

  • Conditional logic is a little different but very manageable.  Print out this page and keep it handy as a reference. 
  • Accessing static classs methods/members example: 

[Microsoft.SharePoint.Workflow.SPWorkflowState]::Running

  • IMPORTANT!!!!  PowerShell Script Function Calls are like the command line – no parantheses or commas: 

Get-SPItemsInProgress $Site $Web $url $List $Field;

  • IMPORTANT!!!!  PowerShell Class Function Calls are the same as in C# 

$WebList.GetItems($Query);

  • Disposing of objects still applies in order to prevent COM memory leaks. BE CAREFUL USING COMMAND LINE.
  • Use built-in Try/Catch/Finally – (use $_.Exception.Message; to print exception)
  • Download some SharePoint examples here – although you need to add disposing logic

I create and test most of my PowerShell+SharePoint script in Visual Studio using a C# project.  You just can’t beat the Intellisense and debugging features.  If you’ve gone through the above or already know it all, then take this script for a spin!  As always, let me  know if you have improvements.

SPNINJA on Workflow DR

•January 4, 2010 • Leave a Comment

Here’s a quick tip with regard to developing workflows:  ALWAYS DESIGN FOR DISASTER RECOVERY.  Below are some guidelines on how to do this.

TRACK INITIATORS:  Allow a “business initiator” to be chosen at workflow startup.  Do not assume the person starting the workflow is the “business initiator”.  Track them separately.  This has major implications for making workflows restartable.

RECOVERABILITY:  The workflow should be restartable from any point in time.  Include the necessary logic to jump to any point in the workflow depending on workflow state values.

WORKFLOW STATE: Store workflow state in list item fields or InfoPath variables.  Ensure that they are editable and make sense to the business user.

BUSINESS DESIGN:  Design workflows with the business user in mind.  You want business users to maintain this and not page you every time a restart needs to occur.  (Visualization workflow tools like Nintex REALLY help in this area.)

UPFRONT VALIDATION:  Validate all state values upfront and notify the initiator if there are problems.

GOLDEN RULE:  Any workflow change/upgrade will result in a workflow restart with the latest version.

Following these guidelines will enable you to AUTOMATE your workflow deployments.  Suddenly, deployments are much more simplified – requiring little or NO custom code because your workflows contain all the logic to start right where they stopped.  Additionally, a script can now be written to automate the restarts.

Hmmm…what scripting technology would allow me to:
1.  Pass in the list and workflow names to the command line for targeting a workflow that needs to be restarted.  Therefore it would be reusable on any workflow.
2.  Access to the SharePoint Object Model for:
 – finding running workflows
 – for each workflow found, stopping the current running workflow and starting the latest version
 – report on any workflows with errors
3.  Run the script and walk away.

It would indeed be very POWERful, taking the (sh)HELL out of workflow deployments!  Next post on how to do this

Likes and Dislikes of Windows 7 + SharePoint 2010

•December 19, 2009 • Leave a Comment

Likes

  • Great for sales and consulting.  Whipping out your Windows 7 configured with SP2010, Office 2010 and SP Workspace is just cool.
  • Fast…very fast.  Even a tricked out VM cannot compete with the performance of a host installed SharePoint 2010.
  • Accelerated learning.  Seriously, if you’re like me, you pretty much have your SP2007 VM up most of the day and rarely start a third VM.  So it’s hard to play with 2010 when the VM has to be started and contends with your existing VM.  And there’s just a TON of new features in 2010.
  • Makes practicing Powershell very convenient.

Dislikes – as a Dev Dweeb

  • Mess with host?  What a DUMB idea.  My current 2007 crashes about once a quarter for whatever reason forcing me to rebuild from a snapshot or entirely from scratch.  Now you want me to screw with my host…with something that hasn’t even had it’s first service pack yet??  Speaking of which, are they gonna service pack this thing for Window 7? 
  • VM goes down, you’ve got options – backup vm files, snapshots or automated install scripts.  Sure…you go right ahead and depend on Ghost or whatever for host backups.  Me, I’ve got yesterday’s deadlines and goal-line-stand bugs waiting.
  • “It works in my VM” is a common mantra for developers.  And very often, my response is “then just gimme your d_mn VM” rather than waist precious cycles fixing my environment.  Often on a team, I recommend at least one person update a “gold copy” VM.  Then the only time you lose is updating the VM with the latest solution deploys. 
  • Are you going to really install/maintain SQL Server Developer on your host as well?  I hope so cause Express just sux…period.
  • As a dev, you’re just going to get dumber.  There are vast rewards for devs who dabble in the infrastructure world when developing on a SharePoint platform.  Sure, you’ll find your niche WebPart and Workflow developers (I’m still in denial about InfoPath).  But I find SharePoint development is more about “quick wins” then complex application development.  Therefore development cycles come and go.  Additionally, the integration between dev and infrastructure is tight, enabling developers to create performant apps by understanding what’s under the hood.

Dislikes – as an Infrastructure Geek

  • HECK NO.  I can’t even imagine testing solutions on my Windows 7.  Again, no snapshots hurt an awful lot here.
  • Stand alone amongst your infrastructure compadres…cause you’re stuck with the Stand-Alone Install.
  • No domain.  Very often, I like to create my base VM as AD and run other VMs for database and WFEs.  No testing of profile imports.
  • Disastrous for disaster recovery testing.
  • Without the hard core server components at my virtual fingertips, why bother creating automated scripts (Powershell, PerfMon).
  • Testing 3rd party tools will most likely not work.
  • Mirror, cluster, load balance, proxy…NEGATIVE.
  • From Mr. Softy himself, pre-RTM upgrades will not be supported and in fact BLOCKED.  So be prepared to uninstall the beta when the RTM is available.  (More likely, be prepared to rebuild your host.)

JD Wade has been enthusiastically urging me to dual boot from a VHD.  Especially with Microsoft’s new trend of releasing Hyper-V VMs for SDPS events.  Thanks Glen for the link on setting it up.

Btw, here’s a link on setting up the Windows 7-SP2010 environment.  Good luck with those goal-line-stands!!

Choosing the Right InfoPath, Part 2

•December 1, 2009 • Leave a Comment

Designing the Right Solution with InfoPath

In Part 1, I discussed the major pro’s and con’s I encountered with InfoPath web forms.  In Part 2, I’ll discuss the basic pattern I see when providing a good design for InfoPath solutions.

Form Design Considerations

When building out your forms, consider the following in order listed below:

BEFORE BEGINNING – read this article on designing for InfoPath performance.  This really is critical as there are so many performance pitfalls with InfoPath 2007.  Additionally, check out this article on developing tips with SharePoint – this is a huge time saver.

1.  Fields – looks for fields you can group.  As forms evolve, behavior is easy to change, fields are NOT.

2.  Visual Layout – use shading and sections for users to quickly identify areas of the form.  For SP2010, utilize themes for possible sync with SharePoint.

3.  Logic – keep it simple.  Be mindful to keep the “spaghetti logic” to a minimum.  Your future self will thank you!

4.  Data Connections – Watch large result sets as paging is non-existant.  If you sneeze, you’ll cause a post-back.  Keep your viewstate small.

5.  Behavior – Use conditional formatting and validation where possible.  Remember there are no pop-up boxes and limited JavaScript support.

6.  Deployment – Package forms in WSPs and use externalized data connections.  You can then change the url in the WSPs and deploy versus republishing forms for each environment (dev, staging, production).  Use Central Admin deployments – do not publish directly to the form library (see previous blog for reasons).

Architectural Considerations

Keeping these four areas in mind and avoiding doing too much in the InfoPath form itself will go a long ways in keeping costs and time-to-production down.

Presentation: Think of the “Form” as a way to present data and provide a means of printing. Keep the form simple and avoid code behinds for as long as possible.

Data Store: Think of the “Form + Form Library” as your typical application database. Utilize content types for backwards compatibility and versioning.

User Edits: For complex solutions, use the “XMLFormViewer + ASP.NET” to edit the form’s data. DO NOT RELY ON THE INFOPATH WEBFORM. This will enable you to use JavaScript, AJAX and whatever other web technology you’d like to incorporate. It will also enable debugging and logging.

  • You will need to parse the InfoPath xml to provide updates.  Remember to add SharePoint checkin/out logic when parsing the xml.  Create a custom content type for hooking in your “XMLFormViewer + ASP.NET” form.  Use a feature activation event to set the EditItemUrl on a custom content type to map the url to your ASP.NET form.  You can then deploy the custom content type to a task list and redirect task edits to a custom ASP.NET form.

Orchestration: Use Workflow (I like Nintex) for orchestrating user/system interaction.

I know there are lots of examples in calling Web Services and etc from within InfoPath.  My experience has been, however, that I spend more time designing around limitations of InfoPath as the complexity increases.  InfoPath is NOT intended to be an ASP.NET replacement and doesn’t even come close to providing the UI scalability and customizations.  Keeping the form simple and creatively leveraging/integrating other technologies will make your travels along the InfoPath much more pleasant!

Choosing the Right InfoPath, Part 1

•December 1, 2009 • Leave a Comment

I’ve recently been heads down in integrating InfoPath 2007 web forms into SharePoint 2007. Here I try to surface the design guidelines and major “GOTCHAS” that cost me many a night and weekend. In Part 1, I’ll discuss the major pro’s and con’s with InfoPath web forms.  In Part 2, I’ll show a basic pattern for orchestrating solutions with InfoPath.

InfoPath Coolness

First lets do a brief take on why InfoPath is a real contender in the collaboration and workflow world.

1. Printing!! By far the best feature of InfoPath web forms is the ability to print forms right out of box.  Very useful and powerful feature given that capturing business processes in forms often involves printing the form.

2. Look and Feel. No CSS skills required.  Just an intuition for borders and shading – I know, that’s pushing it for me too.

3. Conditional Formatting/Rules.  Power users can utilize Excel-like functions to constrain, hide and validate fields.
Although, I consider this a CON as well – it can lead to spaghetti logic very quickly.

4. SharePoint Integration.  With no-code solutions, integration with SharePoint lists and libraries is very powerful.  Mashups with content types, workflows, versioning can enable rapid automation of business processes.

5. Data Portability. XML data is stored in the .xsn package.  You can then port it around.

6. External Data Sources. Pulling in data from a SharePoint List for example is a breeze to setup.

7. Deployment Speed.  Hands down, you’ll have the ASPX developers beat on simple forms.  Key word = SIMPLE.  I explain below.


InfoPath Hangups!

1. Limited Web Development Features

The most common theme you’ll run into with InfoPath is that the fat-client rocks and the web form features are severely limiting. Therefore, be prepared to create forms that resemble the .NET 1.0 era versus your high speed, AJAX enabled, JavaScript-tricked-out apps. Here is a short list of areas I found most lacking:

– No support for multi-level events.  Example, if a user clicks button, a drop down is populated.

– Very annoying post-backs (WANs Beware!).  This is a great article for detailing the performance crippling post-back problem.  Apparently anything from richt-text fields (needed for printing), conditional formatting, view switching, rules, data connections, complex calculations and full moons can cause MULTIPLE expensive post-backs depending on form interaction.  This can be very disorienting resulting in blindness, epileptic seizures or temporary maddness.

– Limited notifications. No popup boxes.  Crap error notifications – dreaded “Form Closed”

– Limited JavaScript support.  You can try the xmlformviewer, but it does not provide near the control or feature richness of an ASP.NET application

– Form url dependencies force republishing per environment (Dev, Staging, Production)

– Issues modifying a “Promoted Field” using the SharePoint list object model.  This may have been content type related but for certain promoted fields, it would not let me update the value.  However the same code logic would work on other promoted fields.  I spent a couple nights on this and after confirming some others in community were having this issue, I finally gave up and wrote an XML parser for modifications against the form data.  UG!

– The contact selector is a riot!  No property promotion support.  Unintuitive to setup.  AWFUL post-backs.  Good luck restricting it to one user – you can try this hack if you’re brave.

Bottom Line:  If you expect to do some validation customizations or feature rich user experience, look at ASP.NET.  Additionally, post-backs can significantly hinder user experience over WANs.

2. Code-Behinds Introduce Whole New Pain

If you cross the great chasm to creating form code-behinds, you should proceed very carefully – and multiply your estimates by two.  Here’s a summary of the steps you must now take to deploy your forms:

  • Enable InfoPath 2007 VSTA feature for compiling your code
  • Publish the form to a network location
  • Upload the form via Central Administration (wait for App Pools to refresh)
  • Activate the feature at the Site Collection level
  • Associate the created content type to the list or library

That’s 4 more steps then if you chose not to have the code behind.  The waiting for the App Pool refreshes in Central Admin and main web application can become VERY time consuming.  Additionally you should consider:

  • “Attach to Process” does not exist in VSTA – therefore no InfoPath debugging
  • Quick-Find in VSTA will not find items in minimized code blocks.
  • Content Type Weirdness. Because your form is a content type, you may run into column duplication on deployment.  My last deployment, I had a content type that insisted on creating a brand new column called “Product” when one in the library already existed.  If you chose the “no-code” solution, you have to option to map the columns and this is not an issue.  A friend of mine found a GREAT workaround here if you need to fix this.
  • If you promote another field to an existing InfoPath content type, you have to reactivate the form feature for field to be pushed down.  This is a common problem with Content Types.
  • For the contact selector, you may not utilize the “AccountId” as a promoted property.  Instead you have to use custom code.  Mapping fields with code-behinds are obviously very problematic.

3. 64 Bit Mayhem

If your clients utilize a 64 bit OS, you may be in for some PAIN.  Even though IE8 32 bit is the “default”, I’ve had email kick open the 64bit IE 8 which is VERY unreliable for displaying InfoPath 2007.  You may want to drop InfoPath all together or find a way to ONLY have the 32bit IE 8 open.  I’ve had so many problems with 64bit clients displaying InfoPath web forms.  The most common error usually occurs at random when using rich text fields and contact selectors.  The entire form locks and a warning appears stating “Stylesheet object not found”.

4.  Breaks the rules on Check-In/Out

If Tom checks out the form and then Jane subsequently opens the form, a number of things do NOT happen:

  • Jane does NOT get notified that the document has been checked out
  • The form is NOT locked into readonly mode
  • After spending 30 minutes editing the form, Jane clicks save and is presented with an error NOT indicating the checkout problem
  • Jane is NOT happy!!
  • Good reference.

5.   Beware of session bloat.

Session bloat can be caused from attachment controls (files & pictures).  The session for non-xmlviewerforms is stored in SQL.  Therefore with attachments this can wreak havoc on your WFE-SQL communication as the session is rehydrated on each post-back.  Also, attachments get stored as Base64 blobs right in the xml.  This may result in Out of Memory errors (even for file sizes as small as 3MB) as the parser barfs.   Use links to doc libs instead or a custom control that stores files in SharePoint.  Good article on session.