I need a tool which can be installed on .aspx platform (on a intranet of a company) which can be used to create collaborative data flow chart diagrams (multiple users can edit the diagram by visiting the intranet webpage).
Have you tried gliffy? - I've seen it used on intranets before, not sure if it's .net or if you can share it, but I recommend it.
I am not aware of a collaborative diagram program that allows you to store the data on your servers. An on premise solution would probably be prohibitively expensive. These SaaS guys aren't really setup to provide that option. You probably would have to get an open source solution and build it out yourself. The company that I work for (Lucidchart) does have a flow chart maker that allows you to lock down the domain so you can't share it with third parties and allows license de-provisioning for someone who leaves the company.
Source: I works for a diagramming company.
Related
Can you explain multi tenancy in more detail? how to check whether that is working or not?
What is a http adaptor? Can we create two http adaptors in a single process?Correct me if I am wrong?
To give you a brief overview of multi tenant concepts may run through several pages. IMHO, the concept of multi tenancy for a developer can be mentioned as,
Single code base or multiple code bases (Based on the level of multi-tenancy) set up in a server or in a server farm to cater to all the disparate tenant's that may have varying user experience, varying applications (managed through subscription) and each tenant given a feel of dedicated application by showing them their own data and the corresponding bills for what features of the app they are using.
If you maintain a single code base, it is complicated in terms of development and a piece of cake when it comes to upgrade or bug fix etc...
You should Google around for multi-tenancy. The sample link is :http://blogs.gartner.com/alessandro-perilli/multitenancy-is-not-just-network-isolation-and-rbac/
Please fell free to post your specific focus area in multi-tenancy and technology that you are opting for so the community help will be to the grain.
I'm the custodian of a pretty sophisticated, yet antiquated, ASP.NET application. It is essentially a platform that makes creating database applications easier - with tools to read in database schemas, auto generate forms, reports, charts, and provide extremely extensive tools to manipulate those things within the UI. There are some pretty big clients using the platform for some niche applications, and despite the age of much of the code (some of it written as early as 2001), everything runs pretty well.
The company is doing well enough that i need to start considering a new version, and rather than plastering on some new features, i'd like to consider a fresh start. The current solution is a ridiculous 150 projects - down from about 220 when i first started working on this full time.
Does anyone have any tips or suggestions for the general structure of an enterprise(ish) level application? What new technologies should i consider? Maybe some particular books or websites i should review?
I've got a good handle on all of the specifics that make our platform so flexible - but because i've been locked into the general structure of our code for so long, i feel like i'm way out of touch with how the entire thing needs to be structured on a large scale. The current application still has a bunch of .NET Remoting for communication with the databases (just a tad out of date), and a ton of incredibly inefficient code written by someone who wasn't really a programmer.
WCF to serve info from the data access layer? WIF to authenticate? I'd really like to be able to assemble an API that my business partners can use to connect to the data and use a huge collection of common functions i've got set up - ideally that API could run in a web context or in some other environment.
I know this is a pretty big question that could have a lot of possible answers - just looking for some thoughts on where to really spend our research time.
Thanks!
-RP
If you want to rid yourself of all the authentication / authorization hassles, absolutely go for claims-based applications, WIF, ADFS etc.
That's the Microsoft direction - CMS, SP. Office 365. Windows Azure AD etc. are all now claims-based.
Only problem is that ADFS authenticates against AD. Have a look at Identity Server for something DB related.
Plus ADFS via ACS provides Facebook, Google etc. logons.
We're looking into implementing an issue tracker for our web agency. The problem is that most issue trackers seem to revolve around the assumption that an issue is a bug, whereas in a web agency environment, a lot of the issues (request, or whatever you want to call them) are about changes and additions to a current web site.
It also seems to me that a lot of issue trackers assume that you're working on one main software project, and uses that project as the focus of the tracker. A good issue tracker for a web agency would be one which puts each separate client and their issues at the heart of the system, making it easy for them to track and report issues.
Does anyone know of a good issue tracker for the web agency workflow? What are other people using?
In my experience, issue trackers are so closely coupled to the workflow of the organisation that what works in one place may be a complete misfit in another. That said, could basecamp work for you?
We are using Gemini very flexible with the ability to have workflow at the project level.
But where Gemini really helps us is the cross project views. You can view your work across all projects with really good fitering.
Have you had a look at fixx at all? Obviously, being the developer of fixx, I will want to plug it but I know from first-hand experience that a lot of our customers are web agencies who work in a service-oriented environment and need to track more than just "software development" projects.
With fixx, you can define custom issue types (for example "change request" or "Copy changes") and track work against that type.
Unfortunately, fixx still does suffer from the "project-centric" view but a lot of our customers work around this by defining a project per client/website. So, if you were doing web/maintenance on stackoverflow.com, you would have a project called "stackoverflow.com maintenance" and would assign all your users from that company to that specific project. From there, using notifications and filters, it would be very easy for clients to keep track of progress on their specific issues.
FogBugz – it's simple by default, but extensible; it's got an integrated wiki, charts, tags, and you can even tie it to your source-control system (and they also offer their own integrated source control system, Kiln, which is pretty amazing with FogBugz).
Are you using other applications to manage the rest of your business' operations?
I ask because WORKetc has great issue tracking software, and this software is combined with other aspects of business management which can simplify the management process. So not only could you manage all support inquiries and responses in one place, but also your projects, finances, and contacts. Most importantly, it would allow you to use one central contact base for your entire company, while allowing you to reference that contact information (as well as lead information) while working on support inquiries, projects, invoices, etc.
WORKetc's support system works around email integration and simple ticket system (as well as prioritizing) and directly integrates with projects, contacts, and other aspects of the system so that you can save time while responding and managing tickets.
I think especially for the use case of a web-agency, where it's not really about bugs, but mostly (visual) feedback and all of it happens on the web, a visual feedback tool might be the thing you're looking for. Most of these tools will create a screenshot of the webpage and include the given feedback on it.
Some of them also have some kind of dashboard where you can discuss further, or have integrations to other tools like Basecamp (and some them do both).
Here's an article from smashing magazine, which describes a lot of them, e.g.: TrackDuck, BugMuncher. Another great tool the article doesn't mention, maybe because the article is a bit dated, is Usersnap – this one even includes browser extensions.
I was involved in a SharePoint(WSS) project that was very data centric. The project consisted of more than 500 lists that has very complex relations between them. The client also asked for more than 350 Reports. Don't tell me why did you use SharePoint from the beginning. It was a managerial decision and we already delivered the project after 14 months of pain (this is 6 months overdue to the deadline)
When we first started the project, we didn't know anything about SharePoint development (believe it or not). The management said that they will take the risk. They were very convinced that SharePoint is the optimal solution for anything!!!(well, that proved wrong at the end of the project).
Anyway, we were learning SharePoint while we were developing. Our development were mainly based on SharePoint designer to customize all the AllItems/NewForm/EditForm/DispForm for every list to provide the needed logic/validation that the client asked for (Using JavaScript). We also implemented around 15 Custom Fields (e.g. master-details fields). We also made an event receiver to handle all the adding/updating/deleting... events for all the lists in the site. Plus around 40 ASP.Net user controls.
The main problems that faced us (we worked-around it but sadly in an inefficient way)
1- The Client asked for a search web part in each AllItems.aspx. The search web part should have multiple keys for the client to search with. We did that using Form Web parts using SPD no problem. But the real problem was how to search for a related field that was not in the current list. (So, in such cases we had to save these fields values in our list to be able to search for (crap, I know!!)). You might ask, why didn't you implement ASP.Net user controls for such task? Well, that would require us to forsake the default AllItems web part, and were already customized hundereds of AllItems.aspx pages with alot of customization that would take us a lot of time to reimplement them from the beginnging. Also, even if we used user controls, CAML is very inefficient in retrieving data from multiple related lists!
2- I think you can guess this one, if we've already faced a big time doing search web parts, how on earth will be able to do the 350 reports!!:D But we figured out a work-around (as usual :S) we made an Access DB file with links to all the 500 sharePoint lists, then we implemented a user control that has a report viewer control. This user controls takes an ordinary T-SQL Query to query on the Access DB, the Access DB retrieves the data from the SharePoint DB and pass it back to the user control which views the DataSet on the report viewer.
There are other administration related problems, but I would like to focus on the development here.
So, after I showed you the picture (sorry for the long post). What do you think was the best SharePoint development technique that we should have taken in such a data centric Project, if any?
I heard that some companies doesn't use lists at all in such projects, and builds there own SQL database tables instead of the SharePoint Database. But I can't keep my self from wondering, If I'm making my own DB, and hence implementing my CRUD web parts from scratch (We will also lose the security module benefits provided by SP Lists), what would be the benefits of SharePoint?
Once again I apologize for the long post.
I think you found out exactly what I did. Sharepoint just isn't good at handling large enterprise type applications. We ended up creating a custom database to house our data. We used Webparts for the user interface, but otherwise, the entire application was independent of Sharepoint.
In my opinion, Microsoft is overselling Sharepoint. It's actually good at team collaboration sites and simple Excel services applications, but anything beyond that it just isn't capable of handling.
I have to disagree with both Geoff and Abu in regards to SharePoint being a bad choice for large enterprise applications.
As you state yourself Abu your team were learning on the job as you had no SharePoint development experience, the issues you faced was more a Management error that a platform problem, management should have brought in SharePoint contractors to work alongside your team to help build what sounds to be a fairly complex system.
As a developer who has worked with SharePoint for a number of years many of the projects I have worked on some that I myself would not have believed suitable for SharePoint with in my first few years of developing on this platform, however now with more experience I know how to leverage the power of the platform far better and I realise the advantages gained using SharePoint for projects of that nature. That said I have a number of issues with parts of the platform but this is no different to any other platform I have worked on including parts of the ASP.Net platform.
If I was asked to develop a solution using a bespoke Java based system (or perhaps the new MVC platform) I am sure I would experience many problems similar to what you experienced where I simply don’t know what the right approach would be. That would not in any way be an issue with the platform but more with my inexperience.
I am sorry to hear that both of you experienced pains working within the bounds of the SharePoint platform that was forced on you by your management. Though I am disappointed that you are so fast to point the blame away from yourselves and your management.
Was SharePoint the best platform for your projects I can’t say, but that doesn’t make it a bad platform for enterprise applications.
I disagree with Geoff that SharePoint is no good for large enterprise type apps. You have to remember from the start that SharePoint is a development PLATFORM. This means it gives tyou a lot of functionality out of the box, but is extremely customisable.
Being a platform does not mean every bit of customisation needs to be done based on SharePoint lists. Seeing as it is built on ASP.NET you can do anything in SharePoint you could do in ASP.NET as well.
I have built a great deal of ASP.NET apps that were hosted in SharePoint, letting SharePoint do the authentication etc.
I have to say though, determining where SharePoint should stop being your base and you should switch to regular ASP.NET is sometimes hard..
If you are looking for a data-centric solution in SharePoint, the best solution is to use the Business Data Catalog (BDC). This keeps your rich data relationships and all of the SQL (or other DBMS) goodness you want where it should be - in a repository designed to be optimal at storing data.
For an overview of what the BDC functionality can do, see this post on the SharePoint Team Blog. For much more details, read the series on SharePoint Magazine. Note that these features requires an Enterprise license of SharePoint 2007.
How would I programmatically connect to an existing back-end system of a restaurant using say Micros POS, with a web app built with .Net and C#. Thanks.
Update: Sorry for the ambiguity but I'd like to set up an online ordering system that takes users' orders and forward to a restaurant's back-end system to be processed and printed in the kitchen for cooks to see.
There is no particular reason for choosing .Net other than the fact I'm most familiar with it. I'm open to other options.
In general I'm looking for information regarding the feasibility of this and how to go about it programmatically. How would my app send orders to the kitchen's printers? Do restaurant back-end systems allow for a .Net (or any other) app communicate with it? Do they provide an API?
I currently work at an ISV that does basically this with another one of the big 3 point of sale systems.
First and foremost, get the Micros environment up in a VM.
Next, most of these back office systems are running either Windows 2000 or Windows XP (depending on the age of the system), so be really careful about the version of .Net you choose.
Now, as far as architecture goes, run a service on the back office that communicates regularly with a centralized web service (the website that customers order on), once an order is made available, from there you can then insert it into <insert pos type here>.
You will also find in most instances, especially with Micros being the largest Point of Sale on the market for restaurants, they will not be very helpful with documentation and helping you out with integrating into their software.
Also, I think that My Micros (their enterprise application) already supports this type of functionality.
Another opinion, get into FSTech this year and browse all the competition, there are tons for online ordering just so you can get familiar with the competitions feature sets.
What you need to know is define what you want to do with the POS before a choice of technology, if all you want to do is show some data/reports from the POS system's work, you would need to connect to whatever back-end database the POS devices feed into.
If you need to do something else, you need to look for whatever relevant documentation.
It would help you more to ask a more specific question.
I would probably start by determining if Micros POS has an API. If they do, are the systems at individual restaurants even connected to the net? Try chatting up the manager at a place that uses one of these systems, or just check the documentation on their website.