Using SharePoint Online for InfoPath Forms Services

Introduction

Today I thought it would be fun to do more research on what InfoPath looks like in the cloud. There had been a few hints about Forms Services running on SharePoint Online and some people were suggesting that it would only work once Office365 came out. Today I started a BPOS trial at https://mocp.microsoftonline.com/site/services/bpos/signup.aspx?offer=suite&quoteid=067303dd-bef3-4bc9-8f95-2b24c6dae143 and created a forms library to test out my strategies on InfoPath.

To give away the spoiler, I got it to work successfully. Apparently this is currently an unsupported feature (I think until Office365 comes out), but it does work. Here are the steps that I did to test this out. In a recent post I talked about how the license changes to MOSS 2010 no longer provide forms services as a feature when you use the standard CAL. But BPOS is relatively inexpensive so I think it provides a cost-effective replacement for the MOSS functionality. I found the documentation a little lacking on how to do this so I thought I would put together a walkthrough of how I got it to work.

Walkthrough

1. So the first thing I did was make a sample form in InfoPath:

2. Then I save it and go to Tools\Form Options to enable it to work in a browser:

3. Then I just have to go through a couple pages of the wizard to publish to a Microsoft Online site.

You have to authenticate with SharePoint Online at this point. Then the next page

Then choose the forms library from your SharePoint Online site that you want to publish the form for. In the following screenshot I show a couple forms libraries. I actually used a different form library for the later pages of this wizard called OnlineFormsLibrary.

 

Then you get a page that says the form was published successfully:

4. Then I wanted to show the form from my browser even though I had InfoPath installed. On the form library settings you can specify that you want the form to display as a web page which will show the forms services rendering that does not require InfoPath. Here is the form for specifying this:

5. Then you can view the form by making a new item in the forms library. Here is an example of my form being rendered through Forms Services:

Conclusion

So Forms Services does work with SharePoint Online, even with just a BPOS trial. This is exciting news. As far as I know, BizTalk cannot currently integrate with SharePoint Online for document library functionality because the WSS adapter web service does not exist in the cloud. The next thing I will try is being able to post the results from InfoPath back into a custom WCF service in the cloud. From there the data could be sent back into an on-premise hosted BizTalk server via the service bus. This whole integration feels like sending something from outer space back to earth but I feel good just knowing that at least it is possible.

Recent Licensing Changes to BizTalk-Related Technologies

Introduction

I got some pretty good traffic for my recent post on the changing BizTalk landscape regarding 3rd party BizTalk adapter companies that no longer sell adapters so I thought it would be good to also try to aggregate some recent licensing changes. Due to new products being out now for both of the license changes, the old terms are no longer available and the old products can no longer be purchased (AFAIK). Both of these licensing changes seemed shocking and a little annoying to me because the previous version was a great deal, especially when paired with a BizTalk standard license.

Forms Services (InfoPath on the web)

• In SharePoint 2007 it was possible to run Forms Server under a Standard CAL.
• In SharePoint Server 2010, Forms Services requires Enterprise edition.

From a BizTalk perspective not being able to work with InfoPath on the web without purchasing a full, enterprise edition of SharePoint is a significant barrier to entry. InfoPath has often been used with BizTalk for providing a rich client application for error routing & resubmit scenarios. There are actually many samples of using InfoPath with BizTalk that are included with the BizTalk SDK.  BizTalk standard is a very  good deal for smaller businesses when compared to Enterprise edition. Fortunately it is still possible to use InfoPath with BizTalk 2010 as long as the InfoPath client has been installed.

A really interesting and likely cost-competitive workaround would be to use SharePoint Online which will eventually support Forms Services. I was unable to determine if this capability is already available but there are several Microsoft people mentioning this is an upcoming reality. Here is one example: http://social.technet.microsoft.com/Forums/en-US/onlineservicessharepoint/thread/03581d46-64bc-4c8e-953b-211ac55fc70c/.

BizTalk Adapter Pack when used outside of BizTalk

• With BizTalk 2009 it was possible to purchase a separate license for using the BizTalk adapter pack WCF custom bindings without a BizTalk license.
• With BizTalk 2010 a BizTalk license (Standard or Enterprise) must be purchased

At the very bottom of the page at http://www.microsoft.com/biztalk/en/us/editions.aspx, this change to the BizTalk Adapter Pack is listed. I am not sure if this change might have been a trade-off with the developer edition now being free. It seems like a relatively good trade. In my experience I have not seen many people pay for the BizTalk Adapter Pack separately from BizTalk. I was actually surprised when anyone mentioned even knowing about this separate SKU for just the BizTalk adapter pack.

