I'm very new to Sharepoint and I am just wondering if it's possible to somehow use data from an external database as a List that users can select from within a form. How much extra development does this involve?
Essentially we have a different (non sharepoint) site that allows us to set up projects. Once a project is set up I would like the project code to be usable from within workflows, forms, etc.
If you have MOSS Enterprise, you may want to take a look at the Business Data Catalog (BDC). It allows you to bring external data to SharePoint. Supported inputs are either a database or a webservice.
http://msdn.microsoft.com/en-us/library/ms563661(office.12).aspx
After you have set up the BDC, you can use the business data field to use that external data as metadata. That way, you can make decisions in workflows based on that metadata. If you want to play with the BDC, get yourself a decent tool to generate the application definition files (xml), because creating them manually is cumbersome.
Consuming external data in forms is even easier. It doesn't require the BDC as you can use databases and webservices directly as a secondary datasource in InfoPath.
Another option (if you don't have MOSS Enterprise) is to create a timerjob that keeps a list up-to-date based on the projects found. Of course, this is not updated in realtime and requires some programming.
Related
I have a business requirement where I need to expose set of custom properties defined by user and since this is user configuration, I cannot go away by creating classes. Therefore I need to opt for open types feature in Odata.
Q1. Is there any sample implementation out there on how I can persist the data to database and also support the querying capabilities on open types?
Q2. One issue I noticed is currently client library is not correctly handling open types and can only be achieved by partial classes that means user has to know the custom properties up front so that they can hand craft partial classes which is not what I want to do. Instead better approach would have been to support open types on client side by dynamic properties. Any pointers on how the client side experience can be optimized.
About query capabilities on open types, order and filter is supported in v5.5(will be released by the end of this month), query the value of dynamic properties, you can follow this pull request, part of this is in master branch now.
About persist the data to database, I think you can consider non-relational database, which can be a good choice for your open type data.
About Q2, achieve by dynamic properties is not implement in client library, maybe you can open an issue in github for us.
I m new to Umbraco, I have watched Umbraco.tv videos and want to use Umbraco in a project as a cms for managing and editing content. I am highly thankful for your guidance, time and for your thoughts on 3 questions:
How a Umbraco based data driven proejct should be architecutured ? For custom database tables do you use a separate database or same Umbraco database ?
How you work with custom data (non content) ? Do you make everything a document type, even if it is data which you are not going to create content of, for example a simple form submitted data ?
For DAL what technology or ORM you use ? Does Umbraco provide any API for saving simple data which is not a content or document type ?
Thank you so much once again.
1 The architecture question is important but it also has be considered against how complex the project needs to be.
I would usually recommend a separate database for non-Umbraco data since this keeps everything nicely independent and manageable especially as projects grow. It also means that CMS-specific data (i.e. content) can be kept separately from none-CMS data, e.g. user registrations.
However, if the project is small and isn't likely to grow, keep it simple. Use the same database and piggy back off Umbraco's implementation of the Petapoco ORM. For example:
ApplicationContext.DatabaseContext.Database.Save(new Thing());
Or
var item = ApplicationContext.DatabaseContext.Database.Single(thingId);
2 For custom data, again it's a matter of need, maintainability and simplicity. Only use document types for what needs to be and can be stored in the CMS. My personal rule is that if it isn't content or organises content then it doesn't belong in the CMS. For example news and news categories obviously belong in the CMS. However, the comments made on an article have no reason to in the CMS.
3 With regards to DAL, as I have said, Umbraco has an implementation of Petapoco that can be used out of the box. If the project is basic enough, just use that. There is little point in using anything else unless you need some separation and/or some additional grunt in which case I would recommend using NHibernate or EF.
In addition to the points above,
Use NuGet;
Use the MVC mode of Umbraco, as it will provide you with substantially more flexibility. Check out the Hybrid Framework as it provides a very good start point for a robust and flexible project architecture;
http://www.youtube.com/watch?v=0PtzyrEFG7I.
You always need a doctype in Umbraco, even if a page doesn't offer any WYSIWYG type editability
I would recommend using a Service Oriented Architecture, and the .dlls you drop into Umbraco can call the service. You can then deploy this service and have full control over how you do data access. Choose whatever method you want. Most modern sites use an ORM and it doesn't matter which, although nHIbernate and Entity Framework are the favourites. Don't be frightened to mix and match a more direct form of data access though as it can give you more control, especially in situations where performance optimisation of large queries is important.
If you're not familiar with adding custom .NET functionality into Umbraco, Trying out adding .NET user controls into Umbraco will give you a good start, and to help you to understand how you can utilise your own .dlls in Umbraco:
http://umbraco.com/help-and-support/video-tutorials/introduction-to-umbraco/developer-introduction/using-net-user-controls.aspx
Anything custom I put in the same database as my Umbraco installation, but everything in custom tables. I don't touch the Umbraco tabes, I would not want to affect my future version updates.
Form submitted data I store in my own custom tables, I avoid creating content nodes with those, it's often tricky and doesn't give me the flexebility I often need. What I do instead is create an "Admin" document type, that is behind login (hard coded access, but easy to hook up to Umbraco users / members if wanted) and use my own custom UI to display my stored custom data.
I use PetaPoto (http://www.toptensoftware.com/petapoco/), it's a micro ORM that is added through a single file (installation is so easy then), using the same db connection string. Then I create custom models as I need and with with parts of the MVC. I normally stay away from route hijacking and rather use Surface Controllers and ajax calls for almost everything.
Hope this helps!
You can use the database containing the Umbraco tables for tables not used in Umbraco. If there are no hosting problems for you using multiple databases then you can simply link to a second database in the web.config - this would be safer than using the default Umbraco database as Umbraco packages often add database tables & there could be naming conflicts.
Viewing non-Umbraco data (eg from a database) is best done by adding macros that access the data using standard .Net patterns (eg razor scripts, .Net User Controls) & then in Umbraco you add in a reference to the macro in the template (view). You can use multiple templates (views) for any document type; so if you have a document type called 'forms' that contains no data you can use the 'allowed templates' checkboxes to say which view(s) are valid for this document type. When you add a content item you must specify a doc type at the start, but the template (view) can be changed at any time.
If you are storing data any .Net ORM will work with Umbraco (see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET) I've used Linq to Sql, Subsonic & Dapper before now - but there are lots of options.
Take a look at my example using umbraco within Onion Architecture
https://github.com/afroukh/OnionCMS
It seems this can be hacked into Django, but I'd rather prefer a framework that has better support for end user defined models.
Basically, I want the users of my app/website to be able to do at the runtime of the application what I do at compile time when writing the Model code: specify models that generate/modify a database schema. Obviously I cannot let the users of the webApp modify the code in models.py, so there has to be another way. Concurrency shouldn't be an issue, since each user-defined model would belong to only one user.
I don't mind using any programming language (Python, Haskell, JavaScript etc.) or any specific database SQL, NoSQL, whatever. Rails/Django freed me from writing a lot of repetitive code, now I simply want that functionality of modifying the model also at runtime (and preferably the corresponding views and controllers). If there is a good framework that rids me of writing all that code then I'll use it.
If there's no framework supporting it natively, does someone know a framework that at least makes it easy?
Portofino version 3 (http://www.manydesigns.com/en/portofino/portofino3) allows a modeler user to create data models interactively using a web interface called the "upstairs level". The system automatically generates a user interface (CRUD, charts, workflows) based on the model definition, without recompiling and basically in real-time with model changes.
You can check the reference manual to see what kind of models are supported:
http://www.manydesigns.com/en/portofino/portofino3/3_1_x/reference-manual
Currently Portofino 3 is an end-of-life version. The newer version 4 (http://www.manydesigns.com/en/portofino) is a significant re-write that currently does not support online editing of the data model as version 3 did, but keeps the same principle of making the application editable (through admin/configuration pages) and customizable (using Groovy) online without recompiling or restarting the server.
For data-model changes and db refactoring, Portofino 4 relies on Liquibase:
http://www.liquibase.org/
On one server there are more than 20 databases with identical structure but different data. I need to collect some of the data (the same queries) from all databases and store in new database which is located on another server. I decided to use ASP.NET MVC 2 but it doesn't seem logical to use more than 20 "LINQ to SQL Classes" (.dbml) files because the structure is the same for all databases and it's repeating if I use so many of these files. Is there a simple way to use one .dbml file (for remote databases) but change only connection string?
I agree that you really wouldn't want to use MVC as that is a web framework and has nothing to do with moving data around.
You can also look into using an ETL tool to accomplish this task. I have used RhinoETL in the past successfully to accomplish something similar.
There are also multiple posts on this site discussing ETL tools. For example, check the following link - https://stackoverflow.com/questions/51198/what-etl-tool-do-you-use
According to this, you can pass in a connection string with the dataContext constructor. So theoretically, you should be able to have one dbml file, but you can instantiate multiple instances of your data context, each with a different database connection string specified. Each context should then point to their respective database and allow you to work with multiple databases.
Why do you want to use ASP.NET MVC at all? ASP.NET is for web UI, not data warehousing (except when you need to display cubes). Looks like you use SQL Server. If that is true you can utilize Integration Services (ex DTS) to do the job.
I have an architectural question. We have many applications in our company and we are planning to use ASP.NET MVC and Entity Framework in our future projects. The next project that we need to implement is a central authorization/authentication system. There is no option to use an existing one for reasons that doesn't mater right now. This system probably will be structured as a service. What we don't know is: how the other applications will know about "the model" of this authorization/authentication system? I mean, how they will know user, roles, etc. classes? What is the best practice? One of our colleagues suggested to create the entity framework model (.edmx) in a class library. The problem is that in this case we should copy this dll for all projects that will access the authorization/authentication system. Is it a good solution? Does anybody has a better idea?
You can implement your service as a SOAP-based web service, which means your data model and methods will be exposed via SOAP and described using WSDL. The web service can be consumed from any language, without requiring you to distribute any class libraries.
Many languages also have tools which auto-generate client side class wrappers based on WSDL description of your SOAP interface (e.g. wsdl.exe for .NET clients).
Just to add to what DSO already said, the standard way to do this is through the "Add Sevice Reference" dialog box in Visual Studio. It will query your web service, figure out the classes that are needed, and put them in a reference.cs file. You can also use the svcutil.exe (or if you're using Silverlight, SLSvcUtil.exe) to do the same thing. You have to regenerate the reference.cs file every time you change the interface of your web service, but that usually only takes a few seconds.
It's also possible to create a distinct set of Data Transfer Objects that can be shared back-and-forth between the various layers of your application, but unless you have very strong architectural requirements, I've found the auto-generated classes to work reasonably well.
See also this article here about the self-tracking entities available in EF 4.0, if that's an option for you: http://msdn.microsoft.com/en-us/magazine/ee335715.aspx.