Geeky Girl : forms

InfoPath and Excel Services

JessMeats — Tue, 01 Dec 2009 14:39:00 GMT

Given that I spent a ridiculously long time trying to get an InfoPath form to interact with a spreadsheet published through Excel Services, I thought this was a suitable subject for a blog post. If I stop someone else feeling like they want to beat themselves to death with their own keyboard, I will consider it a job well done.

Assume the following, much simplified, scenario.

Step 1: A user fills out a field on an InfoPath form. Let’s call this Field_A.

Step 2: InfoPath sends this value to an Excel spreadsheet and puts it in a cell. Let’s call this CellA.

Step 3: Excel does some calculation based on this value and puts the result in another cell. Let’s call this CellB.

Step 4: Excel then sends this value back to InfoPath, which puts it in a field. Let’s call this Field_B.

You’ll probably want to call your fields and cells something much more meaningful based on exactly what it is you’re trying to do. Depending on your actual situation, you may want to do multiple lots of either steps 1 and 2, or steps 3 and 4, or both. This post is just to help with the principles.

Preparing the Fields

The first thing you need to do is to set named ranges in Excel. In your spreadsheet, click on CellA and in the name box, enter whatever it is you wish to call this cell. Then do the same with CellB. Make sure every cell you want to either put data into or read data out of through Excel Services is a named range and remember what you’ve called them all.

Once you’ve named your ranges, publish the spreadsheet to Excel Services, saving the file in a SharePoint library. Go to the library and right click on the name of your spreadsheet. Click “copy shortcut.”

Now go to your InfoPath form. I’m going to assume you’ve already laid up the form and inserted whatever fields you want. You’re going to have to add a few more fields. Add a field for range_name_A and set the default value to be whatever you’ve called CellA. Add another for range_name_B and set the default value to be whatever you’ve called CellB. Add a field for sheet_name and set to default value to “Sheet1” or whatever the sheet is called that contains your CellA and CellB (if the two cells are in different sheets, you will need a different sheet_name value for each of them).

Creating the Data Connections

You need to create a new data connection. Using the wizard, say you want to create a new data connection to receive data and click the option for a web service. You will be asked for the location of the webservice. Enter http://<servername>/<sitename>/_vti_bin/excelservice.asmx?WSDL where <servername> is the name of your server and <sitename> is the name of the site where your spreadsheet is.

On the next page of the wizard, you’ll be asked to choose an operation from a list. Choose OpenWorkbook.

On the next page, you’ll be asked to set parameters. Click on the one called tns:workbookPath and then click the “Set Value” button. Click into the “sample value” field and then click ctrl-v. This should copy into the field the exact url of your spreadsheet. If it doesn’t, you can manually type in the address but be careful not to make any typing errors.

Click next a couple of times until you get to the last screen of the wizard. Uncheck the box next to “automatically retireve data…” and then click “finish.”

That’s data connection number one. This will open up the spreadsheet you will be using. Now you need to create the data connection to send data to Excel. Choose to create a new data connection, this time to submit data.

Enter the same address for Excel Services. This time, choose the operation SetCellA1. In the next screen, you will be asked to set some parameters. Double click on sessionId. A window will open up to allow you to set this value to equal the value of one of your fields. From the drop-down list, choose the data connection you created to open the workbook, expand the folders and select OpenWorkbookResult. Next, double click on sheetName and choose the sheet_name field you created. Similarly, for rangeName, choose range_name_A. For cellValue, you will want to choose your Field_A. Now complete the wizard.

This data connection will take the value entered into Field_A and submit it via Excel Services, setting the value of CellA in your spreadsheet to be the same value.

Now we need to create the data connection to bring in the calculated value from CellB. Choose to create another new data connection. This time choose to receive data from a webservice. Enter the same webservice address. The operation this time is GetCellA1. Ignore all the parameters and just click “next” until you reach the final screen. Uncheck the box to automatically retrieve data and then finish the wizard.