Since BizTalk is not licensed on a CAL model it seems like just a matter of time before the BizTalk Adapter Pack could be remotely hosted (perhaps even in the cloud) and could be provisioned for costs in this way. This is just a guess – I have no knowledge of this being an upcoming trend or possibility. But considering the requirement of needing to upgrade to a BizTalk server edition for anyone currently using the pack in their .NET applications, there seems to be a compelling reason to have a cost-restricted upgrade model.

Conclusion

So both of these licensing changes can make a big impact on your architectural estimates for projects unless you look at using a cloud or ASP based workaround.

Thanks,

SharePoint 2010 Sneak Peek and Office 2010 TP

I just learned about the MOSS 2010 sneak peek site (http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/default.aspx), which shows some very cool screenshots of the upcoming version of SharePoint. There are a couple important points about this release which are exciting from a connected systems perspective.

 

The Business Data Catalog (BDC) definition designer that came with the Office Server SDK is getting a facelift and some updates. The BDC functionality is now called Business Connectivity Services (BCS). If you worked with the BDC in MOSS 2007, you probably know that you could not use WCF bindings other than basicHttp to interact with web services or other services with the BDC. I am speculating, but I would anticipate that BCS will include more WCF functionality than just the basicHttp binding. We will see in a few months.

 

I have used the Microsoft tool and the BDC Meta man tool and consider both to be helpful but fairly limited. There were various ways to encounter issues with the Microsoft tool so I am hopeful this latest release will provide some fixes and a better developer experience. The sneak peek screenshots also show using the tool from within Visual Studio rather than as a separate tool. This means that the new tool will be used with some out-of-the-box SharePoint extensions. The sneak peak also discusses a new designer experience as well. These improvements are significant and provide SharePoint lifecycle benefits for BDC projects.

 

The additional Linq to SharePoint feature extension will be a nice feature as well. The designer screenshots for the BCS tool which is described as being for BCS for entities looks very similar to the LINQ to SQL designer so I would anticipate that the future vision of BCS entities is to provide a richer experience for interacting with the BCS entities like with the ADO.NET entity framework. Previously through the BDC the way to interact with the entities was not on a code level and required web parts or list interactions post deployment. It will be exciting to see how far the LINQ to SharePoint API extends and how much of it applies to BCS entities.

 

Also, the Office 2010 technical preview has been released. I installed all of it (except Visio) on a Windows Server 2008 R1 box successfully. Unforunately, Visio encountered an error so I was not able to install it. In my experience, SharePoint designer does not work on MOSS 2007 sites, although SharePoint Workspace (new name for Groove), does work on MOSS 2007 document libraries. Overall, the graphics are a nice upgrade to Office and I am enjoying the new functionality.

 

I also like the new feedback components of the Office 2010 TP, and I thought it would be funny to post on these. After installing Office 2010, you get 2 new icons on the tray, a smiley and a frowny and you can click on each to report feedback experience, as apporpriate. Each one takes a screenshot so you can quickly and easily report screenshots. Here is a picture with the funny faces in the tray:

 

 

Try out the Office TP if you have time and be watching for the SharePoint 2010 release coming up soon!

 

Thanks,

 

SharePoint Workflow Services

