We use MS Dynamics 4.0 at work for our CRM. This handles all contact management, marketing, resource sharing w/ sharepoint integration, workflow management / collaboration and essentially is used by every department in the firm in some way or another.
We have requirements from business for a new application that we have a tight timeline on. We have only just started rolling out CRM, and most of the custom development was done by a consulting firm.
We need a relatively simple application that we need to track some data for sharing for a specific group. Some of this information already lives in our 'company' and 'client' CRM entity.
This new project would require us to add around 26 fields - we don't want to bloat our already large company entity - especially since only around 5% of our companies would use these extra fields.
We are basically debating a design right now - hybrid solution (create our own ASP.NET app that looks like CRM and communicates to it via web services and store all the 'supplemental' fields on our own database, possibly living on the same DB server as our CRM DB so we can easily write queries). The other alternative is to do it 100% in CRM.
I'm just looking for advice for people who have done something similar to this. Would you recommend doing a hybrid solution such as this or should we do 100% CRM? Our deadline is tight and the developers working on the project have limited CRM knowledge; this is why it's a bit of a debate. For those working with MS Dynamics - how would you typically handle a project like this, where we need to add many fields (and even sub fields with parent->child relationships of their own) that would only apply to a very small percentage of our main 'company' entity.. something to note: we are already having performance issues when people load up this company entity as is (it could take 5 seconds for the page to render) and the same goes for advanced finds.
Last thing to note - this portion of the application is only for storing the data. In the end, the user will be opening a VBA Excel workbook, pushing a 'pull down data' button, that will pull this data from wherever we wind up storing it. We just aren't sure where we should store/manage this data/UI.
Thanks very much for any advice.
EDIT: How can I create 2 list boxes next to each other with 2 buttons in the middle where one listbox is a lost of 'my foos' and the other is 'all foos' and you add/take away from 'my foos' list box??? the classic 'i have these foos as part of me' UI control with 2 list boxes and 2 arrow buttons... Should/can I use jquery for this? and does anyone happen to know of any jquery control that already does all of this out of the box? This is such a common control I'm sure it must be out there somewhere. I've browsed some toolkits and controls and some threads on here and seen some really awesome, even more complicated controls but not this particular one..
EDIT2: After doing more research, it seems like keeping the UI all in CRM would be more complicated then just making an ASP.NET app for that portion and putting it in an iframe or modal popup in CRM.
We can still setup all the data fields and relationships in CRM - and have the ASP.NET do the CRUD using Webservice calls.
It seems we would wind up having to do the same amount of work to get the functionality needed in CRM - except it would be more hackish and done in javascript. At what benefit? Keeping the UI in one place??? Not that much of a trade off IMO...
so far we are leaning towards keeping all data in CRM but putting the UI in ASP.NET
Any advice is greatly appreicated. Is what I'm saying sane? Thanks
I agree, you're better off going with 100% CRM.
If (and I stress if) you find the performance impact is significant, consider using a related entity to hold the additional fields.
CRM doesn't provide a 1-to-1 relationship type so you'll have to manage that yourself. Make your company entity the N side of the relationship so the related entity appears as a lookup.
Alternately, if the related entity lookup is too abstract for your users, add a tab with an iFrame to the company entity form. Use javascript to show/hide the tab and also to set the src of the iFrame to the url of the related entity.
I'd use CRM to store the data. You can stick the new fields in a separate pane in the UI so that it won't clutter. You can even add some Javascript to the UI to hide pane/fields from users who are not part of the group that requires them. I know this sounds a little hacke-ty, but it's a lot less work than coming up with an entirely different app and users will get a consistent experience. Having the data in one place is also a boon for reporting and such.
I can't say for sure, but I don't think adding a few columns to an entity (which already has a bazzilion columns) will deteriorate performance much further. I'd go over the installation and check for the usual performance pitfalls.
Creating ASP.NET applications to create a complex UI in an iframe is a simple solution that I use frequently for MS Dynamics CRM 4.0 applications.
Keeping all of the data in CRM makes a lot of sense, but make the UI however you want it.
The iframe calls your ASP.NET application with a Querystring containing the entity's GUID so that you can use web services to pull any related information.
You can both modify the fields showing on the form with JavaScript, directly update the database or both for consistency. Frequently it is easier just to hide the fields being updated in the ASP.NET application so there is no confusion.
An example from a long time ago was a loan morgage calculator that I built for an iframe of an opportunity that a sales representative would have up. It would find all of the customer's related loan balances and calculate different options that the sale representative could then turn into a quote. Click a few check boxes, and press a button and they were done without having to rekey a lot of information. Data was written to a number of CRM entities, emails were generated and the autodialer list would be modified not to call that customer again.
Learning to use MS CRM as a big development toolbox is the first step to being able to do some serious business process automation.
If you have any questions let me know.
I know that this doesn't fit your situation as you are deep in MS CRM, but there is a good article by Neal Ford that was recently posted to IBM Developer Works (http://www.ibm.com/developerworks/java/library/j-eaed10/) that discusses COTS vs home grown software. Here's a snippet.
One of the common questions that arise in big companies is the decision whether to build or buy: for the current requirements, should we buy COTS (Commercial Off-the-Shelf Software) or build it ourselves? The motivation for this decision is understandable — if the company can find some already written software that does exactly what's needed, it saves time and money. Unfortunately, lots of software vendors understand this desire and write packaged software that can be customized if it doesn't do exactly what the client needs. They are motivated to build the most generic software they can because it will potentially fit into more ecosystems. But the more general it is, the more customization is required. That's when an army of consultants shows up, sometimes taking years to get all the custom coding done.
Related
This is more of an advise / best practice question that I'm hoping someone has come across before and can give me a steer.
I need to build a web application (the client would like webforms because that's what their developers know for when i hand it over)
Essentially when the client logs in, they will pick a language then I need to replace the text for menus, input boxes etc. The client wants to add their translations and update them at any time.
Ideas I have looked at are:
Holding the translations in resource files, building an editor in to the web application and then adding attributes on the fly to my viewmodels.
Holding the translations in sql server so i have the name, language and translation as a lookup e.g. Home | French | Maison. Then on pre-render I'll scrape the screen for any controls needing translation in the menu, labels, text areas.
Does anyone know of any good examples or had the experience of doing this themselves.
I've a similar situation, and chose to store data in SQL.
Translation mistakes happen often, and you don't want to recompile or disassemble every time.
It is possible to avoid the need to republish, but I've found it just more intuitive and straightforward to maintain SQL.
Bottom line, it depends on the amount of data you have. If it's more than just a couple of keywords, it sounds like a job for SQL to me.
Edit:
In a similar question, users recommend using resources, claiming it is the standard method.
However, if your users are going to make changes to values on regular basis (not because of mistake correction, but because data actually changes), then SQL seems best fit for the job.
So, I need some input refactoring an asp.net (c#) application that is basically a framework for creating dynamic forms (any forms). From a high level point of view, there is a table that has the forms, and then there is a table that has all the form fields, where it is one to many between the two. There is a validation table, where each field can have multiple types of validation, and it is a one to many from the form fields table to the validation table.
So the issue is that this application has been sold as the be-all-end-all customizable solution to all the clients. So, the idea is whatever form they want, we can build it jsut using DB configurations. The thing is, that is not always possible, because there is complex relationship between the fields, and complex relationship between the forms themselves. Also, there is only once codebase, and this is for multiple clients - all of whom host it on their own. There is very specific logic for each of the clients, and they are ALL in the same codebase, with no real separation. Sometimes it was too difficult to make it generic, so there are instances where it has hard coded logic (as in if formID = XXX then do _). You can also have nested forms, as in, one set of fields on its own within each form.
So usually, when one client requests a change, we make the change and deploy it to that client - but then another client requests a different change, and we make the change and deploy it for THAT client, but the change from the earlier client breaks it, and its a headache trying to debug, because EVERYTHING is dynamic. There is no way we can rollback the earlier change, because then the other client would be screwed.
Its not done in a real 3-tier architecture - its a web site with references to a DB class, and a class library. There is business logic in the web site itself, in the class library, and the database stored procs (Validation is done in the stored procs).
I've been put in charge of re-organizing the whole thing, and these are my thoughts/questions:
I think this is a bad model in general, because one of the things I heard one of the developers say is that anytime any client makes a change, we should deploy to everybody - but that is not realistic, if we have say 20 clients - there will need to be regression testing on EVERYTHING, since we don't know the impact...
There are about 100 forms in total, and their is some similarity in them (not much). But I think the idea that a dynamic engine can solve ALL form requests was not realistic as well. Clients come up with the most weird requests. For example, they have this engine doing a regular data entry form AND a search form.
There is a lot of preserving state between pages, and it is all done using session variables, which is ok, except that it is not really tracked, and so sessions from the same user keep getting overwritten, and I think sessions should be got rid of.
Should I really just rewrite the whole thing? This app is about 3 years old, and there has been lots of testing and things done, and serious business logic implemented, so I hate to get rid of all that (joel's advice). But its really a mess of a sphagetti code, and everything takes forever to do, and things break all the time because of minor changes.
I've been reading Martin Fowlers "Refactoring" and Michael Feathers "working effectively with legacy code" - and they are good, but I feel they were written for an application that was 'slightly' better architected, where it is still a 3-tiered architecture, and there is 'some' resemblance of logic..
Thoughts/input anyone?
Oh, and "Help!"
My current project sounds like almost exactly the same product you're describing. Fortunately, I learned most of my hardest lessons on a former product, and so I was able to start my current project with a clean slate. You should probably read through my answer to this question, which describes my experiences, and the lessons I learned.
The main thing to focus on is the idea that you are building a product. If you can't find a way to implement a particular feature using your current product feature set, you need to spend some additional time thinking about how you could turn this custom one-off feature into a configurable feature that can benefit all (or at least many) of your clients.
So:
If you're referring to the model of being able to create a fully customizable form that makes client-specific code almost unnecessary, that model is perfectly valid and I have a maintainable working product with real, paying clients that can prove it. Regression testing is performed on specific features and configuration combinations, rather than a specific client implementation. The key pieces that make this possible are:
An administrative interface that is effective at disallowing problematic combinations of configuration options.
A rules engine that allows certain actions in the system to invoke customizable triggers and cause other actions to happen.
An Integration framework that allows data to be pulled from a variety of sources and pushed to a variety of sources in a configurable manner.
The option to inject custom code as a plugin when absolutely necessary.
Yes, clients come up with weird requests. It's usually worthwhile to suggest alternative solutions that will still solve the client's problem while still allowing your product to be robust and configurable for other clients. Sometimes you just have to push back. Other times you'll have to do what they say, but use wise architectural practices to minimize the impact this could have on other client code.
Minimize use of the session to track state. Each page should have enough information on it to track the current page's state. Information that needs to persist even if the user clicks "Back" and starts doing something else should be stored in a database. I have found it useful, however, to keep a sort of breadcrumb tree on the session, to track how users got to a specific place and where to take them back to when they finish. But the ID of the node they're actually on currently needs to be persisted on a page-by-page basis, and sent back with each request, so weird things don't happen when the user is browsing to different pages in different tabs.
Use incremental refactoring. You may end up re-writing the whole thing twice by the time you're done, or you may never really "finish" the refactoring. But in the meantime, everything will still work, and you'll have new features every so often. As a rule, rewriting the whole thing will take you several times as long as you think it will, so don't try to take the whole thing in a single bite.
I have a number of similar apps for building dynamic forms that I support.
There's a whole lot of things you could/could not do & you're right to think hard before throwing away 3 years of testing/development.
My input for you to consider is to implement a plug-in architecture on top of what you're got. Any custom code for a form goes in the plug-in & the name of this plug-in is stored with the form. When you generate a form, the correct plug-in is called to enhance the base functionality. that way you get to move all the custom code out of the existing library. It should also mean less breaking changes, each plug-in only affects the form it's attached to.
From that point it'll be easy to refactor the core engine as it's common functionality across all clients & forms.
Since your application seems to have become a big ball of mud, a complete (or an almost complete rewrite) might make sense.
You should also take into account new technologies like document-oriented databases (couchDB, MongoDB)
Most of the form definitions could probably fit pretty well in document-oriented databases. For exemple:
To define a customer form, you could use a document that looks like:
{Type:"FormDefinition",
EntityType: "Customer",
Fields: [
{FieldName:"CustomerName",
FieldType:"String",
Validations:[
{ValidationType:"Required"},
{ValidationType:"StringLength", Minimum:15, Maximum:50},
]},
...
{FieldName:"CustomerType",
FieldType:"Dropdown",
PossibleValues: ["Standard", "Valued", "Gold"],
DefaultValue: ["Standard"]
Validations:[
{ValidationType:"Required"},
{
ValidationType:"Custom",
ValidationClass:"MySystem.CustomerName.CustomValidations.CustomerStatus"
}
]},
...
]
};
With this kind of document to define your forms, you could easily add forms and validations which are customer specific.
You could easily add subforms using a fieldtype of SubForm or whatever.
You could define FieldTypes for all common types of fields like e-mail, phone numbers, address, etc.
namespace System.CustomerName.CustomValidations {
class CustomerStatus: IValidator {
private FormContext form;
private List<ValidationErrors> validationErrors;
CustomerStatus(FormContext fc) {
this.validationErrors = new List<ValidationErrors>();
this.form = fc;
}
public List<ValidationErrors> Validate() {
if (this.formContext.Fields["CustomerType"] == "Gold" && Int.Parse(this.form.Fields["OrderCount"]) < 10) {
this.validationErrors.Add(new ValidationError("A gold customer must have at least 10 orders"))
}
if (this.formContext.Fields["CustomerType"] == "Valued" && Int.Parse(this.form.Fields["OrderCount"]) < 5) {
this.validationErrors.Add(new ValidationError("A valued customer must have at least 5 orders"))
}
return this.validationErrors;
}
}
}
A record of a document with that definition could look like this:
{Type:"Record",
EntityType: "Customer",
Fields: [
{FieldName:"CustomerName", Value:"ABC Corp.",
{FieldName:"CustomerType", Value:"Gold",
...
]
};
Sure, this solution is a lot of work, but if/when realized it could be really easy to create/update/customize forms.
This is a common but (IMO) somewhat naive design approach. "Instead of solving the customer's problem, let's build a tool to let them solve their own problems!". But the reality is, that generally customers want YOU to solve their ACTUAL problems. So build things that solve their problems.
If you can architect it in a way that allows you to reuse some parts for different customers, fine. But that is generally what the frameworks have done for you already - work out the common features that applications need and make them available in neat packages.
We have a client who is currently using Lotus Notes/Domino as their content management system and web server. For many reasons, we are recommending they sunset their Notes/Domino implementation and transition onto a more modern platform--such as Drupal.
The client has several web applications which would be a natural fit for Drupal. However, I am unsure of the best way to implement one of the web applications in Drupal. I am running into a knowledge barrier and wondered if any of you could fill in the gaps.
Situation
The client has a Lotus Domino application which serves as a front-end for querying a large DB2 data store and returning a result set (generally in table form) to a user via the web. The web application provides access to approximately 100 pre-defined queries--50 of which are public and 50 of which are secured. Most of the queries accept some set of user selected parameters as input. The output of the queries is typically returned to users in a list (table) format. A limited number of result sets allow drill-down through the HTML table into detail records.
The query parameters often involve database queries themselves. For example, a single query may pull a list of company divisions into a drop-down. Once a division is selected, second drop-down with the departments from that division is populated--but perhaps only departments which meet some special criteria--such as those having taken a loss within a specific time frame. Most queries have 2-4 parameters with the average probably being 3.
The application involves no data entry. None of the back-end data is ever modified by the web application. All access is purely based around querying data and viewing results.
The queries change relatively infrequently, and the current system has been in place for approximately 10 years. There may be 10-20 query additions, modifications, or other changes in a given year. The client simply desires to change the presentation platform but absolutely does not want to re-do the 100 database queries.
Once the project is implemented, the client wants their staff to take over and manage future changes. The client's staff have no background in Drupal or PHP but are somewhat willing to learn as necessary.
How would you transition this into Drupal? My major knowledge void relates to how we would manage the query parameters and access the queries themselves. Here are a few specific questions but feel free to chime in on any issue related to this implementation.
Would we have to build 100 forms by hand--with each form containing the parameters for a given query? If so, how would we do this?
Approximately how long would it take to build/configure each of these forms?
Is there a better way than manually building 100 forms? (I understand using CCK to enter data into custom content types but since we aren't adding any nodes, I am a little stuck as to how this might work.)
Would it be possible for the internal staff to learn to create these query parameter forms--even if they are unfamiliar with Drupal today? Would they be required to do any PHP programming?
How would we take the query parameters from a form and execute a query against DB2? Would this require a custom module? If so, would it require one module total or one module per query? (Note: There is apparently a DB2 driver available for Drupal. See http://groups.drupal.org/node/5511.)
Note: I am not looking for CMS recommendations other than Drupal as Drupal nicely fits all of the client's other requirements, and I hope to help them standardize on a single platform.
Any assistance you can provide would be helpful. Thank you in advance for your help!
Have a look at the Data module - it might be able to get you a long way towards a solution.
The biggest problem you are likely to have is connecting to the DB2 server through Drupal since it's DBA layer doesn't support it without patches (as you've discovered).
A couple things come to mind.
You can use Table Wizard to expose any custom tables to views. Views basically gives you a UI for writing custom sql queries. Once your tables are exposed to views you can use filters to "parameterize" the query. Also, views supports many display options including tables and pagers.
If you do need to write your own forms for advanced queries, take a look at the Drupal Form API which makes creating custom php forms a peice of cake.
Views is fairly easy to learn and, in my experience, most clients pick it up quickly. It really depends on the complexity of the query.
Form API should be easy for a developer to pick up, but does require a basic knowledge of php and writing Drupal code.
Does Lotus provide a web service to query it? If so, you can easily do this using a custom form (in your own module) and use Services module to query the data.
I've been looking into ASP.NET Dynamic Data and how it does scaffolding and routing. I've only scratched the surface, but it's looking like I'd have to create a template for each table that I didn't want to display all columns the same way.
My first impression after looking at dynamic data is that it would seem like less time on the programmer to have to edit one-time generated user controls rather than build a template for each table that doesn't have a uniform display behavior.
What proven solutions are people currently using that help ease the laborious tasks of creating ASP.NET CRUD type user controls?
Thanks
In ASP.NET webforms we use CodeSmith. From a single entity we generate admin pages, codebehinds, service layers, data layers and db stored procedures. All in a matter of seconds. I'd recommend you check it our for quickly building the crud in your apps.
We're actually working on our own code generation tool. It has already proven to work perfectly on the lower layers and now we're on the way to extend it for the presentation layer, that is for generating user controls.
I've not looked into dynamic data (although I'd like to when I have some time) but my biggest fear is always to lose flexibility. The problem is that these front-ends are then maybe generated dynamically each time based on some template and editing, especially bringing in special customer wishes becomes quite difficult. For small standard apps it may work perfectly though.
What we're therefore doing is to "generate" these usercontrols based on a set of standard custom server controls we've developed, but we'll generate just the first time from some static information about the entities in our application. Then you can continue customizing.
Such systems should help the developer, improving his development speed, doing the initial awkward work but then they should give him the flexibility to modify till the maximum. They should not add additional complexity...
I used .netTiers CodeSmith templates long time ago (years) and it was proven so strong, so, it must be more than great now.
I know a (big) company who have built a customization engine (allowing GUI for internal company options) around those templates to use them in most of their applications and were so successful.
I've used http://www.ironspeed.com/ in the past which has been great. Saved us MONTHS of time on our last project which has a big DB, so the cost is worth it. But it looks a bit ugly and can be tricky to update the DB schema once you've generated.
Obviously not much widespread use out there other than whats provided in Visual Studio.
Have a look at Blinq.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Visual studio is pretty good but doesn't create stored procedures automatically. Iron Speed designer does supposedly. But is it any good?
I have used Ironspeed extensively for the past two years for most of our ASP.NET forms over data projects.
It works. Does several things well: stored procs, fast layout of table browse and CRUD screens, fast layout of single record CRUD screens. It manages the round-trip (or half-round trip) process decently, detecting changes in your back end db schema and updating its data access layer, then making the changed columns available for you to alter your UI (in record or table control panels). ISD (as they call it) does an excellent job in making security management for your app pretty painless, even down to the control level (if you use ISD's subclassed versions of asp.net controls). Final plus, not a small one, is the CSS-based theme control (easy to change to a variety of themes, easy to customize a particular theme, and not even too bad to build your own theme variant by forking an existing one you like). Depending upon whether you let ISD create your stored procs in the code base or the database, changing DB's at run time can be a piece of cake.
Fairly active forum with a core group of helpful contributors. You can probably avoid the paid tech support through the forum.
Okay, the down sides. Creates fairly large code conglomerations, being a three tiered architecture. As Galwegian says, like any framework, you've got the velvet handcuffs (get your mind out of the gutter if you are thinking about anything other than code limitations and conventions!). The velvet handcuffs are the page and control model, the data layer, lack of a business object/class capability per se, the postback model, and the temptation to make your user GUI look like THEIR user GUI that comes out of the box because it is so darned easy and convenient.
ISD builds a basic page by combining an HTML template (in to which you place ISD specific code generation tags and any other tags, etc., you which using the ISD GUI or by hand). The page model relies upon a code behind page created from a piece of code template. The base classes are almost completely overridable, so that you can override all of the default functions, regenerate the application and not lose your overrides. The database controls live in the page container, but have their own class definitions (i.e., their code-behind) in specific /app_code files. Again, each control type has its own base class with pretty completely overridable methods. A single record control (showing a single db record) is pretty simple. A table, showing several records, has a table class and a table row class. The ISD website (www.ironspeed.com/support) has good documentation of the ISD model as a whole.
So, where are the problems in this model?
1. Easy and tempting to live with their out of the box GUI. Point ISD at your database, pick the tables you want to have it turn in to pages, tell it the kinds of pages, give it a thematic style and five minutes later you're viewing the application. Cool. But, it is very easy to forget that their user GUI is probably not what your user wants to see. So, be prepared to think for yourself and tinker with the GUI thus created. Not hard to do, and you can use VS 2005 to help you.
Business objects. You could put together your own business objects, but it would be difficult and you would get no help from ISD. ISD does a LOT of building of simple validation and checking (appropriate look up values, ranges, lengths, etc.) ISD lets you build custom queries, but these are read-only. It is smart enough (and you can override the write from a page in any case) to let you take a one to many view and write it back to the database (you'd probably override the default base method, but it isn't that hard to do). However, when you get in to serious dependency checking, ISD is still really about tables and not business objects. So, you're going to write some code.
If you are smart, you'll write it once store it in app_code somewhere and use it by calling it from an overridden method in your table or record controls. If you are like most of us, you'll first spaghetti it in to one of the code-behind classes above, and then forget you did so, or have a copy in each of the 10 pages that manipulates customer data. In my world, that has usually meant 5 identical functions and 5 that are all different (even though they are all supposed to be the same). ISD makes it tempting to order marinara, because the model lends itself to spaghetti code. Of course, you can completely prevent this, but you gotta learn the ISD model to determine the best way to do it on your project.
Page state and postbacks. Although ISD is quite open about this problem and tells users not to just take the defaults of returning the whole asp.net page state in the postback stream (cache on the server instead), the default is to return the whole page. Can make for some BIG pages. Which makes users think S L O W. As I said, you can manipulate this. But, what newbie is going to get this when it is SO tempting to just point, click, and boom - instant application. Your manager is now off your back because her product inventory table is "on the web" with a cool search and edit GUI (of 400kb state pages if you've gone a bit nuts and have just taken the default behaviors of ISD). Great in-house, but the customers in the real world....
Again, knowledge is the key. You can fix this, but you need to know you SHOULD.
Database read/write postbacks. No big problem here, but you also need to know that the model is to fetch only the data used at the moment. If your table shows 1000 records in 50 record increments, when you go from records 1 to 50 to 51 through 100, you will postback and hit the database again. This keeps data current, but increases server traffic.
Overall: Try the demo version. Point it at something simple that you really want to turn in to an asp.net application. Build maybe three tables. Then dissect it using the above as a guide. See what YOU think and post back to this question.
I have used it for convenience for a very small project. It did what I wanted and saved me a couple of days work.
The main problem I found was when it came to customising or extending the generated project. You have to spend quite a bit of time trying to understand Ironspeed's way of doing things which, I'll admit, is not my way.
I'd use it again for a small project if I knew in advance I wouldn't have to customise it much after.
If stored procedure generation is all you are after, CodeSmith is a decent option at a fraction of the cost of IronSpeed. There are several sproc templates available, and you can create your own or tweak an existing if that is what you need. You can also gen .Net code to your hearts content with CodeSmith. Tons of business class templates already exist for this.
IronSpeed's value is not in the sproc generation, but in the RAD features. I agree with #Galwegian... IronSpeed is OK for mock ups or very simple apps, not so good at all if you need to do any customization.
You may want to check out Evolutility CRUD framework. It provides some of the same features (limited to CRUD) and is open source.
IronSpeed has been great (out-of-the-box) at helping me develop data-driven corporate Intranet applications. While the code model takes a little getting used to, it is effective at maintaining a nice three-tier app. While the page templates can appear garish compared to 2010's web-design, it gets the job done, when you need function over form.
Iron Speed Designer is great for simple CRUD type web applications. You can find some useful information on our web site http://www.dotnetarchitect.co.uk/