There’s only one more data connection to go. Create a webservice connection to submit data and enter the same webservice address. Chose the operation CloseWorkbook. On the parameters screen, set the sessionId to equal the field OpenWorkbookResponse from your open workbook data connection. Click next and then finish the wizard.

You now have four data connections. One opens the workbook. One submits the value of Field_A to CellA. One retrieves the value from CellB. The final one closes the workbook again.

Querying the Data

You need to attach a rule to Field_A. Create a rule with no conditions so that it will activate when the value in the field changes (you could also do this using a button). This rule should consist of several actions.

Action 1: query using a data connection. Run the Open Workbook data connection.

Action 2: submit using a data connection. Run the SetCellA1 data connection.

Action 3: set a field’s value. In the fields for your GetCellA1 data connection, set the query field sessionId to equal the OpenWorkbookResponse field from your Open Workbook data connection.

Action 4: set a field’s value. In the fields for your GetCellA1 data connection, set the query field sheetName to equal your sheet_name field.

Action 5: set a field’s value. In the fields for your GetCellA1 data connection, set the query field rangeName to equal your range_name_B field.

Action 6: query using a data connection. Run the GetCellA1 data connection.

Action 7: submit using a data connection. Run the Close Workbook data connection.

So now the form is set up to send and retrieve the appropriate fields.

Finishing Off

This is the simple part. Go to Field_B and set the default value to equal GetCellA1Result from your GetCellA1 data connection.

Now your form should take the value entered in Field_A, send it via the data connections and display the CellB value in Field_B.

Just to check it all works, preview your form. With so many fiddly parameters to set, it’s easy to mis-type something. Fortunately, InfoPath’s errors will tell you which data connection is causing the problem and, often, even where the problem lies. For example, if it says that the sessionId is invalid, you’ve mistyped something entering the sessionId for that data connection.

I hope this post is a clear guide on how to get InfoPath and Excel to talk to each other. Feel free to leave me a comment either if you find this useful or if you’re still bewildered by the process.

How to: Create a read-only view

JessMeats — Tue, 06 Oct 2009 13:06:00 GMT

I'm continuing my series of how to videos by showing how to create a read-only view. There are several reasons why you might wish to do this, the most common being that you want to have forms that cannot be altered after a process has been completed. This principle can be expanded to create multiple views, each associated with a different step of a process.

InfoPath in the real world - Care Services

JessMeats — Wed, 30 Sep 2009 14:07:00 GMT

I’d like to continue talking about the use of InfoPath in the real world by talking about Children’s Electronic Social Care Record. If you’ve been following local events in the UK over the past months, you may be aware that we’ve had some problems in identifying children who are at risk and working to protect them. In answer to this problem, Microsoft Gold Partner Deverill created a solution using SharePoint and InfoPath.

The situation was such that social services care team staff were being put under pressure to have more visits to children who were at risk. For each visit, staff had to fill out a thirteen page paper form. This form was manually handed to an administration team to be processed, which took days and could include many errors. As staff were being told to go on more visits, the increase in administration was going to be unmanageable.

Deverill created a solution using WSS 3.0 and InfoPath. The social care staff were equipped with tablet PCs with InfoPath installed. The original paper-based form was converted to an electronic form with handwriting recognition capabilities. The staff could fill out the form on the tablet, which would automatically save the form to a portal area on the network. The administrative team could then access this portal area to progress the case and collaborate. This has significantly reduced the amount of administrative work needed per form, removed the need for a typing pool and made report data more readily available. The data is now more accurate and entered more efficiently, allowing for significantly improved care levels in the community.

Scenario: Stock Ordering

JessMeats — Thu, 03 Sep 2009 12:34:00 GMT

Another simple scenario where SharePoint and InfoPath can work together to make life easier. A SharePoint dashboard which monitors stock levels is linked to an InfoPath form for ordering new stock, which kicks of a workflow to get the prodcuts delivered.

Scenario: Budget Request

JessMeats — Wed, 26 Aug 2009 11:05:00 GMT

Another scenario where InfoPath and SharePoint can aid business processes. In this demo, an employee fills out a budget request form, which is ammended by a manager and the results tracked using key performance indicators.