I was working recently on a SharePoint Workflow project and was exploring some of the Office SDK samples. The latest Office SDK (http://www.microsoft.com/downloads/details.aspx?familyid=6D94E307-67D9-41AC-B2D6-0074D6286FA9&displaylang=en) includes samples that were built for VS 2005 but you can convert nearly all of these over to work with VS 2008 using the .NET conversion wizard. I was exploring one of these samples and found some code that worked with IWorkflowModificationService and then realized that there are at least 4 workflow services exposed by the SharePoint workflow host. The IWorkflowModificationService (as documented at http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.workflow.iworkflowmodificationservice_members.aspx) has just a single exposed method for EnableWorkflowModification(). This method performs some of the same functionality that that the activity shape Microsoft.SharePoint.Workflow.EnableWorkflowModification performs. Then I noticed that in the workflow designer in VS 2008 this activity actually has an InterfaceType which referes to IWorkflowModificationService. Interestingly, when I clicked the … on this part of the property box the object explorer filtered my referenced assemblies by ExternalDataExchangeAttribute and gave me the filtered window as seen below:

 

 

The items listed above are the four available workflow services provided with the SharePoint Workflow host. For this reason a considerable number of the built-in SharePoint activities are just wrappers that work with the workflow services. This was a very interesting find for me because it helps me to understand the way that workflow services are working under the surface the SharePoint workflow host.

 

While I was looking at the MSDN documentation for IWorkflowModificationService I also found there is good documentation for these other workflow services including ISharePointService, ITaskService, and IListItemService. Because these are exposed you can quickly come up with the implementation behind most of the built-in SharePoint activities.

 

Thanks,

 

Variation on WSS Adapter Error & Workaround

On my current project I was working to configure the WSS adapter for BizTalk on a separate server than BizTalk. This requires running the BizTalk installer on the SharePoint box and then running the BizTalk Configuration Wizard to setup the WSS adapter web service. I was running the configuration wizard and was just using the defaults and received the following error:

 

d:depot2300mercuryprivatekwsourcebizofficecodebizofficeconfigurationwssadacfgwssadacfg.cpp(467): FAILED hr = 80070002

This is a similar error to the one reported at https://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3350889&SiteID=17 but I identified a different workaround that did not require an updated DLL from Microsoft. Rather than use "Default Web Site" as the application where the WSS adapter web service should be installed, I used an already existing web site such as "SharePoint – 80". This enabled me to install the WSS adapter successfully.

 

While discussing this issue I wanted to mention that the WSS adapter configuration instructions at http://msdn.microsoft.com/en-us/library/aa547280.aspx mentioned that you needed to install "Windows SharePoint Services SP2" but this refers to WSS 2 SP2 and is not required if you currently have WSS 3.

 

Thanks,

WCF LOB SDK flies under the Radar – BDC Extensions Await

Recently I worked on a BDC project and I was able to get a taste for what is possible for out-of-the-box SharePoint integration with external systems. The tricky aspect of BDC web service integration is that it only works with older web services – ones that use Basic Profile. The challenge of this is that you are limited in the integration options that are available because you must rely on the older SOAP and HTTP protocols. There are Office SDK samples that showcase integration with SAP and Siebel over BDC web services or Oracle over BDC database connections, but I was wondering how I would expose PeopleSoft or some other enterprise system that cannot be reached with a Basic Profile web service or a database connection.

 

Based on my BizTalk background, I knew that I could use the PeopleSoft adapter through BizTalk and then expose a BizTalk orchestration as a Basic Profile web service that could then be consumed by the BDC. So essentially this would be like a BDC bridge over BizTalk. This is when I started exploring the WCF LOB SDK as an interesting technology because the BizTalk adapter pack 1.0 is based on this SDK and it basically provides enterprise integration over WCF. Very few people are playing with the WCF LOB SDK, mostly because I think it seems confusing and has a poor name. The SDK is targeted at BizTalk developers with its "adapter" terminology, but it is really more of a way to talk about BDC from an adapter-oriented mindset. The LOB terminology should connect in your mind the LOB aspects of the BDC. If you look at the BDC documentation, the concepts are all about connections rather than adapters, but the WCF LOB SDK redefines the adapter concept by describing it as part of the channel infrastructure. So the future for the BDC is a redefined adapter based in WCF.

 

I found a few links that tie together the BDC adapters <-> WCF LOB SDK concepts, which really give us a glimpse of how the WCF LOB SDK is going to actually become more valuable from a MOSS perspective as the MOSS product is enhanced to support WCF. Usage pattern 7 on http://blogs.msdn.com/biztalk_adapter_development/archive/2007/07/09/wcf-lob-adapter-usage-patterns.aspx mentions how future BDC enhancements will rely on the WCF LOB SDK. It looks like Jesus Rodriguez also played with some of these scenarios: http://weblogs.asp.net/gsusx/archive/2007/07/12/sharepoint-bdc-wcf-adapters-and-more.aspx. The dates on these links suggest these concepts are old news but it is still relevant because the BizTalk adapter pack 1.0 was only recently released. The plans for this SDK go way back but the vision for how it will be used in the future seem to be missing. The WCF LOB SDK gives us a vision for the future of the BDC, which should include having a better designer experience for BDC developers as well as a much richer level of connectivity and flexibility. So the ROI for the WCF LOB SDK is still down the road, but once MOSS can support WCF it will be possible to integrate these other enterprise systems like PeopleSoft straight from the BDC. This is an exciting vision for the future of the BDC technology and a great reason to get your hands dirty with the WCF LOB SDK.

 

Thanks, 

BDC Column Maximum Length & Workaround

I recently uncovered an overflow problem in BDC columns. When returning data from a BDC data source, it is possible to return too much data if the BDC is being used as a column in a custom list. The maximum length of a BDC column when used in a list is 255 characters, which is the default maximum length of a text type column in MOSS. When using the BDC web part, data that is returned is not subjected to the maximum length of 255 characters. When more data is returned than 255 for a particular column, I received the error: "Invalid text value". Within the BDC application definition, the TypeDescriptor data type for these columns was System.String. I could not find any other errors in the event logs or SharePoint logs for this problem.

 

I wanted to post this maximum length because the MSDN documentation does not mention this.

 

Since I was working with a SQL Server BDC connection, I was able to wrap fields that could overflow the 255 character maximum using the substring function as in substring(<fieldname>,1,255), but this will not be possible for all BDC connections.

 

Thanks,

BDC Implicit Conversion Pitfall

I have been recently working on a MOSS BDC project and have been struggling with some ambiguous error messages that were occuring on when using BDC data columns in a custom list. The error I was receiving was:

   An error occurred while retrieving data from <BDC Database>. Administrators, see the server log for more information.

 

After checking the event viewer logs I realized this error message actually refers to the SharePoint logs in the 12 hiveLogs. After some investigation of the log I realized that my BDC application definition was expecting an Int64 value to be returned when in fact it was receiving an Int32. From a programming perspective it would seem that any Int32 value should fit within an Int64. The other way around should cause an overflow. The BDC complained like the Int64 data type resulted in a data type mismatch.

 

This problem illustrates that implicit conversions when using the BDC are not provided by the MOSS runtime, so it is VERY important to be sure that the type descriptors in the BDC application definition match exactly what is returned from a database or web service. I am sure there are other cases where a developer would expect an implicit conversion to occur but will not with the BDC.

 

When using the BDC Meta Man tool or the Microsoft BDC Editor, watch out for definitions that default to Int64 as the data type for a column because this could result in an error if an Int64 is actually not being returned. This is one very tricky issue in BDC development.

 

Thanks,

Comparing BizTalk and MOSS SSO Configuration

I was recently working on a SharePoint Business Data Catalog (BDC) project and needed to configure the single sign-on (SSO) functionality of SharePoint. For anyone not familiar with the SSO functions in BizTalk or SharePoint that I am talking about, I will explain it briefly. I am not speaking about SSO in the sense that a website or application user logs in once and only once. I am speaking about SSO functionality in these two server products which enables the secure storage of credentials used for connecting to external systems. There are two types of SSO - authorization and impersonation. So that everyone knows, I am talking about the SSO impersonation capabilities of these two server products.

 

Coming from a BizTalk background I had worked with SSO in BizTalk quite a bit but was not initially prepared with how different the configuration was for SharePoint. This post will attempt to do a thorough comparison of all of the SSO functionality between the BizTalk and SharePoint products.

 

Feature	BizTalk	SharePoint
Configuration Interface	Command-Line and BizTalk Configuration Wizard	SharePoint Central Administration website
Encryption Key Management	Possible only via Command-Line	Possible only via website function "Manage Encryption Key"
Encryption Key Backup	Command-Line File Based, Can backup to any file location	Website Based, Can backup only to a removable drive
SSO MMC Capability?	Exists as an MMC, can be loaded remotely with appropriate BizTalk install	MMC does not exist, cannot be configured remotely.
Requires RDP access for SSO configuration?	No	Yes
Group Setup for SSO	SSO Administrators, SSO Affiliate Administrators, SSO Service Account	SSO Administrators, SSO Administrator Account, SSO Service Account
Requires SSO Service Account to be process identity for configuration?	No	Yes
SSO delegation options	Credential based on port configuration	Credential variability options – Group and Individual options.
Runs as Windows Service?	Yes	Yes
Required on all servers in Farm?	No	Yes
Operates out of an SSO database?	Yes	Yes
Command-line options for SSO?	Yes	Partial
Automatic Credential Update?	Yes	No

The above table shows there are a considerable number of differences in the SSO configuration and functionality options of SSO across the two products. Perhaps in the future the two SSO products can provide a combination of the features in the chart above because both offer valuable options and would make an excellent combination together. A more consolidated SSO experience would also be helpful from a product administration perspective.

Thanks,

 

SharePoint Security Permissions Matrix

It looks like an MSDN article that is really useful is located under the SPPermissionGroup64 Enumeration rather than a more descriptive title. This article gives all of the possible user access levels in SharePoint and then describes which individual rights are covered by the levels. These individual rights are used when deploying features for attributes in the feature definition files like "Rights". Here is the link to this vary important SharePoint security chart: http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.sppermissiongroup64.aspx?topic=306117.