Why not? I was just thinking about yesterday's post and had one of those disturbing thoughts that I get when I want to make software do something that its authors didn't intend (well, maybe, sorta, kinda).
Let's say I want to create multiple forms per "entity" (note the quotes). One way I might do this is to define a set of "like" entities in the metadata all pointing at the same physical location. I'd have to jury-rig the relationships a bit so the platform knew how to traverse them during create and update requests, but that's not really necessary.
If I were going to do this, what would I do? I'd define several entities that all mapped to a single, all-encompassing (data-wise) entity, I'd hide the super entity using roles and privileges because we don't want anybody messing with all that data (for some reason Steve Martin saying "you could melt all this stuff" pops into my head right about now… I don't know why), and then I'd configure-up all the forms for the shadow entities. Finally, I'd rename all the shadow entities so they show up, more or less, in the application. Then, and here's where the per-role stuff comes in, define roles for each entity.
In theory you should have different role-based views over the same set of data. Just a thought.
Update 13:45PDT - If I were really going to do this I'd just copy all of metadata for the source entity to the destination entities. There's no reason to go through the pain of actually creating the physical tables. That's why CRM is metadata-driven - so you can define things declaratively and the system will do the rest.
I while back I mentioned in the CRM newsgroups that it was possible to create multiple relationships between two entities. For the most part this is true, but there are some hoops to jump through and each of those hoops is ringed in fire. More specifically, using this approach to solve the "many relationships" problem will plant you squarely in unsupported, probably-can't-upgrade, land.
The problem I'm talking about is where you have a single parent entity - the 1-side, and you want more than 1 1:M relationship from that parent entity (let's call it P) to a child entity (smartly named C). Let's try an example. Say we have a Course that has an Author and an Instructor. Now, ignoring for a moment that CRM can't deal with additional party types and won't allow multiple relationships to SystemUser, we'll call Author and Instructor simply views over the same set of data. That is, they are the same entity with different roles.
In CRM v3.0 you'd implement this by creating the three entities, setting up the Course-Author and Course-Instructor relationship, hiding the Instructor entity, and writing a callout to keep the Author and Instructor data in sync. That'll work and keep you supported. There are a few caveats that will cause some serious grief: you can't use the quick create functionality from an Instructor lookup, you need to keep the security consistent, and you can't completely hide the Instructor type as a separate type.
Well, there is a way around this. It's a hack but it's been successfully hacked for some internal development deployments. Create the three entities as you normally would but keep the child entities Instructor and Author "empty". Set up the relationships using the configuration tools. You now have three entities with two relationships much like you had in the supported approach. Now, customize both Author and Instructor in identical ways by adding all the attributes that the type needs. When you're done you'll end up with two identical entities pointing at two different database structures. You're still in supported land.
Do not add any instance data to either Author or Instructor yet.
Next, change all the display attributes for the Instructor entity so that it looks like an Author (this really isn't necessary and might make sense usage-wise if you treat them as different). Ready to jump into unsupported territory? Open the metadata database and find the Instructor entity (let's assume that Author is the primary view) in the Entity table. You'll see a few columns that describe physical table mappings for the core and extension tables. Change the table names to reflect that the Instructor entity should instead point at the Author tables. You'll want to make a few modifications to the Instructor attributes as well so that they reflect the underlying physical Author attributes (I think the primary key in the base and extension table is the only attribute you need to really worry about).
Now, every time you add an Instructor or Author the data ends up in the same physical table. That means that any query over either entity will return the same set of data. So, your lookup control from Course to Author will present the same physical data as Course to Instructor. As far as CRM is concerned you have two different entities with two different relationships. You end up with copies of all the web service methods and the schemas will look nearly the same (their logical views will reflect the as-configured names, not the physical names). But, at a physical level you only have one copy of the data that you look at and edit, there are no synchronization issues, and there's no tricky callout code to handle multi-master updates.
I might have missed a few steps here because I'm doing this from memory and not on a live CRM installation. If you find that some of the steps seem incorrect (missing, out of order, unnecessary) then post a comment here so everyone gets a chance to learn along with you.
Let's forget for a moment the weird ad-based revenue models that don't make sense for a software development company. Let's focus instead on how we create value for our existing customers using applications that they've already invested in. Let's focus on how we rely on and extend our core competencies to create products and services that customers will purchase. Let's focus on creating a community experience for our partners such that they see a clear revenue model for themselves.
Let's move away from selling a platform to selling an extensible, configurable, and customizable business application suite. Let's put the customer and partner first, after all they generate the revenue for MBS by purchasing or extending our products. Let's make our customers' businesses run better on Microsoft software.
There are four software models available to MBS and its customers:
Notice that nowhere in the list is ad-based revenue mentioned. The reason is simple: business application users have a goal in mind when they use their productivity software (and yes, LOB applications are productivity applications too). They want a simple, uncluttered, role- and task-oriented experience.
It should come as no surprise that MBS has many applications which use one or more of the above models. The user experience varies greatly across the products. The IT experience varies greatly across the product. Far worse for Microsoft is that the partner experience varies in such a way that customization skills are not transferrable across applications.
Things we need:
This sucks. That's all I can say. I know my blog isn't that widely read, and I don't mind that. But damn it all if the spammers give a rip. Somehow they found my blog and as a result I got slammed this morning with crap spam comments. I can deal with the clean-up and approval and I don't think actual subscribers should have to even see spam. So, for now, I'm going to turn on comment moderation. Hopefully the Community Server team over at Telligent and our internal MSDN blog support group can tighten the filters.
What is it about graffiti and spam that's so exciting? I don't get it.
Today, after 8 quarters (2¾ years if you're counting), I went to school and did something "fun": I picked up my cap, gown, and hood. It's been a very long time since I last did that. The last time I went through two schools (not because I got kicked out of one, but because the partying was so serious that I didn't think I'd ever get anything done), studied about seven years, suffered through two years of "liberal arts" requirements (German Feminist Film Studies anyone?), and was put on probation three times. Let's just say I wasn't a great student the first time 'round.
This time things were a little different. I didn't get put on probation and didn't have any grade issues (this time I pulled a 4.0). I think a few things went into this one. I wasn't working first and going to school second (or third, or fourth). I was working and I was going to school in equal parts, but I think I've learned a lot more about time management and that made a ton of difference. Time management the first time was wondering how I could trick physics into sneaking in at least one additional hour each day. This time I was simply looking at the workload and making time to do things.
The last three quarters were interesting to say the least. Fall quarter I took a third class (the normal workload is two classes because the school expects about 3 outside hours per week per class and "working professionals" don't have much more time than that) that I hadn't planned on taking. But, through the past year, I've worked on some pretty cool things for my thesis. In essence I kick-started a process that, for the second time in as many years, revamped the program's curriculum. The outcome was a bunch of new courses, a new way to structure those courses, a set of "rules" for teaching them, and co-authoring of a paper just submitted to IEEE.
When that paper is published, assuming it makes it through the peer-review process, I'll post a link to it. There aren't too many people interested reading something titled "Integrating Academia and Industry Best Practices in Designing a Software Engineering Curriculum". But, somebody might want to read it.
Anyway, thanks for reading…