Scenario: Holiday Requests

JessMeats — Mon, 24 Aug 2009 17:17:00 GMT

This is a short demo showing a potential scenario for InfoPath and SharePoint workflows improving common processes. In this demo, an employee requests holiday, their manager reviews and approves the request, and then the holiday is added to a SharePoint team calendar.

Generating a unique form number - a SharePoint counter

JessMeats — Mon, 24 Aug 2009 11:06:00 GMT

I’ve had a request to expand on my post about generating automatic numbers for InfoPath forms. I was asked to go into more detail about how to set up a SharePoint list to act as a counter.

Go to the SharePoint site where you have your document library and create a custom list by the standard process. There are a couple of different ways to do this. You can click Site Actions, then create. Or you can click on lists to get a list of all the lists on the site, and then click create. Or you can click on view all site content, then create. Either way, you will be taken to a menu screen offering a selection of things that could be created. The top link in the fourth column is custom list. Click this.

Now you have a new list with only one column showing, title, and no elements.

Click on settings and then create column. Add a column that contains a number with no decimal places. I’ve called this count. It doesn’t really matter what you call this column, so long as you remember the name.

Once you’ve got the column, add an element to the list. It doesn’t matter what you put in the title field but you need to put 0 in the count column (assuming there are currently 0 forms in your library).

That’s your counter made.

Now, open up SharePoint Designer. You’ll want to create a new workflow. Select the options to attach this workflow to the form library you want to set the auto-numbering in. Disable the options to allow users to manually start the workflow or to start the workflow when items change. Either of these would mess up your numbering.

Click next to get to the next screen in the wizard. This is an extremely simple workflow that only requires two actions. Click on the action button and add the inbuilt actions do calculation and update list item. Click on the first blue “value” links in the do calculation action, then click the function button that appears. This gives you the opportunity to choose an existing value. For source, choose your counter list with the count field as the field. Now SharePoint needs to know which item to bring back from this list, so set the field to be the ID field and the value to be 1 (since there’s only one item in this list). For the second value, just enter 1.

In the update list item action, click the blue this list. From the drop-down menu, choose the counter list. Add a field to be updated and choose the count field, selecting as the new value the calculated value (from the workflow data). Again, you need to specify the exact list item. Select the field ID and the value 1.

Then click finish. Now your counter will increment every time a form is added to your library. You can now reference this list from your InfoPath forms to create the form ID number.

Generating a unique form number

JessMeats — Mon, 10 Aug 2009 15:15:00 GMT

I’ve had someone ask me about automatically giving InfoPath forms a unique number. The scenario in question was one where the forms were being saved to a SharePoint document library with a unique number attached.

Documents in a SharePoint library do get given an ID, which is unique within document library. This can be used as the unique identifier of the forms out of the box with no additional work. The problem is, this only works so long as your forms remain in that document library. Once you start moving or copying forms (perhaps as part of a workflow) the ID will change.

In those situations, you will have to add a bit of work to your form to generate this number. You just have to be careful about when you generate it. If you have the possibility of multiple people filling out the form at the same time, you need to make sure the number is created in such a way that the method doesn’t result in forms being given the same number. If the form were to create this number on open, basing it on the number of files in the library, you would have issues when someone else opens the form template before the first form has been saved to the library. The easiest way round this issue is to have the number generated on submission.

Here I will describe a simple method of creating this auto number.

Firstly, you will need to create a data connection. If your forms (or a copy of them) are going remain in the document library they are submitted to, then you simply need to create a connection to retrieve data from that library. You only need to retrieve the data from one column. For the sake of argument, we’ll say the unique_number column. I’ll discuss another possibility in a bit for the scenario where forms will be moved or deleted from the library.

Set up the data connection using the wizard as you normally would, but uncheck the box when it asks whether to retrieve data when the form opens. You won’t want to get this information until the end. You will also want to set up the data connection to submit the form to the appropriate form library. Do this as you normally would, but make sure that one of your promoted fields is the unique_number field where you’ll be storing the unique ID of the form. From the submit options menu, uncheck the box labelled Show the Submit menu item and the Submit toolbar button. This is because you don’t want your users to just submit the form; you need the form to perform other actions first.

