I have a requirement to select some data from a table in a database (SQL Server) and display it on a page in a SharePoint site (MOSS 2007).
I have a little bit of experience of MOSS, so I know I have a couple of options:
BDC
SSRS
or possibily even a custom ASPX page.
I've never really worked with any of these. Can anyone advise on the +/-'s of each?
It all depends on what functionality is required once the table is displayed in SharePoint. Do you need extra bells and whistles or is a dump of the data adequate? (Think about the future as well.) Here's some thoughts...
Business Data Catalog (BDC)
If you want to nicely integrate the SharePoint look and feel with your data as well as get some cool functionality, BDC is a good solution. There is no need to program anything and these are the features you get. However if this data will only be used once in one way then it is probably overkill.
You would need to roll your own XML description of the data so SharePoint knows how to pull it from the database (or use something third party like Lightning Tools). As Colin mentioned it requires the Enterprise license of MOSS.
SQL Server Reporting Services (SSRS)
If Reporting Services is already available for use then this is the quickest and simplest solution. It works well but can get painful as more advanced features are required in your reports.
You should be able to use the Report Designer wizard to point to your table and set everything up for you. There are SSRS web parts that can be used within SharePoint, or indeed you can run SSRS inside SharePoint using SharePoint integration mode.
Application Page
This method Steven mentioned lets you integrate an ASP.NET application into SharePoint (such that it can be accessible by a URL within your SharePoint site). This allows anything that ASP.NET does, and the code-behind will be aware of SharePoint so you can tap into that if needed as well. The cons here are code access security and deployment.
See this webcast for how to do it.
Web Part
Similar to developing an application page but much more integrated with SharePoint. A custom web part is very powerful and allows you to integrate ASP.NET code on a SharePoint page. As you would know web parts can be dragged to whatever location and give a consistent properties pane. Again, code access security and deployment needs to be considered.
If you like designer view in Visual Studio then be aware this isn't the approach that Microsoft push. You can however use something like SmartPart where you would develop your custom app as a user control and the SmartPart wraps it into a web part. I'm used to doing it the MS way now and actually prefer the additional control this gives, however it can take more time.
Page Viewer Web Part
If you don't want to touch your SharePoint installation at all then have a look at this web part. It takes a URL as parameter and displays an IFrame containing the page that would be your report, either in SSRS or standard ASP.NET.
The downside from this lack of integration is problems with sizing the IFrame, and possible security warnings from the browser if accessing the URL in a different domain.
Don't forget the DataView Webpart. It has a pretty small developement footprint and works really well as a first "cut" if you are unsure as to how hardcore you need the final result to be.
It renders using XSLT, giving you full control of the final HTML, so it can do some pretty things with Javascript and co.
For a very simple example of charting.
Have you ever used the .NET Framework do develop webpages?
MOSS 2007 uses this framework for master / template files.
So your best choice would be to create an ASPX template file to display the results on the webpage.
BDC is the way to go if you want to keep it "strictly Sharepoint". The problem is, it is only included in the Enterprise edition of SharePoint. If you have the Standard edition, you could go for SSRS and the SSRS webpart, or, create your own webpart. That way you can use your data display anywhere in your site and it's also ASP.NET compatible.
As Nat said - if all that is needed is to display some data from a database on a page - the DVWP is a great solution. Just open your page in SharePoint Designer, add the database connection, and drop the web part on your page. You can use any of the several pre-formatted layouts, or design/tweak your own so the data is displayed as you need.
Relatively straightforward, lots of HowTos online, and far faster/easier to setup than something like BDC.
Related
If I have a requirement of displaying the a content on all the pages inside a header, Whats the best way to do that in an SharePoint 2013?
I am working on a master page that will be using the design manager and there is possibility of using the same master page in the SharePoint online too. The reason why I want to know what is the best way, when I use this same master page in SharePoint online I would like avoid redoing that entire coding for getting a dynamic data from the web service.
Several ways that I have been planning is below
- User control method
- Web part method, but requires server side coding which I doubt can used in online version
This is a complete dynamic data that will be retrieved by a web service and no internal SharePoint data be used.
Thanks for reading
Deepak
If its possible to consume web-service using jQuery/Ajax call you can go with that
Or else if you want to use c#, might need to go with provider hosted app feature (sharepoint 2013)
You can create a Visual Web Part for SharePoint 2013 Online.
Your web part will be contained in a Sandbox Solution which you will develop locally. Once development is complete you will upload the Solution Package created by Visual Studio to SharePoint Online.
https://sharepoint.stackexchange.com/questions/80164/create-visual-webpart-for-sharepoint-online
http://sharepoint-community.net/profiles/blogs/sharepoint-online-2013-web-part-deployment
This could have been already discussed but in context of Dynamics CRM 2013, I am wondering what is the recommended and easiest approach (mine is a on-premise deployment) :
Problem :
May be a known pain point with 2013 - Users want to see 'All Activities' of a Company and related Contacts, Child Companies but
excluding few activities (like campaign emails).
Solution :
Thinking to create a custom form or a web resource which can use CRM web services to query for this data and make it part of the Company form.
Question is :
What is an easy way to do a custom page where I can use CRM web
services to query for all activities data and filter campaign
emails and display it like a grid ? I see two options :
Develop a separate aspx web application(using SDK binaries as references and crm web services) and host that outside of CRM (in IIS) and
use that url in an IFrame within company form.
Develop this as a html webresource (with a grid) and somehow make crm web services call from java script and display as a web resource (If so, is this
easy in CRM 2013, since web api is only present in 2016 ?)
Or something else ? (like a SSRS report may be but I think it will
be too slow)
Many thanks for your advise on this.
Thank you.
I work for an organization where most of the times requirements is like yours, so i have already done a separate aspx web application like your option 1.
Following are the few things to keep in mind:
If you go with Option 1 and develop a custom aspx web application and host it in IIS, it will be alot easier to maintain in future and easy to customize based on new requirements. If you have any new requirements like this in future, it will be easy to add a new aspx WebForm to the existing site and refer that new url. You can have common classes for Connection and authentication stuff in your web-application, which is almost re-usable.
I have used the same approach as described here: Best Practices for Working with Custom ASP.NET Pages and Microsoft Dynamics CRM 2011
In case of Option 2, i have tried this once but it is a bit more complex than the Option 1 because it involves more JavaScript code than C#. It is difficult to maintain although will be a bit-fast than the Custom Web App, but not re-usable code in case new requirements. Also Queries in C# (QueryExpression) is way more easy to write than writing Odata Queries in JavaScript.
Thanks.
I've been brought in as an intern to develop a SharePoint site. My team won't authorize the budget for Visual Studio and I don't have physical or remote access to the SharePoint server (running Windows SharePoint Services 3.0 a.k.a. WSS) on the back-end.
So what exactly can I do? I'm familiar with web technologies like PHP, JavaScript, HTML, and CSS. However, since the environment is SharePoint, I'm stumped trying to figure out how much control I have with Microsoft's definition of "Full Control".
If I can write some C#, I'm pretty sure that would be sufficient, but as I said no Visual Studio for me.
Any good ideas of features that people will use on a site built with the limited functionality of WSS and SharePoint Designer with "Full Control"? Can I somehow manipulate the default Web Parts into something cool or useful? Are there Ajax tricks I can do to accomplish something on the back-end?
Thanks in advance, I'm new to StackOverflow and eager to get involved here!
You can actually accomplish a LOT in SharePoint outside of a custom .NET solution. Some recommended learnings are:
JavaScript/jQuery - Know how to interface with a WebService using jQuery. SharePoint exposes a number of very useful WebServices in the /_vti_bin directory. Click here for a list: http://msdn.microsoft.com/en-us/library/ms479390.aspx. For example, I recently built a scrolling slide-show webpart entirely using jQuery and SharePoint's built-in webservices that pulls from a provided picture library.
DataForm Web Parts. Do some searching around on what these are and how they work in SharePoint. The tl;dr of these is that they're databound webparts that are bound to an SPDataSource and then rendered using XSLT to format the bound data. You can work with these in SharePoint designer, completely through the markup of your aspx page.
Do some searching on "customizing sharepoint list forms." The NewForm, DispForm and EditForm of any list or library can be customized to have behaviour or content added to them.
Those are just off the very top of my head...
EDIT:
I forgot to also mention http://www.muhimbi.com/Products/SharePoint-Infuser-%28Free%29.aspx
I've been meaning to check this out, since the concept is sound. I haven't tried it out myself but it will save you a lot of hassle when it comes to adding custom script that encompasses your entire site.
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
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