My client uses InfoPath form libraries. They want to phase out the use of InfoPath all together and replace it some alternative.
My idea is to implement custom forms for the same and host it within SharePoint, so that the users can have a web based alternative, in place of client application such InfoPath Form Filler.
What can be the best strategy to achieve this?
If you're sure they want to use browser forms, I'd start by investigating Forms9 and Nintex. I think Qdabra did a webinar on getting your data out of your existing InfoPath forms.
However it might be smart not to rush, since InfoPath is not disappearing for several years. New options are in the works. Microsoft is working on native solutions such as Forms On SharePoint Lists that might meet your client's needs in a year or two. Also Formotus (my company) has app-based form filling solutions and has announced the intent to continue superseding InfoPath, so the right solution may come from there too.
Recommended reading: My blog series on InfoPath Alternatives
http://www.formotus.com/category/infopath-alternatives
Related
I am a .Net developer and I need to get started with SharePoint 2010 and InfoPath 2010 for a new project.
I believe I don't want too much SharePoint just the basic configuration and how to host an InfoPath form there. For InfoPath I need to know how to design forms and program it using VS2010.
I appreciate if you can provide me with some links/books to get started with SharePoint and InfoPath (with more emphasis on InfoPath development).
Edit
I really need some personalized advice instead of an entire website to surf. I will be totally lost like this.
As John alluded to - the path to learning really depends on your project needs.
My recommendation would be to learn InfoPath first. You don't need SharePoint and you don't even need Visual Studio to utilize the majority of InfoPath. You might be able to accomplish your goals right there without even delving into anything else.
If that is not enough start looking at the other things. You will need advanced programming (Visual Studio) if you are trying to customize the form experience for the user, adding functionality that is not available directly in InfoPath. Start looking down this path if you run into roadblocks with how you want your InfoPath form to work.
You will need SharePoint if you need a delivery mechanism, forms storage, tracking for the users. Start looking down this path if the forms start being complicated to manage on a file share (or if you need extra functionality like change tracking etc).
In general - start with Infopath and progress to the other things based on your needs. Programming is for the form (singular) experience, SharePoint is for the forms (plural) experience. Note also that they are not mutually exclusive - usually you end up needing both.
We got an requirement for implementing captial expenditure lotus notes application in sharepoint. It's having nearly five massive forms with all expense calculations and workflows.
What is the suggested approach in sharepoint to implement this?
I would agree that creating a custom ASP.net/SQL server web app would be the way to go if you have some ASP.net programmers available, though I'd recommend against embedding it via a Page Viewer Web Part. You can integrate ASP.net web apps directly in SharePoint, no embedding required.
If you don't have ASP.net programmers available, you can certainly do it in SharePoint and it may not be painful. The key issues are where you need to store your data and how relational the data needs to be. If the requirement is to store data in a relational DB, it becomes complicated to do it in SharePoint.
On the other hand, if you can imagine recreating your application's data as a collection of Excel spreadsheets, then it will be pretty straightforward to do it in SharePoint. In the simplest scenario, you could do all "development" using the SharePoint web interface. You would create a custom list in a SharePoint site for each expense form, then customize the site's default.aspx page to display a link the newform.aspx for each list. If the wokflows are basic notification/approval types, then you can also attach SharePoint built-in workflows to the lists via the web interface.
If you need custom form layouts, custom workflows and dynamic data filtering, then you could use SharePoint Designer to accomplish a great deal of design and development. Without more information about the existing application and workflows, it's impossible to say exactly how you should do it. But make sure you consider what parts of the existing application are requirements and what parts are just legacy functionality. If you can simplify the application, this is a great opportunity to do it.
While you can do it in SharePoint, it will be painful. You may be better off implementing the application as a stock ASP.net/SQL DB application and embedding it into SharePoint with a Page Viewer Web Part.
You can also skin your custom application to look like SharePoint using one of the SharePoint master pages as a template and link to it from your portal.
For added SharePoint integration, you can use Data View Web Parts or the Business Data Catalog (MOSS only) to query your expenditure application database and embed small reports and key performance indicators throughout your portal.
Alternatively to a Custom web app:
Create custom web controls implementing the forms and kicking off the workflows with custom layout pages to host the controls?
A site definition (just feature to add the pages+layouts at a pinch) to host the created pages "just so" in order to rely on "form1.aspx" being available always.
I would not try to "push" OOTB SharePoint functionality envelope to avoid creating custom code. Easier by far to
If you are going to do extensive workflow work in SharePoint be sure to consider buying an add-on like Nintex workflow or Blackpoint. It is almost always worth the expense over creating workflows with Visual Studio or SharePoint designer.
It's not easy to implement a solution for this in SharePoint, but we have a SharePoint App we're releasing in March 2014 which is a great capital expenditure workflow solution. http://budgetworkflow.com
Do I need Infopath installed locally to edit forms in a workflow for sharepoint?
Authoring InfoPath forms
If a person needs to create a new Infopath form or needs to change the layout of the existing form one needs to use InfoPath client.
The form layout and data structure is saved as XML so one might try to edit it but I would recommend you not to mess with it.
Filling forms
In order to fill the forms there are two scenarios:
User fills a form via web browser (InfoPath client is not required)
User fills a form via InfoPath client
The first option does sound interesting but limitations do apply:
You must purchase MOSS Enterprise license (for difference between SharePoint editions check this: overview or details here). There is an option to purchase a dedicated Forms Server.
Infopath as web form does not support all the features as the Infopath client form
Although web forms sound very appealing, my experience taught me that most important features are not available in the web edition. Check here for detailed list.
Default workflow forms
Your original question is not clear, but if you are talking about editing default workflow forms like Approval workflow form (which is InfoPath) there is no easy way to do it.
You won't need InfoPath as long as your forms are browser-enabled and you are running on MOSS (to use the InfoPath Forms Services).
If you are on plain WSS, then you will need InfoPath installed to fill out forms.
I don't think this is necessary if the forms are stored in a SharePoint document library.
Do you mean to edit individual forms, or to design a form?
Yes you do, it will be rendered as HTML in the site, but to edit it, you need a copy of infopath.
If you are just a user, and it's a web form, then you do not need to install the software, Otherwise, you should. It depends on what form the InfoPath display.
If you are a developer, you must install it locally so as to edit the template and deploy it.
What are the Benefits of using InfoPath forms in SharePoint?
I’ve been doing research on InfoPath to see how it integrates with SharePoint. The idea of letting users create their own forms offers a lot of power, and could enable people to handle some of the small requests they have on their own. However, outside of creating a form library that is driven by an InfoPath form, InfoPath appears to quickly become a hassle and a hindrance. Sure you can build code to directly talk to the SharePoint Object Model, but then you can only seem to be able to run your forms in the browser.
If you’re going to run everything in the browser, why not just use an ASP.NET form?
Also, besides the basic forms library approach, what other benefits does InfoPath on SharePoint offer?
I like to think of Infopath forms as being a great solution to the age old "form in a word doc" issue that companies have. It moves the task of creating and modifying forms closer to the people who care about the information.
There are tasks that are difficult to achieve in Infopath, but again it depends on the knowledge of the person creating the form more than the technology itself.
For forms that are complex and/or require large throughput, a straight ASP.NET form would be a better fit. As always it is about choosing the correct (cheapest total cost?) technology to solve a problem rather than shoehorning a solution from whatever is lying around.
(i.e. I still don't know enough about InfoPath to make a decision easily all the time).
Here are a few benefits of InfoPath forms over ASP.Net forms.This will, of course, always depend on your mix of requirements, developers, user skill, etc.
Forms are simple to create and modify for people familiar with MS Office
They integrate directly with the metadata in Sharepoint, unlike an ASP.Net form
Workflow Foundation is available through Sharepoint and simpler than using an ASP.Net form
If you're dealing with document-based processes (like work orders, orders, permission requests), it might make more sense to have a repository of the documents, rather than building a reporting structure off the data entered through the ASP.Net form
The documents are ready to be used by a process implemented in BizTalk
The validation and logic are run on the client with no additional programming, many times giving a much better user experience than plain ASP.Net forms
For those using SharePoint or MOSS 2007 specifically. How do you handle forms? Like say you want a form that submits contact information. I don't have this in production yet but I'm currently creating a list for the form that I need and then modifying the list add item form as needed. I'm not sure how this will translate to a public anonymous user environment. Any suggestions?
Thanks,
Curtis Shirley
Forms can be anything from custom lists (lists with your own fields added), custom ASPX pages (ASP.NET development), to InfoPath Forms Services (MOSS Enterprise only).
With lists you can also create your own new and edit forms if you don't like the out-of-the-box look/feel (SharePoint Designer can help you with this).
If you want to prevent spam with anonymous users, I recommend a CAPTCHA approach. Here are 3 to look at (we have implemented the first one recently):
http://nanddeepnachan.blogspot.com/2008/06/captcha-for-sharepoint-blog.html
http://blogs.msdn.com/pranab/archive/2008/12/09/sharepoint-2007-moos-wss-custom-captcha-antispam-field.aspx
http://captcha.biz/doc/asp.net/2.0/asp.net-captcha-sharepoint.html
The issue is really tricky. For a public facing site that must handle spam and usability, it may be best to code a custom form. It is not a major to host a custom form in SharePoint and there is information on getting code behind to work nicely.
Now that I think about it, the Community Kit for SharePoint has had to solve some of the issues for comments on blog posts.