To allow your users to submit, add a button to the form. You’ll want this button to be set to trigger rules and custom code. Click on the Rules button, then Add, then Add Action. The action you want first is to query using a data connection. Choose the data connection you created to retrieve data from the form library.

The second action is to set a field’s value. The field will be your unique_number field. Click on the function button next to the value field. Insert a function. You have a couple of different options here. You can choose to perform the count function on the items in any field, or the max function on the unique_number field. Either way, you should end up with the most recent unique number assigned. So now, you just add one to get your new one.

The third and final action you need to add to this button is to submit the form.

So there you have it. Your form will now check how many items there are in the form library, create a unique number based on that value and save the form back. Brilliant!

But you can probably see why this method only works for scenarios where you leave the forms in the library. If you have a process that involves moving the form from that library to another, the count value will almost certainly be wrong and the max value might well be. There are probably several different ways to work around this. One simple way is to create a SharePoint list to act as a counter.

Have a list with one numeric element. You’ll want to set this list up so that it’s not visible from the menus on the site since you’ll only want to access it through the form and workflows. Initially, this will have the value of 1. Create a one step workflow using SharePoint Designer and attach this workflow to the form library. The workflow should trigger every time an item is created in the form library and all it should do is add 1 to the value in the counter (using the calculate value and update list item inbuilt actions). Then your form should retrieve data from this list instead of the document library and use the counter value as the unique_number.

The phases of technology use

JessMeats — Wed, 05 Aug 2009 17:35:00 GMT

I’d like to make a sweeping generalisation about how people react to technology. Disregarding for the moment the variations and exceptions, I believe that people go through four phases.

Phase 1: What the heck do I do with it?

Phase 2: Wow! That’s amazing!

Phase 3: There’s this one little annoying thing...

Phase 4: I hate this thing.

The speed at which people move through the phases depends on many things, including how technology savvy the person is. My Granny would probably spend a lot longer in phase 1 for almost any product than I would. If a product has a well defined purpose, clear marketing and a good user interface, phase 1 might be kept extremely short. On the other hand, if the product’s purpose is unclear or the user interface difficult to navigate, people might get stuck on phase 1 and eventually give up.

Phase 2 is the ideal spot. How long phase 2 lasts is almost entirely dependent on product design. People in this stage are happily using the project and being pleased with the results. This could be that they’re having fun playing a new game, or it might be that their working is becoming for efficient, depending on the purpose of the product. If the product team has done their job right, people will be in the phase for months. If the team’s done exceptionally well, people might be here for a couple of years.

But nothing is perfect. No matter how well a product does its job, there will always be something it doesn’t do or some little quirk that starts to irritate you. The more you use the product, the more you notice the thing(s) that at first seemed insignificant. You’re now well into phase 3. You still use and like the product, but there’s something about it you wish you could change.

Eventually, the annoyance outweighs the usefulness and you slip into phase 4.

In an ideal product, phase 1 should be short enough to be unnoticeable. Phase 2 should last for years. Phase 3 should last even longer. If the product’s been well-designed, you shouldn’t reach phase 4 until the product is obsolete.

In my journey through using InfoPath 2007, phase 1 lasted about fifteen minutes. I opened up the program with no idea what it was, played around with it and quickly decided it was great. When I started looking into what could be done with conditional formatting and data connections, I was well into phase 2. By the time I realised the power of views, I was in love with the product!

I stayed there for several months but now I’m slipping into the early stages of phase 3. I still think InfoPath is fantastic and can be used in an incredibly powerful way to improve processes in many situations. It’s still my favourite Microsoft product (not that SharePoint and the Xbox don’t have their merits). But there are a few things just are starting to bug me. Like when I have to click “OK” five times to get back to the form after setting a filtered value as the default value for a field. Or when I want to set exactly the same conditional formatting rules for multiple fields and have to manually set the rules for each one.

But now I’ve seen 2010!

