Chris Norman's Groove Blog

Groove Forms and Groove InfoPath Forms Part 3: Which Tool Should I Use ?

Part 1 of the series is here.

Part 2 of the series is here.

In past posts, I've outlined some of the differences between the Groove Forms tool and the Groove InfoPath Forms tool. Armed with that background, we can begin to see the criteria to use when deciding which tool to use for a given application.

Some reasons you may want to choose Groove InfoPath Forms:

• You already have an existing InfoPath Solution that meets Groove requirements (enumerated here) or that can easily be modified to meet Groove Requirements.
• You require forms that generate XML documents that conform to a prescribed XML schema. In this case, you will need some custom code (using Web Services) in order to extract the XML documents when you're ready to archive the data, since there is no out-of-the-box functionality for that in the InfoPath tool. (The Groove Forms tools can both save data as XML, and can export data to Excel, but the InfoPath tool only exports promoted fields. In order to extract the actual XML documents from the InfoPath Forms tool, you'll need to write an application that uses Groove Web Services APIs.)
• You want to develop a form template that can also be used with InfoPath outside of Groove.
• You want to extract and archive Groove forms data on a SharePoint site and have it be accessible with InfoPath. Again, this requires Web Services code.
• You want to use some form features that are available in InfoPath, i.e., repeating sections, that are not easy to reproduce in a Groove Forms design.

Some reasons you may want to choose Groove Forms:

• You require a multi-form solution with hierarchical form relationships.
• Your form requires lookups into other forms.
• You want to use the integrated Groove object model, i.e., implementing simple workflow, using lookups in script code, sending IMs, etc.
• You cannot guaranty that all users will have InfoPath 2007.

In general, I think about the InfoPath tool as being useful for simple data collection, especially when you want to have XML documents to archive, and Forms as being useful for more complex scenarios, for example, hierarchical form relationships.

Hopefully, this series has helped outline some of the tradeoffs in using the different Groove forms tools. Next, I'm going to do a series that will explore the Groove InfoPath Forms tool in more detail.

Groove Forms and Groove InfoPath Forms Part 2: InfoPath Solution Requirements

Part 1 of the series is here.

I want to talk about some of the constrains and requirements that Groove has when using InfoPath.

There is one point of potential confusion that is worth addressing up front though, which is the use of the term "view". In Groove Forms terminology, we use the term "view" to describe a custom aggregate list view of a group of form records. InfoPath generally works with a single form, and uses the term "view" to refer to alternative presentations of a single form. I'll try to be clear about which usage I'm referring to as I talk about the two tools.

Below are the requirements on InfoPath solutions that can be used within Groove. On import, the Groove InfoPath tool scans the imported solution and issues errors and/or warnings if the solution doesn't conform to Groove's requirements. Errors are fatal and mean the solution cannot be imported. Warnings are informational and can be ignored, though they warrant further investigation since you need to understand whether the issue will actually cause problems. I've tagged the requirements below according to whether failure to comply results in an error or warning on import:

• Error: The template must be configured to use "submit to host environment". This allows the Groove InfoPath tool to intercept the submit event and store data documents in the Groove InfoPath tool for dissemination to other endpoints.
• Error: The template must use the InfoPath "restricted" security level. This is required because the Groove Forms tool(s) are sandboxed by design. It should not be possible to use the InfoPath tool to go outside this sandbox, and the InfoPath "restricted" security setting is required to ensure this. Note that this implies that InfoPath templates that use managed code cannot be used within Groove, since InfoPath 2007 requires templates that use managed code to use either domain or full trust security.
• Warning: Some InfoPath field types can not be used for promotion in Groove, and will result in a warning on import. The main reason for this limitation is that Groove uses typed fields in records to store promoted fields, and needs to be able to maintain full fidelity during both promotion and demotion (more on demotion in a future post). On import, any fields that cannot be imported within Groove will be ignored and a warning message will be displayed listing the fields that could not be promoted. This means that although the fields can be used in the InfoPath form, they will not be promoted when in Groove, and so cannot be used as a column in a (Groove) list view. The Groove online help has a table that describes which field types can be promoted.
• Warning: The template should not depend on secondary UI such as a custom task pane, or menu or toolbar integration. Groove does not provide any of this functionality when hosting InfoPath, and will issue a warning message on import if it detects that the template uses it. This is one area where you should seek to understand the warning. If the template is dependent on UI elements such as a custom task pane, you could wind up with a non functioning tool, since the task pane won't be accessible.

Now that we have some background established, next time we can get to the series punchline: how to choose between the two Groove Forms tool alternatives: Groove Forms and Groove InfoPath Forms.

Groove Forms and Groove InfoPath Forms Part 1: Data Storage

I've had a few conversations lately with solutions developers about the Groove InfoPath Forms tool, and one of the first questions that comes up is how to decide when to use the Groove Forms tool and when to use the InfoPath Forms tool.

In order to understand the tradeoffs, it helps to understand the differences in the underlying data storage used by the two tools.

Tool Versions

Before I get into that, though, we need to talk about tool versions. Groove 2007 ships with several versions of the Forms tool, and one version of the InfoPath Forms tool. The default version of the Forms tool that gets created when you add a new Groove Forms tool using Groove 2007 is the V5 Forms tool; older versions are included for compatibility with pre-2007 spaces. The Groove InfoPath Forms tool is new, and thus is a V1 tool. In this blog series I'm going to focus on the Forms V5 tool and the InfoPath Forms V1 tool.

Data Storage

Both tools use the Groove "Record Database Manager" to store user data. The Forms tool uses a record schema that is created at form design time, and each form in the tool has it's own record schema. The Groove InfoPath tool is a variant of the Groove Forms tool that uses an InfoPath solution for the form design, and the InfoPath editor control for form editing and preview. Since InfoPath generates XML documents, the Groove InfoPath Forms tool needs to store an XML document somewhere in the underlying Record Database Manager record.

To do this, when you import an InfoPath form into the the Groove InfoPath Forms tool, it creates a record schema for that form that contains a field for each promoted field in the InfoPath form, and a single attachment field that is used to store the corresponding InfoPath XML document. When a new InfoPath form is saved in Groove, the promoted fields are extracted from the XML document and stored in the promoted fields in the data record, and the entire InfoPath document is stored in the attachment field. Any field that is not promoted is represented only within the InfoPath document.

Next time, I'll talk about some other differences between the two tools, which will help get us ready to take on the original topic of how to choose between the two alternatives.

Groove For Developers

My name is Chris Norman, and I'm a dev lead on the Groove team. I've been working on Groove for almost 6 years, and have mostly focused on the Groove APIs, the SDKs, and extensibility. I'm currently working on the Groove Forms tool, the Groove InfoPath Forms tool, Groove Web Services, and the Microsoft Office Groove 2007 SDK.

I plan to blog mostly on topics related to Groove development and extensibility. Some topics I have in mind are using the InfoPath and Forms tools, and Groove Web Services patterns.

If you're not already familiar with Groove, here are a few good places to start:

Microsoft Office Groove 2007 Preview

Marc Olson's Groove Blog

If you're new to using Groove as a platform, you should check out Hugh Pyle's blog. A while ago he did a multi-part Groove Web Services Primer.

More to come soon...