I have a requirement from HR to make a process managed online. There is a workflow involved, I was checking my options and found out that we can make custom workflow on Sharepoint Foundation and deploy it for use. I would like to use the ASP.net for user interface and Sharepoint for workflow and data storage.
Is this possible at all or Sharepoint Foundation not adequate?
Can I create reports on SSRS from the data stored in Sharepoint lists?
You can use Workflow Manager 1.0 for the creation of your Workflow without even using SharePoint.
Related
I need to create an ASP.NET application that will allow user to create the workflow on the fly and implement it. The user should be able to create the workflow as we create a UML class diagram in case tool. That means user should have an interface to drag drop multiple workflow objects and setting various steps and process.
I will be using:
C# 4.0 ASP.NET, .NET 2010
I need to know how to provide such functionality and which tool I should use for allowing the user to create such runtime workflow and save.
Thanks!
To run workflow foundation designer on the web you will need to look toward XBAP hosting of the WF runtime. Checkout mtaulty's blog.
I have recently started learning Asp.Net MVC2. Somehow i have developed an application using the same.
I want to develop an ecommerce application using which people can open their stores.
1.But I want the new module should independently be developed an incorporated with existing application.
2.As the application i want to be used by many users to create their own store. Will it be good if we use WCF or any service Layer.
3.For large dataset it takes a lot of time to load how we can make it load incrementally.
I am not sure about how the application should be designed for performance and extensibility.
If any book or reference can be provided that will also be helpful.
You might want have a look at Orchard Project.
I'm new to developing in SharePoint and would like some tips please. I want to develop a WebPart. I understand that I effectively need to do this on a machine with SharePoint Server installed and create the web part as an ASP control. Once the control is created, how do I link it into SharePoint?
I would recommend you to take a look at the WSP Builder extensions for Visual Studio. It will simplify the development and deployment process for you, since it contains both templates for web parts, features and it will also package it up in a WSP solution for you.
I would read though this:
http://msdn.microsoft.com/en-us/library/ms452873.aspx
It will answer a lot of your questions about creating a web part, deploying etc.
If you're using the Microsoft Provided WebPart Visual Studio template...it will automatically be deployed to your site when you build it.
If you need to deploy to a test/production environment, you need to create a SharePoint Feature and then deploy the Feature to the server.
http://www.allaboutmoss.com/index.php/2010/03/22/hello-world-sharepoint-webpart-for-beginners/ helps you to create simple webpart and shows how it deploy in server.
You are able to build Web Parts in a number of different ways, through Visual Studio .NET using either the SharePoint Web Part Namespace or the normal ASP.NET Web Part Namespace further you are able to build Web Parts in SharePoint Designer using a combination of different technologies, such as XML Web Services.
XML Web Services will allow you to hook directly into SharePoint using SharePoint's Native Web Services, you can then create a Data View Web Part which will enable you to view, collate, filter and group List Items. This, of course, will also allow you to mingle normal HTML as well as XSLT syntax, allowing you to build logic into the Web Part.
The good thing about doing it this way is there is no "real' coding, i.e. no Code Behind page etc as there would normally be in ASP.NET. This also allows you keep things more or less SharePoint Centric, which is important because you may or may not have access to Central Admin or SSP nor indeed the Server itself, the 12 hive or the GAC.
How you decide to develop Web Parts should include thinking about all of the above, you may have a very restricted development environment. Further, you can also use Namespaces provided directly from GAC assemblies provided by Sharepoint, you may either need access to a development environment which has a MOSS or WSS Server on it or the PIA's or Assemblies from a MOSS/WSS Server.
I am a software developer, however, it is important for me to develop applications which are as SharePoint centric as they can be, which is why I decided to develop my Web Parts in SharePoint Designer. However, there have been times when using full VS.NET is the way to go, I would suggest you look at SharePoint Designer first, get a feel for the interface, XML Web Services, XSLT and HTML once you have created a SharePoint Designer Web Part and Provided this Web Part exists within a Web Part Zone, you can export the Web Part and reimport it into any number of Site Collections.
I must add that the above relates to SharePoint Lists and Libraries but it gives you a grounding to understand how it all fits together. it helped me understand more and made development of more coded Web Parts easier, It may not suit your individual requirements, SharePoint is a huge environment offering many paths.
Hope this Helps you out, search for SharePoint Designer... at least as a starting point.
Cheers
Is there any way that I can use SharePoint document library and document sharing functionality from an ASP.NET page?
There's 3 ways you can have your standalone ASP.NET (standalone meaning not integrated into sharepoint) interact with sharepoint.
1 using the SharePoint object model (sharepoint APi dll's). This way allows you to control every part of how your ASP.NET site interacts with SharePoint (document security etc.) The major drawback is that you ASP.NET site needs to be running on the SAME SERVER as SharePoint (or if sharepoint is used in a farm any machine that is running sharepoint in that farm). Simply including the SharePoint DLL's will NOT work when run on any other machine (even when that machine also has sharepoint installed but is not part of the farm you want to communicate with!)
2 Web Services. These OOTB services can be used from anywhere but are not very extensive functionality wise. They allow you to perform a lot of actions and retrieve a lot of data, but when it comes to more finegrained control they just don't cut it. It might be enough for what you want to do though.
3 Use web services and create your own webservice that is deployed to sharepoint for any tasks not doable with the OOTB services. This requires access to the sharepoint machine in the form of deploying custom code / assemblies though.
I assume that your asp.net application is running on another server because if thats not the case the it would probably be easiest to just use the SharePoint functionality directly and maybe include your app into SharePoint
SharePoint exposes a lot of it's functionality through Web Services, so you can get, add, delete and update information through these.
You can include any SharePoint page into a page in another portal using an IFrame. The main issue there is the fact that you will get the MOSS navigation in that IFrame, which typically is not desired. To overcome that, you can create a special MOSS page that hides all those elements and show just the element you want to expose. To accomplish that, you can create a “minimal” master page and a simple layout with a single web part zone.
I'm looking to take advantage of SharePoint's document management features for an intranet portal. Portal users, find SharePoint rather cumbersome so I would like to build most of the site in ASP.NET, and integrate SharePoint document libraries so that i don't have to create a document management system.
How can I do this?
In my honest opinion it sounds like you are trying to reinvent the wheel. If users are finding it cumbersome it is generally do to lack of understanding or incorrect implementation and training.
However if you do want to integrate into SharePoint, you can reference the full SharePoint API Library. It is .Net based and allows you to access any aspect of SharePoint in code. You need to reference the Microsoft.SharePoint assembly to access these classes. You will need to setup a development environment for this, since you can't develop for SharePoint without having it installed. The detailed documentation on the namespace starts here
From personal experience we had much more success implement a solid SharePoint structure, with training, and also building the SharePoint portal the same way we would have built a website. Users now insist on having applications in SharePoint.
Basically, you can set up and administer your document library (or libraries) through the standard SharePoint pages, but you build your own ASP.NET site for users which will access the information in the document library. This site will use either the SharePoint object model or the SharePoint web services to retrieve, manipulate and store documents in your document libraries.
Generally the rule is that if you are deploying your ASP.NET site onto the same server as your SharePoint instance, then use the Object Model; if you are deploying to a separate web server, use the Web Services.
Some of the common issues for SharePoint development, and how to avoid them can be found here:
http://msdn.microsoft.com/en-us/library/bb687949.aspx
The “Working with Folders and Lists” section will be particularly relevant to what you are doing.
Use an IFrame :)
Seriously.. you'll have to work within the context of SharePoint or you will find yourself rebuilding SharePoint. This excludes building it as a regular ASP.NET app. But it is not that far off.
Why not adapt the way SharePoint works to how your users like to work? It was made to be changed and appended.. within limits.