I’ve skipped straight past phase 1 and into phase 2. You’re going to be seeing quite a lot of excited posts from me about 2010 over the coming months.

Improving Form Performance

JessMeats — Tue, 04 Aug 2009 18:45:00 GMT

When you load up InfoPath forms in a browser, do you see this message?

Probably. The important question is, for how long? Does the form open in a couple of seconds, or are you sitting waiting for minutes?

There are various reasons why a form might be slow in loading up. In this blog post, I’m going to cover the most common and explain ways to improve performance. A lot of the credit for the content of this post should go to Rafiq El Alami on the InfoPath team in Redmond for his presentation at TechReady on forms performance best practices.

If you have a form that’s loading slowly, ask the following questions. If the answer to any of them is yes, look below for suggestions that might help solve the problem.

1. Are several hundred controls (text boxes, option buttons, lists, etc.) appearing when the form loads?

2. Is the form doing lots of complex calculations?

3. Does the form have deep nesting (i.e. groups, within groups, within groups)?

4. Is your form requesting a lot of data?

5. Are your controls as simple as they can be?

1. Are several hundred controls appearing when the form loads?

Each of those controls takes time to load. Each may only take a fraction of a second, but those fractions add up. Each text box, drop down list and check box adds a tiny bit extra data for the form to download and display. When your form has a few dozen different controls, it will probably open in a few seconds. If you have a few thousand... you’ll be waiting minutes.

Plus, think about it from a usability angle. If someone opens up a form and sees thousands of controls, they’re going to be put off.

One way this can occur is when you have repeating tables or sections, within repeating sections. The form may load perfectly fine the first time but be a nightmare once a user has clicked the “add section” button a few times. Yes, repeating sections can be immensely useful under the right circumstances, but always bear in mind what will happen if they’re taken to extremes.

Another way to get round the problem of too many controls is to use views. You can create multiple views and display different controls in each, with back and next buttons triggering rules to swap between views. This way, the end result is still the same data being collected, but the user doesn’t get overwhelmed and the form will load up in a reasonable time.

2. Is the form doing lots of complex calculations?

InfoPath includes the capabilities for quite complex calculations, whether written in through the standard rule interface or coded into the form’s logic. This can lead to some very powerful forms being tied directly into business processes, but calculations take time.

The first thing you need to check is whether it’s really necessary to do the calculations. The answer is likely to be yes, otherwise you wouldn’t have written them in the first place. In which case, the thing to do is to decide when the calculations need to be done. Do they need to be done when the form is first opened?

Spreading out the calculations doesn’t reduce the amount of work being done by the form, but it significantly improves the user’s experience. Do calculations only when they’re necessary rather than when the form first opens.

3. Does the form have deep nesting?

When a form opens in a browser, most of the work is being done by that browser. The browser is not designed to deal with complex form logic. If you have deep nesting in the form, the browser is likely to send requests back to the server to ensure the information is being displayed and acted upon correctly. Each request takes time.

The simpler you can make the logic of your form, the easier it will be for the browser to handle and less requests will be needed. When designing forms, aim to have all your fields listed in the main data source window in a single line. I say to aim for this, I’m not saying you must have this. In large forms, you’re going to end up with some grouping, particularly if you use repeated tables or sections. But trying for a simple layout will mean that you avoid any unnecessary grouping that might slow down your form’s performance.

4. Is your form requesting a lot of data?

This is the big one. Do you have your form linking up to several databases, web services or lists to pull data into the form? If so, make sure that the data isn’t being pulled in from all of them right at the start.

You can easily set rules to query a data connection. For example, if you have a drop down list populated from an external source, add a rule to that list to query the data connection and select that the form doesn’t retrieve data on open. Now, the form will only query the data connection when someone goes to use the control. That way, if the list is optional and a user doesn’t click on it, the data is never requested. If you have multiple lists of this type, the time needed to retrieve data during form filling will be a lot less noticeable than if the lists all pull in data at the same time.

Only pull in data when it’s needed. You can link data connections to fields or buttons to ensure that the data is there when it’s required, but it doesn’t slow the initial loading.

5. Are your controls as simple as they can be?

Do you have a rich text box when all you need is a text box? Do you have a scrolling region when you just need a section?

Some controls are more complex than others. The simpler the control, the less time it will take to load. Try to simplify your controls. For example, there’s no point having a read only date picker. If you have a date field that is read only in a particular view, you can display it as a text box without altering the format of the data.

When you have things like combo boxes or multi-selection list boxes in your form, ask yourself whether they’re really necessary. The same goes for rich text boxes. Does it actually matter if the user can italicise their text?

Keep things simple and you’ll improve performance.

How to: Connect to a database

JessMeats — Tue, 04 Aug 2009 17:22:00 GMT

Continuing my series of how to demos. I had a request to do a video showing how to show red, yellow, green indicators based on values from a database. Yesterday, I posted a demo showing how to set up indicators. Today, you get to see how to connect to a database. The procedure is the same to connect to an Access and a SQL database.

The procedure for connecting to a web service is very similar, but includes choosing which method to use for reading and writing data, based on a list of methods supported by the web service.

How to: Show indicators based on values

JessMeats — Mon, 03 Aug 2009 14:20:00 GMT

This video is a response to a request. The request was to show how to show indicators based on values taken from SQL. In this video, I showed how to set conditional formatting to show indicators based on the value in a field. In this example, the value was entered manually, but exactly the same process can be applied to set rules on fields where the data is taken from an external data source.

I can show how to connect to an external data source in a separate demo.

If you have a request for a how to video, please let me know.

How to: Display a form in SharePoint

JessMeats — Fri, 03 Jul 2009 12:37:00 GMT

Continuing my "how to" series with this requested demo. In this video, I show how to embed an InfoPath form as a web part in a SharePoint page.

If you have a request for a feature you'd like to see demonstrated, please leave a comment.

How to: Hide a Section

JessMeats — Wed, 01 Jul 2009 15:40:00 GMT

Continuing my series of "how to" videos, I show how to use conditional formatting to hide or show a section based on the values entered elsewhere in a form.

Conditional formatting can be incredibly valuable when you're creating a long, complex form where people might need to fill out different parts depending on the circumstances. By including a few, logical rules, you can ensure that people only see those parts of the form that are relevant to their circumstances. This makes the process of filling out the form much easier and reduces the frequency of errors, which can in turn reduce process costs.

If you have suggestions of features you'd like to see in this series, please leave a comment and I'll see what I can do.

InfoPath in the Real World - Commitments

JessMeats — Wed, 01 Jul 2009 14:47:00 GMT

This is my second post about real-world implementations of InfoPath. Again, I’m sticking close to home. Microsoft have certain processes around employee commitments. At the start of the year, we have meetings with our managers to come up with various commitments and ways to measure whether we’re achieving them. Half-way through the year, we have meetings to discuss whether we’re on track, whether any of the commitments should change (if there were changes in company goals or something) and make sure we’re working on the things that we should be. At the end of the year, we have to decide whether we’ve underachieved, achieved or exceeded our commitments.

This whole process is handled using an InfoPath form. For each commitment, there are various fields, such as a title, execution plan, status and whether it’s aligned to a manager’s commitment (to ensure that individual goals support team goals).

The form has some basic information auto-filled in. So my name, title, manager’s name and so on are all included on the form without me having to type a thing. This is done using the data connection capabilities of InfoPath.

Then there are repeating sections for the commitments. Different people might create different numbers of commitments so the form must be flexible. So each person can add as many commitments as they feel necessary by clicking to add a new section with all the appropriate fields. The data connection capabilities allow for the form to reference commitments set by the person’s manager and consume that information in the form.

There is the option to attach supporting documents. There is even a help panel giving instructions on how to fill out the form properly.

When you’re done, the user can choose to save the form as a draft or request approval. Either of these options will save the form to the server so that it can be accessed by the person or their manager. Clicking to request feedback will save the form and email the manager with an automated message informing them that the form is ready.

The form is incredibly easy to use and both the user and their manager can be sure they’re seeing the correct view of the latest version.